Hello Fellow Yuneec Pilot!
Join our free Yuneec community and remove this annoying banner!
Sign up

St16 v1.

Would it be easier to capture the serial data using your PC between the flight controller and the SR24? That's how I was studying the protocol for developing telemetry for the Thunderbird firmware.. ;-)


You are saying monitor and capture the serial data to the SR24 during a firmware update and then use that captured data as the FW on a zigbee module? I thought about that but wasn't sure that I would be able to determine what part of the serial data was the firmware update and what part was just other communication. But I might have to try that because I can't seem to get a serial bootloader to work on my zigbee module. Even if I could I don't know if the SR24 uses the same type of bootloader.

I don't know, I might put working on programming an off the shelf zigbee module as an SR24 on the back burner for awhile. I did find a thread on another forum where somebody said they had made their own custom firmware for the SR24 that output SBUS. I requested more information, but it is kind of an old post and I haven't heard back yet..
 
It's only capable of binding with the SR24 receiver. However, as Dylanfm and Helsner stated, the protocol specification is available and it is rather easy to write a Yuneec to PPM/PWM/SBUS converter with a Teensy or Arduino. The codes are somewhere here... and I may have something too if you need (Arduino/Teensy to PPM source code, partial telemetry implementation/protocol specification... ;-))

The SR24, when used as a transmitter, is connected to UART of the ST16, and interfaced using a closed source driver written in C/C++, the ST16 is x86 running Android/Linux. The Flight app written in Java, makes calls to the binary driver, if that helps anything... ;-)

Br,

TR

I have Yuneec to SBUS code for a ESP32. It also has a 2nd serial output with the proper serial output to control the pan and tilt on the CGO3+ at the same time. I haven't done anything with the telemetry yet.

There is somebody on this forum who says he has made his own app to read the ST16 sticks and knobs and redirect those inputs to control a toy drone (over BT or WiFi I think). I want to figure out how to do that. I need to learn some Android programming.

Dylan
 
