if you have long sleep times between transmissions, you could use the RN2483 sleepmode (up to 49 days) and use the module’s uart line to wake up your processor, instead of wake up the processor everytime to increase a counter until a certain value is reached.
1 Like
And as for ABP vs OTAA, the all-knowing @htdvisser wrote on Slack October 18th:
I’d say if you use ABP correctly it’s equally secure as OTAA. However, if you switch off the frame counter checks (many people do this), security is significantly reduced. If you’re worried about silicon inspection, I think there are some devices available that store the keys in a secure element. OTAA devices are more flexible than ABP devices. If you ever decide to change networks (from the public community network to a private network that has better SLAs), your device can simply do the OTAA procedure again to switch networks, and you don’t have to reprogram the device in order to change the DevAddr and keys.
If someone gains access to your keys, you should consider your device lost either way
That person would probably already have had physical access to the device, so you can’t trust the original device anymore anyway
For OTAA, the counters are reset to zero on every join.
See also https://www.thethingsnetwork.org/wiki/LoRaWAN/Security
Yes, that would be an option. Unfortunately that consumes too much power. I switch off the radio any time it is not essential using a P-Channel MOSFET switched by one of the PIC outputs. The ‘sleep’ of the PIC XLP mode is essentially a switch-off of everything except a schmitt trigger waiting for a discharging capacitor to generate a reset pulse - with 160 nA I guess we can’t expect much more !
Interesting point. I guess if I want to change networks I could send the node new keys with a LoRa message and ask it to rejoin - sounds a bit risky though, and requires the ‘old’ network to be operational. A bit like remotely changing the IP of a router and then having to drive there anyway after the reboot !
For ADR, a node would need to check if its transmissions are still received, and if not it could also decide to re-join. I’d assume the RN2483 does the ADR validation all by itself, so will probably not allow your code to hook into that; it will raise an error at some point though, I guess.
See also How can an operational node be triggered to join a different network? to keep things on topic.
Hi Arjan,
Coming back to the discussion about OTAA and ABP, I got working what I wanted working and made some choices. I referred to joining first using OTAA and then subsequent joins using ABP. My problem was that I switch off the radio (RN2483) so when I switch it on again I must do some kind of jion, otherwise it wont transmit. I found the article I was talking about once more:
http://www.microchip.com/forums/m945840.aspx
Essentially, if you do a join OTAA, then transmit something, then do a ‘mac save’
you can remove power to the radio, reapply power, do a ‘mac join abp’ and the network
will not ‘know’ you removed the power - it will look like a continuation of the OTAA
session. When you remove power (as I do!) this seems to be the power-cheapest way to rejoin.
I think using this techniek I still keep the advantages of being able to join another network by
telling my node the new keys and instructing it to repeat the initial OTAA join.
Perhaps you could tell me what do you think of this techniek ? Am I missing anything ? - it
works on my prototype, have not got round to testing the ‘switch’ to a new network as yet.
regards,
Dave
1 Like
That needs the old network to be available. Which it probably will be… But let’s take that to How can an operational node be triggered to join a different network?
OK - still getting used to using the forum ! - I will try to find the right topics from now on !
I’m using an RN2903. I configure it for ABP and do a mac save.
After that, I can put the RN2903 to sleep and wake it by sending a break
and 0x55 as described in the manual, I can send data without having to do
another join.
e.g
mac sleep 86400
Then later I wake it by sending a break on the uart connected to the
RN2903 followed by 0x55 …
mac tx uncnf 1 0x1234 …
I can also wake it using the reset pin, but then I need to do a join
before sending data.
Yes, but the radio in sleep mode uses 16 uA, I switch off the radio to get an idle current of 0.16 uA by using the XLP sleep mode of the PIC controller - that’s the reason for all the messing around !
Ah …
You should be able to a “mac save” then power the unit off completely using your
mosfet switch, then on power-on. it will retain the previous mac settings.
Issue the single command “mac join abp” and send data, mac save again to
save your frame counters etc. and power off with the PIC
Tom
Yep, that’s what I do - it’s working well now. I am currently fiddling with the calibration of the charge time for the capacitor, then I’m pretty much done for this node, then I can switch it on and wait to see what comes first, empty battery or my pension - I’m banking on the latter !
I’ve did something similar to what your doing with an ATiny85 only I used an
MCP1252 regulator and had the ATiny toggle the enable pin on the regulator.
It used 0.1uA in standby. The ATiny was in deep sleep, wake on interrupt tied
to a n.o. reed so very little current was used in until the “event” triggered / closed
the reed. Lasts forever on a small lipo.
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 ?