Servers by jDrones

Yuneec ST16 Transmitter Support?

i am learning the hard way that there are actually several versions of transmitters Yuneec manufactures. Theres the obvious ST10, ST16 and ST24. As best I can tell - I dont think the ST24 is produced nor shipped with any copters anymore.

  • ST10 & ST10+ - smaller transmitter that looks more like a Jumper with the large lower screen. Shipped (and I think still does) with the Q500

  • ST12 - looks very similar to the ST10. I dont believe they supply the ST12 any more - I think they were replaced with the ST10

  • Original ST16 - Only had 2 external antennas: 1x 2.4GHz long skinny antenna, 1x 5.8GHz short stubby flat antenna. At the time, these shipped and are dedicated to the Typhoon H’s

  • ST16+ - Part No: YUNST16USRF (Note no “S” after “16”)I suspect “RF” is for refurbished) Beleived to be the same as ST16, but with the second, internal, 2.4GHz antenna moved to an external position. Handle on the back is metal with rubber grip. Shipped with Typhoon H. Comes pre-loaded with the yuneec “Flightmode” app and auto-boots this app at startup. Seen here: https://www.vertigodrones.com/Yuneec-ST16-Ground-Station-Certified-Refurbished--Grade-A_p_574.html
    FCC filing and internal, external pictures here: https://apps.fcc.gov/oetcf/eas/reports/ViewExhibitReport.cfm?mode=Exhibits&RequestTimeout=500&calledFromFrame=N&application_id=JZZOL5%2B5ipJTCxYoeNxwNw%3D%3D&fcc_id=2ACS5-ST16P

  • ST16S - Part No: YUNST16SUS Looks identical to the ST16+. Definitely different software. Definitely different outer case - handle on the back is plastic. Has full size USB port on top. Ships with Typhoon H Plus and H520. I am not positive, but I beleive these would have come pre-loaded with the “Datapilot” app. Shown here in some FCC filing: https://fccid.io/NCC/CCAF16LP038AT2/bwRsnegmx6g=
    youtube vid with clear pictures of internals (Note larger, black PCB instead of multiple green PCBs):https://www.youtube.com/watch?time_continue=1&v=o5SF4mb9xZU

  • Unknown ST16 variant - Now Ships with the H920. On the Yuneec site, the H Plus and H520 specifically refer to the transmitter as the “ST16S”. The H920 page on the other hand only refers to the transmitter as “ST16”. I dont know if this is a simple case of non-continuity in website editing or if that actually implies a different transmitter. The pictures on the H920 page show a different style 5.8GHz stubby antenna.

  • ST24 - Gray outer case, only ever had 2 external antennas. Also featured 2x more knobs up near the switches. Different software interface for the H920. At some point, Yuneec stopped supplying the H920 with the ST24 and now the H920 ships with a ST16S.

A quick google of “yuneec ST16 vs ST16S” comes up with many threads over at yuneecpilots.com, but there is clearly a ton of confusion about the nuances between these controllers. Lots of “you dont know what youre doing - this controller was made for xxx drone, dont you dare use it on a different one” going on. Aside from the ST24, which is not even supplied with drones any more (still available as a replacement part at some distributors). Unfortunately, users who list these for sale used typically do not know which specific variant they have.

As best I can tell, the transmitter I purchased was originally a ST16+. It has both external 2.4GHz antennas and did not come with Datapilot installed.

Now…back to my progress case. I Installed and ran the Yuneec “Updatepilot” app downloaded from this page: http://commercial.yuneec.com/comm-downloads-h520. The app looks like this: https://www.youtube.com/watch?v=s48t_vHe7Vg It showed that I needed to update all three available update-able things (no camera and gimbal showed up in this app, but thats no surprise cause i dont have any):

  • the “Updatepilot” app itself - i guess the app at yuneec.com was out of date already, lol
  • “Remote Control” - I assume this is the transmitter itself
  • “Datapilot” - again, the app download on yuneec.com was already out of date

