Create SpeedyBee F405v4 Target with Support for SoftSerial (for use cases like SmartPort specifically).

[Painless360]

On the existing Speedybee F405V4 flight controller, there isn't a way to use SmartPort for FrSky receivers with INAV.

Using the resource mapping in Betaflight, it is possible to reassign the LED or CC pad for this function. See https://speedybee.zendesk.com/hc/en-us/articles/21197634652059-How-to-Use-SmartPort-Telemetry-Data-Transmission-on-F405v4-Flight-Controller for full details

Could a alternative target with this modification be created so that pilots using SmartPort can access the same telemetry as Betaflight on this flight controller?

Thank you in advance for looking at this request. Happy flying!

[b14ckyy]

Hey Lee. That should work already. Based on the Target definitions, if you enable softserial support in the Configuration tab > Features, the Tx2 pad will become a bidirectional softserial pad. You can use that for smartport telemetry and even invert it if needed.

[amstan]

I feel like TX2 pad doesn't do anything when feature SOFTSERIAL is enabled. I have a scope on it, no matter what I connect to it, it's always HiZ.

I tried: SmartPort Telemetry, then the following just to check that the port is capable of being an output: MSP, SmartPort Master.

When I turn off SOFTSERIAL and TX2 is back to hw uart 2, Smart Port Master or MSP instantly causes the pin to be driven high on idle (and I even see traffic from smart port master). But that won't exactly help for telemetry.

Furthermore! the HW UART2 TX configuration (eg: if it's set to smart port master) seems to still be driving the TX2 pin regardless of SOFTSERIAL being enabled.

[coutiere]

I had the same issue as Painless360, and I still do (with iNav 7.1.1)

I modified the source code (target.h file) and compiled it, without the expected results:

• first modification: I moved UART2_TX_PIN from PA2 to something else, so as to leave PA2 specifically dedicated to SoftSerial
• second modification: I put back UART2_TX_PIN to PA2, but I assigned SOFTSERIAL_1_TX_PIN and SOFTSERIAL_1_RX_PIN to UART3_TX_PIN = PC10.

No success with any of these configurations. I suspect SoftSerial is working with other FCs, so I wonder where the issue may come from.

I fear I am stuck there (and I will need to use BetaFlight or ArduPilot, except if someone proposes a working solution...)

[coutiere]

Switching to F.Port could be a good option, but I can not... I never really looked about the reason before, so I insisted today, and I just cannot see how to change it.
I have two ways to use the procedure described by Sensei-hacker (and the documentation of the receiver).
The first one (about Tx, apparently) gives me "waiting for the Tx.... No option" in a very short time.
The other option, where I try to deal with the Rx itself, shows "waiting for the Rx". And it waits there...

[MrD-RC]

But you can switch to FPORT. It works just fine on the Archer RS.

The messages you're getting sound like you may need to update the firmware. Is the receiver and transmitter RF firmware up to date?

[coutiere]

The Rx is really new, so it should be up to date.
Still, I tried to update it. I downloaded the firmware for RS Plus, but the only option that I have is to upload it through S.Port (which is not available, as this is precisely my problem).

I think I will temporarily switch to BetaFlight, to see if it does work, and to configure the Rx to use F.Port, and then I'll revert to iNav because I strongly prefer it.

Thank you for your support, by the way! I really appreciate your ideas!

[MrD-RC]

It's ACCESS, so you can flash it over the air.

If you have to flash via SPort. You need to remove it from the aircraft and solder on a servo connector, to plug it in to the transmitter. You can't flash it through the flight controller.

[coutiere]

Well, I finally found (an easy...) solution.
I added a wire to the "Inverted S.Port" and put that on the Tx of an UART, and it just worked with S.Port. Telemetry is a priority over other UART usages... No need for SoftSerial.

Thanks MrD-RC, you helped me to push further. I must say I was about to give up...

For further reference (and also to answer to the old message of Amstan), here are my thoughts...

• I could have tried to flash the Rx the way you propose, but it seemed pretty complex for a Rx which is supposed to be up-to-date...

• When I tried to flash the Rx OTA, I only had the option of SPort. The error message was "Rx not responding" (with the problematic "S.Port" configuration, and not "inverted"... see below.). To use a Servo interface, I probably should have determined a way to address the interface...

• BetaFlight does not accept to create a SoftSerial port... I don't know why. I have the classical message ("index not between 1 and 10") despite SoftSerial being enabled. And SoftSerial does work with iNav. Also, the CLI command "serial 30 32 115200 57600 0 115200" has no effect, but it generates no error message: then, "Serial" does not show the softserial port. This is tricky but I will not investigate.

What I see (with a probe) is that :

• the Rx S.Port is globally on GND, and starts sending messages with 3.3V, at 57600 bps (17 µs per bit). It's Inverted UART (as expected).
  It sends messages every 12 ms, with the documented S.Port format : 18 bits total, starting with a start (1 in our case), followed by 0x7E (1000 0001 in our case), one changing byte (the address to poll), and ending with a stop (0 in our case).
  When it sends this burst to the TX of Taranis, the Taranis is supposed to answer on the same TX, and this was not the case.
  This explains why the TX port is always High (if not well addressed): it is not an issue.

• on my Rx, the "Inverted S.Port" is indeed inverted to the S.Port (!): it is a non-inverted UART, reproducing the signal of the S.Port (as expected), so it could be plugged onto any UART.