I am building a node in which long battery life is the primary factor. I Am using th RN2483 in combination with one of the PIC controllers with ‘XLP’. All is going well, I have been able to get all the LoRa communication running fine. I have a couple of questions about joining the network:
If I have joined the network using OTAA, when does this ‘join’ expire ? after a certain amount of time? after the RN2483 has been switched off and on again ? where can I find a description of this behaviour ?
I see that it is also possible to perform a single OTAA join, use ‘mac save’ to save the parameters to the RN2483, and after that use ABP to join. I have not looked into the finer parts of this technique as yet, but I understand it uses less power since OTAA requires network communication for each join. Are there disadvantages to this method ?
Although I understand the differences between OTAA and ABP to a certain extent, I keep reading remarks like ‘ABP is ok for development, but you need to use OTAA for production devices’. Im not sure I understand this - is there an article somewhere that I can read outlining the disadvatages of ABP?. It seemed at first to me that it was a similar discussion to the use of DHCP versus fixed IP addresses, but as far as administration of the keys , device ids and so on goes I don’t really understand the advantage of OTAA - it seems like just as much work !
So I suppose my question boils down to ‘if I want really low power consumption and no bad choices which will come back to haunt me further down the line, should I choose OTAA or ABP, and how often to I need to do a join ?’
I hope for wise advice - I have already read a lot of that on this forum !
Thanking any responder in advance,
Merry Christmas!
Dave Long
Yes, you should save the keys, and should certainly not repeat the OTAA join for every transmission. It’s up to your software if there’s ever going to be a time to repeat the OTAA join.
It’s merely up to you: do you expect the TTN backend to ever lose the keys in some disaster, do you expect to exhaust the frame counters, do you ever want to join a different network?
Also, ABP needs you to manually configure RX2 (for which TTN uses SF9 rather than SF12, at least in EU), which for OTAA would be set automatically using the details of the Join Accept.
Thanks for the fast and complete answer - That is fills in pretty much all the holes I had, and I will certainly read the content at the link you sent me !
I can finish my node now. The PIC controller with XLP is great (PIC PIC18F46J11 in my case) the idle current is already down to 160 nA and I think I can go further - seemed a shame to spoil it with unnecessary chatter with the network !
As for the chances that TTN loses the keys and to not join too often to avoid duplicate nonces from being rejected, a transcript from Slack, October 29th:
As you may know, we use Redis, an in-memory data store to store devices. This gives us very high performance (messages being handled in a couple of µs), but indeed has a higher risk of data loss. Redis has two mechanisms for persistence, and we use both of them. The first is to write every transaction to an append-only file, which, in case of a power outage, we can replay to restore the state. In the worst case, we may lose the last transaction if the disk write was interrupted. The second mechanism is to make periodic dumps of the entire data store. The dump frequency depends on the number of writes, but it happens at least every 10 minutes. This dump can be used if, for some reason, the first mechanism fails.
Next to this, we have an off-site storage facility where we keep hourly, daily and weekly backups of those dump files, plus all configuration files that are needed to fully restore the server to the exact state at that point in time. These backups should only be needed if the server’s SSD can not be recovered for some reason.
So […] for TTN there should be no reason for @dbrgn’s comment “right now, rejoining every few days is probably the best approach to make sure that the device survives new keys, should that ever be necessary”?
I can’t think of any reason to do that. In fact, I can only think of a reason not to join that often, which is that every join needs to use a unique 2-byte nonce. This means that a device can do 65.000 joins in its lifetime. That’s perfectly fine if the nonces are incrementing (as is the case in LoRaWAN 1.1), but if they are random (in many LoRaWAN 1.0 devices) the chances of a successful join will quickly become smaller over time
All said, users could backup the TTN-generated keys as well. And keys could be compromised too, in which case you might want to tell a node to get new keys. LoRaWAN 1.1 supports that.
‘LoRaWAN 1.1 supports that.’ - good to know, I will look into that. The node I am making is likely to be buried in places where it will be as good as impossible to service them, so any kind of ‘disaster recovery’ will need to be automatic and only via LoRa communication, otherwise it will become… well, a disaster !
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.
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.
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.
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:
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.
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
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…