Betaflight regarding the electrical characteristics of STM32F405 SBUS protocol compatible hardware

Betaflight regarding the electrical characteristics of STM32F405 SBUS protocol compatible hardware

  • 1. Origin
  • 2. Reserve knowledge
    • 2.1 Tri-state Logic
    • 2.1 Pull-up
    • 2.2 Pull-down
    • 2.3 Current Sink
    • 2.4 Current Source
    • 2.5 GPIO input mode
    • 2.6 GPIO output mode
  • 3. Introduction to FPV system protocol
    • 3.1 TX Protocols – communication between radio transmitter (TX) and radio receiver (RX)
    • 3.2 RX Protocols – communication between radio receiver (RX) and flight controller (FC)
    • 3.3 ESC Protocols – communication between FC and ESC
  • 4. Analysis
    • 4.1 Hardware solution
    • 4.2 Receiver sbus flip
    • 4.3 Flight control firmware
  • 5. Measured 4.4.2 firmware
    • 5.1 Firmware compilation
    • 5.2 Configure ELRS receiver
    • 5.3 Configure F405 flight control
    • 5.4 Actual measurement results
  • 6. Summary
  • 7. References
  • 8. Supplement
    • 8.1 Wiring & Commands
    • 8.2 Custom compilation selections

1. Origin

I encountered a problem recently:
1) Phenomenon: STM32F405 flight controller cannot connect to the sbus receiver.
2) Reason: The difference from the usual F405 flight control is that there is no sbus interface.

In order to better explain this problem, let’s first reserve some basic knowledge.

2. Reserve knowledge

2.1 Tri-state Logic

Usually the GPIO of the MCU is designed to be three-state, and the signal depends on the external circuit logic.

  • Logic 0 (connection to ground)
  • Logic 1 (connection to VCC, mostly through resistor)
  • High-impedance (also called “floating”, “Hi-Z”, “tri-stated”)

Note: The high-impedance state is a signal line sharing mechanism. When the signal line needs to be used, the output signal is pulled high and low. Give up the right to use the signal line when the resistance is high.

2.1 Pull-up

Pull the signal line to the default output state through a pull-up resistor. The MCU controller is also designed with an internal pull-up option, which is equivalent to the effect of an external pull-up resistor.

2.2 Pull-down

Pull the signal line to the default output state through the pull-down resistor. The MCU controller is also designed with an internal pull-down option, which is equivalent to the effect of an external pull-down resistor.

2.3 Current Sink

It usually refers to how much load current the IO can withstand. Exceeding the load will damage the IO (chip).

2.4 Current Source

Usually refers to the load driving capacity that IO can provide. If the load exceeds the load, it will not work.

2.5 GPIO input mode

  • High-impedance (often the default – floats if not driven)
  • Pull-up (internal resistor connected to VCC)
  • Pull-down (internal resistor connected to Ground)

2.6 GPIO output mode

  • Push-pull output: common GPIO configuration method, with Current Sink/Source capability

  • Open-Drain output: equivalent to a switch to ground, with Current Sink capability

Open-drain
Open-drain with internal pull-up // Commonly used for communication, such as: I2C


Note: Open-Collector refers to BJT, Open-Drain refers to FET

【

2

】

^{[2]}

【2】.

3. Introduction to FPV system protocol

3.1 TX Protocols – communication between radio transmitter (TX) and radio receiver (RX)

  • ACCST (Frsky)
  • ACCESS (Frsky)
  • DSM (Spektrum)
  • DSM2 (Spektrum)
  • DSMX (Spektrum)
  • AFHDS (Flysky)
  • AFHDS 2A (Flysky)
  • A-FHSS (Hitec)
  • FASST (Futaba)
  • Hi-Sky (Deviation / Devo)

3.2 RX Protocols – communication between radio receiver (RX) and flight controller (FC)

  • PWM (universal)
  • PPM or CPPM (universal)
  • SBUS (Futaba, Frsky)
  • IBUS (Flysky)
  • XBUS (JR)
  • MSP (Multiwii)
  • CRSF (ExpressLRS, TBS Crossfire and Tracer)
  • SPEKTRUM1024 (Spektrum DSM2)
  • SPEKTRUM2048 (Spektrum DSMX)
  • Port (Frsky)
  • SPI_RX (universal) – More detail in this article
  • GHST (ImmersionRC Ghost)

3.3 ESC Protocols – communication between FC and ESC

  • PWM
  • Oneshot (Oneshot42, Oneshot125)
  • Multishot
  • Proshot
  • Dshot (Dshot150, Dshot300, Dshot600, Dshot1200)

4. Analysis

Back to the main goal of this article: the F405 flight controller without sbus pad communicates with the sbus receiver.

