An Open Source Frsky Telemetry Script for the Horus X10,X12 and Taranis X9D,X9E and QX7 radios

Alex this is the telemetry log recorded from my Bluetooth link from the Tbs Crossfire, So I Had a laptop at field and am connected to mt taranis via mavlink and tbs so this i believe shows that modes and arming data are present,

OK but this is mavlink, how do you get them on your QX7, I guess by discovering some TBS crafted sensors, bu which one because the TBS manual states that for extended info support from the flight controller is needed and ardupilot does not support CRSF!

Alex.
Here is how i Have done it pleaase see link to my folder here, hope it helps.
i am only an enthusiast so may not correctly answer your questions regarding tbs, but i believe in my setup crsf is not being used, i am using matek F4-5 Wing using sbus with ch 3 and 4 set as serial ports going to serial1 on f/c these are set to mavlink protocol.
this folder will explain in pics
Thanks.

Dave thank you, the way you have mavlink via bluetooth is the one I already knew about, what I was asking you is an explanation for this quote

How did you get full telemetry on your QX7 (non mavlink)?

Alex.
Don’t know how to answer this properly it’s coming out of serial 1 into the nano tx Ch 2 the qx7 is reading the data and telemetry shows

Ok Dave, this explains it, it’s using OpenTX sensors just like ardupilot’s “repurposed frsky” telemetry.
Your TBS system is decoding mavlink messages on the ground extracting the info you see in order to inject them as fake OpenTX sensors in your radio sport pin on the back of the radio.
This way you’re missing some ardupilot specific info like flight modes and the like.
Unfortunately my script does not work with this kind of setup, it needs a “passthrough telemetry stream”.

If you have an ESP32 board around you might try the firmware I linked in my previous post.
With ans ESP32 board you could:

  • connect the esp32 via bluetooth to the TBS to receive mavlink
  • produce a passthrough telemetry stream to inject in your radio to support my script
  • connect to the esp32 via wifi to use mission planner

If you decide to try this road I strongly suggest you ask for support in the mavlinkToPassthrough thread

Hi Alex,

“The BMP280 sensor in the F405-Wing is nothing special, but would be sufficient if the VSpd displayed by the Mission Planner were transmitted in the same way.
With the Yaapu script come strange values. First often much too late (>1-2s), then often inaccurate (+/-0.6 m/s) and often values stay for seconds. They have nothing in common with the display in the Mission Planner.”

These are statements from users who use an F405-Wing with ArduPlane, but would like to use the vario functionality. But that’s not possible due to the problems. Is it possible to optimize something in the script here?

Hi Reinhard,
a couple important points:

  • ardupilot does not send baro vspeed but the EKF fused vspeed (GPS + imu + baro) so the two values baro vs fused could differ (mavlink has baro and ahrs vspeed, sport only ahrs).
  • ardupilot sends vspeed info at 2Hz so there’s a built in 500ms “potential latency”.
  • the script does not manipulate the values, it simply displays what it receives from the telemetry stream so it cannot introduce latencies, the vspeed and alt sensor values at injected into OpenTX at around 3 to 5Hz depending on the radio with the Taranis being faster

How can we proceed to debug what users are reporting? we need a reliable way to reproduce the very same issue!

Hi, Alex,

that’s gonna be another problem to debug… I’m also thinking about how to do that.

I hardly use a Vario myself (I have my OSD), but in a direct comparison with an OpenXSensor Vario it is already the case that the data in your script arrive very delayed.

Of course this is not directly comparable, because the OpenXSensor uses a completely different Baro, but it would perhaps be a viable way to optimize the display if possible.

…well it really depends on what you’re trying to achieve.
If you fly auto modes or even soaring in auto you’d want to see on display what the plane is processing so you really need the same source for vspeed info (pretending there’s no delay).
If you fly manual or acro than you can benefit from an external vario source I guess.

I also think that it probably tends to result in an external vario. I will discuss that again. Thank you for your hints!

Thanks Alex.
I will give this some thought. I have an ESP32 here already.
Thanks for your time,
Dave.

1 Like

Hi Alex,

do you know why VSpd is not transferred with protocol 4?

I released version 1.8.0 with minor changes from RC2.

code is on github

x10

screenshot_x10_19-09-08_21-52-54

full changelog:

  • removed dependency from blue theme
  • added new hud layout, speed on left, alt on right VSI on bottom
  • new message history screen with telemetry info
  • added support for up to 6 user selectable frsky sensors
  • added haptic feedback support
  • added total flown distance (calculated from speed)
  • added PX4 flight modes support
  • added support for mavlinkToPassthru firmware
  • added vocal playback of selected mavlink messages
  • added support fot series and independent battery configurations with individual cell count override
  • added support for battery voltage > 51.1V
  • added new message alert silencing options
  • added menu option to define a channel to toggle between main screen and message history
  • added support for boat frametype
  • fix for quick flight mode switch
  • fix for rover modes vocal playback

Alex

1 Like

Hi Reinhard,
I have no idea why it was not implemented, I checked the code and the library is using the vario IDs to only send altitude, you might raise an issue and ask to add it?

I did a simulation to check vspd latency, SITL is running my patched scheduler and I did not notice any “big” pauses in vspeed reporting.

I realized I told you to use “alt” (altitude) as vario source but I was terribly wrong, please excuse me, the correct sensor is vspd indeed!

Hi Alex,

thanks for the info.

Hi Antonio,
release 1.8.0 has a black background for user sensors and should be much easier to read under direct sunlight.

cheers,

Alex

Thanks Alex, I am very excited to try the new release and thanks for satisfying my request.
Sorry for my english
Grazie.
Best regards

Antonio

You’re welcome and “il tuo inglese va benone” :slight_smile:

Alex

1 Like

Is there a straightforward way to add custom flight modes?