Keep in mind the eeprom used to save the values in the RN module might be first to go due to the write limit of eeprom cells…
Good point. I am not using a PIC with EEPROM (didnt realise this at first) so I only have two bytes that survive the reset by XLP every 10 seconds. I use these to count how many resets there have been and send a value every 15 minutes (90 x 10 seconds). I’m probably going to use Flash to store the capacitor calibration values every time the counter rolls over - they say it is good for 10000 writes or 20 years - probably very sceptical of me, but by then I probably wont remember what I made ! (I’m already 60!).
Don’t you also need to store the frame counters?
Yes - I thought so too, but up until now my testing all seems to be working ok. I don’t really understand why. I didn’t expect the Radio to store them over a power loss - I am probably missing something…
Just to prevent laughter I just checked that frame counter checks are enabled, and they are. Bit of a mystery ?
Are you calling mac save each time now?
No. At the moment I do an OTAA join after programming the device. After this I send an initial value and then I do a mac save. After doing this the radio is switched off and the PIC goes to (XLP) sleep discharging a small capacitor. When it wakes up I check if the low-power-surviving register is at a multiple of 90. If it is is, I do a mac join abp and send a value. In all cases I then increment the register and go back to sleep. I feel lazy just talking about this, I should check it out and come up with an answer to what is going on - tomorrow I’m afraid !
And just to be sure: are the counters increasing in TTN Console…?
Yes, that is going ok. One strange thing is that it seems to be the case that the first transmit after the ‘mac join abp’ doesn’t get through, although I get an ‘mac_tx_ok’ back from the radio. If I then transmit a second time,it works and the counter increments as expected in the console. I will try to figure out what is happening exactly. Perhaps when I understand it I can confirm the behaviour with a mail to Microchip, then I can be certain.
…again just to be sure: the counters are not zero after each mac join abp, right? So, it’s an ever increasing number in TTN Console?
Still worried I’m missing something, but yes, its couting up fine - if you start teamviewer you can have a look if you like ?
Actually my first point about the first transmission not working is incorrect - it does. I think I was testing too fast and getting blocked in some way. If I wait a minute between actions it all works first time round.
I believe you 
If you’re in doubt it’s really powered off, then maybe you can try without the mac join abp…?
Already did - and it fails. I will try to get to the bottom of this and let you know, now its time for my low power mode to kick in, the alarm goes at 6.00 tomorrow morning 
1 Like
FYI … in my experience with the RN2903, mac join abp always succeeds. I’m not sure anything gets sent by the radio at all.
One last thought: in the article from Microchip they imply that ‘the network’ doesnt see the difference in the situation before and after the power break on the RN2483. Is it possible that the gateway which I am talking to somehow ‘remembers’ my frame count and increments it for me ? - I have no knowledge of the gateway software or how precisly the frame counter logic works.
It doesnt indeed, but if you have zeroed the security keys before doing the OTAA join and then have done a transmit and a ‘mac save’ the ‘mac join abp’ instructs the radio to transmit using the encryption keys that were generated during the OTAA join in the first place. In this way the network thinks you are just doing another transmission. Have a look in the article at the link I posted, I didnt understand it at first, the ‘0000000’ values are really important, without this the whole idea doesnt work.
No. Gateways are dumb and just forward what they receive. Also, multiple gateways might receive the same transmission.
If you have access to gateway logs (like the Traffic page of a gateway in TTN Console) then you can see the raw packet, which you can paste into https://runkit.io/avbentem/lorawan-packet-decoder/branches/master to see that the uplink counter is really part of the message. (It’s in the non-encrypted part of the message headers.)
Arjan,
Your wise advice led me down several as yet unexplored paths. The solution was not magic after all - I was doing a ‘mac save’ after each transmit - just missed the place in the software where it was occuring, so one of your first remarks was correct.
In the process I learned about the ‘mac get upctr’ command and others. I guess my solution will have to be to manipulate the counter in such a way that uses the correct counts when uplinking since I dont want to turn off frame counter checks and reduce security.
Thanks everyone for your patience and excellent help. I am enjoying the learning experience !
regards,
Dave
2 Likes
Quite late, but just for future reference:
Indeed, I’ve also seen that this is required for a Libelium device back in May 2016, which identified as RN2483 1.0.1 Dec 15 2015 09:38:09. And here’s the part that is relevant from that link, October 2016, numbered and formatted for readability:
The initial RN2483 and RN2903 both contained an errata meaning that the sleep current is above spec, and this can be an issue for sleepy devices trying to achieve very long battery life. As hinted in the post above, there is a work-around for this which allows Vdd to be completely removed, but then for the module to continue after Vdd is re-applied. Using OTAA to rejoin would cause a lot of over-the-air communication and so could negate any current benefit of removing Vdd in the first place.
The solution is to store all the radio state before sleeping, including the session keys, using the “mac save” command and then to continue the session after waking using the “mac join abp” command, with no over-the-air comms needed. To the network this is invisible and no different from the module sleeping instead of being turned off.
In the RN2483 example below,
>indicates a command to the modem and<indicates a response from the modem:
OPTIONAL - resets the module firmware to default values
> sys reset
< RN2483 1.0.1 Dec 15 2015 09:38:09OPTIONAL - resets the module firmware to default values, plus clears the EEPROM (session keys, EUIs etc)
> sys factoryRESET
< RN2483 1.0.1 Dec 15 2015 09:38:09OPTIONAL - reads the IEEE EUI of the module. Can be useful for node serialisation
> sys get hweui
< 0123456789ABCDEFMANDATORY - in this example the hweui value (read above) is used to uniquely serialise the deveui
> mac set deveui 0123456789ABCDEF
< okMANDATORY - unique per web app. Used to route data
> mac set appeui 0123456789ABCDEF
< okMANDATORY - unique per device & must match server
> mac set appkey 0123456789ABCDEF0123456789ABCDEF
< okMANDATORY - create blank ABP credentials in preparation for ABP re-join. These blank credentials will be overwritten with server assigned values during the successful OTAA join accept process
> mac set devaddr 00000000
< ok
> mac set nwkskey 00000000000000000000000000000000
< ok
> mac set appskey 00000000000000000000000000000000
< okOPTIONAL - default value is 34. Some private networks use 12
> mac set sync 34
< okOPTIONAL - default is off, but ADR is healthy for battery life & capacity if supported by the network
> mac set adr on
< okOPTIONAL - saves all the settings to EEPROM for future use
> mac save
< okMANDATORY - starts the join request/accept negotiation process, over the air
> mac join otaa
< ok
< accepted(ordenied)NOTE - accepted/denied response is useful to validate network coverage & set up
DEFAULT - tx an unconfirmed packet on port 1. “Hello World!”
> mac tx uncnf 1 48656c6c6f20576f726c6421
< ok
< mac_tx_okMANDATORY - “mac save” used here to store all radio state, inc counters, devaddr & nwks/apps session keys to EEPROM
Note: “mac save” command is writing to EEPROM which is a slow process. Wait for “ok” response to confirm completion
> mac save
< okREMOVE VDD AND POWER DOWN INDEFINITELY
MANDATORY - prepares the LoRaWAN mac with the radio state previous stored using “mac save”. No server intervention needed
> mac join abp
< ok
< acceptedDEFAULT - transmit an unconfirmed packet on port 1. “Hello World!”
> mac tx uncnf 1 48656c6c6f20576f726c6421
< ok
< mac_tx_okIn both the initial session and the follow-on session the same network credentials are used and the radio state (data rates, counters etc) remain in sync, so the network server can not distinguish between this and a continuous session.
For more recent RN2xx3 devices, maybe removing the full power is no longer needed to achieve good battery life, and a regular sleep (if that exists…?) without the need for the mac join abp trickery suffices?