FrSky SPI D8 - significant range reduction starting from PR #11380

[limonspb]

Describe the bug

Master branch starting from build # 2644 (PR #11380) has a significant range reduction for FRSKY SPI receiver with D8 protocol (FRSKY_D)
We got a report of that in Discord, then in Slack by another guy.
I was able to reproduce it with my whoop as well and narrowed it down to this PR:
#11380

To Reproduce

How i did it, watch out it can damage your radio!!! (or use range check function in EdgeTX)

1. flash 4.3 RC4 or anything starting from the build # 2644
2. Bind, set up your drone, and make sure it flies.
3. Take off the antenna from the radio to purposely reduce the range. (or use range check function in EdgeTX)
4. Drone starts failsafing in 1 meter away from the pilot already.

Expected behavior

For any builds prior to #2644 (for example RC3) the range in the described conditions is at least 5-10 meters.

I have verified it multiple times flashing back and forth 2644 and 2643 builds.
2643 range - 5 meters.
2644 range - 1 meter.

Flight controller configuration

# 

# diff

# version
# Betaflight / STM32F411 (S411) 4.3.0 Apr  9 2022 / 22:23:37 (642689dfc) MSP API: 1.44
# config: manufacturer_id: MTKS, board_name: MATEKF411RX, version: a074838b, date: 2021-06-14T21:36:54Z

# start the command batch
batch start

board_name MATEKF411RX
manufacturer_id MTKS

# serial
serial 1 2048 115200 57600 0 115200

# aux
aux 0 0 0 1700 2100 0 0
aux 1 27 1 1700 2100 0 0
aux 2 13 3 1700 2100 0 0
aux 3 35 1 1700 2100 0 0

# vtxtable
vtxtable bands 6
vtxtable channels 8
vtxtable band 1 BOSCAM_A A FACTORY 5865 5845 5825 5805 5785 5765 5745 5725
vtxtable band 2 BOSCAM_B B FACTORY 5733 5752 5771 5790 5809 5828 5847 5866
vtxtable band 3 BOSCAM_E E FACTORY 5705 5685 5665    0 5885 5905    0    0
vtxtable band 4 FATSHARK F FACTORY 5740 5760 5780 5800 5820 5840 5860 5880
vtxtable band 5 RACEBAND R FACTORY 5658 5695 5732 5769 5806 5843 5880 5917
vtxtable band 6 IMD6     I CUSTOM  5732 5765 5828 5840 5866 5740    0    0
vtxtable powerlevels 1
vtxtable powervalues 25
vtxtable powerlabels 25

# master
set dyn_notch_q = 250
set dyn_notch_min_hz = 90
set acc_calibration = -347,262,-4274,1
set rx_spi_protocol = FRSKY_D
set dshot_idle_value = 600
set motor_pwm_protocol = DSHOT300
set failsafe_delay = 4
set failsafe_recovery_delay = 0
set align_board_roll = 180
set align_board_yaw = 90
set force_battery_cell_count = 1
set yaw_motors_reversed = ON
set crashflip_motor_percent = 100
set small_angle = 180
set runaway_takeoff_prevention = OFF
set osd_tim1 = 17
set osd_tim2 = 1
set osd_vbat_pos = 2401
set osd_rssi_pos = 2105
set osd_link_quality_pos = 2137
set osd_tim_1_pos = 2422
set osd_throttle_pos = 2073
set osd_total_flights_pos = 2081
set vtx_band = 5
set vtx_channel = 8
set vtx_power = 1
set vtx_freq = 5917
set frsky_spi_tx_id = 98,70,1
set frsky_spi_offset = 17
set frsky_spi_bind_hop_data = 0,30,60,91,120,150,180,210,5,35,65,95,125,155,185,215,10,40,70,100,130,160,190,221,15,45,75,105,135,165,195,225,20,50,80,110,140,170,200,230,25,55,85,115,145,175,205,0,0,0
set gyro_1_align_yaw = 1800
set stats_min_armed_time_s = 50
set stats_total_flights = 22
set stats_total_time_s = 1683

profile 0

# profile 0
set vbat_sag_compensation = 80
set anti_gravity_gain = 0
set iterm_rotation = ON
set iterm_relax_type = GYRO
set iterm_relax_cutoff = 20
set p_pitch = 83
set i_pitch = 162
set d_pitch = 89
set f_pitch = 171
set p_roll = 76
set i_roll = 153
set d_roll = 82
set f_roll = 162
set p_yaw = 108
set i_yaw = 162
set f_yaw = 162
set d_min_roll = 82
set d_min_pitch = 89
set simplified_pids_mode = OFF

rateprofile 0

# rateprofile 0
set tpa_breakpoint = 1250

# end the command batch
batch end

# 

