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...
I have the following connected to my PixHawk.
Telemetry port 1: the 3DR Radio
Telemetry port 2: the 3DR Bluetooth kit and the Teensy with only RX+GND connected.
This allows data to be received on all 3 systems, and data to be sent via 3dr radio and bluetooth.
Do you use LRS or 2.4GHz rc control? And if 2.4 does Bluetooth interfere at all with the rc link?
Rolf I have a couple of questions about this reply. First I am running an apm 2.6 with the teensy 3.1 board hooked to my Frysky 8XR receiver using my Taranis Transmitter. My telemetry is working fine but my battery voltage (CEL and CELS) is showing .2 amps low. Is there anyway to correct this or should I just work around this issue. (not a big deal...better lower than higher)
My A2 reading on the Taranis is jumping all over. When I disconnect teensy it goes back to normal. You mention that A2 voltage comes from pin A0, My A0 pin is not wired into anything. How would I go about connecting and correcting it.
No issues with FrSky X8R radio command (the 2.4GHz RC part)
Just as a precaution the Bluetooth is on left side of a F550 frame and the X8R on right side so about 20cm apart.
Would u mind building me one of those for my Quad? needed to be shiped to germany!
OpenTx 2.0 companion will compile it for you
I just wish someone would answer my question, this forum is substandard to RCG (functionality and response), a year now and no one has answered any of my posts regarding mostly APM 2.5, :(
Thanks Rolf and all for your efforts, just still trying to get my teensy working 100%
Install 2.0.5 as that is the last good firmware that didn't mess with some of the device ID's.
Don't expect people to answer questions from a year ago on a blog post. Go to the forums and if they don't answer there, well, it's either been answered somewhere else or no one knows.
Under which license is this code released?
I have made some changes to the code to fix fix the cell-voltage problem and a couple of other changes. My plan is to put the changed code on a github fork, if that's ok with you?
Besides the tension corrections (I assume due to the changes on OpenTX 2.06+) what other changes have you managed to introduce.
I was looking at replacing the AccXYZ vibration values with Roll Pitch Yaw angles and currently looking at how to have Mavlink errors reported down to the Taranis telemetry, perhaps as A3 or A4, but as both OpenTX is changing specially the Lua part and also APM from 3.1.x to 3.2 is like shooting at two moving targets simultaneously.....
Also there is now a fork on APM code to have "native" FrSky telemetry from the controller (there was already for Dbus protocol) and SPort is moving also.
I'm trying to build a "kind" of HUD as one telemetry screen like this first draft image....
I have no idea of the any specific licensing that Rolf has on the code (I assume none) but I've seen pieces of this code spread around other projects even on GitHub.
Since i don't have the any documentation on the s.port, I had to look in the openTx-source and "guess". This resulted in a change of how I respond to openTx's telemetry request.change,
Except for this structural change, I have fiddled a little with the cell detection-code. And also made the acc-values show the vibrations by having a moving window and sending the difference between max and min. I planed to use it to show a warning if there are excessive vibrations on my multirotor, but I don't know if it's useful.
Thats a nice looking HUD. Personally i only have one screen with the information I might find useful when taking a glance at the display (work in progress):
As for native frsky. I havn't really looked at those forks, but those are for the 32bit boards, right? I'm currently run a Apm2.6-clone :(
The screen grab I have is only responding to roll angles for now :) but I'm not satisfied with my current solution because it requires "painting" several BMP's (and there's a bug with OpenTX painting odd width bmp's), but the objective is to have all the other flight relevant data on screen.
I believe the Mavlink error codes would be great to have but the way to parse them from Mavlink is not trivial (at least from what I've seen).
My plan to ditch the AccXYZ and use Roll/Pitch/Yaw angles is because they are not so helpful on casual flight and are already recorded on APM logs (I'm not sure of the situation on APM boards, my board is a Pixhawk) and at a certain distance knowing the multirotor attitude might be more important.
And yes, I also think that the APM fork for FrSky might be PixHawk only, but I believe this Teensy solution might be better and more versatile.
Just as a heads-up you can have now a Course to home with a few lines on the Lua script. I've opened an issue to have it natively but it can be calculated now.