Upon Arm, RX stops communicating with FC (ELRS EP2 RX, Arducopter 4.1.0RC4)

Upon Arm, RX stops communicating with FC (ELRS EP2 RX, Arducopter 4.1.0RC4)

Firmware: Arducopter 4.1.0RC4

See also

Is this a bug in Arducopter or ELRS or a configuration error?

FC: Flywoo F745

“Flywoo GOKU GN745 2-6S AIO Whoop/Toothpick Flight Controller w/ 40A 32Bit 4in1 ESC”

RX: Happymodel EP2 Firmware 1.1.0

“Happymodel 2.4g ExpressLRS EP2 RX Receiver module”

GCS: Mission Planner 1.3.75 on Win10

TX: Taranis running OpenTX 2.3.14

TX module: Happymodel ES24TX running ExpressLRS 1.1.0

“Happymodel ES24TX 2.4GHz ExpressLRS ELRS Long Range Low Latency High Re-flashed Micro TX Module”

Description of issue:

Before arm, the RC inputs make it to the flight controller as shown in Mission Planner (monitoring the inputs setup, radio calibrations tab)

After arm, almost immediately, Arducopter goes into failsafe mode (low throttle). Also, there are no RC input changes shown in Mission Planner when I wiggle the control sticks. Also, the telemetry from the RC to the Taranis says “sensor lost” meaning the Taranis is not getting the sensor telemetry data from the FC (battery voltage, etc). HOWEVER, the Taranis shows it is still connected to the RX (showing the RSSI telemetry from the RX). AND the RX shows a solid light, indicating it is still bound.

Reboot FC reconnects RX:

If I hard reboot the FC (power cycle) or if I reboot it from MP (using ctl F secret menu and “reboot pixhawk” button), then the RX is connected again MP shows the values of the channels responding when I wiggle the TX sticks.

Independent of UART:

I tried this on UART3 and UART4. Same exact symptoms.

Independent of Arm method:

This problem occurs if I arm using the down right hold on the throttle/yaw stick on the TX, and if I use the “arm” button in MP under “actions” menu.

Reproducibility:

I have tried this on two FCS and two RXs. Exactly the same problem. The second time I tried it, only the battery and RX were connected to the FC (no other peripherals connected).

Conclusion:

After arm, the RX is still bound and communicates with the TX. However, the RX loses communication with the FC.

Why would arming the FC cause the RX communication to stop?

Key parameters:

ARMING_ACCTHRESH,0.75

ARMING_CHECK,1

ARMING_MIS_ITEMS,0

ARMING_RUDDER,2

FLTMODE_CH,12

FS_CRASH_CHECK,1

FS_EKF_ACTION,1

FS_EKF_THRESH,0.8

FS_GCS_ENABLE,0

FS_GCS_TIMEOUT,5

FS_OPTIONS,16

FS_THR_ENABLE,1

FS_THR_VALUE,975

FS_VIBE_ENABLE,1

RC_OPTIONS,0

RC_OVERRIDE_TIME,3

RC_PROTOCOLS,512

RC_SPEED,490

RSSI_ANA_PIN,-1

RSSI_CHAN_HIGH,2000

RSSI_CHAN_LOW,1000

RSSI_CHANNEL,0

RSSI_PIN_HIGH,5

RSSI_PIN_LOW,0

RSSI_TYPE,3

SERIAL3_BAUD,115

SERIAL3_OPTIONS,0

SERIAL3_PROTOCOL,23

This sounds like the issue I was seeing on an F7 with tracer, but the fix is in rc4. It’s almost certainly a timing issue, but its strange that you lose connection and it never then comes back.

Update: This seems to be an issue with the Flywoo F745 FC and not just expressLRS.
I tried a different receiver technology: Frsky XM+ receiver.
I found it would not communicate with the FC if it the TX was on when powering up the FC.
The reason must be due to the boot sequence: The FC boots slowly; by the time the FC has booted, the RX is bound to the TX but the FC for some reason does not register it.
However, if the TX is off when the FC is booted, then the RX is not bound yet, and after the FC boots, if the TX is turned on to bind the RX, there is a connection.
So it is something in the handshake between the FC and the RX that is not timed right for Frsky XM+. I suspect it is a similar problem for ELRS.