Confirmed - no issues using latest beta on F405-WING! Couldn’t confirm on the Kakute copter, since it requires your special handmade version.
Does the beta include that failsafe fix? I guess I’ll use it either way for now, as it’s much newer than the june version.
In the meantime I also checked another copter (F405-CTR) with NON-Diversity RX, and just like the craft using Nano RX there are no problems using latest.
Randy is going to merge the failsafe fix into either beta9 or rc1.
It would be good to understand exactly what combo is causing the problem as this could be a TBS FW issue. Even better if I can reproduce. The diversity nano just has two antennas right?
It has 2 antennas but considering it’s almost double the price of the Nano RX, I hope it also has the “true dual-input stage, chip-based diversity” it promises.
I would assume it includes mostly the same tech as the big Crossfire Diversity RX with PWM outputs (https://www.team-blacksheep.com/products/prod:crossfire_8chrx) as it also shares the backup battery option. The big one has a battery built-in that can keep it running after a crash to find the craft. The Nano Diversity (https://www.team-blacksheep.com/products/prod:xf_nano_div_rx) has the option to connect a 1S lipo to do the same. To put it short, the Nano Diversity was probably meant to make diversity more affordable.
Ok looks like I have the regular nano. I’ll see if trappy will send me a diversity.
As that might take a while, would it be possible to remove CRSF V3 from master as well for now (in case it is not needed for anything specific), or should I just stick to betas?
Because I have 4 or 5 of these receivers, and I haven’t been keeping up with how often betas are released as I always used master. So I’m just used to getting any zero-day fixes and interesting updates that come with master immediately. 
And could you maybe remove CRSF V3 from the special Kakute copter version…? If you can already think of anything, that would also be a good way to try out any fixes, as this copter is in rebuild phase and probably won’t be flying for 2 or 3 weeks anyway.
Nope 
it’s hard enough getting these changes in let alone remove them. The issue is likely on the TBS side rather than our end. That’s what you get for bleeding edge I am afraid.
FWIW CRSFv3 only appears to enable if you switch your TX on first. If you power on the Copter and then the TX you will get CRSFv2 (at least that’s what happens for me). It seems to be to do with the TX/RX handshake. So its a way of forcing CRSFv2 if you want.
Do you lose all CRSF control or only telemetry? If its CRSF in totality then this sounds like what happens when the switch from CRSFv2 to V3 doesn’t happen correctly - basically the two ends end up talking different baud rates and hence not talking at all. What APM messages do you get (best to see with mavproxy so you get the initial boot ones as well).
Great hint, I’ll try powering the copter up first later today - I might never have tried that otherwise, even if it has no props - safety regulations are hard coded into my mind.
As for removing stuff - not being a dev I had no idea removing stuff is more difficult than getting it in, so no problem at all.
There is no control at all* and only the first few messages of telemetry. However, when I checked sensors in OpenTX, it looked like there was still some data coming in (flashing stars next to some entried), but very slow. I’ll check the APM messages with Mavproxy tonight and report back.
(* Actually there might have been 2 or 3 boots where I had some control for a few seconds - a servo was moving according to a slider position)
Yeah this sounds like the baud rate issue. Its quite timing sensitive - are you sure its not FC dependent?
You will still get activity on the TX because the TX/RX link is fine - its the FC/RX link that is the problem
Ok, I’m back and will now proceed to some more checking. I was assuming it’s not FC dependent after it occured on both on F405-WING and Kakute F7. If it’s in fact a TBS (Nano Diversity RX firmware) bug, could the FC still matter?
If its a firmware bug then no, but who knows
Here’s a first bit from Kakute F7 (btw, switching it on before the TX didn’t change anything for me):
online system 1
Mode STABILIZE
fence present
AP: ArduCopter V4.2.0-dev (5f980929)
AP: ChibiOS: 4e053f70
AP: KakuteF7 00380039 3538510A 31373730
AP: RCOut: DS600:1-5 PWM:6
AP: IMU0: fast sampling enabled 8.0kHz/2.0kHz
AP: Frame: QUAD/X
Flight battery 100 percent
AP: RCInput: decoding CRSF
AP: CRSFv2: RF mode 2, rate is 201Hz
AP: Rangefinder MIDDLE
AP: Landing HIGH
AP: LandingGear: RETRACT
AP: Radio Failsafe - Disarming
RC fail
Is it possible to capture even more messages with MAVProxy? The problem with the Kakute is that I always have to connect battery before USB, otherwise all I get is a repeating message like “Baro : Unable to initialize driver - Fix problem and reboot”. (That’s not new, it has always been like this.) So when I fire up MAVProxy (to let it autoconnect), a few messages might be missed.
Is 201Hz a ‘healthy’ value? I’m pretty sure I used to see only values below 200 in the OSD when flying, before this problem started to occur.
This definitely looks like the baud rate switch. 201Hz might be fine - you would have to wait for things to settle down, the first few values reported are likely inaccurate.
So it’s probably the switching to CRSF V3 indeed and can only by fixed by TBS with a FW update? I guess I could also downgrade to a Crossfire version without V3, but binding problems were my reason for updating to 6.x, and I don’t want those back.
Anything else I can do to help advance knowledge? I could try this with either an F405-CTR or F405-WSE, or both - if it helps.
Can you make sure that only one of your CRSF outputs on the nano is turned on? Apparently there is an issue where the baud rate switch can happen on the wrong port if you have both enabled.
I can double check that tonight, but actually I’m 99.9% sure there is no second CRSF output selected as I always use the same set: CRSF TX, RX, CH7 (for a cam switcher), SmartAudio (to VTX).
Update: Confirmed, no second CRSF output active on Diversity RX at Kakute F7.
TBS have found the issue - they are working on a fix. Thanks for testing!
That’s great to hear! I hope I don’t miss the release of the fix, as TBS seem to announce things preferably via Facebook, which I’m not a big fan of, so I usually only log in once a week.
@tridge
@yaapu, Here are some bugs with 4.1.0 beta release.
I got the Yaapu working but it is not displaying “flight Modes” correctly on the RadioMaster screen. For example FBWA is shown as Rattitude Mode. Takeoff mode is Loiter.
Here are the parameters settings:
Test test results using Beta Version on Matek 765-Wing = V4.1.0beta6 (87alezoo)
UART6 = Serial 7
baud rate = 57
Serial7_Option = 0
Serial7_Protocol= 23
Serial8_baud rate = 57 (Not sure why Serial 8 was showing up in the MP, under Serial7 search?)
RC_Options = 258
RSSI_Type = 3
All other Serial# should be set to -1 other than GPS
Radio:
RadioMaster with TBS CRSF Module (Full feature)
Receiver:
TBS-CRSF Nano
Output 1 = CRSF Tx
Output 2 = CRSF RX
3 = CH3
4 = CH4
5 = BST SCL
6 = BST SDA
Yaapu Version = 1.9.5_Dev (bf94571)