Add SNR-driven dynamic coding rate selection for repeater retransmits#1923
Add SNR-driven dynamic coding rate selection for repeater retransmits#1923weebl2000 wants to merge 2 commits intomeshcore-dev:devfrom
Conversation
When a repeater forwards a direct-routed pkt, it looks up the next-hop neighbor's SNR, computes the link margin against the SF-specific demodulation floor, then determines coding rate (RT) based on SNR. Weaker links get higher CR. We apply CR on a per-packet basis and restore to default configuration after TX. Margin thresholds: <3 dB - CR 4/8 3-6 dB - CR 4/7 6-10 dB - CR 4/6 >=10 dB - CR 4/5 Flood repeats adhere to configured CR, as do forwards to unknown neighbors.
Is that the local node's SNR when receiving packets from the remote node? So the calculation assumes symmetric link SNR's at each end? I'm always leering about making decisions/calculations based on this assumption. |
Correct, we assume the link is fairly symmetrical. In practice this might not be the case. This can go both ways, either we're spot on with our CR, but it can just as easily be too low or too high. The system will be somewhat self-correcting though, if our CR isn't spot on our SNR will drop for neighbors and thus yield a bump in CR. I think it's a reasonable starting point for SNR-driven CR. Knowing our neighbor's SNR receive values from our signals is a heavier protocol change. The 3dB margin before dropping to a lower CR seems like a conservative enough choice too. |
|
Is there data that shows that each CR has higher success of being received successfully at those SNRs? eg how was it determined that CR 4/5 will work adequately at 10 dB margin vs 20 dB (or some other value), etc? |
The demodulation floors are from the SX1262 datasheet. The CR-specific thresholds are heuristic starting points based on ~2 dB per CR step approximation (it's probably less). It should be refined with real-world testing. Without this PR there will be no real-world testing though 😉 |
What's the fallback path? If the remote doesn't decode the packet successfully at the higher CR, will we retry at a lower CR? or just flood? I don't understand the part of your statement, "our SNR will drop for neighbors". How will that happen? |
|
Re: testing, what metrics can be analyzed to determine how often this is executed and the success rate? |
There is no fallback path really. If a direct-routed packet is sent with too little error correction, a neighbor simply cannot decode it. In a healthy mesh this shouldn't be an issue. Stronger links will pick up the slack and stronger routes will establish more naturally. Mind you, this "deafness" would only occur with highly asymmetrical links. Asymmetrical links are troublesome in their own right, but aren't the most common. Most links imo are fairly symmetrical. If there is no other route? Your default CR will still apply to any flood routed packages, so if direct messages fail with a lower CR, if you have CR8 configured your flood message might still go through. Might it break weaker direct links on the edge of working? Yes, maybe. But these links would still work on flood if your default CR is higher than the determined CR. Will it encourage stronger links to have preference over weaker links? Also yes definitely. Stronger links that work with lower CR will take less airtime and be more succesful, leading to a healthier mesh. In the end, the main benefit of this change is not about fixing one specific link, it's about not forcing every link to pay the cost of our WORST link. |
In my opinion? Test if the dynamic rate selection works for your repeaters. I.e. does it adjust based on observed SNRs from neighbors? If so: deploy this to the mesh as a whole and see what it does. Are direct links more succesful, less airtime spent? There is no way of analysing the net result of this by looking at just one node. We definitely also need improvements like #1691 - our companions are way too eager to spam the network currently. |
|
The recommended CR varies... in UK it's 8 but in US it's 5. I can see how going "faster" (lower CR value, eg fewer bits of correction) for strong links can reduce airtime, etc, and be beneficial. I can see how going "slower" (higher CR value, more bits) can help marginal links get messages through, to reduce the number of retries or dropped messages, at the cost of one slower direct message (hop). But if the slower message still fails, and the default (in the case of US/default=CR5) is less resilient, would this still be helpful? Is the dynamic adjustment beneficial in theory to both default settings? I need to think about this more... |
|
A separate topic, slightly related... how about automatically increasing CR on very-low airtime nodes? |
When a repeater forwards a direct-routed pkt, it looks up the next-hop neighbor's SNR, computes the link margin against the SF-specific demodulation floor, then determines coding rate (CR) based on SNR. Weaker links get higher CR. We apply CR on a per-packet basis and restore to default configuration after TX.
Flood repeats adhere to configured CR, as do forwards to unknown neighbors.
If you want to try this you can BUILD HERE.
I saw this was on the roadmap so I had a go at it. For now we leave flood repeats as-is. In future we might do something smart with average SNR of all our neighbors, but let's take small steps.