iFlight F405 and Crossfire oddities

I’ve got a Nazgul5 and have just upgraded to Crossfire Micro Tx (now sitting in my TX16S) and a Nano receiver. All binds perfectly.

There’s always a but… I’ve followed multiple guides on line for the set up, however if I set config in BetaFlight 4.2 to CRSF and Nano Outputs 1 and 2 to CRSF TX / RX… the quad beeps constantly and doesn’t connect, the Tx is not detected.

If I set it to SBUS in BF config and Nano Output 1 to SBUS, it connects and works perfectly - but it’s therefore not using the full Crossfire self-healing cleverness etc.

Have checked it is on correct UART (#2 - it’s also on a connector so I don’t see how this can be wrong) I have also checked that Tx goes to Rx and vice versa - still nothing. I also tentatively swapped these to see if something was either mislabelled or the wrong way round, again it made no difference.

Baffled - all suggestions grateful appreciated.

Cheers!

I ditched the connector on mine and direct soldered the nano to the flight controller, I can’t remember what UART I used I think it was TX4 and RX4. And set UART4 to serial RX in betaflight then set the protocol to CRSF in the configuration tab. This worked fine for me on my Nazgul5 V2 :+1:t2:

I used these pads circled above :+1:t2: hope this helps.

2 Likes

Infact just re reading your post if you’re using the same UART as the FRSKY RX previous then I believe that the UART is inverted for the SBUS protocol so therefore won’t work for the Crossfire protocol as this requires a non inverted UART. Try it on UART4 and let us know how you get on :+1:t2:

1 Like

Ahh… I think the inversion is going to be it - magic thanks!

(I’ve already used UART 4 for the GPS too!)

Cheers,

DP.

1 Like

PS - love the antenna mount :sunglasses:

1 Like

Just found the following info via Oscar Liang…

“Note that the CRSF protocol is NOT an “inverted” protocol like SBUS and SmartPort, therefore you must NOT use dedicated SBUS and SmartPort pins on an F4 FC, which have built-in signal inverter for those pins”

Which, if I’m completely honest, is super annoying. On the F405 board, UART #1 is vtx, #2 is the receiver, #4 as mentioned I have the GPS on and #6 is the ESC.

There does not appear to be another pair of pins available on the F4 board to use.

There appears to be a software hack, which reduces the baud rate massively or a there is a hardware hack with an inverter board but I’m not really into dismantling and desoldering SMT components from a brand new TX16S tbh!

You can use uart 1 if you use a smart audio vtx. The smart audio will connect straight to the nano. But that means buying another vtx.
Or if you’re not using a compass, use scl/sda as uart 3.
And you shouldn’t need a uart for the esc, so you can use uart 6.

2 Likes

I’m planning on using UART 3 for my GPS it’s the 4 pads below UART4 that I’ve circled above these pads should work for your Nano as well just set UART3 to Serial RX in betaflight :+1:t2:

@DaveJaVu did you get it working in the end?

1 Like

Similar issues using Ghost with the SRXL2 protocol, the actual Ghost protocol is not in Betaflight, other than the nightly builds, yet.

The venerable Mr Bardwell claimed that on F4 boards the SRXL2 protocol would work by simply connecting to the S-Bus pads, this is not true in all cases. Some boards will work if you set it to half-duplex and the serialrx_buad_fast = ON in the CLI, but not for me using the MatekF411 target as used in the TinyHawk Freestyle. Instead I’m using SBUS-FAST for the time being.

1 Like

I didn’t go back to it as yet tbh. I’m not a complete amateur when it comes to strapping electronic doodads together so I’ll admit I am finding the vague instructions that are supplied with a lot of FPV gear just make it far far more complex than it needs to be, and in some cases the info provided is just plain wrong.

I am still however largely loving it… this is best result by far…

2 Likes

Nice :+1:t2:

It seems to be in Emuflight