Has anyone used a Yuneec ST16 Transmitter with arducopter?
It looks like the RC control protocol is in the AP_HAL_:
…But has anyone been successful at running a GCS software on the touchscreen? Has anyone been able to get the telemetry to work?
These transmitters can be found on ebay for pretty cheap:
and the receiver is super cheap as well:
Itd be real slick to integrate it and run QGC or Mission Maker.
Ok, so ive been doing some more digging…
Turns out the Yuneec copters run a version of PX4 (which isnt a surprise since theyre part of drone code). Back in 2015, they actually announced support for the pixhawk and the ST24 in particular:
The links in that post are 404 by now, but using the Wayback machine, I was able to pull an archived page from April 2018 which describes the pinout from the Yuneec 2.4Ghz receiver and connection to the SPKT/DSM port:
https://web.archive.org/web/20180405205736/https://pixhawk.org/peripherals/radio-control/yuneec
Does anyone know if the ST24 and ST16 protocols are the same? I assume they are…
well, i took the plunge and picked up an ST16 on ebay for $160 and a SR24 for $12.
The android version is 4.4 and the installation on these things is heavily modified. The google play store is broken (intentionally from yuneec). However, I was able to load apps with just their APK files.
My prefered GCS would be Mission Maker, but that requires Android 5.0 and up - so that is a no go. However, QGroundcontrol runs on Android 4.1 and up - so that installed fine with an APK.
Then i noticed some curious similarities between the screenshots of Yuneec’s “Datapilot” app and Qgroundcontrol. I was able to find the APK of Datapilot at the Yuneec site: http://commercial.yuneec.com/comm-downloads-h520
Re-pinned the connector from the SR24 per the links above…But I cant figure out how to bind the transmitter and receiver. With the Typhoon and Tornado copters, you would tilt the whole copter forward twice and it would enter a binding mode. Obviously that procedure is not available. There is a button on the receiver, but it doesnt seem to do anything that I can tell. Doesnt change the light pattern or anything. I tried holding the button down while powering it on, but no change in the lights and I cant get it to show up in the binding screen of the native Yuneec app.
So I am stuck at trying to get the transmitter and receiver to bind. I emailed yuneec service to see if there is a way to bind the two without the copter. They may not like that I am trying to repurpose their gear, but we’ll see.
@ekliptiko sorry, i can‘t tell for sure if it‘s working on current release firmwares, but i remember positive comments in the context of the receiver protocol RSSI type implementation PRs. that’s been a while though, likely back in the NuttX days.
i‘m currently trying to gather information for an update of the RSSI wiki page, but these yuneec protocols don’t seem to be used very frequently. so i‘d highly appreciate your feedback if you get it working, even more so regarding the use of RSSI_TYPE = 3 (receiver protocol, SUMD / ST24).
good luck! cheers, basti.
Hi vierfuffzig,
Thanks for jumping in here! Are you familiar with the Yuneec protocol? Ive found limited to no documentation about re-purposing it outside of the yuneec ecosystem (which probably shouldnt be a surprise - that is not intended by yuneec).
I did find this:
https://www.rcgroups.com/forums/showthread.php?2973916-Yuneec-Receiver-protocol
Where the OP broke down and reverse engineered the protocol.
I didnt even think to check any parameters - let alone RSSI_TYPE. Ill read into that. Are there any other special procedures or parameters required to use the SPKT/DSM port?
The OP over here appears to have successfully connected the SR24 receiver to the pixhawk. Some posts say to push the button during power on, but at the end of the thread mentions that they had to install it on a Typhoon H to bind, then removed it and it worked with the pixhawk after binding.
Im just stuck at binding, let alone checking all the telem, etc!
sorry @ekliptiko , not familiar with the hardware. as far as i understand the respective ardupilot code, it should be well possible to use the yuneec controller / receiver hardware once bound correctly. i can’t find any helpful information on the bind procedure outside of a yuneec airframe beyond what you already got though.
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):
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.
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
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.