Support for native FrSky telemetry

[lakeroe]

Add support for native FrSky telemetry (S.Port based X-Series receiver) using only a simple external inverter (i.e. https://github.com/TauLabs/TauLabs/wiki/User-Guide:-FrSKY-S.PORT-telemetry). Somebody has already started a thread about this: http://ardupilot.com/forum/viewtopic.php?f=100&t=10013

Apart from "real" telemetry data (position, height, velocity, ...) it would be great to also show possible pre-arm check errors.

Two useful links: https://code.google.com/p/telemetry-convert/wiki/FrSkySPortProtocol https://github.com/TauLabs/TauLabs/blob/next/flight/Modules/UAVOFrSKYSPortBridge/UAVOFrSKYSPortBridge.c

[badzz]

You mean that 3.3rc1 is working and not master ? If you use the cable as explained on the wiki, 3.3rc1 is working fine. T1 shows flight mode , t2 shows nb of sats and 3d fix

On Sat, 25 Apr 2015 20:33 Andrei notifications@github.com wrote:

@badzz https://github.com/badzz, can you suggest any update/fix for the current master to use T1, T2?

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/1587#issuecomment-96258249 .

[furynick]

@mrpuzzler, my friend uses a FUL-1 and SPC with ArduCopter-v2_2015-04-24-23.04_3.3-dev on a Dropix. He told me there's no data until 3D fix. I'm also using a FUL-1 and 1N4150 instead of SPC.

[badzz]

Once you have a 3d fix , distance will show up but the rest of the data will show up at init , eg : t1, t2, vfas (battery),.. On 25 Apr 2015 21:41, "furynick" notifications@github.com wrote:

@mrpuzzler https://github.com/mrpuzzler, my friend uses a FUL-1 and SPC with ArduCopter-v2_2015-04-24-23.04_3.3-dev on a Dropix. He told me there's no data until 3D fix. I'm also using a FUL-1 and 1N4150 instead of SPC.

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/1587#issuecomment-96269372 .

[furynick]

I agree, it should ... but it doesn't for me, still searching why. @badzz, do you agree to this statement : if I connect a FTDI on Serial2 (57600,8,N,1,no flow ctrl) and set SERIAL2_PROTOCOL=4, I should have a reply when I send 0x7E,0xC6 right ? If possible, can you try it with your pix ?

[badzz]

Yes it should be working, try SERIAL2_PROTOCOL=3 , it should send data continuously as there is no polling on d receiver. Speed is 9600 though. We are talking about 3.3rc1 right ?

On 25 Apr 2015 23:21, "furynick" notifications@github.com wrote:

I agree, it should ... but it doesn't for me, still searching why. @badzz, do you agree to this statement : if I connect a FTDI on Serial2 (57600,8,N,1,no flow ctrl) and set SERIAL2_PROTOCOL=4, I should have a reply when I send 0x7E,0xC6 right ?

— Reply to this email directly or view it on GitHub.

[furynick]

Yes, it's about 3.3rc1. I'll make some tests with my FTDI and try to snif bytes sent and received on Serial2.

[mrpuzzler]

@lakeroe , could you please test 3.3rc3. It should has support for native telemetry + converter. I can't make it work on my side.

[badzz]

It does work, just tested it. As explained above and the wiki, you need a little more than a converter and you should display the old dport metrics not the new ones for sport.(eg:t1 t2, not the new t1+ t2+ on the taranis) I did the code and therefore tested on the latest rc.

On Sat, 2 May 2015 20:24 Andrei notifications@github.com wrote:

@lakeroe https://github.com/lakeroe , could you please test 3.3rc3. It should has support for native telemetry + converter. I can't make it work on my side.

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/1587#issuecomment-98384223 .

[mrpuzzler]

@badzz, but @lakeroe (from the first post) uses only converter and some code. As far as I can see, now 3.3rc3 sends codes as well as code from @lakeroe.

[badzz]

I might have missed something, can you point to a line in the code ? On 3 May 2015 10:26, "Andrei" notifications@github.com wrote:

@badzz https://github.com/badzz, but @lakeroe https://github.com/lakeroe (from the first post) uses only converter and some code. As far as I can see, now 3.3rc3 sends codes as well as code from @lakeroe https://github.com/lakeroe.

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/1587#issuecomment-98454513 .

[mrpuzzler]

@badzz, your code uses AP_Frsky_Telem::frsky_send_data to send to S.Port, and AP_Frsky_Telem::frsky_send_value at @lakeroe code to send data to S.Port. Same bytes order. So, it should be possible to catch it on Taranis side?

[badzz]

There is no frsky_send_value code in https://github.com/diydrones/ardupilot/blob/master/libraries/AP_Frsky_Telem/AP_Frsky_Telem.cpp

On Sun, May 3, 2015 at 10:48 AM, Andrei notifications@github.com wrote:

@badzz https://github.com/badzz, your code uses AP_Frsky_Telem::frsky_send_data to send to S.Port, and AP_Frsky_Telem::frsky_send_value at @lakeroe https://github.com/lakeroe code to send data to S.Port. Same bytes order. So, it should be possible to catch it on Taranis side?

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/1587#issuecomment-98456023 .

[mrpuzzler]

AP_Frsky_Telem::frsky_send_value - this is a func name from @lakeroe code, not from your. And it does exactly same for s.port. Did you see @lakeroe code?

[Johnex]

So guys, just to confirm. I have ordered one of these: http://www.banggood.com/Serial-Port-Mini-RS232-To-TTL-Converter-Module-Board-Adapter-p-81399.html

That in conjunction with a diode to make the output sport compatible, plus 3.3rc3 and the latest opentx should give me telemetry?

Right now i'm using a teensy to do the conversion but want to test this out.

[badzz]

Yep, I just did this yesterday and it works fine https://plus.google.com/+MatthiasBadaire/posts/UaC1wmB11mg

[Johnex]

Sweet! Thanks ) You are on OpenTX 2.0.15? And which lua script are you using?

