What should I do if my node moves away from the gateway and re-enters the field of view? Rejoining or similar process? Or Do the uplink and downlink messages continue from where they left off when it enters the field of view?
I want to show whether the LED on the card is connected to the gateway. The way to do this is confirmation?
Please start with LoRaWAN 101, LoRaWAN devices start a session with the network using OTAA (preferred) or ABP. At that point both device and network are synchronized (same secrets and counter values).
When you move out of range of all gateways your device continues transmissions, unaware of the transmissions not being received. It keeps incrementing the uplink frame counter. When a device moves to a place there is a receiving gateway in range it will forward the next transmission and as long as the counter is within 16383 of the last count received by the network that transmission will be forwarded to your application. All data transmitted between the last received frame and this new one is lost.
If you count exceeded the valid window you will need to rejoin (for OTAA) or find another way to sync (ABP).
You device will not know if an uplink is received by the network, at least not if you do not use acknowledged uplinks. Keep in mind you are allowed just 10 downlink packets a day and acknowledgments are included in that count. So driving a led on the device to show the device is connected to the network (you never connect to a gateway, this isnât WiFi) wonât work.
Thanks for this great explanation. I have further small questions:
Is automatically executed this rejoining by the lorawan stacks for OTAA? Or should I check if this number stays in 16383 in the firmware?
Do you mean the 10 downlink limit specifically for the TTN?
NOTE: Actually, I used the term âconnectâ on purpose. Things I know 99% of the time and Iâm sure of. But for the sake of 1%, I used this term and succeeded. You corrected me. I think itâs a bit sad and discouraging to tell people to start from 101. Of course, I am here to learn. But I donât think a very experienced person like you really needs to use such advice.
We have no way of knowing your skill level or depth of knowledge wrt LoRaWAN. Your initial question strongly suggests a lack of knowledge of the fundamentals. Jac was doing you a favour by responding and providing a simple but effective description of the processâŚhe could have just said go away and read the documentation and do some searching, instead he tried to help you understand the mechanisms involved. The message count is quite important and fundamental and is actually baked in as part of the LoRaWAN specification and normal behaviour and security provisions. Far from being discouraging, I know Jac,and know he was trying to help you. If you want a quick introduction to the fundamentals of LoRaWAN (101 plus a bit more if you will!) and in part TTN perhaps you might review the short presentation done by the TTI/TTN CTO Johan Stoking
Not necessarily - but there is a whole raft of link check facilities in the spec which ever stack you are using may or may not implement.
Yes, but there are legal limits as well. But you know this already.
Succeeded? All the way through this forum people use the phrase âconnected to the gatewayâ and each & every time this is corrected - the device transmits, any gateway that hears the signal passes it on. So Iâm not sure how you feel you succeeded?
LoRaWAN has many layers, like an onion, and if someone asks questions that demonstrate a lack of understanding of the fundamentals (like moving in & out of range or having a âconnectedâ status LED), then itâs not unreasonable to ask people to review the basics.
If you read the Learn section, linked at the top of the page and watch some of the TTI videos it will save you hours in the future debugging issues and save you asking questions that canât be effectively answered without sending you back to LoRaWAN 101.
PS, if the device moves then it may have a GPS on it. If you capture the signal strength and youâve moved a certain amount, then a link check may be appropriate. The âcertain amountâ is complicated but a scheme could be figured out. This is the sort of implementation detail that youâll find a whole host of suggestions from a range of people. The â101â errors usually only get the moderators answering âŚ
Thanks for all your responses to the question(Technical). All were useful for me. @Jeff-UK âThanks for this great explanationâ.I draw your attention to this expression. I thanked him and appreciated him. Also you and @descartes. I just expressed that this phrase is not useful, not making any contribution. But in return, I saw people who were not critical.
How would you do that? Your firmware doesnât know what the last successful number is the network received.
There are a number of things to consider:
Uplink frequency.
How long do you expect a node to be out of range of any gateways.
If your node can reasonably be expected to be in range well within the window you donât need to do anything specific. However it is good practice to make sure your LoRaWAN stack uses a mechanism like linkcheck (very infrequently as it requires downlinks) to verify it still has an active session and after a number of missed responses consider the session to be invalid and rejoin. That not only takes care of situations where a node is out of range too long but also makes it recover whenever something else goes wrong (like inadvertently using two nodes with the same credentials) without having to retrieve the node to reset it.
When (re)joining make sure to back off attempts when it fails (your device might still be out of range) to avoid burning too much battery.
Then please use it correctly in order to not confuse anyone reading along or trying to answer/help. Not having a connection to a gateway but in stead to the network is a fundamental difference between LoRaWAN and other networks and confuses people no end. There are TTN users that after 2 years of using LoRaWAN still think (thought) the node needs to join again when moving from coverage area of one gateway to that of another. The result is many unnecessary rejoins (which are limited during the lifetime of a node) and unnecessary battery use.