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

Helps! thanks…I increased it a bit more to 1 sec, more to my taste…
also, I modified the 9D script for imperial units (feet/mph/feet per sec)

Great, now I have a reference for an imperial units version :slight_smile:
…and as the only user of the “synthetic vspeed” feature your opinion counts a lot :slight_smile:

thank you.

HI Alex
i used to work with teensy 3.1 board on converting Mavlink to s.port and i wonder is it the same with your script ?
or you are using a different method to connect the X8R to pixhaxk ?
i want to use it but on fixed wing fpv plane with pixhack and horus x10s
with arduplane firmware .
will it work ?
thanks for your grat job here
effy

Hi,
the teensy is not required anymore for ardupilot supports the frsky passthrough protocol as a native option.

For the pixhack you will need a cable like this one

then you’ll have to configure your serial port to output “serial protocol” 10

http://ardupilot.org/copter/docs/common-frsky-telemetry.html#frsky-telemetry-configuration-in-mission-planner

cheers,

Alex

thanx
ill give it a try with fixed wing

1 Like

Hi,

I had an old version of the LUA from the MavLink project on my taranis and decide to try this one - got a new version 1.5.0, i think.

so, i got all the sensors in, i see it partially gets data shown on the screen but it has constant banner ‘no telemetry data’ in front.
following the script i see it looks like it goes into the sub
local function telemetryEnabled()
if getRSSI() == 0 then
noTelemetryData = 1
end
return noTelemetryData == 0
end

and at which point i am lost as obviously i get RSSI fine and it even prints it on the screen in top line - 80 to 81 something, not important how much. RxBt also gets sent in fine. Logic in drawtelemetry also seems ok at a first glance - what can be the deal?

old mavlink 2.01-rc script does not complain and draws all fine, screen works correctly. I can of course kill that sub and suppress this window but i am confused - what is going on?

Only part i suspect - i see no function getRSSI() defined in the yaapu9.lua script - is it something global? or is it the reason - should it be defined in this same script? sorry for stupid questions, i am not a lua expert.

I googled a bit and found this alteration was done on
"yaapu commented on Mar 9
switched to getRSSI() to detect telemetry status"

odd stuff, if i have standard last 2.2.1 OpenTx - is it a firmware issue?

Hi Paul,
my script and mavlink one use a completely different approach.

quick requirements list for the yaapu script

** no sensor discovery is required for the script to work.**

If you’re getting “no telemetry data” it means that your radio is not receiving passthrough telemetry packets.
please double check that you’ve enabled the correct protocol in mission planner.

Alex

Sensor discovery was needed as i upgraded radio from 2.0 into 2.2 bios.
The fact that it found channels and shows values coming from vehicle means it is linked correctly.
Setup i run is a usual build that was “standard” for 2016 or so - pixhawk telemetry goes into teensy board, and teensy feeds into x8r frsky receiver.

So, it all actually works fine. I see rssi channel with F101 tag, when vehicle is powered up i see telemetry values updating on the telemetry channels screen and on your script main page.

Issue is with getRSSI call, not sure why. I will try to look at it more today but cannot find anything on this thing other than it is ‘built in’ in the 2.2 firmware. Not sure why but it does not seem to work properly.

Paul we are talking about different protocols.
The teensy projects, all of them, use the “plain” frsky sport telemetry protocol. The teensy receives mavlink messages and simulates “many” sensor by sending these virtual sensor values using legit frsky sensor IDs, that’s the reason why you can discover them on opentx.

My project uses the frsky sport “passthrough” protocol which was designed not to use frsky sensor Ids and is natively supported by ardupilot (no teensy required)
For my script to work you would replace the teensy with a passive cable that adapts the levels from rs232 to ttl and inverts the logic, the pixhawk has to be configured to generate frsky passthrough packets and not mavlink as before, so the serial protocol on the telemetry port on the pixhawk has to be set to 10 not 1.

that’s it.

Alex.

Ok, it makes sense. Obviosly i am not going to rebuild drone to accomodate script, it will be other way around. I see what to do now. It makes sense, and if getRSSI is the only obstacle it is an easy fix.

Everything else in the script works fine with teensy and simulated channels from what i can tell so far and this “legacy” hookup to pixhawk seems to work just fine.

An option that is work in progress is a mavlink to frsky passthrough teensy adapter, right now used on the ULRS project by community member @Eric_Stockenstrom, this would have to be modified to emulate a sensor rather than an frsky RX which currentely does.
Check his github repo

this setup would allow you to retain your current cabling.

Alex

Alex,

thanks for this reference. it makes more sense now.
Also, as we got on this topic - could you please tell me what exactly you did to compile your lua script?

