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

testing some minor cosmetic changes:

  • extended status bar with last 4 messages
  • roll and pitch on the cockpit
  • colored message history on black background with telemetry bar on the right

Hi all,
this is the first public test version 1.8.0-beta3 for Horus radios

Note 1: OpenTX 2.2.3 is recommended
Note 2: This version requires the luac option checked in OpenTX settings

image

Notes

Layout changes

There are 2 user selectable layouts, the new one (default)

screenshot_x10_19-04-27_15-16-08

and the legacy one,

screenshot_x10_19-04-27_15-08-03

selection is made with the config menu

Message history is now colored

screenshot_x10_19-04-27_15-10-59

Frsky custom sensors support

Just like the Taranis version is possible to display up to 6 “frsky sensors” from those discovered in the radio telemetry screen.
In the example I’m showing individual cell voltages from my FLVSS sensor

screenshot_x10_19-04-27_15-08-24

screenshot_x10_19-04-27_15-06-06

Sensors can be defined by editing the per model lua configuration (example included in the /SCRIPTS/YAAPU/CFG folder)
This was designed with gas suite users in mind, it’s possible to define multipliers, labels, warning and critical levels in the conf file.
There’s also the option to define lookup tables, when a sensor value is found in the lookup table the script shows that value instead of the sensor one.
When the script is in “show min/max” mode by short pressing [MENU] the custom sensor panel will show min or max values depending on the “min or max tracking” option defined in the lua configuration file.

@ChrisOlson briefly explains this new feature in his video

Support for @Eric_Stockenstrom “Plus” firmware,

By using Eric’s Plus version the teensy adds some extra info to the passthrough protocol:

  • waypoints
  • airspeed
  • throttle

In order to display this additional info a custom left panel has to be enabled in the script conf menu

screenshot_x10_19-04-27_15-23-47

screenshot_x10_19-04-27_15-24-15

Support for new battery configurations: serial and independent

  • independent dual batteries with cellcount override for 1st and 2nd battery (select “other” in batt config menu)
  • batteries with voltage higer than 51.1V (requires to select 12s override in config menu)
  • chained FLVSS as serial battery config (select “ser” in batt config menu)

…and

  • voice playback of selected mavlink messages
  • fix to skip flight mode vocal announcement for very quick flight mode changes, like flipping a switch from pos 1 to pos 3
  • haptic feedback, has to be enabled from the menu
  • more options to silence the incoming message beep
  • support for PX4 flight modes when used with Eric’s mavlinkToPassthru firmware (has to enabled from the config menu)

as always feedback is very welcome,

cheers,

Alex

1 Like

Hello Alex,
take a big compliment for that work.
Looks great and just have done two flights with different Cube black 3.6.8, CUAV-V3 and the default config - everything works for me.
best wishes and have a nice day

Thanks Roland, really glad it worked all right!

Alex

Hi Alex, I’m having a problem with one of my quads where I get occasional “Bad GPS Health” messages on the yappu screen, but there is no message displayed on the OSD (Kakute F7), and nothing in the dataflash log. At the time it occurred the GPS log showed NSats = 21, HDOP = 0.56, and status = 4. Any idea what is happening here? Thank you.

Hi Anthony,
that particular messagge is sent only by the telemetry library, take a look here, it is forged and sent as a text message after checking the healthy bit of your gps.

You’re not seeing it on your OSD because mavlink sends it as a status bit mask not as a text message and OSDs usually ignore it.

Maybe a duplicate of these?

Thank you - that’s exactly what’s happening. And I thought more satellites was always better. Obviously not in this case.

1 Like

Question about Receivers

Long time Futaba user for some 40+ years- and most of my gear is Futaba FASST with a T8FG Tx. I am looking at all this Open TX stuff and considering buying a new Tx. I an currently flying mostly LOS multi copters with ArduPilot.

Seriously looking at Horus TX but I want some advice on some small Rx(s) that will be suitable for smaller quads with the mavlink ArduPilot telemetry available using this script on that Tx screen. I do want Rx’s with a reasonable range, as I don’t want problems with range if something goes wrong during flight in my back yard( That never happens-right!) I will admit- I am a bit confused on all the FrskyTx/Rx protocol stuff; and think I know some answers from Wiki, but before I pull the trigger and waste money these questions;

What 2.4Ghz Frsky Rx(s) -and compatible -including some really small ones for “micro” quads, work REALLY WELL with no hassles with ArduPilot and this Script.