resource show all
Currently active IO resource assignments:
(reboot to update)
--------------------
A00: FREE
A01: GYRO_EXTI
A02: SERIAL_TX 2
A03: FREE
A04: GYRO_CS 1
A05: SPI_SCK 1
A06: SPI_MISO 1
A07: SPI_MOSI 1
A08: RX_SPI_CC2500_TX_EN
A09: FREE
A10: FREE
A11: USB
A12: USB
A13: RX_SPI_CC2500_LNA_EN
A14: RX_SPI_CC2500_ANT_SEL
A15: RX_SPI_CS
B00: ADC_BATT
B01: ADC_CURR
B02: RX_SPI_BIND
B03: SPI_SCK 3
B04: SPI_MISO 3
B05: SPI_MOSI 3
B06: MOTOR 2
B07: MOTOR 3
B08: MOTOR 4
B09: LED
B10: MOTOR 1
B11: FREE
B12: OSD_CS
B13: SPI_SCK 2
B14: SPI_MISO 2
B15: SPI_MOSI 2
C00: FREE
C01: FREE
C02: FREE
C03: FREE
C04: FREE
C05: FREE
C06: FREE
C07: FREE
C08: FREE
C09: FREE
C10: FREE
C11: FREE
C12: FREE
C13: LED 1
C14: RX_SPI_EXTI
C15: BEEPER
D00: FREE
D01: FREE
D02: FREE
D03: FREE
D04: FREE
D05: FREE
D06: FREE
D07: FREE
D08: FREE
D09: FREE
D10: FREE
D11: FREE
D12: FREE
D13: FREE
D14: FREE
D15: FREE
E00: FREE
E01: FREE
E02: FREE
E03: FREE
E04: FREE
E05: FREE
E06: FREE
E07: FREE
E08: FREE
E09: FREE
E10: FREE
E11: FREE
E12: FREE
E13: FREE
E14: FREE
E15: FREE

Currently active Timers:
-----------------------
TIM1: FREE
TIM2:
    CH3 : MOTOR 1
TIM3: FREE
TIM4:
    CH1 : MOTOR 2
    CH2 : MOTOR 3
    CH3 : MOTOR 4
TIM5: FREE
TIM6: FREE
TIM7: FREE
TIM9: FREE
TIM10: FREE
TIM11: FREE

Currently active DMA:
--------------------
DMA1 Stream 0: SPI_MISO 3
DMA1 Stream 1: FREE
DMA1 Stream 2: FREE
DMA1 Stream 3: SPI_MISO 2
DMA1 Stream 4: SPI_MOSI 2
DMA1 Stream 5: SPI_MOSI 3
DMA1 Stream 6: TIMUP 4
DMA1 Stream 7: TIMUP 2
DMA2 Stream 0: SPI_MISO 1
DMA2 Stream 1: FREE
DMA2 Stream 2: FREE
DMA2 Stream 3: SPI_MOSI 1
DMA2 Stream 4: ADC 1
DMA2 Stream 5: FREE
DMA2 Stream 6: FREE
DMA2 Stream 7: FREE

# 

Flight controller

MATEKF411RX (BetaFPV F4 1S AIO Whoop Flight Controller)

Other components

No response

How are the different components wired up

No response

Add any other context about the problem that you think might be relevant here

The same drone setup with REDPINE does not show the problem and REDPINE range remains 5-10 meters regardless of the firmware build.

[KarateBrot]

ℹ Small tip for RC link tests in general

The cage of a microwave might as well help with simulating a failsafe. This potentially saves you from having to screw off the antenna.

Close the microwave door with a transmitter inside and the RC signal gets attenuated a lot.

https://en.wikipedia.org/wiki/Faraday_cage

[SteveCEvans]

@KarateBrot The microwave trick is one I use a lot. Very effective.

@limonspb Testing using a CRAZYBEEF4FR with both 4.2.11 and current master 642689d I'm seeing no difference. Both links are stable until I shut the microwave door.

Does anybody have both a MATEKF411RX and a CRAZYBEEF4FR to compare the two?

[limonspb]

@KarateBrot The microwave trick is one I use a lot. Very effective.

@limonspb Testing using a CRAZYBEEF4FR with both 4.2.11 and current master 642689d I'm seeing no difference. Both links are stable until I shut the microwave door.

Does anybody have both a MATEKF411RX and a CRAZYBEEF4FR to compare the two?

On latest master my link is also stable till I get far or unscrew antenna. The link is not totally messed up just way smaller range. So if your microwave killing the signal either way, or not killing it enough it's not a lot of sense. Need to compare the range, maybe it's even connected with the fact the quad flies, not just sits.

[SteveCEvans]

Using the EdgeTx RANGE function (next to BIND in the first model settings page) I see RSSI drop to 0 with master, but not with 4.2.11. Something to chase now...

[limonspb]

Using the EdgeTx RANGE function (next to BIND in the first model settings page) I see RSSI drop to 0 with master, but not with 4.2.11. Something to chase now...

