Randomization of uplink time? #1214
Replies: 3 comments
-
|
The device has to take care of this. The LoRaWAN stack only does random delay between confirmed retransmissions which is part of the spec - TR007 isn't spec but a recommendation to the users. And a good recommendation nonetheless. |
Beta Was this translation helpful? Give feedback.
-
|
It isn't implemented in RadioLib - it's only a technical recommendation - TR007 - and it tends to confuse new users if they sit and wait 3 minutes for the next uplink and it doesn't do it for a 3 minutes 45 seconds, for instance, so not embedded. The comment mostly refers to those that choose to uplink at a particularly time - on the hour for instance - which when you have nine devices, one (or more) loses! Jitter can be as simple as a random ±60 seconds added to the interval - so that it spans -30 to + 30 seconds - before sleeping. Which is pretty much what I do. This just provides enough jitter so that if any local nodes end up in sync, they quickly diverge. This is absolutely essential where Class C nodes are powered up at the same time due to local power issues. But I've had some instances where other local radio activity has caused issues for std Class A devices. Like many of these code two liners, easy to add, no particular harm and just occasionally saves your bacon. The join is a bit more complex with a recommended sequence of longer retries. All the details can be found here: https://resources.lora-alliance.org/document/tr007-developing-lorawan-devices-v1-0-0 |
Beta Was this translation helpful? Give feedback.
-
|
@StevenCellist and @HeadBoffin: Thank you very much for the detailed explanation. I will consider this in my projects. |
Beta Was this translation helpful? Give feedback.
-
In #1204 (comment), @HeadBoffin wrote "randomisation of uplink time" - is this handled by RadioLib or does the LoRaWAN device application have to take care of it?
Beta Was this translation helpful? Give feedback.
All reactions