APM MavLink to FrSky X8R S.Port converter

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...

3691093032?profile=original3691092992?profile=original

MavLink_FrSkySPort_1.3.zip

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • I guess because all of this is customized, that Taranis does not support the scaling for the raw data.

    Thx for your help

    Scot

  • 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.

  • 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, 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

    athertop/MavLink_FrSkySPort
    APM MavLink to FrSky S.Port converter. Contribute to athertop/MavLink_FrSkySPort development by creating an account on GitHub.
  • 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.

    Cheers

    Scot

  • 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.

  • 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.

  • 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.

  • 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?

    Thx

    Scot

This reply was deleted.

Activity

DIY Robocars via Twitter
RT @Smartphone89: DonkeyCar Racing League Korea #donkeycar @diyrobocars https://t.co/mDlHDR1d98
yesterday
Jørn Ramnæs liked VIDEO LINK's profile
Friday
Mark Harrison left a comment on Moderators
"Wow, Ning2 looks really great on mobile. I had sort of drifted away as my browse-time went more on my phone, so this is great."
Friday
Hank Deucker left a comment on PIXHAWK
"I am sure most will say not again, Pixhawk telemetry. I do need help and all can be reassured that I have spent many hours scouring the net for useful information. I am not new at quadcopter flying, I started in 2012 and have progressed through many…"
Thursday
DIY Robocars via Twitter
https://t.co/rLmFr8M2UK
Thursday
Hank Deucker left a comment on PIXHAWK
"Tomorrow, I am thinking about the wording at the moment."
Thursday
DIY Robocars via Twitter
https://t.co/8EMCvYW6oz
Tuesday
DIY Robocars via Twitter
RT @OttawaAVGroup: We are going to try something new this week. We will be having a drop-in style meeting Wednesday @ 7-9pm EST. Pop in and…
Monday
DIY Robocars via Twitter
RT @tawnkramer: Thanks Everyone for another fun virtual race! Amazing Ai racers competing head-to-head, Virtual Makers Fair event. Catch us…
May 23
DIY Robocars via Twitter
RT @make: Find out the latest from @diyrobocars at 10am PT from @chr1sa of @3DRobotics on Virtually Make Faire! #makerfaire #maketogether #…
May 23
DIY Robocars via Twitter
RT @Heavy02011: Join us Saturday online: Virtual Race League: @DIYRobocars Race #2 - Parking Lot Nerds https://t.co/aJUu4sdutx #Meetup via…
May 22
DIY Robocars via Twitter
RT @donkey_car: Yay, we are part of the virtual @makerfaire with @diyrobocars. Come see our race or better yet train a model and race with…
May 21
DIY Robocars via Twitter
RT @chr1sa: The @DIYRobocars Virtual AI Race is going to be part of the virtual @makerfaire on Sat! https://t.co/wnMDAboLID
May 20
DIY Robocars via Twitter
RT @tawnkramer: Please join us next week for our second DIYRobocars online race. We will be using a new Mountain Track course! https://t.co…
May 19
DIY Robocars via Twitter
RT @SmallpixelCar: I realized that the size of the cones in @diyrobocars is known. If we can detect the bounding box, which can be done wit…
May 19
DIY Robocars via Twitter
RT @chr1sa: Our next @DIYRobocars autonomous car virtual race is this Saturday. Sign up here to compete or just spectate on @Twitch https:/…
May 19
More…