After all of that and several auto-reboots with the little gear-tuning android guy, I am pretty sure the software think this controller is an ST16S (It showed “ST16S” at one point in the update process). After installing Datapilot, I was able to change the Home launcher in the android settings to force the Datapilot app as the home launcher instead of the stock Flightmode app. Now Datapilot launches at startup and whenever I hit the android Home button.

I was digging around in the Datapilot app settings and it looks very similar to QGroundControl, but with some clear tweaks. I did see a “Manual Bind” option in the settings, so I will need to try that. I have also emailed Yuneec to see if there is a way to bind the receiver without the copter. We’ll see what they say, but I doubt they will tell me even if there was a way.

TL:DR - there are a couple of variants of the ST16 transmitters. There is lots of misinformation and speculation online about it. After installing “Updatepilot” and “Datapilot” apps, it appears that my transmitter now thinks it is an ST16S. I am still working on binding, but I found a “Manual Bind” setting that I will try next.

Edit: No surprise - but I was wrong. Updated with better information. The controller I got was definitely an ST16+ due to the fact that mine has no full size USB and a Metal handle with rubber grip. Regardless, the android version of mine reads “ST16S” now.

I am a little concerned that with the internals being significantly different might also mean that hardware addresses and such are different…

I ran across the Yuneec Developer documentation page: https://developer.yuneec.com/documentation/133/Custom-Payload

And saw this:

RC Binding

To bind RC, you either need to send the bind command with param1 = 1, param2 = 0. Or alternatively, you can flip the H520 upside down. If it is in bind mode, the LEDs will flash yellow.

The “bind command” refers to MAV_CMD_START_RX_PAIR, ie command 500.

After some struggles, I was able to get MAVProxy running and connected to my copter. I do not know the details of the “rcbind” command, but when I type in
rcbind 1 0
the terminal window returns that it received the mav message #500 and “result:0”. I am unsure if result=0 is a success or failure, but nothing seems to happen. The light on the SR24 receiver does not change and continues to blink.

According to https://fccid.io/2ACS5-SR24/User-Manual/User-manual-2564161, I am expecting the light on the SR24 to go solid showing it is ready to bind.

