Plane: incorrect CRSF rxrssi displayed on Mission Planner HUD

[EjectSteve]

Bug Report

I am seeing what appears to be incorrect CRSF rxrssi behavior.

Test setup:

• Flight controller and CRSF receiver remain powered throughout the test.
• Transmitter is turned on and connected normally.
• Mission Planner Status shows rxrssi = 100.
• I then turn the transmitter completely OFF.
• The receiver remains powered and connected to the flight controller via CRSF.

Result:

• ArduPilot correctly detects the loss of the RC signal and enters RC failsafe.
• However, Mission Planner Status continues to show rxrssi = 100.
• It remains at 100 rather than changing to reflect the loss of the transmitter.

This is reproducible with both:

• ExpressLRS receiver
• TBS Crossfire receiver

It is also reproducible on both:

• ArduPlane 4.4.4
• ArduPlane 4.7.0

The receiver is still powered and the CRSF serial connection between the receiver and FC is still active. Only the RF link from the transmitter to the receiver has been removed.

I would expect rxrssi to reflect the receiver's current RF signal condition rather than remain at 100 after the transmitter has been switched off.

The fact that ArduPilot simultaneously enters RC failsafe seems to indicate that it is detecting the transmitter loss, while rxrssi is not being updated appropriately.

[IamPete1]

Do you have the RC option set to use link quality "11: Use Link Quality instead of RSSI for RX signal strength"? (https://ardupilot.org/plane/docs/common-rc-options.html#rc-options)

As far as I can tell both the RSSI and link quality are coming directly from the receiver, ArduPilot does not change the values. So if the RSSI is being reported as 100 then that is because that is what the receiver is telling us. However, I have not confirmed this. If you have a bin log of your testing that might help.

One thing I do notice looking at the parser is that we seem to get RSSI from several different messages. Its not clear to me if its expected for a receiver to send all the messages.

For example we put both the RC and TX RSSI in to the same variable here:

ardupilot/libraries/AP_RCProtocol/AP_RCProtocol_CRSF.cpp

Lines 638 to 660 in 371990d

	// process link statistics to get RX RSSI
	void AP_RCProtocol_CRSF::process_link_stats_rx_frame(const void* data)
	{
	const LinkStatisticsRXFrame* link = (const LinkStatisticsRXFrame*)data;
	if (_use_lq_for_rssi) {
	_link_status.rssi = derive_scaled_lq_value(link->link_quality);
	} else {
	_link_status.rssi = link->rssi_percent * 255.0f * 0.01f;
	}
	}
	// process link statistics to get TX RSSI
	void AP_RCProtocol_CRSF::process_link_stats_tx_frame(const void* data)
	{
	const LinkStatisticsTXFrame* link = (const LinkStatisticsTXFrame*)data;
	if (_use_lq_for_rssi) {
	_link_status.rssi = derive_scaled_lq_value(link->link_quality);
	} else {
	_link_status.rssi = link->rssi_percent * 255.0f * 0.01f;
	}
	}

So if a receiver is sending both then its essentially random whether you get the RX or TX RSSI. It seems to me that we should only accept the RX packet and ignore the TX one. @andyp1per what you you think?

[EjectSteve]

I did not have RC Option 11 enabled originally, but I have now enabled it and tested again. Same result.

This FC does not have blackbox logging, so I don't have a BIN log from tests. With RC Option 11 enabled, is the value displayed in the Mission Planner HUD/Status still rxrssi, or is there another field I should be looking at to verify the CRSF link quality?

I captured the CRSF UART traffic directly from the receiver to PC using a USB/serial adapter at 420000 baud.

With the transmitter on, the receiver sends 0x14 Link Statistics frames such as:

C8 0C 14 1F 00 64 0D 00 17 08 00 00 00 48

The relevant fields are:
uplink RSSI = 31
uplink LQ = 100%
uplink SNR = 13 dB

After I turn the transmitter completely off, the receiver continues sending 0x14 frames for approximately .5 seconds such as below

C8 0C 14 20 00 00 0D 00 17 08 00 00 00 2F

So the receiver is explicitly reporting:
uplink RSSI = 32
uplink LQ = 0%

Less than one second later the receiver stops transmitting CRSF data altogether which was a surprise (for me)

CRSF Capture.txt