[solved] Relaunch a LoRa connection which has unexpectedly interrupted?

End Devices (Nodes) Hardware
24

Thanks to all of you for your interesting, useful and educative inputs. I learnt a lot.
It is indeed likely that I confused TTN-branded “Things Uno” node board with TTN.
I apologize for that confusion, but I hope that the community is also meant to help unskilled people.

In great part thanks to your comments, I finally solved my problem (see at the end of the message). In spite of the numerous suggestions that you made I unfortunately could not identify the origin of the problem. For sure I am not expert enough. I have however been very surprised that the community would not consider “possible” that a LoRa connection might be interrupted for many uncontrollable and possibly unresolvable reasons. When I make a phone call, I sometimes face an unexpected interruption although there should be no reason for that.
So, instead of climbing the steep mountain, I walked around it. This may not be satisfactorily as some of you mentioned, but at least I ascertained that it works.
The ttn_response_t toto = ttn.sendBytes(payload, sizeof(payload)); command 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.
Thus I added a test on the toto value to restart the join procedure when the value of toto is different from 1. And it works finely.

I still do not know how to close a discussion (is it my responsibility ? or the responsibility of any authorized member of the community ?), but as far as I am concerned, the discussion can be closed.

25

There is not really any such thing as a “connection” in LoRaWAN. Certainly not in the way there is between your mobile and its network.

It’s important to understand that the node’s module really has no idea if any gateway is listening or not. There is no “connection”. Hence an error here likely indicates that the module is still busy with a previous request, that it is refusing to transmit because it believes the regulatory duty cycle has been exceeded, or because it believes that it does not have any currently valid OTAA session address/keys set.

In the first two cases, doing a rejoin is a severe mistake, and will only make things even worse.

In the latter case, you should probably not command a restart of the join process unless you know for a fact that no join attempt is still in progress. You can only join a limited number of times, and if you abort an attempt after the network has heard you, not only will you have to start over, but you will have uselessly used up one of those join allowances.

1 Like
26

no problem :rofl:
see you next time