Changes retransmit delay to no longer use buckets #961
Conversation
|
One behavior i've noticed, but i'm not sure yet if it's related to this change. For direct path messages, having the Should I clamp the minimum delay so it's never 0? |
Cisien
force-pushed
the
cisien/change_txdelay_calc
branch
from
5c36659 to
22dce23
Compare
|
Updated so the minimum value is 5 (arbitrary number), traces are reliable on |
Cisien
changed the title
|
|
||
| uint32_t t = (_radio->getEstAirtimeFor(packet->path_len + packet->payload_len + 2) * _prefs.tx_delay_factor); | ||
| return getRNG()->nextInt(0, 6) * t; | ||
| uint32_t total_delay = getRNG()->nextInt(5, t); |
There was a problem hiding this comment.
This would make the maximum delay 't'. Whereas it used to be 5*t was the max.
This would change the interpretation of the _prefs values. Admins can set to some small fraction, like 0.1 (or smaller) if very small delays want to be experimented with. Currently max for the pref is 2.0 (I think), which is probably very wild/unrealistic.
Also, currently the minimum 'extra' delay is 0, and this introduces min of 5 which could be a fairly 'radical' change. For a first-try, I'd rather introducing JUST the granularity change... ie. no 6 buckets, and just continuous range instead
|
BTW, I've pushed to dev similar because a few of the main team want to try out what more granular tx delays are like. |
|
Excellent, i'll run it on my repeaters and let you know if anything looks off |
2 participants
This change would give the "listen before send" code a better chance to detect if another nearby repeater is transmitting.