Radio failsafe with CRSF (continuation of discussion from 4.1)

4.4 is stable release for Rover, or did I miss something? Always a bridesmaid, never a bride…

I believe 4.4.0 is the last stable Fw for rover. 4.4.4 for plane and copter. 4.5 beta has some changes that helps with some FC to RX communication issues that sometimes cause a radio failsafe. Hopefully soon 4.5 will be an official stable release.

1 Like

For info-
I have been calling my issue ‘loss of bind’ but I think it would be more accurate to say its receiver firmware corruption. Its triggered by the RX dropping link rate from 150 to 50Hz.
Previously I had not experienced this with the nano pro, which was not immune from RC failsafe but it seemed to recover after 6 seconds. I purchased additional nano pros to replace my nanos but unfortunately this morning a nano pro permanently disconnected after a link rate drop and had the usual solid red light.
I solution could be to fix the link rate at 50hz, but the system seems to ignore this setting and still uses dynamic. In my last contact with TBS support they have admitted there is a firmware problem that causes the link to jump back to 150hz when it shouldn’t. I suspect this is not the only problem with the firmware.

Which firmware version are you talking about? I haven’t noticed anything unusual with version 6.19 so far.

I was on 6.19 but on the advice of TBS I tried the latest beta. It made no difference.
I cant imagine what it is with my setup that causes this issue. I know most people are not having this problem. I thought it could be my Ethos radio but Ive had contact with people with other systems (opentx etc) that its also happening to.
FrSky X20s (Ethos)
Matek H743 Wing
Arducopter 4.5.1 (and previous versions)
Nano RX (3 having this problem)
TX unit - one full size and one nano bay
SIK telemetry radio.

I did go off on a wild goose chase because I first noticed it seemed to occur when near a local power cable. Then it seemed to occur when I turned on the VTX. Of course both of these things were inducing the CRSF to drop into 50Hz mode, which is the real culprit.

Can you please take a photo of your installation? The distances between the various antennas are particularly interesting.

Its a large quad (14" props) and the antennas are well spaced. In any case it still occurs with VTX and Sik433 disconnected. Only GPS and CRSF still on. These things may cause the dynamic link rate to drop earlier but the result is the same. RTL.

(Thats not my lounge carpet)

The separation of the antennas is probably ok. It also looks cleanly built.

What is not so clear is whether the Crossfire antenna is original and whether it is at the bottom of the base?

Its a standard CRSF dipole, mounted mid-frame.

Update. Nothing good to report.
TBS confirmed there was a problem that the RC link speed menu selector was not working properly. When you attempt to fix the link rate at 50Hz ‘something’ is causing it to jump back to 150Hz and then rapidly cycle 150/50.
Im having a loss of bind (probably RX firmware getting screwed up) caused when the link drops from 150 to 50. Being able to lock it at 50 would at least get around the main problem, if it worked.
CRSF 6.33 (beta) has just been released. I knew deep down it wouldn’t fix it but gave it a shot anyway. Much worse. Cant keep a link for more than a couple of minutes. Link rate still ignored. Also after update, a servo got driven hard over and smoked.
Im using the same radio (X20s Ethos) and same RX in a Betaflight 5" quad without issues.
Im convinced something with Ardu-CRSF coms is at the bottom of this.
Here, its probably the 10th time I have re-bound. I go into the RX settings and the bind is lost again. It also happens if I just leave it.

Hi guys,

Today I had something strange and lost a brand new Zohd Altus.
I’m using a crossfire nano rx and after a first flight, I takeoff and after 40 seconds I face something similar.
around 100 feets from the takeoff point the crossfire lost bind with radio exactly in the moment of crossfire switching from 150 to 50, Is this related to your problem @Vince_Hogg ?


Nano or Nano Pro RX?

Yes. Welcome to my problem. That is exactly my issue. We should try to isolate what similarities we have. What is your radio system and what FC?

Did you try to fix the rate at 50hz and notice it dosent work? In fact it makes it worse because the 150-50 switch happens much more frequently.
If you succeed getting past the range when the system automatically changes from 150 to 50, you should be ok for a long range flight.
There is an increasing number of people reporting this. I hope it will soon be looked at as a serious issue.
Im now getting the same problem with nano and nano pro. Previously I mistakenly thought the pro was immune to this but its not.

I’m using a Nano SE receiver

Hi @Vince_Hogg ,

I didn’t realize that was a problem, today after the crash I was looking this forum and found your post.
I have at least 5 or 6 planes running ardupilot 4.x and tbs nano rx and is working nicely for more than 2 years.
What I saw is the hardware version and bootloader version of the nano rx se is different. The SE firmware is the same (Firmware 6.19, Hardware 1.01 and Bootloader 2.04) while the working version of RX nano is (Firmware is 6.19, Hardware 1.33 and bootloader 2.09 - If I not wrong).
Another thing is , always when I bind the older receivers - rx nano only - always the bind procedure update the firmware and after that the bind screen appear bind sucess, and this SE the bind is always showing bind message box - I had to close and reboot the receiver.
I made a first and perfect fly, and in the second one I had this bind lost problem - in the first flight I had the same message of rate change 150 to 50 and nothing happens.
An strange thing what happen in the problematic flight was, when I lost the radio, I lost de video too - the video was frozed and the artificial horizon was wrong as the other information on the screen was frozed too. I had to reboot the DJI goggles 2 to regain video and OSD.

Have you tried the ExpressLRS group or Discord channel? This seems specific to ELRS and not necessarily ArduPilot (though relevant and good to know!).

I had a really good experience on their Discord a while back when seeking help with some newly released features.

Back on the topic at hand - does this happen if you use a binding phrase? Or is it unique to having used the manual/traditional-style binding procedures?

Hi,
me and my friend Rodrigo has posted in groups about this problem and if we can have a satisfactory answer or update I will post here. What you mean with binding phrase ?
The binding process was made as all others, first powering a fresh new receiver while the transmitter is in the bind mode. After that, in some moment at bench, the receiver lost the bind - and I was thinking I made some mistake, so I rebind - pressing bind button while the radio was in bind mode.

Details on using a binding phrase can be found here:

Binding ExpressLRS - ExpressLRS

It’s the only method I use.

I don’t know if there is this phrase in the crossfire.

I apologize, I may have conflated Crossfire and ExpressLRS in this case.