[badzz]

I am on 2.0.15 indeed and not using any LUA script. The current S-port code in pixhawk does not send S-port metrics but older D-port ones, I suspect that most script uses the S-port data and therefore wont work. I am just using the opentx telemetry screen and select my metrics.

On Sun, May 3, 2015 at 11:46 AM, Johnex notifications@github.com wrote:

Sweet! Thanks ) You are on OpenTX 2.0.15? And which lua script are you using?

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/1587#issuecomment-98460834 .

[Johnex]

Wouldn't it be possible to update the pixhawk code to send the S-Port metrics before 3.3 release? :)

[badzz]

I am reorganizing stuff (check my gihub) and I do not want to break the older d-port as it is still used by lots of people. It will require an another 3.x iteration I am afraid. So many things to do and so little time. 8)

On Sun, May 3, 2015 at 12:26 PM, Johnex notifications@github.com wrote:

Wouldn't it be possible to update the pixhawk code to send the S-Port metrics before 3.3 release? :)

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/1587#issuecomment-98465342 .

[Johnex]

Do you have a list of all the values that we can display in the opentx telem screen? I checked the wiki but it doesn't say. Also, how are you handling for example the flight mode, is it just for example A1 as 1, 2, 3 and so on for the flight modes? I want to have them spoken when the change is detected.

[badzz]

The current ones are all there https://github.com/diydrones/ardupilot/pull/1266 T1: Mode will display number that correspond to the flight mode All the numbers are here : http://copter.ardupilot.com/wiki/configuration/arducopter-parameters/#flight_mode_1_arducopterfltmode1

On Sun, May 3, 2015 at 2:50 PM, Johnex notifications@github.com wrote:

Do you have a list of all the values that we can display in the opentx telem screen? I checked the wiki but it doesn't say. Also, how are you handling for example the flight mode, is it just for example A1 as 1, 2, 3 and so on for the flight modes? I want to have them spoken when the change is detected.

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/1587#issuecomment-98477524 .

[Johnex]

You write "Battery percentage remaining (Fuel)", is that calculated from the mah set in mission planner and the used current from the power module?

So Fuel would just be 100 to 0 value?

[badzz]

Yes it is a percentage calculated by APM code https://github.com/diydrones/ardupilot/blob/master/libraries/AP_Frsky_Telem/AP_Frsky_Telem.cpp#L532

On Sun, May 3, 2015 at 3:07 PM, Johnex notifications@github.com wrote:

You write "Battery percentage remaining (Fuel)", is that calculated from the mah set in mission planner and the used current from the power module?

So Fuel would just be 100 to 0 value?

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/1587#issuecomment-98478182 .

[Johnex]

Sweet thanks! Have a wonderful sunday :)

[epquilloy]

I just bought the RS232 to TTL converter from ebay. What diode should I connect to the SPort line?

[Johnex]

Hi! 1N4007, same as in this guide at the bottom: http://www.frsky-rc.com/download/view.php?sort=How%20To&down=121&file=How%20To-S.Port%20Products

[epquilloy]

thanks! I have those in my stash. By the way, my current setup includes a Teensy board and a Lua script loaded on my taranis x9d plus. I would like to try the native telemetry feature of the Pixhawk. As I understand it, I just need a RS232-to-TTL converter and a diode soldered on the converter. If I plug it straight to a telem port on my pixhawk (via a 6 pos DF13 connector), would my taranis read instantly the telemetry data from my pixhawk just like as the teensy setup does? i am using AC3.3 rc5. Please correct me if I missed out a step.