I really thought I had seen a SR24_rx.bin firmware file somewhere
The SR24 firmware is part of the ST16 FW. If you unzip ST16_V3.1.30.yuneec you will get a folder "firmware". There are two files in (I don't know why):
sr24_tx_en_v01.10.bin and sr24_tx_en_v02.05.bin with the same MD5 checksum 9248674c34a888028c0e65f4fb2b97.

But that are bin files. Did someone knows a way to convert CC253x .bin files to Intel hex file format?

br HE
 

Attachments

  • rf.zip
    23.7 KB · Views: 6
For the begining you can try to use the file in an ST10+. Add it in the Firmware folder on the SD card.

Stil didn't test this, just a speculation with a great possibility for success

Regards!
 
The SR24 firmware is part of the ST16 FW. If you unzip ST16_V3.1.30.yuneec you will get a folder "firmware". There are two files in (I don't know why):
sr24_tx_en_v01.10.bin and sr24_tx_en_v02.05.bin with the same MD5 checksum 9248674c34a888028c0e65f4fb2b97.

But that are bin files. Did someone knows a way to convert CC253x .bin files to Intel hex file format?

br HE

I have seen those files but i assumed that the "_tx_" in the file name indicates that it is for the SR24 transceiver in the ST16, do you think one of the files is for the SR24 on the receiver side?

I still don't know if it is the same as programming a zigbee with a hex file, but you can write a .bin file to the zigbee flash using the TI flash programmer from the command line.

Dylan
 
Would it be easier to capture the serial data using your PC between the flight controller and the SR24? That's how I was studying the protocol for developing telemetry for the Thunderbird firmware.. ;-)
Where I can read a bit more about this?
 
A little bit late but but now I have connected a SR24 receiver to Raspberry Pi. I wanted to read all received data (no transmitting). This may be a first step to use ST10 or ST16 for other models like cars or boats.

As far as I have seen, the ST16 senst only two types of messages:
MessageID=0: channel data for 12 channels.
MessageID=3: channel data for 12 channels + RemoteGPS data.

Attached a description of the message format and a Raspi tool to read and decode messages.

br HE
 

Attachments

  • SR24_read.zip
    903.3 KB · Views: 2
  • Love
Reactions: Vaklin
A little bit late but but now I have connected a SR24 receiver to Raspberry Pi. I wanted to read all received data (no transmitting). This may be a first step to use ST10 or ST16 for other models like cars or boats.

As far as I have seen, the ST16 senst only two types of messages:
MessageID=0: channel data for 12 channels.
MessageID=3: channel data for 12 channels + RemoteGPS data.

Attached a description of the message format and a Raspi tool to read and decode messages.

br HE


I think you are saying is correct.

I have posted a lot of misc info about this various places on this forum if it helps.

Here is a message where I describe what I think is going on from decoding the SR24:

A good portion of that was figured out after someone pointed out that the Pixhawk firmware had a library for decoding the ST24 receiver:

I have used that library to program microcontrollers to convert the output of the SR24 into other more common outputs.
There a few off topic posts in this already off topic thread about me using an SR24 to control a small RC car using using microcontroller to convert the serial to servo type control outputs. The code for doing that was attached a few posts later:


Here is a video of me controlling a modified DJI Phantom with the ST16. Since doing that I have actually worked on the microcontroller code more so that it now converts the SR24 receiver serial into Sbus rather that PPM like it was in that video (the DJI FC can take either) so it should be more stable and I can decode the ST16 pan and tilt controls and output them to the CGO03+ with the proper serial protocol to control it (previous attempts were outputing PWM like signals to the CGO03+ which only allows for tilt control not pan).
 
Thank you @dylanfm for all those information. Especially your RC car was a strong motivation to do something with the the ST10/16 controller. But I have had a serious delay because of other things to do.
But I'm on track. Still some items are on the do do list.

12 channel data are just the same as the flight log files Remote_xxxxx.csv. Meaning is claer and reproducable.
The GPS data are similar to RemoteGPS_xxxxx.csv from flight logs.

a) The values for "Angle" in GPS data makes no sense, not for ° nor for rad. I don't know... Also the measurement unit for Accuracy is unknown (as well as in flight logs).
b) Binding procedure needs to be tested. Binding was described in the second link above (#29). Currently I have no success.

br HE
 
a) The values for "Angle" in GPS data makes no sense, not for ° nor for rad. I don't know... Also the measurement unit for Accuracy is unknown (as well as in flight logs).
If about the coordinates -> reverse order and "to dec". If about another thing, please pm in topic thread between us.
 
Thank you @dylanfm for all those information. Especially your RC car was a strong motivation to do something with the the ST10/16 controller. But I have had a serious delay because of other things to do.
But I'm on track. Still some items are on the do do list.

12 channel data are just the same as the flight log files Remote_xxxxx.csv. Meaning is claer and reproducable.
The GPS data are similar to RemoteGPS_xxxxx.csv from flight logs.

