That sounds really interesting - I choose the PIC because the lack of memory was frustrating to me, I don’t know the ATiny, perhaps I will take a look. In any case you broke my low-current record with it, so I will have to !
Key with mine was it took a physical event to wake the unit. There was no
timer running… I used an ATiny85. Not sure what it’s sleep current was but
I’m think it was appox also about 0.1ua so total of about 200na while sleeping
/ inactive. The ATiny waits for a signal from the radio that it is done before
shutting down power…
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…
2 Likes
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.)