Yuneec Typhoon H+ SR24 Research

[z3rodae0]

I am studying and experimenting with the Yuneec Typhoon H+ drone. I have reviewed the SR24-related projects posted by @h-elsner and @dylanfm on the YuneecPilots forum, and I found that their work aligns closely with my current goals. I have a few questions:

1. While identifying chips and testing pins inside the ST16S transmitter, I accidentally erased the firmware image of the STM32F373. Is it possible to obtain this file or restore it through a firmware update?
2. I separated the SR24P module from the YTH+ (Yuneec Typhoon H Plus) drone and connected it to a USB-to-TTL cable. By sending the binding mode message (55 55 08 04 00 00 42 49 4E 44 B0), I successfully switched the SR24P into binding mode and was able to connect through the ST16S FlightMode app. However, since only part of the overall binding logic was executed, the connection was established but proper communication did not occur. In the SR24_decode project, a similar approach was used to process signals coming from the transmitter (the model used there was the ST16) and analyze the UART data. In my case, however, nothing happens. Are there any additional steps I need to perform?

 

[dylanfm]

I am studying and experimenting with the Yuneec Typhoon H+ drone. I have reviewed the SR24-related projects posted by @h-elsner and @dylanfm on the YuneecPilots forum, and I found that their work aligns closely with my current goals. I have a few questions:

1. While identifying chips and testing pins inside the ST16S transmitter, I accidentally erased the firmware image of the STM32F373. Is it possible to obtain this file or restore it through a firmware update?
2. I separated the SR24P module from the YTH+ (Yuneec Typhoon H Plus) drone and connected it to a USB-to-TTL cable. By sending the binding mode message (55 55 08 04 00 00 42 49 4E 44 B0), I successfully switched the SR24P into binding mode and was able to connect through the ST16S FlightMode app. However, since only part of the overall binding logic was executed, the connection was established but proper communication did not occur. In the SR24_decode project, a similar approach was used to process signals coming from the transmitter (the model used there was the ST16) and analyze the UART data. In my case, however, nothing happens. Are there any additional steps I need to perform?

What do you mean only part of the binding logic was executed? Maybe a stupid question, but after binding did you power off the SR24 and then power it back on without sending the binding message? Can you log the serial output of the SR24 when it is connected to the ST16S and you are sending commands from the flight mode app (ie moving the sticks around)? I don't have an ST16S, but I would guess everything should be pretty similar.

 

[h-elsner]

1. I'm not sure but I think the FW for the STM controller is the TX firmware file "mcu_firmware.bin". This is a small file but I think the STM32 has not much to do. Android is running on the other processor (Intel ARM). I will try find the menu how to update the TX-FW.
What is shown in the RC calibration screen > Controller test > Transmitter version?

2. If bind mode is working the communication to SR24 is working. You should see some data coming in on Tx. This data is also in form of 0x55, 0x55 messages.
What do you want to control with the SR24? With other words, what device is meant to decode those messages and for what?

 

[Vaklin]

He probably wants to replace the ST. The protocol is almost the same but only almost.
Why it isn't public yet is a big dilemma...

 

[MobileTechSpecialists]

He probably wants to replace the ST. The protocol is almost the same but only almost.
Why it isn't public yet is a big dilemma...

 

[z3rodae0]

First of all, thank you for your replies. There were several responses, but since the nuances seemed similar, I’ll leave one general reply here.


Let me clarify my question a bit further.
My primary research goal is to observe the control data from the ST16S remote controller being received by the SR24 (mounted on the YTH+ drone). (For example, the data transmitted when moving the joysticks.) From the PX4 forum and the Yuneec forum, I found similar research, and I also tried sending the 0x55, 0x55 formatted binding-mode command to the SR24 receiver through the serial port.


Here is what I observed:

