Where in LMiC is the "fCnt" parameter stored?

hello,
I want to use my ABP node as a GPS tracker in a car, powered from 12V car socket. But if I stop the engine, the voltage from socket will also disappear. So then the node is resetted too. After next start, the “fCnt” parameter (on server side) is set to “0”, but server awaits last fCnt value + 1. Then there are no data transmitted…

Anoyne knows, where in LMiC is the “fCnt” parameter stored? So then I can store it to my MCU’s eeprom and after reset use it again.
Or is there another solution how to solve this node-after-reset problem?

Thanks,
Y.

If you want to take care of loading and saving it yourself have a look here. It’s the LMIC.seqnoUp field.

Depending on the LoRaWAN chip you use, you might want to use a different solution and let the LoRaWAN chip itself store its counter. On the RN2483 for instance if you send it a “mac save” command after each transmission, the chip will save the counter and load it automatically after a restart.

Be careful because it is not the only parameter to save, you also might also have to save current SF, frequency, …
Maybe the best way to do it is to use OTAA as fcnt is reseted each join request :wink:

Also, you can use the --relax-fcnt option when declaring your device to TTN, it will allow reset of uplink frame counter :wink:

thanks, the eeprom trick works fine.
Have you tried what will happen when LMIC.seqnoUp value exceeds integer range?

EEPROMs usually have limited write cycles and the datasheet for both Arduinos and the PIC18LF46K22 micros inside the RN2483 module lists 100,000 erase/write cycles.

This means if you’re sending 5 messages/hour every day and recording to EEPROM every time you’ll potentially kill the EEPROM in about 2 years.

Maybe not a huge concern, just something to keep in mind.

1 Like

Hi, do you know which fields one has to save? I currently cannot receive my sent data after wake up although I see it in the Gateway’s traffic view. So the data must be dropped by TTN.

1 Like

Maybe not a life-changing discovery, but if you only write the EEPROM when the data has actually changed by first reading it, you get to reduce the number of writes significantly !