LoRaWAN frame counters (fCnt) setters

[giam]

Re: Frame counter "fCnt" variable or setter function in LoPy

Re: LoRaWAN Sequence Numbers

As per the above topics, when using ABP it is necessary to persist the frame counters.

As of now, the only possibility is to persist the current state (lora.nvram_save()) and restore it (lora.nvram_restore()).

Now, to make sure that after an unexpected power-cycle counters are restored, you would have to nvram_save() after every frame sent, but that would very quickly wear the flash memory.

A better approach would be to persist every N (say 50 or 100) frames, but adding N to the persisted counter or, at boot, setting the counter to the saved value + N.
This would assure a valid frame counter upon restart, without wearing the flash so quickly.

Unfortunately though, with the current API, this is not possible.

Would it be possible to add setters for uplink/downlink frame counters and maybe functions to separately persist/restore the different parameters of the LoRaWAN state?

Thanks!

[jcaron]

@giam nvram_save uses wear-levelling methods to avoid any issues with flash. You should be able to use it after each frame sent.

Skipping frame numbers will cause issues with packet loss stats and ADR. And you would need to persist when to save your counter anyway.

[giam]

@jcaron Thanks for the response!

nvram_save uses wear-levelling methods to avoid any issues with flash. You should be able to use it after each frame sent.

Do you have any reference about this? "should" is not enough :)

And you would need to persist when to save your counter anyway.

Yes, but N times less...

Thanks!

[jcaron]

@giam said in LoRaWAN frame counters (fCnt) setters:

@jcaron Thanks for the response!

nvram_save uses wear-levelling methods to avoid any issues with flash. You should be able to use it after each frame sent.

Do you have any reference about this? "should" is not enough :)

This has been discussed in the forum before. You can also check the source of the nvs functions if you’re interested.

And you would need to persist when to save your counter anyway.

Yes, but N times less...

I don’t follow. How would you know how many times are left before N cycles have happened?

[giam]

@jcaron I'll check the source...

I'm not sure I understand your question. If you persist the counter not every time you send, but every N times you send, you will write N times less.

[jcaron]

@giam Unless I missed something, you would still need to know how many times you've awoken and sent a packet since the last time you saved the frame counter. You're basically replacing one counter with another.

Basically, you're replacing:

• wake up
• restore LoRa state
• do whatever you need to do
• send LoRa packet
• save Lora state
• go to sleep

With:

• wake up
• load counter
• do whatever you need to do
• send LoRa packet
• increment counter
• if counter == N then save LoRa state and reset counter
• save counter
• go to sleep

It adds a lot of complexity, and I don't see what it actually saves. Did I miss something?

[giam]

@jcaron In my case I don't go to sleep. Power-cycles are only exceptional cases, otherwise, of course, the whole logic of saving counter+N would not make sense