ABP Frame Counter slow writing?

[fuma01]

Hello, First thanks for the great work to this firmware. It fixes my problem with MKR13x0 Boards and resetting frame counters at board restart. (I run in ABP mode, with TPL5100 timer with battery in field, restarting the board every hour to make measurements and send the values to TTN).

Now I noticed, that it needs about 3 seconds after sending a message to store the frame counters to EEPROM. so if I shut down the MKR node to early after sending, the FCU is not inreasing at the board and the ttn gateway does not forward the message to the application. The screenshot (Live data from TTN gateway) shows the behavior of the node with dev. address ending with "13 8B": at time 13:12 i set the delay(5000) between message send and shutdown - it works, FCU is increasing. at time 13:14 i set the delay only 2 seconds - the FCU at the board doesn not increasing and hence it is not working. at time 13:17 I set the delay to 3 seconds - it seems to be sufficient.

Is it possible to speed up the writing process? The measurement and sending message takes about 5 seconds - so 3 seconds delay after sending to store the FCU is a lot and increases battery consumption by factor 1.6.

[janakj]

Hello,

Thanks for reporting this. Would you mind elaborating on what you mean by shutting down the node? Does that involve powering off the LoRaWAN modem? In other words, does the LoRaWAN modem lose the memory contents when you shut down your node?

Jan

[fuma01]

Hello Jan, With "shutting down" the node i mean to power off the MKRWAN1300 (as TTN node). I am using TPL5110 (timer) for low-power management. First the timer gives 5V to the node (VIN). Hence, the node power on, makes measurements and sends the values to TTN network (takes about 5 seconds). At the end of the program the node gives a signal to the TPL5110 timer to safely turn off the power (VIN = 0V at node). One hour later the timer wakes up and power on the node again. in the meantime (during the node is switched off) the timer runs with very low power (I can't see big difference to self-discharge of battery).

With the orignal MKRWAN firmware I had the problem, that the frame counter is always starting at zero after turn power on. That behavior is not supported well by TTN (Frame Counter Reset at MAC settings did not work properly). And i do not want to make OTAA every time after power on. After flashing firmware of the node with "lora-modem" the framecounter ist stored somehow (I think in modems EEPROM), even after turn power off and on. - but, only, when I am waiting 3 seconds after sending the message.

I use MKRWAN.h library for sending a message with following code (short version): modem.begin(EU868) modem.joinABP(devAddr, nwkSKey, appSKey) modem.setPort(4); modem.dataRate(5); modem.setADR(false); modem.beginPacket(); modem.write(data, dataSize); err = modem.endPacket(false); delay(3000); //waiting for frame counter digitalWrite(donePin, HIGH); //signal to TPL5110 to power off

I mean for me 3s would be ok. But I was wondering about that behavior. It came out, because frame counters increased by power the node at USB port and not when power off by the timer.

[janakj]

I will take a look at it. I am not sure if I can speed things up. This functionality is controlled by the embedded LoRaMac-node library which determines when to save the crypto state (which the FCnt counter is part of) to NVM. It could be that it is waiting for some LoRaWAN-related timers to fire.

One potential work-around might be to implement an asynchronous notification sent from the modem to the host to indicate that the modem is idle, i.e., that there are no more pending tasks, including unsaved NVM data.

By the way, the LoRaMac-node library this firmware uses has not been designed for this kind of power-on power-off operation. It keeps a lot of data in RAM and not all of it is saved to NVM. Most of it can be recovered after the RAM contents has been lost, but probably not all, depending on what state your device and your network are in. It is generally recommended to operate such devices in an OTAA mode with periodic JOINs, for example, if it has not heard from the network for a while.