[Johnex]

Yes but i don't think it will work with the lua scripts as they require modifications (native telemetry outputs the old frsky format, while the scripts need the newer format). Your taranis will however receive the data into the many variables that you can add into the native telemetry pages (the ones shown when you hold down page for more than 1 second). You also have to change the type of the telemetry port in Mission planner from Mavlink to Frsky.

[Johnex]

Matthias shows here how to soldier it correctly: https://plus.google.com/+MatthiasBadaire/posts/UaC1wmB11mg?pid=6144577126697845218&oid=111345306876503099445

And you can see from X-Receiver and down here (just follow how Matthias soldered it, but it is techincally how you see in the pictures, just that we dont need the frsky stuff to do it, just the diode and the rs232 converter): http://copter.ardupilot.com/wiki/common-optional-hardware/common-telemetry-landingpage/common-frsky-telemetry/

[epquilloy]

I see, it does not use the lua script but the native telemetry page on the taranis. Thanks for the info :) the teensy solution is straightforward, but the native frsky approach is way cheaper. I will try this soon, maybe this weekend

[Johnex]

Lua scripts could be made to work, but devs are holding off since OpenTX 2.1 is just around the corner and the telemetry will be much more powerful (we might not need Lua scripts even).

[erkki]

Probably any common diode works here, I'm using a signal type diode (1N4148) successfully.

[badzz]

I used 1N4007 On 25 Jun 2015 13:06, "Erkki Eilonen" notifications@github.com wrote:

Probably any common diode works here, I'm using a signal type diode (1N4148) successfully.

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/1587#issuecomment-115211560 .

[Johnex]

Matthias have you made any progress on the frsky telem update?

[lvale]

@Johnex The use of scripts has more to do with presentation of data. Although in the current implementations where we have several Mavlink values "encapsulated" on FrSky telemetry elements is also useful to parse those. There are quite a few changes with 2.1 telemetry, and I don't know how Matthias "native" implementation will work with the dynamic assignment of telemetry sensors on OpenTX 2.1. I haven't tried it. Last I've heard from Bertrand, of OpenTX, there will be changes to make OpenTX more Mavlink/Ardupilot "friendly"....

[Johnex]

Hi Luis! What i mean is that Matthias is reworking the native implementation in APM:Copter to work with the "new" format of FrSky, as in S style vs the D style now. Technically this would mean that just a few things in your telemetry script for example would break, things that arent "hacked" in would still work, so minimal changes would be needed to make it fully work. At the moment using Matthias implementation you are stuck with the telem pages of 2.0, since lua scripts use the new frsky format.

[lvale]

@Johnex Hi The issue is that there is a newer implementation of the SPort telemetry which will be starting at the 2.1 release of OpenTX, and this newer implementation breaks the 2.0x implementations of SPort.... Crazy I know, but it's the way things are moving..... So not even related with the previous debates about DPort telemetry vs SPort telemetry, now we'll have DPort vs SPort 2.0x vs SPort 2.1+ telemetry :)

So, while things are at this stage, I'll be at the nearest beach (5 minute walk from home) :)

http://www.mylivestreams.com/webcam/praia-de-carcavelos-beach-surf-weather-web-cam-carcavelos-portugal/11249.html

[Johnex]

Luis bro, i know all that :+1: For the moment i am wondering on the progress of the SPort 2.0x. Also remember that OpenTX has to make 2.1+ telemetry compatible with all the Frsky sensors, so i wouldn't really worry about that next step so much. What is more worrying is that the teensy will break from all the mavlink changes. I want to get rid of the teensy and just go with the rs232. If Matthias can get the changes to SPort 2.0x before 3.3 final is out, then changing a Lua script to support it while 2.1 is out will be a breeze, if not, then i will make my own D style Lua script. Since SPort 2.0x will have to be compatible in 2.1 cos of the sensors, then i think the lua scripts wont totally break either. Issues people are having right now with the teensy is cos of the mavlink changes breaking the teensy in some areas, but not the Lua scripts.

[lvale]

@Johnex Perhaps you know about this thread http://openrcforums.com/forum/viewtopic.php?f=45&t=6887

Lately Bertrand has also cooperated.

I still think that having FrSky telem native might be convenient, but is more restrictive because these two projects (Ardupilot and OpenTX) move each at their own speed. I still prefer the "external" approach, which might be a third way :)

Just imagine a OSD module that would also translate to FrSKy :) https://sites.google.com/site/alceosd/

[lvale]

@Johnex

