thanks to @adam for the picture, this is the Horus version running on an X10S
Wow, beautifully done Alex.
Well hell…(goes to find credit card to buy an X10S)…
Ok…maybe not. $450 US is a bit more. I’ll stick with the x9 plus
can you send to me download link for x12s horus telemetry script ?
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
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!
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 ?
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
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
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.
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.
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.
@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
3 decimal digits
there’s room for both
I’ll set 2 digits as default on X9D
You are a great person.
I did a search with my friend 's introduction … I was able to get very satisfied LUA.
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.
finally a tester for the rangefinder
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
No problem to test
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?