Save and restore frame counters

[jpmeijers]

Never firmware versions of the RN2483 has the following commands:

• mac set upctr
• mac get upctr
• mac set dnctr
• mac get dnctr

We need to check if the firmware is newer than 1.0.0, OR check if these get commands return a valid value.

In the case where we can get the counters:

• at startup we need to save the up and down frame counters,
• then do the normal reset, which will reset these counter too,
• after which we should restore them.

This should only be necessary when doing an ABP join.

[jpmeijers]

Datasheet for reference: http://ww1.microchip.com/downloads/en/DeviceDoc/40001784E.pdf

We do need to keep backwards compatibility for modules with older firmware versions.

[Alex9779]

I know this is rather old but IMHO this could be closed.
I don't think handling of this is needed as those commands came with version 1.0.0, just 0.9.5 has them not and as that is a firmware which should not be used as I read between the lines I think someone using this and having a device with that firmware should update.
Also the counters are handled in the module properly if you do a "mac save" after a transmission (is this lib doind this acutally?) and so surviving resets and power cycles. They get automatically reset when re-joining a network by OTAA.

[TD-er]

Performing a mac save on every tx is probably wearing out the flash.
What you can do, is save it every N messages and when you are unsure about the value, just add N to the last saved value.
For example after a power cycle or when the counter you read is exactly a multiple of N (and you are sure you must have sent something)
I think N=1000 is roughly the max you can use.

[Alex9779]

Yeah well maybe we should keep track of that in the MCU and so need methods to read and set so in a case where you have to reset the module, without powering down the whole system the MCU can publish its know value to the module again.
The real problem is error cases, yes. But the device actually cannot know what the counter should be and really reinitialize it would be to re-join by OTAA. ABP is not a real join where data is exchanged between the node and the network.
But from my experience if the counter is higher than what TTN or ChirpStack has for that device it still accepts the packet. A packet loss can always happen, but if it is lower the networks rejects, that's proved.

[TD-er]

That's why I suggest to add N to the counter value when in doubt.
So the simple check can be to read the counter value before performing a TX.
If it is a multiple of N, call a save and perform the TX.
This way, if you power up and the counter is a multiple of N, you know for sure the counter is not correct and then you can add (N-1) to the stored value, set it and continue the usual procedure.

[Alex9779]

Hmmmm but how big should N be?
This method has to be bundled with some kind of regular "mac save", no idea what a reasonable interval would be.
Let's say we keep track of the counter in the MCU too persistent, we save the values in the MCU when we do a "mac save" on the module.
Then the module works and the counter increases and so differs from our stored value. So if something unpredictable happens and we restart the whole system or just one part and the counters are equal we have to add N to the counter according to the predicted possible increase set by the interval we chose to do a save.

[Alex9779]

Ahhh sorry you outlined it already, got confused, maybe we stick to this issue to discuss and not the PR...

[TD-er]

That's why I suggest to use "N-1" to add to the counter.
Let's assume N = 10.
If you boot the module and the counter is a multiple of 10, you know your module loaded the last saved mac state.
But you only call mac save when you plan to send data and the counter is a multiple of 10 before calling tx.

Thus the regular steps for sending are:

1. Check counter
2. If (counter % N == 0 && counter != 0) Call mac save
3. Call mac tx => counter increases

Now the boot-up scenario:

Check counter

1. If (counter % N == 0 && counter != 0) Set counter value to (counter + N - 1)
2. Proceed with normal steps when sending.

This way you don't need to keep track of the counter on the MCU as you can be sure it will never send out messages with the same counter.
One problem is when the RN + MCU crash when the counter is a multiple of N, then you may add (N-1) where it is not needed.

Another problem is when your setup crashes between mac save and completing TX.
But maybe you can do some clever things based on combining up and down counters.