i did not do this thing in 3 years - :slight_smile: - and completely forgot what was the sequence. i figured by the “LuaR” front signature in the luac it is the 5.2.x compiler - but i cannot recall how to compile this damn thing. i have luac installed on CentOs - but it does not seem to be able to produce a luac file that is consumable by OpenTX. if i compile it on linux box it says on taranis ‘incompatible precompiled chunk’.

After upgrade to 2.2 it also installed new companion, and i see no options in it at all how to compile lua script. or may be i just forgot it altogether. how exactly did you get that file compiled for 2.2 opentx? as without luac it produces memory error.

Use opentx companion, copy the script there and run as a telemetry script. I use a local Lua setup to apply the preprocessor. Select the luac checkbox in radio settings

holy cr@p. :slight_smile:

yes, sometimes things are way simpler than one would think. thanks so much, it is ridiculous that i have tried - everything but that. it did compile it fine now, thx!.

you’re very welcome, LOL

Hi all,
new release for the Horus radios:

  • rangefinder support with max range from config menu
  • “synthetic vspeed” calculated from altitude changes with menu option to enable/disable
  • air/groundspeed unit selectable from menu (m/s or km/h)
  • larger HUD
  • many small fixes

image

for an explanation of what’s displayed on screen please check the documentation on github

thanks to all who contributed

Hi Alex,
Thank you very much for this great work.
Before I use the Flight Deck telemetry but only yours support the Horus X12S.
At current I run the script under TX2.2.x on a Taranis X9D+ and HorusX12S.
For the autopliot I use the Pixhawk series and the ArduPilot Plane software.

Now I have a question about the displayed speed.
I only get the value from the air speed sensor. According to your description it should be possible to display the grundspeed or the synthetic speed.
If I use a Pixhawk without air tube the displayed speed is allways zero. On the log files I could read the groundspeed from the GPS values.

Have You any idea in witch direction I could search?

Thanks and best regards,
Markus

Hi Markus,
the frsky telemetry library on the pixhawk sends down the telemetry link only 1 speed value.
Where it picks that speed value depends on arduplane configuration.
There are 2 possible configurations:

  1. you have enabled an airspeed sensor in arduplane: ARSPD_TYPE > 0
    in this case the telemetry library will try to use airspeed even if the sensor is unhealthy, if it’s unhealty (no tube) the speed will be 0, with the tube present you will get airspeed.

  2. you have not defined an airspeed sensor:ARSPD_TYPE = 0
    in this case the telemetry library will always send groundspeed (gps) even if physically the tube is present.

As you can see the script has no control on what gets sent by the library.

The only way I can think of to have both airspeed and groundspeed is to let the user enable such feature in the script config menu, for only the pilot knows if he/she has an airspeed sensor enabled on arduplane.
I do not fly planes so I’m asking you: would it be of any help to have an estimated synthetic “groundspeed” updated at 1Hz based on GPS coords?

If so I could:

  1. create a menu option to let the user enable “synthetic groundspeed”
  2. calculate “synthetic groundspeed” based on GPS coords updated at around 1Hz
  3. display both airspeed and “synthetic groundspeed”

what do you think?

cheers
Alex

1 Like

Hi Alex,

I fly planes and copters. Even I try to build a Quadplane.
But I have had to learn that the weight witch is maybe ok for a copter could be a no go for a plane.
Leason learnd - next time (in the winter) I will take more care about the weight.:grinning:

At the moment I fly planes and I like the virtual cockpit very much.

Yep the problem was the ARSPD_TYPE. I should erase the Pixhawk completly before place in a other plane.:thinking:
Before it was in the damaged Quadplane and there was a airspeed sensor inside.

I would prefere only one value at the screen. Airspeed or groundspeed. Ohterwise maybe to much information.

At the moment your display on the Horus is very well balanced.

Personaly I like the groundspeed because less problem with the calibration an the ugly tube.
Of course the indecated airspeed would be the best if the wind is stronger. But mostly my landing speed is to much and I need the full runway.

In a older article from 2010 I read about wind estimation without an airspeed sensor.
They use the GPS, accelerometers and extended Kalman filtering.
I think its already integrated in the actual ArduPlane V3.8.5 but I didn’t found some information about it.

On the mission planner I see too values.
Airspeed and groundspeed - even the airspeed sensor is type 0.
The values are different, so I think the airspeed value is the “calculated airspeed”.
In this case it would be very nice to select airspeed or groundspeed on the telemetry menue.

Cheers
Markus

1 Like

Hi,

The airspeed is very important for a manual landing.

At an airplane, the ground speed may be negative if the wind speed is higher than the speed of flight

it is good to have both values

How can I get the airspeed to get an audio alert?

Hi Roman, could you please explain better what you would like to achieve?