Summary
The OpenIPC-FPV community reports dis_cca (EDCCA disable) "doubles range / removes stuttering" on the rtl88x2eu. I implemented and measured it in devourer (Jaguar3, 8822EU) and got a null for monitor-mode RX. Filing this so someone with a real bidirectional / long-range link (not a bench monitor inject) can verify the community claim, because the mechanism suggests the benefit lives on a path devourer's monitor inject doesn't exercise.
Vendor recipe (rtl88x2c/e rtw_proc.c dis_cca proc)
# disable:
MAC 0x520[15] = 1 # BIT_DIS_EDCCA
MAC 0x524[11] = 0 # BIT_EDCCA_MSK_COUNTDOWN
BB 0x1a9c[20] = 0
BB 0x1a14[9:8] = 3
BB 0x1d58[0xff8] = 0x1ff # <-- "OFDM CCA off"
# enable = the inverse
What I measured (8822EU, swept B210 AWGN, DEVOURER_DIS_CCA A/B — tests/dis_cca_onair.sh)
- Full recipe → RX goes deaf. The
0x1d58[0xff8]=0x1ff write is the OFDM-CCA-off write (devourer's CW-tone path uses it to stop OFDM detection). Delivery collapsed ~6800 → ~10 frames. Do not apply the BB half on a live RX.
- MAC EDCCA-disable only (
0x520[15]/0x524[11]) → exact null. Delivery within 1% at every noise gain (33700 vs 33400 hits over 46–76 dB; IGI pinned, false-alarm identical).
Why (hypothesis)
EDCCA gates TX deferral (the STA holds off transmitting when it senses in-band energy above the ED threshold), not RX decode. devourer injects in monitor mode, which already bypasses the MAC CSMA/EDCCA backoff — so the "keep transmitting through interference" benefit the community sees is already inherent to devourer's inject path, and a runtime RX-side EDCCA knob adds nothing.
What's in the repo
RtlJaguar3Device::SetCcaMode (DEVOURER_DIS_CCA=1) — J3 research knob, writes only the safe MAC EDCCA bit, not on IRtlDevice.
tests/dis_cca_onair.sh — swept-AWGN delivery A/B rig.
What would confirm/refute this
- A real link (both ends associated / a live video stream), co-channel interferer, dis_cca off vs on — does the TX side keep going where it otherwise defers? (Needs a non-monitor TX path, or proof monitor inject truly ignores ED.)
- Or a bench that can actually bury the wanted signal (the near-field B210 limit prevented a delivery cliff here) to stress the RX-side ED gate directly.
Refs: PR #198 (the measurement + safe knob), the #190 DIG null, #195 (per-packet power probe).
Summary
The OpenIPC-FPV community reports dis_cca (EDCCA disable) "doubles range / removes stuttering" on the rtl88x2eu. I implemented and measured it in devourer (Jaguar3, 8822EU) and got a null for monitor-mode RX. Filing this so someone with a real bidirectional / long-range link (not a bench monitor inject) can verify the community claim, because the mechanism suggests the benefit lives on a path devourer's monitor inject doesn't exercise.
Vendor recipe (rtl88x2c/e
rtw_proc.cdis_cca proc)What I measured (8822EU, swept B210 AWGN, DEVOURER_DIS_CCA A/B —
tests/dis_cca_onair.sh)0x1d58[0xff8]=0x1ffwrite is the OFDM-CCA-off write (devourer's CW-tone path uses it to stop OFDM detection). Delivery collapsed ~6800 → ~10 frames. Do not apply the BB half on a live RX.0x520[15]/0x524[11]) → exact null. Delivery within 1% at every noise gain (33700 vs 33400 hits over 46–76 dB; IGI pinned, false-alarm identical).Why (hypothesis)
EDCCA gates TX deferral (the STA holds off transmitting when it senses in-band energy above the ED threshold), not RX decode. devourer injects in monitor mode, which already bypasses the MAC CSMA/EDCCA backoff — so the "keep transmitting through interference" benefit the community sees is already inherent to devourer's inject path, and a runtime RX-side EDCCA knob adds nothing.
What's in the repo
RtlJaguar3Device::SetCcaMode(DEVOURER_DIS_CCA=1) — J3 research knob, writes only the safe MAC EDCCA bit, not onIRtlDevice.tests/dis_cca_onair.sh— swept-AWGN delivery A/B rig.What would confirm/refute this
Refs: PR #198 (the measurement + safe knob), the #190 DIG null, #195 (per-packet power probe).