RN2483 – how to handle if connection to ttn is lost?

How can I automatically check if an OTAA connection is still upright?

Should I trigger a new join process once a day to restore a possibly disconnected connection from the TTN server?

Or what is the best way to restore a lost connection to TTN server?

Hi @ledi007, I use commercial sensors from a number of manufacturers. A lot of them seem to use variations on a similar strategy. They all use OTAA. Most of the uplinks do not request an ACK but periodically they send an uplink requesting an ACK. If they do not get an ACK then they also send the next routine uplink with a request for an ACK. If there is still no ACK then they raise the SF. If there is still no ACK then they attempt to re-join.

1 Like

It should also be noted that there is no concept of connection that can be maintained or lost. Packets are sent and can be received or not, without a stable connection.
If the node is moving, then maybe some packets can be lost. The technique mentioned by @cultsdotelecomatgmai is used to adjust SF when the node thinks packets are lost, of course only sometimes because uplinks cannot be too much. Re-joining is not a good idea because, in principle, you have to join just one time and then save your parameters.

3 Likes

Ok, but what can i do, when ttn server fails?

How do I know in this case that I need to reconnect with join otaa?

I would not prepare for a relatively rare, catastrophic event, in which TTN loses your keys. More likely you will do some mistake on node side. Remember, there is no connection: only a way to associate your node to your application.
This is a good, yet perhaps now old, read on more or less your same issue:

2 Likes

For nodes placed in remote locations with difficult access this “rare” case is a case to be taken into absolute consideration and a periodic rejoin, in my opinion, is advisable to save yourself a trip.

Ok!
I want to build up 100 or more nodes outside and all PCBs are shed. The lifetime of a node is calculated with > 5 years before the battery must be replaced. But within this time it is not possible to make a restart of the MCU if a connection to TTN is lost. Therefore it must be robust. And if the node does not need a new join process after the first join is done successfully, this will be great.

Use the advice @cultsdotelecomatgmai provided. Make sure the node can rejoin, but don’t rejoin too often as each join uses a random nonce and after a number of joins new attempts will fail due to nonces not being unique (which is required). The nonce is 16 bit so each node will only be able to join 65536 times, however conflicting nonces will be generated much sooner. (LoRaWAN 1.1 solves this issue allowing all 65536 nonces to be used but is not available for the rn2483 modules and the TTN community network does not support it.)

2 Likes

Thank you for information!
I think a good way to do that is to count the number of failed transfers in order in the MCU software. A 9-byte value is sent once per hour. And if the consecutive transfer fails after the 10th attempt, then a new join otaa should be executed.

Just make sure you do not exceed 10 downlinks including acknowledgements a day. Keep in mind a gateway is not receiving anything when it is transmitting so downlinks (includes join accepts and acks) don’t scale.

1 Like

You have to use RN2483 commande mac get status, and check bit 4 : Join status (‘0’ – network not joined, ‘1’ – network joined)
look at
RN2483 LoRa® Technology Module Command Reference User’s Guide for more details

Best regards

1 Like

that’s a good hint, thank you. But I mean it is bit 0.
Bit 4 is automatic reply status. image

be carefull, join status bit mapping is differente beetween versions , if before 1.0.4, join status bit is 1 for 1.0.4 or later it’s bit 4

Since also Jac is here (and I trust him :slight_smile: ), let me check if it’s me missing something.

I agree that in general a strategy for rejoining is needed (in particular for nodes with 5y expected life). However, it seems to me that thinking at network server failure is looking at the least important factor.

@cultsdotelecomatgmai advice works well first of all for the most likely events (failed or moved gateway, a truck in front of the node that shields signals, etc), while network server failing could be considered one of the least likely. It does not only need that the server is temporarily switched off, but also that it lost all keys, without backup. If it just shuts down gracefully and then is restarted, there is no real need for rejoin (@kersing: am I missing something on this? it’s not a TCP connection). You could do it, but guidelines ask not to do it too often, and I would not use it as a solution for other issues.

This technique does not tell you that a rejoin is needed. 99.9% of times it tells you there is something wrong in the communication chain (your node and gateways being the first places to look for). So it’s not that a new join is needed: you know you need to do something. First thing to try is to increase SF, if you are not yet at SF12. If it failed 10 times, there is a high probability that a new join will fail too, because of something in the middle.
This without considering how you know that 10 attempts failed. If you mean that all packets are confirmed, then one per hour is more than the maximum allowed by fair use policy.

it is useful to know if a joining attempt succeeds, but then it will stay as is even if the network server is switched off. So it is not a way to know the network server crashed.

… and be careful because this bit isn’t so reliable. It’s not clear how the RN2483 estabilish if a join is lost and how update conseguently this bit. In my case I use a combination of this bit with a confirmed packet every X time and a join every Y time. The supposition is that RN2483 uses a nack on confirmed packet to clear or not this bit… but it’s only a supposition. Any one know more?

1 Like

Dear ledi007
I am not sure whether you got your information and whether my input will be sound or not. Though, I add my two cents.
I think I asked a similar question as yours 2 months ago. I experienced interruption of the sending of payloads from my arduino through LoRa using the TTN protocol and I was wondering how to overcome these interruptions through being able to check whether the connection was still OK.
I finally used the following command:
ttn_response_t toto = ttn.sendBytes(payload, sizeof(payload));
It seems to both send the payload and put the feedback from the gateway into the toto variable, with values being 1 when the transmission is successful, -10 when there is a problem, -1 when the payload could not be sent, and maybe other values in other situations.
Then I added to my script a test on the toto value to restart the join procedure when the value of toto is different from 1. And it works finely.
Best regards.
PB

Normally there is no feedback from the gateway, unless you send confirmed packets, which are limited to maximum 10/day because they involve an uplink. Likely the response tells you whether the packet has been sent or not by the radio chip, which in turn likely depends on your (ab)use of the duty cycle.