I had an email this morning from TBS support.
They have just had a meeting about this issue and have ‘discovered a bug’. It should be fixed in 6.34.
1 Like
Hi Vince.
Good news! Thks.
I am following the discussion having the same problem. As I have also a bind problem. Mentioned in RCG: CRSF Nano. Anyone else losing bind? Now waiting for 6.34.
My setup:
- TBS Crossfire, large module with BT.
V 6.19 (was 6.33)
HW V 1.03
Bootl. V 2.05 - Nano Rx, 3 of them Nano 44, 3 others deep dug in, but at least one year+ old.
- FC: Matek H743-Wlite Ardupilot V 5.4.1 on plane on Uart Tx6 Rx6 serial 7
- Radio Horus x10S on OpenTx-X10 V 2.3.11-otx(4328055e)
M.
Same, been having very similar issues and I’m checking the TBS website for the firmware update daily!
I’m testing 6.34 at the moment. Seems they fixed it. I’m not sure when they will release it.
That’s encouraging - do they know the root cause of our specific issue?
I broke my shoulder recently so had plenty of time to update all of my various firmwares to very latest versions.
That’s when my unbinding problems started!
They are waiting on your feedback Vince! Have you flown it yet? A flight test will be important.
Hi Andy.
Just got in from flying; day 2
Yesterday, 35min mostly waypoint mission in and out of 150/50Hz changeover region. No problems.
Today, possible issue. Previously I believed the nano-pro behaved differently from the nano as it would reconnect after 6 seconds and not lose bind, however later testing contradicted this and it did sometimes lose bind as well. Today I had an RTL at about 200 mts but it reconnected and I was able to continue mission. On checking the logs I see that once again its exactly a 6 second disconnect but did not seem to be immediately after a 150>50hz change. I thought I had a standard nano in the quad but I see that I accidentally installed the pro. I will test again later after swapping RX. See logs inc radio log named 6.34
1 Like
Vince, please can you reflash 6.34 as there are some additional fixes that might address this. You will also need to factory reset the RX in order to force an update on bind
Ok, checked the firmware. It still has same date 2024-05-08 as previous. Ill reload anyway.
Also 2nd test just now with standard nano. 2 RTLs. Logs show 2 radio fail-safes. Second one has the classic straight line on RSSI and LQ for 6 secs. First one however seem to have no obvious reason. Its uploaded in dropbox as above.
But no loss of bind.
3rd test with reloaded 6.34 firmware.
Method- short out and back waypoint mission. If I see the RC link has returned to 2 (150HZ) then I orientate the antenna directly to the copter to induce and early RC link rate drop. As l see link has changed to 1 (50Hz) I select loiter followed by Auto (restart mission) to get as many 150/50 cycles as possible.
No loss of bind on any flights.
Still a strange issue with random temporary link ‘freezes’ that last 6 seconds. This causes an RTL but can be overridden. Had 3 in last mission.
The other RTL was my finger trouble. Pressing the ‘auto’ button twice deselects any buttons and defaults to RTL.
bin and TX CSV files in folder linked above.
No more testing for a few days. Will be away.
BTW if any expert feels like checking my quad tune feel free. It seems ok mostly but really dosent like descending into its own propwash. Gets a right wobble but perhaps nothing can be done about that. Auto tune gave a very mushy feeling. Didnt use its values.
Finally I’m also able to report a radio FS, actually the first one I ever had with Crossfire in real flight. It suspiciously also lasted exactly 5 seconds. It was then cleared, could continue flying, no bind issues afterwards.
- AC 4.6.0 dev
- CRSF 6.19
- Definitely an older NanoRX (purchased probably 2-3 years ago)
This doesn’t really fit with the direction explanations were going last, I’m afraid. So maybe it’s a different issue. But I have flown this copter for years without failsafes, albeit on earlier versions of Crossfire and AC.
How can I find out from the log if there was link rate switch just before the FS? In OSD, there is no message just before the incident, but not all messages reach the OSD from my experience. The last OSD message, a few minutes before the incident, was 150Hz. After the FS was cleared, it showed a switch to 50Hz.
Just came across this discussion. I’ve been having the exact same problem for the past couple of months. Setup: ArduPlane 4.5, Heewing F405 FC, Radiomaster Tx16s running openTX and Yaapu telemetry scripts, Crossfire Micro TX.
I purchased a new Crossfire Nano SE RX for a new VTOL plane. During the first couple of flights I began running into failsafes and RTL where binding was lost and could not be recovered exactly as described above. Upon RTL the RX would have a solid red light and required rebinding as described by @Vince_Hogg . Loss of bind would always occur on transition from 150-> 50 HZ telemetry. I attempted to trouble shoot this for awhile but eventually chocked it up to a faulty RX. I switched the new Nano RX out for an older model Nano SE (Pic processor marked with 45) that had been in use in another plane. I have now flown this old model Nano SE for many flights both long and short over the past month with no failsafe/loss of bind events. Yesterday I switched this old Nano RX out for a new Nano Pro RX and immediately began experiencing failsafe/loss of bind events again. All of my receivers were updated to the most recent CRSF firmware last month. The problem seems to be specific to newer RXs as my older Nano SE with pic processor and marked 45 works fine, even on new firmware. As documented previously, loss of bind did not happen at every 150->50 transition. I never had a loss of bind on long range flights but it would reliably happen at some point during short range flights when frequently switching between dynamic telemetry modes.
I’ll be anxiously watching this tread for a resolution!
1 Like
As mentioned a few lines up, I was just asking myself how to determine these transitions took place by looking at the logs in MP - or does it require separate telemetry logs maybe?
I’ve been looking at the telemetry logs directly from my TX16s transmitter. The telemetry logs saved on the transmitter can be opened in the Open TX Companion (or viewed as a CSV file). Whenever I lose bind, RFMD always drops from 2 (150 Hz) to 1 (50 Hz). This is followed a short time later by a drop in TQly and RQly to 0 as well as a loss of telemetry from the nano RX. The loss of telemetry/rc link isn’t instantaneous but rather happens several seconds after the transition from 150 to 50 Hz.
2 Likes
Just an update - TBS have a fix for the loss of bind problem, which Vince has been testing. However, the 6s failsafe is a headscratcher. If anyone is seeing this and has a reliable way of reproducing that would be helpful.
1 Like
Quick question: if we were to roll back to an older version of the TBS firmware do we think the problem will go away? Thank you.
I tried to go all the way back to 6.13 and it still occurred. I cant advise about any further back than that. Whats more, when attempting to return the TX unit (nano) to 6.19 it bricked the TX. It never completes a firmware load.
No, the bug has been there since 2015
Crikey! Do you know what is causing the bug to manifest for us and seemingly few other people?
Its a buffer overrun bug in the telemetry. AP + yaapu sends a lot of telemetry and throttles based on the link rate. At the time the switch from 150Hz to 50Hz occurs you have too much telemetry in transit and the buffer overflows leading to the loss of bind (it’s an RX crash effectively). Why this is so much worse on the newer hardware IDK - its a different chip so free memory reads/writes might have very different consequences. But it has occurred on the older hardware (see the video above) just much more rarely.
In other news its sounds like TBS have a bead on the 6s failsafe.
5 Likes