Message - No RC Receiver

Quaxwilly · May 25, 2021, 10:01am

Plane uses a different strategy/code.

Based on my experience it’s not an issue of RC-link, because it happens in every situation/distance. I think it’s a critical internal timing - maybe on not so powerful FCs…

It needs a change of the code and a new build.

Quaxwilly · May 28, 2021, 7:26am

I built a version with 500ms/2Hz and will test it in real flight at the weekend - if possible (we had very nasty weather the last time here in Germany).

If all is ok, I will start a PR.

Quaxwilly · May 29, 2021, 12:10pm

I tested yesterday, but unfortunately without success.

It seems, the warning is happening especially when motor is on. It will also happen in soaring and other modes, but only in rare cases.

I had a look at the logfile, but you can’t see any missing RC value there.

So I’ll have to investigate and measure the signal-level and the stability of supply-voltage of the receiver at the desk. Maybe I can manipulate the signal or voltage to cause the warning.

Allister · June 1, 2021, 1:15am

It’s happened to me with three different setups (two planes, but one was rebuilt with a new flight controller). I guess it’s possible all three had voltage issues, but I wouldn’t put a lot of faith in that as the cause of the problem.

Quaxwilly · June 13, 2021, 1:19pm

I had some different changes and tests on desk and in real flight, but couldn’t find out the root-cause till now.
I’m still working on that issue - if my job will allow it

Quaxwilly · June 13, 2021, 1:21pm

On what FCs you have the problem? Matek F405-wing?

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