So just affecting Ardupilot?
IE - we should be able to continue flying our iNav and Betaflight-based models without issue?
Same bug in all of them, so no reason it couldnât happen on any - just more likely on ArduPilot given the amount of telemetry we send.
Could it also occur on a Nano Diversity RX?
EDIT: Any news/ETA for the firmware update from TBS?
1 Like
I donât understand how this issue is only happening to like, 3 of us and how there is absolutely nothing we can do to fly safely in the meantime whilst waiting for TBS to release fixed firmware.
TBS have created an alpha code just for us. If you want to try the pre-release of 6.35 then please add this to your Agent-M ids - ARDU_Grn9dZjEHAbF7hxm5TSBz2 - it needs to be ADDED (not replaced) to the agent menu under Settings â Agent ID.
So far Iâve had about 4 hours flying with 6.35 without any issues. Hope to test a plane today.
However in mode 1 (50hz) yaapu update is painfully slow, like over a minute. I need to test if itâs only yaapu or general telemetry.
1 Like
Apparently this is somewhat expected. On the old firmware you were actually getting 150Hz telemetry on a 50Hz link. Now you are getting true 50Hz telemetry.
1 Like
I also had endless trouble trying to update my (TBS Micro TX V2) just before all the unbinding issues.
Tried so often and it eventually flashed.
Then the issues with unbinding.
PS - Vince, I see you are a fellow Airbus sort!
@jasonleech Yes, been on it so long I almost know what all the buttons do. Is that you on YT by a different name?
@andyp1per Just had 2 long twin plane flights with 6.35. No problems at all. I see the various telemetry âsensorsâ come down at different intervals. Some take forever but the at least the GPS position has very little delay.
1 Like
I bought yesterday a rx nano (not SE) from getfpv and is version 50 with espressif processor 
Hereâs a telemetry log from the 5-6 sec failsafe I had last week. It would be very interesting to know if it falls into the category that is being fixed right now, or if it had other reasons.
TMlog.zip (60.2 KB)
on Betafligh 4.4.1-4.4.3 had the same issue , also with nanoRX 45 revision. One thing I canât understand is how it can be that the bind is like overwritten, it is stored in the chipâs memory. and after reconnecting the power you have to rebind. On some receivers it is only possible to restore the module through recovery. How can this be explained? on two modules, that after that issue after do recovery couldnât connect, and for them helped to restore operation by resoldering sx1272.
Canât tell anything from a telemetry log - need the airside log
1 Like
Looks like I made an incorrect assumption, here it is:
Hm ok, thanks⌠I was almost out of the door to go flying with that quad again on 6.19. I guess I better drop that idea and first update my stuff to that 6.35 alpha tonight, which seems to work very well according to @Vince_Hogg. I really would have preferred an official, final version but I already lost many days with good flying weather due to this.
By the way, this was old Nano RX, probably bought 2-3 years ago.
1 Like
I added ARDU_Grn9dZjEHAbF7hxm5TSBz2 to my Agent ID with no space in between, it says update successful. But the latest version Iâm seeing is v6.33? I had to use Agent for Windows since the web version wouldnât connect to the RX (usual prompt in browser when clicking connect doesnât appear).
You must use Agent web/M it wonât work otherwise. Try a different browser?
Was able to connect with another browser, but still only seeing v6.33.
Adding the code to the existing ID without space is correct? Because it also says âsuccessâ with a space in between, so it seems the validity is not really checked at that point.
There should be a + symbol at the bottom right to add it