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...
Replies
Would like to know also. I cant really see any difference visually with the boards,
Yes LC will work as well. Due to reduced hardware capabilities there are some things it probably can't do like LED control, but basic stuff should work.
On the telemetry screen the Voltage and current is not showing correctly (First Image). On the model telemetry screen (Second Image) the numbers are showing up correctly. Any idea what is causing this? Thanks
Thanks Paul, I should have known that !
Another question, The Hdg doesn't show until I get a GPS lock and if I loose GPS lock Hdg just keeps showing the last heading before loosing GPS lock. The problem seems to be in the data stream from the pixhawk because the telemetry data screen on the Taranis also stops updating as soon as GPS lock is lost. Is this the way it is supposed to work? Mission Planner shows Hdg right from the start. Is there a different parameter we can tap into to to get Hdg all the time? Thanks
Doug,
I've not really been involved with the Teensy/Arduino programming of this project, but have just checked out the code and can see what's causing the phenomenon you are seeing. Even though the source of the Mavlink data for the heading is coming from the compass/mag reading as you would expect (I.e. same as the HIUD display in Mission planner), when this is sent to the Smart Port it is actually being sent within the emulated GPS sensor data (its actually being sent in place of what normally would be the COG (course-over-ground) value). This is simply the means the design has chosen to get that data down to the Taranis - it has to send it as a value appropriate to one of the pre-defined smart-port sensors, and the developers must have simply chosen the GPS sensor as the best one to include this data.
The issue you're experiencing with that heading being dropped if there's no 3d GPS fix, is caused by the fact that the GPS sensor data is only sent whilst a 3d fix is established on the GPS, so even though the source/sensor data is coming from a non-GPS related device, it is being constrained by the implementation of the GPS smart-port sensor in the teensy code.
The good news, is that this can be changed to fix that issue. The bad news, is that I (like I said) am fairly new to Teensy programming, so instead of getting stuck into it myself, I will likely instead have a word with Jochen (the lead dev on this project) to suggest this fix, and hopefully he will have a go to fix it.
My idea simply is to send the GPS sensor data whether we have a 3d fix or not. But in the case where there is no 3d fix, all the GPS sourced values will be zero, but the Hdg value will always be included. Hope this makes sense?
I have raised an issue for this here: https://github.com/Clooney82/MavLink_FrSkySPort/issues/59
Thanks Paul for elevating the issue !
Doug, I just merged the fix, so if you download a fresh zip and compile/upload the sketch to your teensy, you should see the fix in action. Please let me know how you get on. The zip download is here: https://github.com/Clooney82/MavLink_FrSkySPort/archive/s-c-l-v-rc-...
I was lucky with the weather so got my quad out tonight to test the fix and works a treat.
You should also note that the teensy now also creates a new "ASpd" sensor in the Taranis (if you do a discovery it will be added) to the telemetry sensors page. This shows the Airspeed, which is probably only of real use on a plane (if you have an airspeed sensor installed). For this reason I have also updated the plane217.lua file to include Airspeed "ASpd" alongside the ground speed, plus some changes to the Power panel in the plane lua only (so far). No changes to the copter217.lua though in this merge.
Thanks Paul, That was quick. I'll try it tomorrow. Thanks again !!!!
Thanks Paul, that fix worked great. Thanks Again !!