Maybe @tridge can tell us if result = 0 is a success or failure after a 500 command? Do I even have the right context for the rcbind command ([command]-space-{param#1}-space-{param#2})?

Does rcbind even do what Im assuming it does? (Mavlink Cmd #500; “MAV_CMD_START_RX_PAIR”)?

Regardless, I tried going through the Manual Bind steps on the ST16 after executing the rcbind command, but no lights change and I still do not have response on the RC calibration page within Mission Planner.

Edit: I found documentation on the Mavlink results response:

Value Field Name Description
0 MAV_RESULT_ACCEPTED Command ACCEPTED and EXECUTED
1 MAV_RESULT_TEMPORARILY_REJECTED Command TEMPORARY REJECTED/DENIED
2 MAV_RESULT_DENIED Command PERMANENTLY DENIED
3 MAV_RESULT_UNSUPPORTED Command UNKNOWN/UNSUPPORTED
4 MAV_RESULT_FAILED Command executed, but failed
5 MAV_RESULT_IN_PROGRESS WIP: Command being executed

https://mavlink.io/en/messages/common.html#MAV_RESULT

So 0 should mean “accepted and executed”. At least I got the context right enough for it to accept the command, but I see no response at the SR24’s receiver. Lights blinking the same - still cant seem to bind fromt the ST16.

It turns out that mavproxy’s context for rcbind is rcbind <dsmmode>. Since DSM mode would be Param #2, it appears that mavproxy is only interpreting one argument. so I dug into the source for MAVproxy and found this:

As suspected, rcbind's one and only argument is being interpreted as MAV_CMD_START_RX_PAIR’s param #2 via the float(args[0]) placed in the second parameter position.

So I downloaded the source and edited mavproxy_misc.py to read:

def cmd_rcbind(self, args):
    '''start RC bind'''
    if len(args) < 1:
        print("Usage: rcbind <dsmmode>")
        return
    self.master.mav.command_long_send(self.settings.target_system,
                                      self.settings.target_component,
                                      mavutil.mavlink.MAV_CMD_START_RX_PAIR,
                                      1,
                                      float(args[0]), 0, 0, 0, 0, 0, 0)

…And re-ran rcbind 0 to force MAV_CMD_START_RX_PAIR’s Param #1 == 1 (via hardcoded as above) and param #2 == 0 (via the default <dsmmode> argument in MAVproxy)

The light on the RX turns off for a second, but then picks up blinking the same as before. So It is getting the message, but it still doesnt seem to be going into bind mode. I am looking for a solid light to indicate that the RX is in bind mode.

Work in progress…

Anyone have any pointers? Im just talking to myself here.

1 Like

Hello all, I’ve been watching the progress here for a bit because I’m working on a custom drone with a cgo3 and wanted to use a st16 for it. I finally went ahead and bought a st16 and rx that were previously bound so I could skip this part of the process, but I need help with what comes after and maybe this will be at least a bit helpful to you. So, as far as I can tell, the RX and st16 are bound, however the light is a constant orange when on the flight screen. According to the manual solid is binding, but it would be quite odd for it to be stuck in bind mode all the time, every time it connects. When I power off the st16 or leave the flight screen, the receiver begins to slow blink, as it should. My big issue, however, is that stick inputs are only being registered at the instant the reciever connects to the pixhawk. The stick positions at that instant appear in the stick monitor in qgroundcontrol, but it immediately says manual control lost and does not update again. Could the reciever be truly stuck in bind mode? Or is there an issue with the st24 decoder in the pixhawk code? If anyone can help me I would really appreciate it.

Hi Josh.

I have still been unsuccessful getting this to work. As you can see, ive basically just been talking to myself so far. ive asked some of the wizards around here for help but just gotten crickets. I assume they have bigger fish to fry, but I wish someone would jump in and help cause I am confident this should work from a technological perspective. and these transmitters are so cheap for what they are. So far, ive really just been poking around trying to get it to work.

Where did you find an ST16 and SR24 pre-bound? How do you know they are bound? Did the seller say that?

I did notice that on the hardware monitor screen in settings, all inputs appear to be frozen any time the ST16 is put into bind mode and they would stay that way. Restarting the TX and all the sticks, switches, etc come back to life. Try re-starting the TX and dont put it into bind mode.

How do you have the SR24 wired to the pixhawk?

Edit:
I also started this thread over in the MAVproxy section:

but im getting no traction over there, either.

I bought the pre-bound sr24 and st16 from someone who had a crash and was selling the parts off. I know they are bound because it shows the reciever in the bind screen when the receiver is on. The wiring to the pixhawk is according to an old page (internet archive) on the pixhawk website that shows how. I assume they must be bound because the momentary 12 stick inputs are correct, so data is definitely being transfered. However, it may be slipping into bind mode too quickly for the light to fast blink. Even if I never go to the bind screen, it stays a solid light once the transmitter turns on, as if it’s stuck in bind mode. Well, at least it’s connected.

You’re a step ahead of me. I wish I could find a typhoon with an owner local to me willing to bind mine.

Do you see the stick, switch movements in the hardware monitor on the TX?

What about the rc calibration page on mission planner?

Edit: what app are you using on the TX? Flightmode? Or datapilot?

I have still been unsuccessful getting my RX to Bind with my TX.

I am sure that the RX is now getting the command because the light on the RX turns off for a second, but then starts up blinking again after issuing a MAV_CMD_START_RX_PAIR command in MAVproxy. Prior to editing MAVProxy to hardcode Param #1==1, the light pattern did not change at all. According to the only documentation I have to go off of (the old original FCC application), blinking means ‘bound but not connected’. I am looking for a solid light which means ‘ready to be bound’.

@tridge @bugobliterator - your names are all over the ST24.cpp and ST24.h as well as AP_RCProtocol.h. Can you provide any guidance? I cant quite tell if the ST24 protocol implementation in Ardupilot is capable of binding or simply capable of handling the RC protocol AFTER it is bound? Surely one of the guys that wrote it must know?

It doesn’t do the bind, sorry, just the protocol

Hi tridge. Thanks for the input. How can we “send the bind command” as shown on the Yuneec page below? Yuneec is using the long mavlink command #500: mav_cmd_start_rx_pair. If they are using a standard mavlink command to bind, is there any reason ardupilot cant handle that?

the mavlink command doesn’t help. It is the implementation of what gets sent to the receiver to make it bind. We would need some technical documentation on the receiver on how it does a bind.
We could get this from yuneec, or you could use a logic analyser to look at what happens on the receiver pins when you bind with their system.

aww …man…

…well that is a roadblock for me and my “knows-just-enough-to-get-into-trouble” level of knowledge. are the $20 logic analyzers at sparkfun worth it? seems too good to be true compared to the prosumer grade saelae at $400. Even if I did find a logic analyzer, id still need a Yuneec 'copter in order to capture the bind protocol.

it would do the job, yes.
Note that Saleae also have a good hobbyist discount, and they are very nice devices

yes, or find some other open source project which has implemented it and learn from their code, or find someone in yuneec willing to tell you how it works

are the typhoon 4k running the st12 controllers the same as the st16 and 24, I have access to a st12 and a logic analyzer if that would help just not sure if they are running the same.

I THINK so. but im reverse engineering this from absolutely no documentation. The yuneec manuals and documentation available are no where near the technical detail required.

The receivers have different part numbers:
Q500 4k - YUNQ500107SVC
Typhoon H - YUNTYH135SVC

…but I have also seen both referred to as ‘SR24’ and they appear to be similar in appearance as well as pin/connector layout.

The RX i purchased on ebay was labeled ‘YUNTYH135SVC’ on the ebay listing only this number is nowhere on the actual component.

When you say ‘have access to’ that makes me think it is a friend of yours. Capturing the bind protocol would require opening up the typhoon and connecting to the RX to capture the bits being transmitted from the FC to the RX - Is that something you are willing to do?

Edit: It appears that users have been able to use the ST16 TX on the Q500 copter: https://yuneecpilots.com/threads/looking-to-mess-up-a-perfectly-good-st16.17124/

Reports read that they are having video resolution issues, but lets tackle this one step at a time.

When I say I have access to means its sitting in my closet collecting dust as it was the first ever UAV I bought, still fun to fly, not that capable for what I use UAV’s for. Yes I would be willing to open it up as I have done plenty of mods on it and am quite familiar with its insides, better question is time. I am currently working on defending my thesis and that is taking up a lot of time. The logic analyzer I would be using is from our physics department I could possibly try and get it done in the next cpl of weeks but we just came back from a very large data collection in Oregon that is also going to take up a good bit of my time. PM me and we could discuss sending it to you so you can do it yourself, like I said its has been sitting in my closet for ages collecting dust.

Hey, man, you do you. If you want to jump in to help, id be happy to have it. Ive never gotten into logic level stuff, so this will be a fun challenge for me.

i suspect the typhoon controller just send some command to switch the rx to bind mode (LEDs flash yellow)

with a logic analyser we should be able to capture and compare the data sent by typhoon and MAVproxy

Hi Sheng,

are you familiar with the Yuneec hardware? In particular, the recievers?

When you say the LEDs flash yellow - are you referring to the LED indicators under the motors of the air frame? or the LEDs on the actual RX board?

The LEDs on my RX are blinking orange when powered - but I was operating on the understanding that a ‘slow’ blink indicates bound, but not connected. ‘fast’ blink indicates bind mode and solid light means bound and connected.

actually I don’t have experience with yuneec hw.
I just bought 2 SR24 rx from Taobao, very cheap ($5 in total). but I don’t have any yuneec drone, so I can not capture the data.

after power on, the led on my rx is also blinking slowly. according to some video, it should flash quickly when in bind mode.

Servers by jDrones