Let me describe you my experiences with a custom Lora node (based on RN2483), a custom gateway (based on RAK833 concentrator) and the TTN server.
At the beginning of my project and for development purposes I kept the node always powered. I used OTAA as activation method and my node worked perfectly during 3-4 days until the TTN stopped accepting the data from the node. I learnt hat it was due to some kind of expiration of the OTAA session and that a OTAA join has to be issued every few days.Otherwise, the node, the gateway and the TTN server worked great.
Now a I would like to shut the power off my node between measures (including the RN2483). I read that a possible solution is to do an OTAA join and then after subsequent power-off sequeces use ABP joins and send the data. I did that and after some twiddling with the appkey, the devaddr and the upcnt registers of the RN2483, I managed to make it work.
The problem I’ve got with this configuration is that is only working for a few power-cycles. At one point the TTN server stops to show any new data from the node, but the node is still successfully joining with ABP and transmiting the data without errors in the RN2483. I think the problem has to do with the frame counter values in the node and in the server that for some reason are out of step but I have to checked that. Is that correct? Is there any possible solution to that problem?
Another issue I’m having is that in this situation (the node sending data and the TTN server ignoring it) I cannot reset the node for OTAA join because always denies it. The only way to recover from that is to kill and run the packet forwarder in the gateway. Is there any way to avoid that? Can I end an OTAA session from the server without having to reboot the gateway?
This will be tricky. There is no such thing as an “ABP join” - you just start sending data. The closest thing to a “session” in ABP would be to have ADR have ramped up the data rate, but that’s unique to data rate, it isn’t really a “session” from a registration point of view.
Because there’s no such thing as an ABP join, this report is more confused than meaningful. If you were doing an OTAA join that would mean you have roundtrip traffic. Likely you are not having any success at all, either because you are using an invalid devaddr and keys combination from an expired OTAA session, or un-initialized values from a node that “forgot” everything on power cycle, or because of frame count rollback.
You can disable frame counter checks but you still need a valid devaddr and keys combination, either static (ABP) or from a still-valid and not superseded OTAA session.
This may be because your node has forgotten everything and is re-using an already used join nonce. You can only do an OTAA join with a join nonce that the network has not previously seen you try to use.
No, that is pure coincidence. If your gateway is getting stuck that would be one thing, but then it wouldn’t be reporting any uplink traffic into the console. Actual network<>node state has no dependence on gateway - you can restart the gateway, or power it off and let one a few km away be seen as the strongest candidate, or smash it with a hammer and replace it with another, and the sense of sessions and nonce / frame count re-use protection is unaffected.
One conclusion from all of the above, is that there’s no good way to make a node in a traditional LoRaWan network like TTN, without it having a fairly sound long term “memory” of state - you either need to retain the frame count with ABP, or to retain the last used join nonce. If battery changes are rare (only a handful in device lifetime) you may be able to do this with low power memory or backup registers and just try until you hit a clean join nonce (though this will make development painful), otherwise you need EEPROM perhaps with careful management of write cycles (ie, don’t write every frame count change, or at least walk it if you do) or something less limited like FRAM.
Sorry to disagree, I have an OTAA activated node using an RN2483 that has been transmitting data for 912 days since last activation. So I can assure you OTAA sessions do not expire and require activation every couple of days.
Thank you very much for the insights and the corrections you made to my description of the problem.
I’m using the term “abp join” because that is the mac command you have to issue to the RN2384 in order to transmit the data, but as you say there no roundtrip traffic that ackowledge the received data.
From the responses I received it seems that I have to look at the gateway and check that is working properly. Other possible causes like invalid keys,etc does not seem to be the problem because I issue a “mac save” command before sending the node to sleep, but I you said one has to be careful with EEPROM wear (fortunately I have plenty of flash memory in my node)
My suspicions would be the opposite of yours; the gateway is probably not the issue, at least if you can see that it is receiving traffic (apparently TTN backends have been down some in the last two days however).
Rather, it is likely your node is not behaving properly - re-using nonces, using wrong keys, etc. In part because a lot of the behavior seems hidden behind a command set, you don’t seem to have a clear idea of what it is actually doing.
If you can get the raw traffic, and you know the (hopefully non-production) keys allegedly in use, you can decode it yourself (there is for example an online decoder). Likely you will find it is not valid or does not match those keys.