Message - No RC Receiver

Allister · June 15, 2021, 12:33am

Three of them: Matek F405-Wing, F405-WSE, and a mRo x2.1 Rev 2.

Edit: I should add the mRo has been removed from service thanks to a direct hit from a scale warbird… But the two Matek boards are still in service.

Quaxwilly · June 17, 2021, 7:56am

I built a code to measure the time since the last valid rc-value (that’s the decision base of the message).
On desk the regular value is lower than 20ms in every case, so >200ms seems to be a good threshold.

But unfortunately I couldn’t reproduce the “critical warning” on desk to measure a value higher than 200. - so I need to fly.

Maybe the warning is correct and just a little more quick/sensitive then the RSSI?
After I have a warning and a corresponding value in flight, I will change the orientation of the antennas and test again. Currently they are 90° on one side and it’s possible to fly out of sight - but for a test I will e.g. pull them just out under the canopy.

UnknownPilot · June 17, 2021, 10:12am

Sorry for being OT but how do I get that “Wind warning” to show up in Yaapu, and where can I set a threshold? I wasn’t able to find anything on it, could be very useful to me.

AndreyI · June 17, 2021, 11:21am

This is a LUA script:

github.com

ArduPilot/ardupilot/blob/master/libraries/AP_Scripting/examples/plane-wind-failsafe.lua

-- warn the user if wind speed exceeds a threshold, failsafe if a second threshold is exceeded

-- note that this script is only intended to be run on ArduPlane

-- tuning parameters
local warn_speed = 10 -- metres/second
local failsafe_speed = 15 -- metres/second
local warning_interval_ms = uint32_t(15000) -- send user message every 15s

local warning_last_sent_ms = uint32_t() -- time we last sent a warning message to the user

function update()
	 local wind = ahrs:wind_estimate() -- get the wind estimate
	 if wind then
	    -- make a 2D wind vector
	    wind_xy = Vector2f()
 	    wind_xy:x(wind:x())
 	    wind_xy:y(wind:y())
	    speed = wind_xy:length() -- compute the wind speed
	    if speed > failsafe_speed then

This file has been truncated. show original

UnknownPilot · June 17, 2021, 3:09pm

Thanks, in that case I won’t be able to use it on my current planes (all only 1MB flash).

Quaxwilly · June 17, 2021, 3:10pm

As an interim conclusion I would say:

The SBUS signal connection between receiver and FC is very robust. I manipulated the receiver voltage and the signal levels in a wide range without problems on the communication. The communication only stops on very extreme levels.
The critical warning “CRT:NoRCReceiver” means “No valid RC-Receiver-Throttle signal above Failsafe-Throttle value for more than 200ms”
The ardupilot FW seems to work exactly as it should. That warning is an early warning about signal gaps.
Because I have four Matek F405-wing with R-XSR running and just one system shows that issue, it shouldn’t be a general problem. It seems to have the root cause in that single system.

So my next step is to measure continuously the values and to manipulate the system step by step:

to change the antenna orientation
to enlarge the distance between receiver and FC
to test a different receiver
to test a dual-receiver configuration

@Allister It seems you have that issue with all your FCs. So you should also have a look at your transmitter. (What transmitter/receiver are you using?)

If anybody has that issue, too, he should have a closer look at the radio connection and possible hash - and post the result here

Quaxwilly · June 18, 2021, 10:52am

Sorry, but that guess has been wrong:

Today in the morning I tested the system and the result has been very clear:

That big numbers are a “negative” result of an unsigned subtraction (-1 or -2).

So the current timing of the calls of millis() and plane.failsafe.last_valid_rc_ms is wrong. Because when millis() is called and after that a taskswitch with an update of RC is done, the value of plane.failsafe.last_valid_rc_ms is bigger than the former fetched millis() (see line 118).

To fix that, it’s necessary to correct the chronological sequence. First fetch plane.failsafe.last_valid_rc_ms, then fetch the current time millis() and then substract (see lines 118/119).

I’ll start a PR to correct that issue after a positive flight-test.

Allister · June 18, 2021, 9:30pm

I’m using a Radiomaster TX16S. The issue is only showing up on Planes using the Jumper R8 receivers. I have a copter using a Radiomaster R161 and no issues there. And depending on how far you want to go in the troubleshooting: I’ve also been using CRSF MicroTXV2 and RFD900 TXModV2 and of course no issues with those.

Thanks for looking into this!

Quaxwilly · June 19, 2021, 8:32am

It’s just an issue of plane-code.

I tested my fix in the morning in real flight and no more CRT:NoRCReceiver warnings popped up.

Quaxwilly · June 19, 2021, 11:25am

PR is started: https://github.com/ArduPilot/ardupilot/pull/17808

Allister · June 19, 2021, 10:23pm

Yes, I had forgot that when I wrote my reply. Good thing, because I have a student project coming up and they’ll be using R8s in copters so this is one less thing I need to worry about.

Quaxwilly · July 7, 2021, 12:38pm

PR #17808 has been merged into master today

AndreyI · July 30, 2021, 6:06pm

Is this change present in the latest beta 4?
Today I flew on beta 4 for the first time, this message appeared again, though only once.

kniuk · August 21, 2021, 1:59am

Willy, I just wanted to say thank you! This message was really annoying