Make the ground-station uplink configurable, and stop it starving video RX creating color blocks

[kkbin505]

Make the ground-station uplink configurable, and stop it starving video RX

Fixes the persistent colour-block corruption on RTL8812AU ground stations (see Issue #109 ).

The problem

The adapter is half duplex: every uplink frame is a receive blackout. The uplink was hardcoded to k=1, n=5 at MCS0, and Transmitter::sendPacket emits a block's fragments back-to-back, which measures as ~102 frames/s in bursts of 10-12 inside 1-2 ms. Those bursts blind the receiver long enough to drop video fragments — the one loss pattern the downlink
so the decoder gets partial frames and paints the rest of the buffer as colour blocks. That is the H.265 encoding, the compressor block is dynamic, so the colour blocks are random.

This was latent until devourer 5f099ee ("drop DEVOURER_TX_HT_MCS gate") made the uplink actually reach the air. Before that fixed_rate stayed at MGN_1M, and CCK is illegal on the 5 GHz channels this link runs on, so the frames were never transmitted — the uplink was silently dead on my device. (So there is no issue with the official release 0.23)

The change

The uplink airtime is configurable through the menu rather than fixed as a hardcoded constant, because the optimal trade-off depends on the airframe. A short-range quad can afford to allocate more airtime to the uplink, whereas a long-range fixed-wing aircraft cannot. A ground station using a separate RC or telemetry radio may not need an uplink here at all. Until a dynamic optimization algorithm is implemented, this is the most practical compromise I have found.

Adaptive → Uplink… exposes three controls, stored in SharedPreferences and applied on the next link start (same lifecycle as the existing LDPC/STBC options):

Setting	Default	Range
Uplink enabled	on	off = receive only, no adaptive bitrate and no mavlink uplink
Uplink MCS	1	0-7
Uplink redundancy	5	1-8 copies per message

New JNI entry points nativeSetUplinkEnabled / nativeSetUplinkMcs / nativeSetUplinkFecN mirror the existing nativeSetUseLdpc pattern. Out-of-range values are rejected rather than clamped — silently transmitting at a rate the operator did not choose is worse than keeping the previous one.

Choice of default

Measured on an RTL8812AU at 5 GHz ch161/20 MHz. The metric is lost_last_second from the adaptive-link telemetry: video fragments the downlink FEC could not recover.

Uplink config	uplink rate	SNR	lost/s	zero-loss samples
MCS=0, n=5 (previous hardcoded)	102/s	59.8 dB	15.82	4.9 %
MCS=0, n=5 (second run)	100/s	53.9 dB	9.78	7.8 %
MCS=1, n=5 (new default)	101/s	52.1 dB	2.18	62 %
MCS=3, n=2	42/s	57.0 dB	0.12	94 %
uplink off (control)	0	56.3 dB	0.00	100 %

The baseline was measured twice, 9.78 and 15.82, which is the honest spread for a config that is losing 5-15 fragments a second — the exact figure moves with how much video the drone is sending and with ambient traffic. Every other row is a single run. What is not ambiguous is the ordering: each step down in uplink airtime moves the loss by roughly an order of magnitude, and
muting the uplink removes it entirely.

T
Colour blocks were still occasionally visible at the default in my testing. It is a large improvement, not a complete fix — the honest end of the range is the uplink-off row, and everything between is a trade.

Note the improvement is superlinear in airtime — halving per-frame transmit time cut loss 7×, not 2×. Shorter blackouts stop clipping runs of fragments, and the downlink FEC absorbs isolated losses fine.

What I tried that did not work

Keeping the burst and spacing the five fragments 8 ms apart. Total lost fragments dropped (15.8 → 10.4) but the artefacts became visibly more frequent — the same damage spread over more downlink FEC blocks, and one damaged block is one visible glitch. Pacing is the wrong instinct here; the lever is total airtime.

Testing

Ground station: Samsung Galaxy S22 (SM-S901U1, Android 16), RTL8812AU (0bda:881a), 5 GHz channel 161 @ 20 MHz. Each configuration run 30+ s, 200-1200 telemetry samples, statistics from logcat. Every run was validated as actually transmitting (TxFrame countPIncoming > 0 and the expected fixed rate code in the devourer log) before its numbers were used — the uplink can die silently, which invalidates a run that otherwise looks clean.

Also tested on Google Pixel 1, same issue and same fix.

Not tested at long range; the MCS default trades uplink margin, so that is the axis to check before trusting it on a distant airframe.

Fixes #109

[vertexodessa]

@kkbin505 you are right to point this out, there seems to be a regression after devourer update. However the old devourer + alink worked for me on rtl8812au, so I think it's not the MCS issue. increasing the MCS decreases the air time, so the issue is less visible.
thus I disagree with:

This was latent until devourer 5f099ee ("drop DEVOURER_TX_HT_MCS gate") made the uplink actually reach the air. Before that fixed_rate stayed at MGN_1M, and CCK is illegal on the 5 GHz channels this link runs on, so the frames were never transmitted

---

since the PR can help to mitigate the issue and adds a useful feature (MCS switch for uplink in the menu), I would like to keep the code, but the PR and commit description should be updated. WDYT?

[vertexodessa]

P.S. please keep the default as is, I think the TX issue is unrelated to MCS

[vertexodessa]

OpenIPC/devourer#354

I think this should be a correct fix for the TX issue (+related change in PixelPilot to disable retries). Currently devourer retries every packet 12 times which leads to the channel overflow.