Node code freeze on Loraserver


Curious if anyone has seen issue like bellow.
I know it’s most probably not LoraServer side… but I’ve found something that quite weird and would like to share…

My node code was freezing after sending a few messages. 8 to be exact. I got uplink and downlink from the server and everything is well… but freeze after 8 message. just at mac_tx.

Manufacturer found small issue in their code and sent me a updated code release.
I got now 16 messages… then freeze. I’ll see with them next week what’s up with that…

but here is the weird issue.

I’m currently installing a second gateway home as a bridge… so it was not completely setup yet…
I just pluged the node to test and left it run in the background while setuping the new bridge, …

and the node code is not freezing if it’s not connected to a gateway !! :open_mouth:
I’m using abp, no frame counter, on the 915mhz…

anyone has ideas on why this is happening ? (other than the code base being incorrect ?)


can you please let me know what is the intended behavior of a node/gateway if the frame counter do not match ?

Should ‘Gateway live lorawan frame log’ should display uplink indefinitely ? (*and not transfer the data to the node live log)

after activating the frame counter my node code still freeze after reaching the exact frame counter seen in device activation tab of the specific node.

I think I’m almost done finding my problem but I need little help. node manufacturer tested my code on a different gateway / server and it’s proven to work. we are almost sure it’s related to frame counter or some sort of configuration.

The live LoRaWAN frame-log will display all received LoRaWAN frames by that device, without validation of correctness. The same tab but then under devices will only show frames that valid for that device and thus pass all validations.

At what exact frame-counter does the device freeze?

The LoRaWAN specification describes how a device should behave when the frame-counter is not as expected:

the frame are getting higher on each test.
that makes me really think I should focus on the frame counter part.

right now loraserver has 81 frames count(in the device activation tab)…
resetting the node, it will send messages until it reach 16 more messages than the last time.
FTDI console stoped at 96.
refreshed the page node/device activation… I’m now at 97 uplinks… device is frozen.

*before sending my reply I did it again…
started at 97 on server, sent message until console showed 112… frozen.


to do those test, I’ve checked the ‘disable frame-counter validation’ on the device configuration tab. however, it’s still un checked on ‘device activation’ tab… now I’m not sure it’s really activated or not.
to reset a frame counter device, should I re-create a new device with same addresses or edit in database ?

and see after refresh;


I was reading
looks like my device might have same issue as microchip.

I’m trying as we speak to run node with ADR disabled internally and it looks great… got way more than 16 messages ! :slight_smile:

is loraserver currently forcing ADR ? witch could be crashing mac_tx…

reading ;
I’m curious if the impact on battery saving is considerable and worth the trouble fixing…
current project should leave the node sleeping and only sending a message per day.

If your device has adr: true on uplink, then LoRa Server will control the data-rate through ADR (given it hasn’t been disabled in the configuration).

Thanks for the note.

do you think it be the cause for my previous crashes ? at mac_tx…
I still don’t get why it was crashing completely if enabled adr: true in the node
can’t see if it’s really a big loss not to have the feature enabled for static nodes.?!