LoRaWAN: Reason for change of LinkCheck and DeviceTime request scheduling? #1221
-
|
Hi, is there any technical reason why the condition for scheduling the LinkCheck and DeviceTime request has changed from Thanks in advance, |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments
-
|
Nope, no technical reason whatsoever, but the |
Beta Was this translation helpful? Give feedback.
-
|
It's only an example implementation - there are recommendations on many aspects of deployment in TR007 - but you should fit the situation to your application. Doing a LinkCheck on the first uplink after a join is a bit academic. My copy has If the device hasn't had a downlink in a while - number of uplinks or actual duration - then it may perform a link check which is the most network efficient way of checking it's still talking to the mother ship. If it doesn't get a reply after two or three LinkChecks then it could consider performing a join to reestablish it's connectivity. TR007 has recommendations on the backoff of join so that if a gateway in an area goes down there aren't a gazillion devices all banging on the door. DeviceTime can be performed at device appropriate intervals - which you can figure from your bench - if it drifts much over a day, you need an RTC - ideally it figures out it's own drift and then does a DeviceTime when it suspect it is out by a margin worth getting a correction for. Although the use of actual times on a device is prone to poor design - uplinks at a particularly time aren't a good thing - again TR007 recommends some jitter on the uplink - I tend to use ±30 secnds when deployed - but stick to a monotonic period when testing otherwise it can get messy figuring out when to expect something - unless the serial debug tells you! |
Beta Was this translation helpful? Give feedback.
-
|
@StevenCellist and @HeadBoffin: Thanks again for the detailed and helpful answers! It seems I should put reading TR007 on my ToDo list... |
Beta Was this translation helpful? Give feedback.
It's only an example implementation - there are recommendations on many aspects of deployment in TR007 - but you should fit the situation to your application. Doing a LinkCheck on the first uplink after a join is a bit academic. My copy has
((fCntUp % 64 == 0) && ( fCntUp > 0))which is a good example of fuglly code but at least it waits until uplink 65 before it triggers. As another loverly bit of WTFing, The Things Stack does not return a field if the value is null, empty or zero due to the way that Google Protocol Buffers encodes such things - you have to infer its value in your own code.If the device hasn't had a downlink in a while - number of uplinks or actual duration - then it ma…