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

Ok…maybe not. $450 US is a bit more. I’ll stick with the x9 plus

3 Likes

hi Alex
can you send to me download link for x12s horus telemetry script ?
https://discuss.ardupilot.org/uploads/default/original/3X/8/b/8b410e79f8b775b543f3e15db6ba30b083253830.jpg

Just a heads up that someone has released a beta of a Mavlink to Frsky Passthrough convertor that runs on Teensy. This will be great for all us Dragonlink V3 users using full Mavlink as it means we can use your lua script. I will test soon and report back. https://github.com/zs6buj/MavlinkToPassthru/wiki

2 Likes

Thanks Marc,
Eric has contacted me to debug a small issue so I was aware of his project but I agree it’s worth mentioning it here for I believe he did a hell of a job!

1 Like

Folks, I’m using the ancient Teensy-based MavSky protocol, and my X9D is still on OpenTX 2.1.7, for which I have a nice and simple script. Do I need this new Passthru protocol on my Teensy or build a serial inverter to be able to upgrade to 2.2.1 and enjoy your HUD ?

Hi,
as a first required step you would have to upgrade your radio to OpenTX 2.2.x.

Then if you run a recent version of ardupilot you can enable serial protocol 10 and all you would need is a serial inverter like this one Some soldering required (if you have a pixracer you don’t even need the inverter)

But if your flight controller cannot output native frsky passthrough protocol but can send mavlink then with Eric’s Teensy converter you should be able to use my script.

Hope this answers your question, if not ask for more help :slight_smile:

cheers

1 Like

hello Alex “yaapu”, a couple of days ago I received my Horus x10s and I was looking for a couple of LUA Scripts and found this masterpiece that you have created.

Could you send me your script? I can inform you of the failures or ideas of improvements
thank you very much
Max from Germany

Hi Max,
I’ll send you a download link.

All the implemented features have been verified as working, so you should be able to fly with it.

Alex

1 Like

Hi Alex,

This looks fantastic. I really like the Horus colour version - any chance I could get a link to the beta script also? I will be happy to feedback my experience if all goes well with the implementation.

Great job!

Darrel

Hi Alex.

Thanks for the instructions. I’ve built the MAX3232 cable, upgraded the radio, setup Serial_4 protocol on Pix and everything works.
Now, how do I get on with modifying the screen layout ? I really need the mAh spent instead of just Ah. Last summer there was an instance when changing meteo conditions meant pushing a couple of batteries to the limit to finish the job - 9930 and 9875 mAh spent out of 10 Ah lipos. I know my Mauch sensors are accurate within 10 mAh on the whole battery so the change rate on those last two digits is important.

Cheers,
Cornel.

@ThePara I sent you a PM

@ThePara there should be room for 2 decimals in default version, if so I’ll add it to master.

EDIT: there’s room
2 decimal digits
immagine
3 decimal digits
immagine

there’s room for both

I’ll set 2 digits as default on X9D

Alex

Hi, yaapu

You are a great person.
I did a search with my friend 's introduction … I was able to get very satisfied LUA.
Thank you.

@wolflone thanks for the kind words, happy it worked for you.

Alex

hi Alex, just have a doubt about the Altitude value that is displayed, because I use a TFMINI range sensor. When I take off, ok value is 0. But after a short fly, value indicates 1.5 or even 2 meters when landed. So 2 possibilities, it could be the baro altitude value, in this case my range finder is working correctly, but if the displayed value is the one calculated by the FC (range finder value in this case between MIN and MAX values) that means that the FC is not calculating the Altitude value correctly.

Hi Chris,
finally a tester for the rangefinder :slight_smile:

The telemetry sends altitude and rangefinder distance as separate streams, that’s the reason why you see 2 when landed, It’s the EKF fused altitude (baro + gps + imu + range, range only if configured in mission planner with specific parameter if I recall right)
I’ll change the code so when I read a rangefinder value > 0 I’ll display it instead of the AltAsl value which is nice but not so usefull.
On the QX7 I’ll have to be creative :slight_smile:

No problem to test :slight_smile:

I think it could be more difficult, what will you display when the Range finder will be outside the limits of RNGFND_MIN_CM and RNGFND_MAX_CM ?

You’re right, for me, if I correctly understand, the displayed value in your script the EKF fused and this value should be correctly calculated. When I read the doc, this value should shows the Range Finder altitude between the MIN and MAX altitude (set for each different RF), and the Baro Alt in other situations, but it seems not to be the case (for me!) What do you think?

I agree, we’ll have to test it and see, the telemetry library doesn’t do any checking at all, looks like it sends what is reported by the rangefinder

// rangefinder measurement in cm
attiandrng |= prep_number(_rng.distance_cm_orient(ROTATION_PITCH_270), 3, 

the relevant function is

/*
 * prepare attitude (roll, pitch) and range data
 * for FrSky SPort Passthrough (OpenTX) protocol (X-receivers)
 */
uint32_t AP_Frsky_Telem::calc_attiandrng(void)
{
    uint32_t attiandrng;

    // roll from [-18000;18000] centidegrees to unsigned .2 degree increments [0;1800] (just in case, limit to 2047 (0x7FF) since the value is stored on 11 bits)
    attiandrng = ((uint16_t)roundf((_ahrs.roll_sensor + 18000) * 0.05f) & ATTIANDRNG_ROLL_LIMIT);
    // pitch from [-9000;9000] centidegrees to unsigned .2 degree increments [0;900] (just in case, limit to 1023 (0x3FF) since the value is stored on 10 bits)
    attiandrng |= ((uint16_t)roundf((_ahrs.pitch_sensor + 9000) * 0.05f) & ATTIANDRNG_PITCH_LIMIT)<<ATTIANDRNG_PITCH_OFFSET;
    // rangefinder measurement in cm
    attiandrng |= prep_number(_rng.distance_cm_orient(ROTATION_PITCH_270), 3, 1)<<ATTIANDRNG_RNGFND_OFFSET;
    return attiandrng;
}

Edit: I checked the code briefly, looks like we’ll get raw values even when out of range, only EKF2 and EKF3 seem to use RNGFND_MAX_CM

Edit: If this is the case I could add a menu option to specify the RNGFND_MAX_CM, with vocal warning when out of range :slight_smile:

Sorry,what do you mean with “raw values” the basic Baro value or the calculated EKF value?

Sorry Chris I meant that the frsky telemetry library sends the “raw” values reported by the rangefinder without doing any checking wheter they exceed RNGFND_MAX_CM or not.

From my (rather quick) checks appears that only EKF2 and EKF3 libraries do check for max ranges and ignore the value when necessary.