Hi all,

I just bought an FrSky Taranis for my quad copter and needed to get the Mavlink data up on the Taranis LCD telemetry display. So here is my solution using a Teensy3.1 as a converter between MavLink and the S.Port on FrSky X8R.

See attached file below...

Views: 307406


Reply to This

Replies to This Discussion

Robert, That is an issue with the wiki (missed removing a bit) since the configuration page took over from the offset.lua mixer script - that was how we used to set the offsets and plane/copter before I rewrote the LUA scripts. Thanks for spotting the wiki issue - I have just fixed that.

I haven't had the weather lately to do any flying, but once I do I will get my fx61 in the air to test the windspeed (its the only pixhawk equipped plane I have (also has digital windspeed sensor.

Cheers, Paul

This is clearer to me now.  I did two more flight and noticed that the speed on the lua dashboard is likely correct.  Outside of that, I have my own telemetry screen that has air and groundspeed in it as well as voice alerts for providing warning speeds.  Those elements are either reporting in KPS or m/s.  I am not sure which.  I also got the sensors to dump logs and they seem to indicate the airspeed to be in kts but the values in the logs are consistent with my dashboard and not the Lua dashboard.  I can upload the logs if you want to see them.  I would like both dashboards to be consistent with each so I can setup custom alerts.  

Let me get the GS Telemetry, onboard logs, and Taranis logs uploaded.

Link to logs below


Robert, the telemetry sensor is configured for kts as you know (the log file shows the same), but the numeric value on the sensor is actually m/s. The teensy sends in m/s, but if the sensor on the taranis is configured in anything other than kts, OpenTx applies a scaling factor to the received value which skews it beyond use. So you should expect the value in the OpenTx logs to be in m/s even though the column header shows kts. My telemetry script scales this depending on which scale you choose. This scaling is applied in https://github.com/athertop/MavLink_FrSkySPort/blob/Mav_Sport2.1-2.... in the function setUnits()

for kph multiplication factor is 3.6, for kts its 1.94384, and for mph its 2.23694 (of course, for m/s its simply 1).

Regards, Paul  

I am not a programmer but it seems that the below variable needs to be set:

shvars.speedUnits == 2

I am assuming that units_set is unset so it traverses the if/elseif/elseif/else code.  Let me know if I am wrong.  If I am right, how would I set speedUnit to 2?  If I correct this, will this corrupt the speed displayed on the lua display?



shvars.speedUnits is set by your units selection on the configuration page (which is the code in confrun.lib), which writes the chosen value to your model config file. Its read back in from the config file when the code is initialised. I think you are over thinking this - assuming that there is a code issue.

So I should make a change to my models configuration?  What should I set the speed to?

return {["speedUnits"] = 2,["altUnits"] = 1,["apType"] = 1,["offsetmah"] = 0,["offsetwh"] = 0,["whCap"] = 0,["armGvar"] = 0}

If I change this, will this impact the other customized lua dashboard that goes along with this tool?  I do not want to fix one dashboard to corrupt another.

I am sure this is a coding issue as you stated as much.  They are sending 'm/s' over for speed but labeling it knots in the sensors on Taranis.  My impression is as much too.  It seems that somehow your code mathematically corrects that mistake for the customized lua dashboard only, leaving the raw sensor with the unit error.  It seems proper to fix the raw data in the code so it can be used for future purposes without having to code in a correction after the fact.

I want to walk back the statement that your code is mathematically correcting the error.  That may not be true now that I have a chance to think about it.  it is possible that the person who coded this knew that the data is coming over in m/s regardless of how Taranis is calling it.  The script code does indicate that the units being sent over are m/s.  There is a problem in the sensor code on Taranis where they use the wrong units.  That is a mistake in someone's code.  It should be an easy fix for someone familiar with the code.

On a side note about the AoA question, I can see that the data flash logs do have an AOA data set.  I am unsure how it is calculated or how good the data is.  There are lots of fluctuation probably due to vibration but you can see it creep up as the plane slows or in turns.  It would be nice to have data like this to sound a stall warning.  I have no hardware on my plane for measuring AoA.  For now, I am just using the calculated airspeed to alert me when a stall might be coming.  Not perfect but better than nothing and good for helping me shoot consistent landing approaches.



Robert, Glad you're finding the project interesting.

Are you aware of the configuration page which is part of the main lua script? The telemetry script has two screens. When you load it (long press on PAGE button) you see the main telemetry screen, but if you press the MENU button on the Taranis, then the script switches to the configuration screen. Press MENU again and it switches back. You can see a picture of the config screen in the second image on this wiki page https://github.com/athertop/MavLink_FrSkySPort/wiki/0.-Overview

In fact the screens are described in the WIKI using that link - would suggest you give that a read.

This configuration screen provides drop downs providing options which set all the required parameters - you don't need to tweak any code or manually write to any config files (or use the old offsets.lua mixer script any more) - this screen does it all. If you haven't yet gone into this screen, then default options are assumed - these default options are those you see when you first access the config screen for any model using the script. So if you change any option on that screen then all the settings on there are written to a config file which is loaded next time you load the telemetry script. There is one configuration file saved for each model using that script. So say if you have a model stored for a plane called "maverick" and a copter called "goose", you will have two config files - maverick.cfg and goose.cfg in /SCRIPTS/TELEMETRY/DATA on your SD card (make sure that path exists, along with all the other SD card contents as detailed in the wiki also), each holding your selected config for that model.

As regards your next post (two above, or is it three?) - yes I knew that the teensy provides the speed values in m/s and wrote the lua script to deal with this. Not exactly sure what issue you have with this - as a user, if you set kts on the telemetry sensor page (as discussed in the WIKI which is the default unit for newly detected GSpd and ASpd sensors) you should have no issues at all. OpenTx seems to be coded to expect the incoming data in kts, so by selecting kts as the sensor it does no scaling on the value sent from the teensy (or FrSky GPS/Airspeed sensor), so the LUA script expects the value provided by the sensor to be m/s (which it will be even though the sensor is configured for kts) and it provides scaling based on this m/s input.If you choose any other unit against sensor config then this is scaled by OpenTx (it assumes the incoming value is in kts and scales this to fit the selected unit) and this messes things up for the LUA script (which like I said assumes that incoming number to be m/s). So just leave that detected sensor alone, choose the unit format you want to appear on the LUA telemetry screen and that should be it! There's no smoke an mirrors honestly! Its all documented in the WIKI - see the link some paragraphs above) and the wiki documents the code in my repo, so make sure you're not using the older Clooney82 code from his repo (even Clooney is using my version of this code now :-)

As regards AoA - i'm not really interested in developing this, but feel free to fork the repo and have a go yourself - that's the beauty of Open Source code after all! Just for info AoA and sideslip estimation was added in Plane 3.8, and I believe this data is available in Mavlink. See release notes here: https://github.com/ArduPilot/ardupilot/blob/master/ArduPlane/releas...

Cheers, Paul

The issue I have is not with the lua script.  The issue I have is with the sensor data.  I am fully configured for kts as my units of choice.  The Lua dashboard you have is working accurately.  But when I create my own dashboard and create alarms based on aspd and gspd sensors, they come through in m/s, even though I have them configured for kts.  See screens which are attached.  The scalling is missed for these sensors for some reason.  

I will look over the docs again but I think this should have covered all of my scaling needs.


Robert, the input to your scripts (even though the sensor is configured for kts in the sensors screen) will still be in m/s you need to do a translation in LUA to scale that to whichever scale you need.

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service