First of all, we learned the following information from the previous knowledge accumulation:

  1. SBUS is a protocol between the receiver and flight controller
  2. The GPIO of the MCU is used as an input: it can be in a high configuration and sense high and low levels according to changes in external signals.
  3. The SBUS protocol is a RC control protocol compiled by futaba

    【

    5

    】

    ^{[5]}

    【5】, use low level effective if interference is not reduced.

    【

    1

    】【

    3

    】

    ^{[1][3]}

    【1】【3】

4.1 Hardware solution

A common processing method on the market: use a converter for conversion.


In addition to the above hardware methods, there are actually two other ideas to consider:

  1. Signal inversion is performed when the receiver signal is output
  2. When parsing the protocol on the flight control side, the signal is flipped.

4.2 Receiver sbus flipping

The ELRS receiver is configured with inverted sbus signal.

4.3 Flight Control Firmware

After investigation, it was found that the F405 chip is different from the F3/F7 in that there is no reverser inside the chip. Usually the STM32F405 flight control board uses an external reverse circuit to convert the sbus signal of the receiver.

From reference [1]
A serial signal is composed of a series of High and Low electrical signals sent down a wire. In the standard serial protocol, a high signal is 0 and low is 1. In an inverted signal this is reversed so that a high is 1 and low is 0. You might think it makes more sense that low should always be 0 and high be 1 but electronics engineers decided that standard serial protocol should be the former.

To convert a standard serial signal to an inverted signal you run it through an inverter chip (which can be as simple as a single transistor) which will simply change all high signals to low and vice versa.

F3 and F7 chips have inbuilt inverters on their hardware uarts, which enable them to transmit or receive serial signals in any polarity. For some reason, F4’s were designed without that feature and thus do not support inverted signals on their uarts.

Usually the “hard” ones don’t work, and we always hope that the “soft” ones can solve them. This idea can indeed solve or bypass many hardware problems under the development of software technology. These are also some advantages of GPIO (General Purpose IO).

After code analysis, it was found that in the F411 era, there was indeed a soft serial port to expand the serial port. At the same time, it also supports the use of timer scheme for sbus protocol analysis.

Further in-depth analysis shows that USE_SOFTSERIAL has been defined in the chip platform definition.

./src/main/msp/msp.c:669:#if defined(USE_SOFTSERIAL)
./src/main/target/STM32F7X2/target.h:33:#define USE_SOFTSERIAL
./src/main/target/STM32H725/target.h:86:#define USE_SOFTSERIAL1
./src/main/target/STM32H725/target.h:87:#define USE_SOFTSERIAL2
./src/main/target/STM32F745/target.h:38:#define USE_SOFTSERIAL
./src/main/target/STM32H723/target.h:57:#define USE_SOFTSERIAL
./src/main/target/STM32H750/target.h:71:#define USE_SOFTSERIAL
./src/main/target/STM32F411/target.h:33:#define USE_SOFTSERIAL
./src/main/target/STM32F446/target.h:34:#define USE_SOFTSERIAL
./src/main/target/STM32H743/target.h:34:#define USE_SOFTSERIAL
./src/main/target/STM32F405/target.h:37:#define USE_SOFTSERIAL
./src/main/target/STM32G47X/target.h:34:#define USE_SOFTSERIAL
./src/main/config/config.c:426:#if !defined(USE_SOFTSERIAL)
./src/main/drivers/serial_pinconfig.c:173:#ifdef USE_SOFTSERIAL
./src/main/drivers/serial_pinconfig.c:189:#if defined(USE_UART) || defined(USE_SOFTSERIAL)
./src/main/drivers/serial_pinconfig.c:243:#if defined(USE_SOFTSERIAL)
./src/main/drivers/serial_pinconfig.c:250:#ifdef USE_SOFTSERIAL
./src/main/drivers/serial.h:106:#if defined(USE_SOFTSERIAL)
./src/main/drivers/serial_softserial.c:31:#if defined(USE_SOFTSERIAL)
./src/main/cli/cli.c:5036:#if defined(USE_SOFTSERIAL)
./src/main/io/serial.c:37:#if defined(USE_SOFTSERIAL)
./src/main/io/serial.c:102:#ifdef USE_SOFTSERIAL
./src/main/io/serial.c:410:#if !(defined(USE_UART) || defined(USE_SOFTSERIAL))
./src/main/io/serial.c:476:#ifdef USE_SOFTSERIAL
./src/main/io/serial.c:517:#if !defined(USE_SOFTSERIAL)
./src/main/io/serial.c:546:#ifdef USE_SOFTSERIAL
./src/test/unit/target.h:67:#define USE_SOFTSERIAL