a) The values for "Angle" in GPS data makes no sense, not for ° nor for rad. I don't know... Also the measurement unit for Accuracy is unknown (as well as in flight logs).
b) Binding procedure needs to be tested. Binding was described in the second link above (#29). Currently I have no success.

br HE
I'm not sure why the binding isn't working for you. I just looked at that post again and the only thing I noticed is that some of the bytes of data are missing the leading zero (ie 0x4 rather than 0x04). This in my arduino code to put it in binding mode:

Code:
// This is the array of values that need to be sent to the Yuneec SR24 receiver to initiate bind mode.
const byte BINDARR[55] = {0x55, 0x55, 0x08, 0x04, 0x00, 0x00, 0x42, 0x49, 0x4E, 0x44, 0xB0, 0x55, 0x55, 0x08, 0x04, 0x00, 0x00, 0x42, 0x49, 0x4E, 0x44, 0xB0, 0x55, 0x55,
                          0x08, 0x04, 0x00, 0x00, 0x42, 0x49, 0x4E, 0x44, 0xB0, 0x55, 0x55, 0x08, 0x04, 0x00, 0x00, 0x42, 0x49, 0x4E, 0x44, 0xB0, 0x55, 0x55, 0x08, 0x04
                          , 0x00, 0x00, 0x42, 0x49, 0x4E, 0x44, 0xB0
                         };
HardwareSerial YuneecSerial(1);

...
...
...

void bindmode() {
  for (int i = 0; i < 55; i = i + 1) {
    YuneecSerial.write(BINDARR[i]);
  }
  while (1) {
    delay(100);
  }
}

When the function is called it just sends the array of byte values (which is the binding sequence repeated 5 times) with no line ending characters and then goes into a constant loop until rebooted.
 
With the older SR24 module from Q500 binding works now without problems. Modules goes into binding moder after 2-5 binding messages you described above ($08 is the same byte as 8 in Pascal). I have also checked the CRC and it is true $0b.
With the later SR24 module from Typhoon H binding is as tricky as the bind process for YUNSIM stick. If something goes wrong you have to switch off all and try again. Also the Typhoon H can only brought in the binding mode after switch on. This was the trap I stepped in. After restart it works but if something goes wrong then it remains wrong. I don't know why. Again the Q500 looks more stable.

However, the binding message you provided is correct. Thank you for that.

br HE
 
You can check the version of SR24 in the ST10+. With the help of this controller, you can change them too. Somewhere here I posted some flash filles.
 
I have probably 15 or 20 SR24s. If you drop a picture on how to connect to the ZigBee dongle programmer, I can read them. If this is necessary, of course. Good idea is to have an archive of all possible FW versions. (If the content isn't protected.)
 
With the older SR24 module from Q500 binding works now without problems. Modules goes into binding moder after 2-5 binding messages you described above ($08 is the same byte as 8 in Pascal). I have also checked the CRC and it is true $0b.
With the later SR24 module from Typhoon H binding is as tricky as the bind process for YUNSIM stick. If something goes wrong you have to switch off all and try again. Also the Typhoon H can only brought in the binding mode after switch on. This was the trap I stepped in. After restart it works but if something goes wrong then it remains wrong. I don't know why. Again the Q500 looks more stable.

However, the binding message you provided is correct. Thank you for that.

br HE

I only have tried the binding code on 3 Typhoon H SR24s and I haven't noticed any problems getting into binding mode that I remember. Maybe I have been lucky because my code runs right after boot up and I was powering the microcontroller and the SR24 at the same time.

When you say "...but if something goes wrong then it remains wrong" what does that mean? Does it never go into bind mode after that? Does it get stuck in bind mode?

Dylan
 
@Vaklin: The firmware seems to be protected. When I connect the SR24 via debug port to the prorammer, it answers with the right ID-code a524 for CC2530. But if I read the FW I get a file filled with zeros:
:020000040000FA
:1000000000000000000000000000000000000000F0
:1000100000000000000000000000000000000000E0
and so on...

See#11 for debug port.

@dylanfm: I had the effect, that the SR24 was going in the bind mode but if I tapped on Refresh at the ST16, no receiver was shown and the SR24 left the bind mode immediately. No connection established.
When I removed 3.3V power from SR24 and switch it back on it was no more accessible.
A reboot of the Raspberry pi did also not help. Power off for both and restart brings all back to work and binding is possible again.

br HE
 
When I removed 3.3V power from SR24 and switch it back on it was no more accessible.
Try to disconnect it from the Pi, not to power down only. Probably you feed it via RS232 via some internal circuit in the SR24.
A reboot of the Raspberry pi did also not help. Power off for both and restart brings all back to work and binding is possible again.
Do you put the receiving side in binding mode? I don't know the sequence for this, because especially the drone side is out of my interest, but I guess some happens when the copter blinks orange. You can sniff what is in the air at this moment with a ZigBee sniffer.
 

New Posts

Members online

No members online now.

Forum statistics

Threads
20,973
Messages
241,800
Members
27,360
Latest member
MichaelNiece