btw: I do have the Teensy working perfectly with 3.3RC5 and OpenTX latest 2.1 builds :)

[epquilloy]

Currently I am still using a teensy board with my pixhawk and taranis. Should the opentx 2.1 be released, and the arducopter 3.3 be released, which one will be functional? Teensy approach or the native frsky telemetry approach using the Rs232-TTL converter?

[Johnex]

Luis, Yeah the projects would have to be more in sync. I think what would be best is if OpenTX used the Mavlink library directly from APM adding support for it directly, then it would always stay in sync on github, so when things break with changes Bertrand would be forced to fix them hahaha :D.

[CodeChief]

In the end I found the Teensy solution the best for now, with some of my own modifications... What I learnt so far about MAVLink interaction is both (telemetry and OSD) devices start their session by sending commands to subscribe to more or less data at more or less frequency.

This publisher/subscriber design is all good but a Y cable is not going to work fully. Whoever has write access when booted/reset decides which (limited) commands will occur and the frequency. The first symptom I noticed of this was the OSD feature to use free channel to switch pages didn't work.

I fixed this by extending the Teensy design a bit. I wired-up a "through port" using the spare Teensy UART, edited the Teensy code to add another serial port variable and the initialization/read/write code to include the OSD MAVLink messages.

With this solution I have these benefits (total in comparison to native telemetry cable): 1) OSD works same/faster update speed (not slower or missing information). For example the OSD screen switching will work because the RC control messages will be received. 2) Both devices on one serial port with read/write capability. 3) The lipo cell sensor only possible with more pins (external board/Teensy) currently.

For point 2 I must admit in the initial poof of concept I just subscribed to the maximum amount of messages but with this hardware connectivity it would be straightforward to implement a full proxy for more complex devices, not required for my current OSD requirement.

For testing I purchased an FrSky SPort Lipo sensor (the cheap one with an OLED display) which could be an indirect way to get the same features as the Teensy solution (except the serial thoughput) without requiring any soldering/non-consumer parts. The other requirement to really "finish" this PixHawk solution is to include the additional messages required by the OSD or add some kind of filter parameter so users can decide (or did you already fix that in the latest firmware?).

The other reason to focus on the native solution is if SPort is fully supported (full telemetry bridge) then this opens-up a load of new sensors at cheaper prices to PixHawk. We should end-up with the best of both worlds. With the FrSky lipo sensor and full software support, the native solution would finally be the best and consumer ready (all parts available worldwide and without soldering).

p.s. I am writing all this up into a blog entry and will post pictures and code soon.

[epquilloy]

hi CodeChief,

can you share your modified teensy code? I do not want to use a y-connector. thanks! :)

[Johnex]

@epquilloy on firmware 3.3 you can set the Seial4/5 port to output mavlink, so you can have 3 ports total. do you really need any special cables in that case (you can have minimosd, teensy and 3dr radio or gimbal at the same time)

[CodeChief]

Yes that's a good point and a welcome feature. I hope to reduce complexity of my build if the FrSky sensor works together with it.

Anyway I think the MAVLink Teensy proxy will be useful to finish and document. For example when using multiple GPS receivers or when another device/protocol should be injected into the MAVLink stream/back to Pixhawk.

It's also interesting to note Hobby King developed a radio+OSD module which solves the serial port problem and reduces interference/complexity by having a direct (PCB) link between the radio and OSD chipsets. As usual the HK descriptions are terrible but if you search through the "HKPilot" radios you'll find a few variants with OSD onboard.

[epquilloy]

Hi! I just made the Rs232-to-ttl converter with a 1n4007 diode. i followed how it was made. then I connected it to Telem 2 on pixhawk. on mission planner, I changed the Serial 2 protocol to "4" for frsky SPort. On taranis, I copied my existing model to a new one and renamed it. I restarted the radio, and the LUA script for that model is not running. When I long press the PAGE button, all i can see is the A1 voltage (i think for RSSI). but the cells and other parameters are not shown. I tried to edit the telemetry page on the taranis to show the current, cells, cell, consumption, distance and speed. but all parameters show zero for the values. Have I missed any step that made this setup not working for me?

by the way, I am using Copter 3.3 rc6 firmware. thanks in advance!

[epquilloy]

here's the frsky telemetry module i made.

[erkki]

A1 is sent via the radio, check the value for VFAS (via a custom telemetry screen) for battery voltage, or TEMP1 and TEMP2 for mode or gps status respectively. Only a subset of arducopter params are sent encoded in a set of frsky parameters. Check the source for further params.

[erkki]

Also on the photo (can't tell for sure) it seems like one of the diodes is connected to the other side of the module? The module is dual channel so different sides are independent.