The main configuration contents are as follows:

  1. The firmware must ensure that the configuration defines USE_SOFTSERIAL so that the soft serial port code can be compiled;
  2. Correctly configure the software serial port flip status:

SBUS protocol receiver? set serialrx_inverted = ON
Inverted SBUS receiver ? set serialrx_inverted = OFF

5. Measured 4.4.2 firmware

Given the SBUS Agreement

【

5

】

^{[5]}

【5】The format is as follows: serialrx_halfduplex = OFF

Supplement: From a performance point of view, 16CH Data (3ms), the fastest rate is 1000ms/3ms = 333Hz; and ELRS can currently achieve 500Hz/1000Hz, so the ELRS module that supports CRFS does not necessarily use the SBUS protocol.

5.1 Firmware compilation

  1. SBUS protocol
  2. USE_SOFTSERIAL
  3. 4.4.2 BF firmware cloud compilation

Note: There is a problem with custom compilation here. USE_SOFTSERIAL should not be used, but SOFTSERIAL should be used. But this does not affect the final result, because this definition has been defined in the chip platform code.

5.2 Configure ELRS receiver

First, use the ELRS receiver to use the CRSF protocol to test that the hardware wiring between the receiver and the flight controller is correct (UART2-RX is connected to ELRS-TX).

When the protocol is switched to SBUS, ELRS-TX is the ELRS-SBUS hardware interface.

Then, configure the Inverted SBUS protocol and use hardware UART2-RX to ensure that the receiver and flight control work properly.

Receiving RC remote control is normal (the throttle will be higher than the 885 value without a receiver).

5.3 Configuring F405 flight control

First, configure the software serial port SoftSerial.

Then, configure the software serial port resource port UART2_Rx (A03).

Note: 11 is the first software serial port. 

# resource SERIAL_RX 11 A03

Resource is set to A03

Finally, check the serialrx_inverted status (because the ELRS sbus receiver is configured as Inverted SBUS protocol).

# get serialrx_inverted
serialrx_inverted = OFF
Allowed values: OFF, ON
Default value: OFF

5.4 Actual measurement results

Test results: Betaflight 4.4.2 firmware software serial port cannot parse inverted SBUS protocol and SBUS protocol.
Suspected problem: There is a configuration problem in the software serial port code part or the logic BUG cannot be used.

For related tracking, see:

  • Does ELRS 3.3.0 supoort SBUS inverted? #2462
  • Does BF support sbus on softserial? #13144

6. Summary

Currently, a large number of STM32F405 flight control designs consider using BJT/FET.

【

2

】

^{[2]}

【2】The inverter performs hardware flipping of the SBUS signal and is compatible with the MCU.

The possible reasons for abandoning the software serial port are probably the following:

  1. The mainstream flight control F7/H7 and subsequent products will have built-in inverter design on the new film end;
  2. A large number of STM32F405 flight control hardware on the market also adopt the hardware compatibility method and provide SBUS pads;
  3. Software serial ports occupy a lot of resources: timers, interrupts, timing, etc.;
  4. With the development of new firmware functions and flight control trends, the soft serial port may fade out of sight;
  5. Official feedback: The soft serial port does not support SBUS, and its use is not recommended (the specific reason is not yet clear, although this part of the code is called at the code level, it is estimated that this part of the code will no longer be maintained, and there will be problems with reliability, stability, and usability) ;

7. Reference materials

【1】What does it mean for SBUS to be an inverted protocol?
【2】difference-between-bjt-and-fet
【3】What is the advantage of SBUS over IBUS?
【4】Uninverted SBUS and Smart Port on Frsky Receivers
【5】Protocol decoder:sbus_futaba
【6】Tutorial: How to Setup Betaflight Softserial
【7】BetaFlight module design thirty-six: SoftSerial
【8】BetaFlight module design thirty-seven: SBUS

8. Supplement

8.1 Wiring & Commands

Note: This verification uses AocodaRC F405V2 MPU6500 flight control. The flight controller itself has SBUS solder joints. For verification, the UART2_Rx pin is used directly.

Default settings

resource SERIAL_TX 2 A02
resource SERIAL_RX 2 A03
set serialrx_inverted = OFF
set serialrx_halfduplex = OFF

Software serial port

resource SERIAL_TX 11 A02
resource SERIAL_RX 11 A03

Flight control SBUS signal flip

set serialrx_inverted = ON

Single bus single duplex setup

set serialrx_halfduplex = ON

Work status query

get serialrx_inverted
get serialrx_halfduplex

8.2 Custom compilation selection

There is a problem with custom compilation. USE_SOFTSERIAL should not be used, but SOFTSERIAL should be used.

But this does not affect the final result, because this definition has been defined in the chip platform code.

./src/main/target/STM32F405/target.h:37:#define USE_SOFTSERIAL