What Tx protocol do I look for in a Rx, assuming a Horus Tx is used?

Do I need some kind of converter/cable for that Rx to get data from my FC to the Rx? (I have 2.4.8 Pixhawks, Mr0 Pixhawks, Mr0 Pixracers, and a few of the newer Ominibus FC’s running ArduPilot machines).

Thanks,
Joe

1 Like

Hi Joe,
nice question and a complete answer is quite challenging :slight_smile:
I suggest you open a new thread such is the challenge :slight_smile:

IMO the features you want are: sbus and s.port telemetry
There are 3 firmware types, FCC, LBT (EU) and Flex.
All FrSky radios have built in support for X series on 2.4Ghz and need an extra module on the back for 868/900Mhz and 2.4Ghz DJT (V8 binding)

You get s.port telemetry on:

  • X series on 2.4Ghz by binding in D16 mode (no extra module, range figure 1.5Km)
  • R9 series on the 900/868Mhz, you get different s.port telemetry options based on the firmware type and selected power output (up to 1000mW) (requires extra module, range figure 10Km)

The s.port on the receiver is wired to the flight controller, in many ways:

  • with a dedicated inverter/level converter cable such as this, most boards need this cable
  • with a direct connection on Pixracers, the cable has tx and rx on the pixracer side shortened
  • with a direct connection on selected F4/F7 boards like Kakute AIO (latest ardupilot dev versions adds support for boards with hardware inversion and/or single wire serial)

hope this helps to put you on the right track :slight_smile:

Note: I found this comparison table that might help

Alex

Alex,
Thank you for the response. You completely answered my questions and the link to the Rx table filled in my understanding of the various Rx protocols and options and limits. ( Note: the link to the eflight Wiki listed in that table appears to be hijacked). Can’t wait until I get a new Open Tx and use your script. I have been following your thread since day one. This script is really the only reason I wanted to get a new Tx.and really appreciate your sharing of all your hard work.
Joe

You’re welcome Joe, and thanks for the kind words, hard work without sharing is only half fun :slight_smile:

2 Likes

Alex, any idea how to proceed with my issues with some systems using Teensy Mavlink converter working with Taranis and this script, and other not doing so? perhaps a minimally invasive debug version that just checks, yes/no, at a few points in the stream acquisition process?

mhmmm the “lightest” tool I can think off would just count the incoming packets per type and display them on screen, if you see the counters getting higher you’d know passthrough telemetry is working, unfortunately I don’t have such a script ready for you but I’m sure I can make one pretty fast.

But since it’s OpenTX code that decodes the packets from the serial port and pushes them on the lua telemetry queue I doubt that you’d get any insight on what’s going on.

Henry, I sent you a very light script that just counts the incoming packets

Thanks, I ran it…its not your script…its something in Opentx…
on working models, I see the stats increase (albeit slowly…its certainly not every packet…more like every 10th or more…but it does increment), on non-working it never gets off zero…
then I would take a nonworking model and just use a working models, and it worked…so its something to do with model setup in Opentx

you have to run it alone, 2 scripts cannot share the sport lua queue.
btw, we already know the flow starts and stops from your previous dump, if you see it flowing with this minimal version than we’ll try to dump it with another minimal script in the hope that a minimal version is not affected by whatever is sent by your setup

probably the slow increment on working models is the two scripts sharing the queue…they do seem to work in parallel, apparently r
obbing packets from one another

I’m not sure I understood but you can have as many models as you like, all with the same script assigned to one of the telemetry screens, what you cannot have is 2 or more scripts sharing sport queue access on the SAME model
Note: the sport queue can be shared but each packet can be processed by only 1 script so the scripts would steal packets from each other

I added the stats script on screen two of the models…it works, both sharing the queue, one gets some packets, the other gets some…

but I have several model on the TX with the same Yaapu script… all have the same DL RX/TX setup…all get good telem thru DL TX via the BT I have wired in parallel with Teensy (which is one unidirectional)…
on the same FC on the bench, I can switch between models using the DL module on the Taranis…some have the script working and the stats upcounting…some do not…it seems linked to the model configured on the Taranis, not actual plane…I tired enabling the internal RF, thinking that it may be that transfer on Sport pin is somehow linked…no difference

if a copy a model, whether it works or not, follows with the copy

Can you test it on a new model created from scratch?