Message - No RC Receiver

https://1drv.ms/u/s!AgyvhCRrlh2RmFnnat3pruCmPh33?e=EUD9jX

After this flight, a screen was made that I attached above.

as far as i can tell that message was generated after disarming, so not caught in the logs unless you set LOG_DISARMED = 1
i checked again and yes, it’s likely due to AP not registering a valid RC input for > 200 ms, see https://github.com/ArduPilot/ardupilot/blob/74045ba50af6ced91afe4d6a1b197e08aacc7d79/ArduPlane/GCS_Plane.cpp#L115 for reference.
i can’t spot any suspects in the log, so hard to tell what might have caused that flag to come up.

The screen shows two such messages, the first was during the flight

When it’s happened to me there’s no record in the logs of any RC related events, and nothing on the GCS.

I’m seeing that message too on current ArduPlane V4.1.0dev.
MatekF405-Wing
X9E
R-XSR
SBus
I’m on yaapu 1.9.1 beta2 on my transmitter, but it seems to me, that yaapu is just displaying it.

That CRT(critical)-Info is based on _sensor_status_flags, so maybe the time between two SPort-requests from receiver to FC is sometimes slower than 200ms?
That’s just an assumption, I didn’t deep-dive into the code so far.
Maybe it will help to increase that timeout a little. If I would find the time I could test that in the next weeks.

1 Like

Something similar happened to me. Matek F405, Slim+ and F.Port. During the flight the controller changed his mind about the receiver protocol and said it was DMS (Spektrum). RC channels went crazy. Changed flight modes, maximum aileron and elevator deflections. Death spiral in full swing. Fortunately 100m altitude, empty field. Four seconds later and at a speed of 30 m/s it was all over.

First and last flight with F.Port. Back to SBUS after rebuild. Stable release 4.0.9 not so stable.

A word of warning when using F.Port.

I had a look at the code this long weekend and I’ve seen:

That Problem of “CRT: No RC Receiver” should only happen on Plane. On Copter there is used a different logic.
To prevent that message, a throttle-signal higher than THR_FS_VALUE has to be received within 200ms.

So check that value, if it’s low enough. Hint: My transmitter sends 988µs while the FC receives 982µs!

Maybe the voltage-level of the SBus signal is a little critical - it depends on the receiver. If possible have a look at it and try to stabilize the level e.g. by a pull up/down resistor. I also have to measure/check/manipulate that.

If all that will not help, I’ll try to increase the 200ms to 250ms in the code for a test.

I have the value of this parameter set to 925. The value of the C3 channel does not fall below 985. This message can appear with any throttle level.
Why is this message not written to the log file?

If the message was being triggered by the THR_FS_VALUE then there should be a message in the log or on Mission Planner and I’m only seeing it in the Yaapu screen. I’ve run into a problem in the past having the THR_FS_VALUE too close to the min-throttle value and that was triggering full failsafes.

I’m seeing this message on two planes, both with Jumper R8 receivers. One with Matek F405-Wing and the other Matek F405-WSE.

The WSE hasn’t flown yet, but the image below is from bench setup yesterday. It’s on AP 4.0.9

The F405-Wing has flown a bunch, but I don’t recall the issue from last season but it’s happening now. It’s on AP 4.0.7

The radio is a TX16S running Yaapu 1.9.3 Beta 4

Wow, I need to clean my screen.

Hi,
the ardupilot AP_RCTelemetry library regularly checks the MAV_SYS_STATUS_SENSOR flags at around 60Hz and if any bit is high creates a status text message and sends it on the passthrough link, those are “private” messages to the AP_RCTelemetry library, that’s the reason why you do not see them as regular status text messages on your GCS.
You should have a log of the SYS_STATUS message in your tlog but chances are high those are not logged fast enough to catch a no rc receiver shorter of 200ms.

So my personal idea on this is that you are actually getting a genuine “no rc receiver” (lost rc frames) for some reason for a period shorter than 200ms or whatever the failsafe is set to, so no failsafe triggering and no logging in SYS_STATUS and since the AP_RCTelemetry library checks this every 17ms it’s the only one catching it.

I think it might be safe to delay the AP_RCTelemetry checks down to 500ms i.e. 2Hz without affecting flight safety since those bits are there to simply alert the pilot, this should prevent (mostly) these messages from being sent, what do you think @peterbarker?

1 Like

Thanks @yaapu.

Why does this only show up on Plane and not copter?

Do you think this is a sign of an actual issue with the RC link or is it a by-product of an overly high sample rate?

Is the change to the AP_RCTelemetry checks something I can do in Mission Planner or does it need a change in the code (aka: something out of my reach or knowledge level.)

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.

1 Like

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.

1 Like

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.

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.

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 :roll_eyes:

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

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.

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.

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.