@KarateBrot , @SteveCEvans just told me about the range check function in Edge TX LOL. It sits next to the bind button in the model settings. It reduces the range/power and i am able to reproduce the behavior with this one too.

[SteveCEvans]

Spent some time bisecting between 4.2.11 and master, and the change is indeed at

fc8640154ac2bc09c7b2fa0fcdc54beab05e2c3c is the first bad commit
commit fc8640154ac2bc09c7b2fa0fcdc54beab05e2c3c
Author: Steve Evans <Steve@SCEvans.com>
Date:   Wed Feb 2 21:05:58 2022 +0000

    Interrupt/DMA driven SX1280 interaction for ELRS

[limonspb]

Spent some time bisecting between 4.2.11 and master, and the change is indeed at

fc8640154ac2bc09c7b2fa0fcdc54beab05e2c3c is the first bad commit
commit fc8640154ac2bc09c7b2fa0fcdc54beab05e2c3c
Author: Steve Evans <Steve@SCEvans.com>
Date:   Wed Feb 2 21:05:58 2022 +0000

    Interrupt/DMA driven SX1280 interaction for ELRS

cmon you could have trusted me :)
Just kidding, its good to double-check.

[SteveCEvans]

Actually, whilst it got a bit worse with that commit, even the commit before is a lot worse than 4.2.11.

With 4.2.11 when I got into range check mode the rxSpiExtiHandler() starts to get called a bit sporadically.

But with master, once in range check mode there is an interrupt, but the STATE_DATA state in frSkyDHandlePacket() isn't processed. Need to figure out why.

[SteveCEvans]

@MJ666 You're the expert on this code; any insight would be most appreciated.

[SteveCEvans]

I've tried reverting the following files to the 4.2.11 versions and that didn't help.

src/main/rx/cc2500_frsky_d.c
src/main/rx/cc2500_frsky_shared.c
src/main/rx/cc2500_frsky_shared.h
src/main/rx/cc2500_frsky_x.c

[limonspb]

I've tried reverting the following files to the 4.2.11 versions and that didn't help.

src/main/rx/cc2500_frsky_d.c
src/main/rx/cc2500_frsky_shared.c
src/main/rx/cc2500_frsky_shared.h
src/main/rx/cc2500_frsky_x.c

But the PR #11380 did not change any of these files.
This PR is where the problem became really bad, didn't it?
Wondering if it makes sense to find out why #11380 made things worse first. And make the performance similar to what we had in RC3 for FRSKY SPI if possible.

[SteveCEvans]

Let me go back and compare AGAIN. I wasn't getting a clear night/day difference with PR #11380, but from 4.2.11 to master it really does make a difference.

[SteveCEvans]

OK, now getting consistent results with #11380.

A bodge fix for this is the below, reverting the call to rxUpdateCheck() to the RX checker routine. Now I'm onto something.

diff --git a/src/main/rx/rx.c b/src/main/rx/rx.c
index 6e299c1..bb37a00 100644
--- a/src/main/rx/rx.c
+++ b/src/main/rx/rx.c
@@ -473,6 +473,8 @@ bool rxUpdateCheck(timeUs_t currentTimeUs, timeDelta_t currentDeltaTimeUs)
     UNUSED(currentTimeUs);
     UNUSED(currentDeltaTimeUs);
 
+    rxFrameCheck(currentTimeUs, currentDeltaTimeUs);
+
     return taskUpdateRxMainInProgress() || rxDataProcessingRequired || auxiliaryProcessingRequired || !failsafeIsReceivingRxData();
 }
 
diff --git a/src/main/scheduler/scheduler.c b/src/main/scheduler/scheduler.c
index f43cbe1..6f1f14c 100644
--- a/src/main/scheduler/scheduler.c
+++ b/src/main/scheduler/scheduler.c
@@ -506,7 +506,7 @@ FAST_CODE void scheduler(void)
                 // Check to for incoming RX data. Don't do this in the checker as that is called repeatedly within
                 // a given gyro loop, and ELRS takes a long time to process this and so can only be safely processed
                 // before the checkers
-                rxFrameCheck(currentTimeUs, cmpTimeUs(currentTimeUs, getTask(TASK_RX)->lastExecutedAtUs));
+ //               rxFrameCheck(currentTimeUs, cmpTimeUs(currentTimeUs, getTask(TASK_RX)->lastExecutedAtUs));
             }
 
             // Check for failsafe conditions without reliance on the RX task being well behaved

[MJ666]

@MJ666 You're the expert on this code; any insight would be most appreciated.

Will see what i can do. Normally im not flying D8 mode anymore since D16 was working well with latest code. Likely since #11380 is not changing any of the FRSky code D16 may also be affected. I did not upgrade any off my FRSky SPI based copters recently and i'm mostly an LOS flyer i would not even detect the range issue? If #11536 does not fix the problem i can take a look. There is also an SPI code related fix pending. May be this could also be related.