• When the SR24 is powered via the serial port, the LED blinks slowly, indicating that no communication is established.
• After sending the binding-mode command, the SR24 enters binding mode, confirmed by the LED blinking rapidly.
• Using the ST16S FlightMode app, I refreshed the connection tab and clicked on the scanned receiver, after which the SR24 LED stayed solid on, indicating that it was connected.
• After this, I attempted to capture the data transmitted by the joysticks via the SR24’s UART TX line, but I saw no output at all.

Because of this, I assume that only part of the connection process (maybe just at the 802.15.4 layer, though I may be wrong) is being completed between the ST16S and the SR24 (taken from the YTH+ drone), which might explain why I cannot see the control data.


To summarize the steps I followed:

1. Removed the SR24 from inside the YTH+ drone.
2. Connected the SR24 to a PC using a CP2102 (USB-to-TTL device).
3. Sent the message 55 55 08 04 00 00 42 49 4E 44 B0 via UART using Python.
4. After step 3 succeeded, the SR24 LED began blinking rapidly (indicating it had entered binding mode).
5. Connected the SR24 to the ST16S through the Android FlightMode app.

Even after completing these steps, I still cannot see the ST16S control data coming into the SR24.


My question may still not be entirely clear, and there may be gaps in my explanation, but thank you very much for taking the time to read it.

 

[Vaklin]

You want to reverse the protocol between ST16S flight controller, both based in ST16, or between the same things in the H+?
Doesn't matter the names are the same, communication protocol is different.
With another words, which of the FC's you want to replace with your own one?

Your goal is not clear.

 

[h-elsner]

Name is bit misleading but this project covers both UART connections SR24 to Flight controller and Flight controller to Gimbal:

GitHub - h-elsner/H480_UART_reading: Reverse engineering serial connections at Yuneec Typhoon H

Reverse engineering serial connections at Yuneec Typhoon H - h-elsner/H480_UART_reading

github.com

In /docs you will find 3 Excel readable LibreOffice files, one is "Format_SR24UART_messages.ods" that contains the messages from/to SR24.
In short:
Message type 0: Channel from data 12 channels. Those used by ST16, ST16S and ST24.
Message type 1: Channel from data 24 channels. Only used by very old FW of ST24.
Message type 2: Telemetry from Flight controller.
Message type 3: Channel data 12 channels + telemetry data from ST16's GPS. I'm not sure but I think the ST16S will sent it too.
Message type 4: Binding command.
Message type 5: Telemetry from H920 only.
Message type 20: Command messages for switch LED, GPS, OBS, Setting home altitude, RealSense and maybe other unknown things. Also the used to carry data that comes from Flight controller like OBS distance. Different payload length.

 

[z3rodae0]

Sorry for the late reply. Regarding the device or module names, while they look similar, I concluded that there are detailed differences, so I referred to the FCC documentation to use the correct names (e.g., SR24, SR24P).

1. I have fully reviewed the Format_SR24UART_messages.ods file and confirmed that the same format and data exist as what I observed with my logic analyzer.
2. My goal is not to replace the FC. My goal is to analyze the communication protocol. That is why I wanted to analyze the data going into or coming out of the SR24.
3. I was already aware of the mcu_firmware.bin file, and I found from another forum post that the firmware on the STM32 chip was restored by repeatedly performing the firmware update process. https://yuneecpilots.com/threads/yuneec-typhoon-with-st16.22614/page-2#post-249951
   Although, I am not certain if it was actually the STM32 firmware that was restored.

 

[Vaklin]

Let me try the last time to ask.
SR24 ZigBee transceiver is available in the drone , as well in the remote ST16S.
So, protocol of which of these you're discovering?

 

[z3rodae0]

Let me try the last time to ask.
SR24 ZigBee transceiver is available in the drone , as well in the remote ST16S.
So, protocol of which of these you're discovering?

I understand that both use the same format. Of course, the data contained in the 0x55, 0x55 type packets is different. I am looking for both.

 

[Vaklin]

Not the same...

 

[z3rodae0]

Thank you for your reply. I’m sorry that my question was unclear — I realize I wasn’t exactly sure myself what I was looking for, and I asked out of curiosity. I’ll try a few more things on my own first and get back to you afterwards.