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

[robustini]

Some tests today:

• the inverter with transistor work only with the quad firmware compiled by @lakeroe posted here, with the LUA script but not with the master (with SERIAL2_PROTOCOL=4)
• the master of today broken the Teensy sopport, i tried with the Plane and work fine only the latest beta available (3.2.1)

I wait your feedback...

[badzz]

@Marco: master is not compatible and has never been with the lua script. Only standard OpenTX metrics works (amps, gps, volts,..) No roll, pitch,etc..

SerialManager changed the protocol number, if you are connecting the teensy to telem2, you need to set serial2_protocol=2 for mavlink

https://github.com/diydrones/ardupilot/blob/master/libraries/AP_SerialManager/AP_SerialManager.h On 1 Feb 2015 13:00, "robustini" notifications@github.com wrote:

Some tests today:

• the inverter with transistor work only with the quad firmware compiled by @lakeroe https://github.com/lakeroe posted here, with the LUA script but not with the master
• the master of today broken the Teensy sopport

I wait your feedback...

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

[lvale]

Hi @robustini Marco

IMHO if today's master broke the Teensy support then all telemetry is broken. At least using the external solution as I've been using for some time. Just make sure that the protocol on telem1 or telem2 is still Mavlink.

I've been following from a distance the current effort to have native support for the FrSky SPort telemetry protocol.

While it is helpful, I don't like the approach of having more code running on the PixHawk/VrBrain.

If we have a standard and stable method of delivering info to the outside (Mavlink) which is understood and already used by most of alternative telemetry solutions like MinimOSD. So, why the rush to have native support, considering that it will require an external "adapter" (the level inverter).

The Teensy (and some also had success with Arduino's) is, in the same "spirit" of the MinimOSD which has been used for some years.

I like the "decoupling" of the flight controller from the telemetry converter, because, as we know, both the ArduPilot and the OpenTX code are in constant change, and not necessarily in sync.

On the Ardupilot side there is some heavy lifting to do, specially regarding how the error/status messaging is being handled (the issue with not having numeric codes for the different messages being sent from a lot of places in the code). The current solution for the native FrSky telemetry requires that a lot of code has to be "touched". And other telemetry protocols will require again a lot of effort to be done on the ArduPilot, and I (and I'm sure none of us) want instability on the flight controller.

On the OpenTX side the imminent release (for the 2.1 branch) of a new implementation of the telemetry will render the current efforts null, and you'll have to wait for a new release of ArduPilot to have it fixed, and as we know, the time between releases of ArduPilot has been in the order of months.

The current external Teensy solution is very similar in "spirit" to the MinimOSD. And although some have spoken about the renewing of the MinimOSD to have HD overlay I believe (and not being a HW designer) that a great solution would incorporate both the HD overlay and output for other telemetry protocols (like the FrSky, Spektrum, Jeti and others).

If Ardupilot persists on this path, of incorporating a lot of stuff of the main codebase, then should also consider some kind of conditional compiling (like the OpenTX guys do).

just my 2c

Luis

[badzz]

@Luis: From what i understand of openxtx 2.1, it should stil works with the existing IDs. It will allow new ID to be used but it should work, right ? I'd like eventually to make it fully configurable (which metric goes to which Id). we will see if it is feasible.

Completely agree with you on the error messaging. To be honest the current solution in the teensy is not ideal either as you need to maitain the list of strings send my the APM code.

MAVlink compatible receiver (openlrs?) would be a must indeed and the teensy solution is a good compromise.

On Sun, Feb 1, 2015 at 2:01 PM, Luis Vale notifications@github.com wrote:

Hi @robustini https://github.com/robustini Marco

IMHO if today's master broke the Teensy support then all telemetry is broken. At least using the external solution as I've been using for some time. Just make sure that the protocol on telem1 or telem2 is still Mavlink.

I've been following from a distance the current effort to have native support for the FrSky SPort telemetry protocol.

While it is helpful, I don't like the approach of having more code running on the PixHawk/VrBrain.

If we have a standard and stable method of delivering info to the outside (Mavlink) which is understood and already used by most of alternative telemetry solutions like MinimOSD. So, why the rush to have native support, considering that it will require an external "adapter" (the level inverter).

The Teensy (and some also had success with Arduino's) is, in the same "spirit" of the MinimOSD which has been used for some years.

I like the "decoupling" of the flight controller from the telemetry converter, because, as we know, both the ArduPilot and the OpenTX code are inconstant change, and not necessarily in sync.

On the Ardupilot side there is some heavy lifting to do, specially regarding how the error/status messaging is being handled (the issue with not having numeric codes for the different messages being sent from a lot of places in the code). The current solution for the native FrSky telemetry requires that a lot of code has to be "touched". And other telemetry protocols will require again a lot of effort to be done on the ArduPilot, and I (and I'm sure none of us) want instability on the flight controller.

On the OpenTX side the imminent release (for the 2.1 branch) of a new implementation of the telemetry will render the current efforts null, and you'll have to wait for a new release of ArduPilot to have it fixed, and as we know, the time between releases of ArduPilot has been in the order of months.

The current external Teensy solution is very similar in "spirit" to the MinimOSD. And although some have spoken about the renewing of the MinimOSD to have HD overlay I believe (and not being a HW designer) that a great solution would incorporate both the HD overlay and output for other telemetry protocols (like the FrSky, Spektrum and others).

If Ardupilot persists on this path, of incorporating a lot of stuff of the main codebase, then should also consider some kind of conditional compiling (like the OpenTX guys do).

just my 2c

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

[robustini]

I agree with you, we risk continuing alignments between the various codes, threatening to create confusion.

[CodeChief]

@lakeroe thanks for the correction and supplier for the FUL-1, and so cheap I've ordered it anyway.

BTW very good architectural points from @robustini about where the telemetry translation belongs.

I'll probably end-up trying/building all three variants as an electronics project. Maybe help with some documentation to start with. Anyway thanks all for the guidance, I like where this is going!

[lvale]

@badzz Well, you can compile the latest 2.1 builds of OpenTx and test (I already did), but this statement from one of the lead OpenTX guys is IMHO relevant

[badzz]

@luis: Right, I had read that but interpreted in this way : "we will not upgrade telemetry config and therefore you will have to redo it". Maybe i am wrong and will indeed compile 2.1 build.

On Sun, Feb 1, 2015 at 2:47 PM, Luis Vale notifications@github.com wrote:

@badzz https://github.com/badzz Well, you can compile the latest 2.1 builds of OpenTx and test (I already did), but this statement from one of the lead OpenTX guys is IMHO relevant

[image: screen shot 2015-02-01 at 13 44 16] https://cloud.githubusercontent.com/assets/3130363/5992236/c4b47ce8-aa18-11e4-8f8c-1b93256f356e.png

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

[lvale]

@robustini

Marco, is not the confusing part that worries me (at least not much), that could be handled by some good documentation :) :) :)

It's really the flight code stability.

If we all want a great flying platform (ok, I'm discarding Rover, but these don't fall from too high :) ) IMHO the code running at the flight controller should be the most efficient and tested (a big thanks to your videos) as possible.

[badzz]

@Luis: the code in master is doing the minimum and the time critical stuff are done in a separate thread. But I agree that if we add too many stuff,we might have problems.

On Sun, Feb 1, 2015 at 3:01 PM, Luis Vale notifications@github.com wrote:

@robustini https://github.com/robustini

Marco, is not the confusing part that worries me (at least not much), that could be handled by some good documentation :) :) :)

It's really the flight code stability.

If we all want a great flying platform (ok, I'm discarding Rover, but these don't fall from too high :) ) IMHO the code running at the flight controller should be the most efficient and tested (a big thanks to your videos) as possible.

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

[badzz]

@luis: I just checked opentx 2.1 and it works just fine. It discovers what is being send my the rx and you can rename, change unit, ... The current code works fine with opentx 2.1. However as said by killrah , your previous opentx telemetry param are lost, you need to redo it. (eg:screen position) but that's independant from our code, everybody will have to do it.

On Sun, Feb 1, 2015 at 3:04 PM, Matthias Badaire mbadaire@gmail.com wrote:

@Luis: the code in master is doing the minimum and the time critical stuff are done in a separate thread. But I agree that if we add too many stuff,we might have problems.

On Sun, Feb 1, 2015 at 3:01 PM, Luis Vale notifications@github.com wrote:

@robustini https://github.com/robustini

Marco, is not the confusing part that worries me (at least not much), that could be handled by some good documentation :) :) :)

It's really the flight code stability.

If we all want a great flying platform (ok, I'm discarding Rover, but these don't fall from too high :) ) IMHO the code running at the flight controller should be the most efficient and tested (a big thanks to your videos) as possible.

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

[lvale]

@badzz : To my point exactly. Now that we have the telemetry "open", we no longer need to "encapsulate" Flight modes, Hdop and others "inside" Fuel, or Accx. We can just send with other ID's and leave those alone.

[lvale]

@badzz : I've been playing with a new version for the Teensy that does exactly like I mention above.

[badzz]

@luis: ok, got your point now but unless somebody wants to use real sensors at the same time, we do not need to do something in the short term. But I agree we should make use of this new capability, that's why I would like to make it configurable, this way users can choose on both side which ids to use and keep compatibility with older system. On 1 Feb 2015 18:52, "Luis Vale" notifications@github.com wrote:

@badzz https://github.com/badzz : To my point exactly. Now that we have the telemetry "open", we no longer need to "encapsulate" Flight modes, Hdop and others "inside" Fuel, or Accx. We can just send with other ID's and leave those alone.

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

[lvale]

@badzz : We already have about 400 parameters on ArduPilot. More configurable parameters? IMHO, there is a small basic set of parameters really needed for Radio based Telemetry, and an extended set. If we have enough "cpu" power and telemetry bandwidth to send the extended set then, just send everything.

We can discuss which values are "core", such as Voltage, Current, GPS Pos, Current Flight Mode, Arm status, etc, and which would be at an extended set, such as messages, tilt, roll, etc.

Better would be to have everything in sync, i.e. External solutions like the Teensy, Arduino and MinimOSD and the internal solution.

Please note that I'm including MinimOSD, as I consider it as a telemetry solution.

Regarding FrSky sensors, I know that there are users that have the FrSky Cell Monitor and others the GPS.

[dbaker1]

FYI – It’s not an FUC-1 you’re looking for, it’s the FrSky FUL-1 (upgrade lite). You can find them here:

http://www.helibatics.com/frsky-receiver-upgrade-lite/ http://www.ebay.com/itm/NEW-FrSky-Receiver-Upgrade-Lite-FUL-1-RS232-to-TTL-level-converter-/331442912632

Not sure what the SPC cable is, maybe this? http://www.helibatics.com/frsky-smart-port-adapter-converter-upgrade-cable-for-usb-programmer/ http://www.ebay.com/itm/NEW-FrSky-SMART-PORT-Adapter-Converter-Upgrade-cable-USB-programmer-/231206826159

From: lakeroe [mailto:notifications@github.com] Sent: Saturday, January 31, 2015 9:47 AM To: diydrones/ardupilot Subject: Re: [ardupilot] Support for native FrSky telemetry (#1587)

@Matthiashttps://github.com/Matthias I know Luis' scripts and also used them as a starting point for my own ones, I just didn't know his name.

@CodeChiefhttps://github.com/CodeChief The documentation on the APM Copter web site for X-Receivers is not valid yet (X-Receivers are supported beginning with AC3.3). Whatever solution you choose you either need FUC-1 TTL to RS232 converter + SPC cable or one of the different inverters mentioned above. I don't think you can buy a ready solution somewhere (yet).

For the firmware you have two options: 1) Use "my" 3.2.0 firmware (download link some posts above) + LUA scripts (also for download above) 2) Wait for 3.3 firmware ...

@Marcohttps://github.com/Marco Can you again try my compiled firmware ?

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

TradeStation Group, Inc. is the parent company of five separate but affiliated operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, NFA and SIPC), IBFX, Inc. (Member NFA), IBFX Australia Pty Ltd, which is authorized and regulated by the Australian Securities and Investments Commission, TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Forex products and services are offered by the TradeStation Forex divisions of IBFX, Inc. (Member NFA) and IBFX Australia Pty Ltd (ASIC registered).

[mrpuzzler]

Hey guys, any updates for this task in upcoming 3.3? I'm interested to use telemetry with only this small custom made converter. Is it possible with new 3.3, is code included into master or we have to use custom builds to get this feature?

[mrpuzzler]

Ok, I have made pull request based on code here https://github.com/diydrones/ardupilot/pull/2007 @lakeroe, could you please check it and fix? some new changes in 3.3 - need your hints

[lakeroe]

Hello mrpuzzler,

I think the current master code already has some native FrSky telemetry support. But this code uses some different implementations and is NOT compatible to my LUA scripts !

I'd appreciate to get my code into master, but I think I'm the wrong one to ask. Before merging some things have to discussed and probably changed. Maybe "badzz" or "Randy" can help.

I can assist to merge and also provide the latest source and LUA scripts, because I made some minor changes since.

Best regards, lakeroe

[mrpuzzler]

@lakeroe maybe it is possible to use current FrSky with our scripts? Or make some minor changes at master to match our latest lua side? Can you share latest scripts?

Now your changes is too huge, and I even did not compile it with 3.3, because it does not match new api.

[lvale]

@lakeroe

Perhaps this issue https://github.com/diydrones/ardupilot/issues/1707 is relevant ??

[lakeroe]

@mrpuzzler My latest source and LUA scripts are for download here: http://www.adrive.com/public/U6yfYd/FrSky-Telemetry.zip

Because I use this code only for myself so far, I removed support for D-series receivers (but this can be added quite easily again). The biggest change probably is an info after EKF has warmed up (approximately 20 seconds after 6 sats received first) the transmitter says "Ready". I use this firmware for about 3 months now without any problems.

The binary I use is here (based on V3.2.1 for a quad): http://www.adrive.com/public/AHky2C/ArduCopter-v2.px4

It has two more changes:

1) I adjusted the PWM value range for the flight mode switch to better suit to my PWM values. Old -> New Flight Mode 1 0-1230 -> 0-1083 Flight Mode 2 1231-1360 -> 1084-1288 Flight Mode 3 1361-1490 -> 1289-1493 Flight Mode 4 1491-1620 -> 1494-1697 Flight Mode 5 1621-1749 -> 1698-1902 Flight Mode 6 1750+ -> 1903+

2) Output Aux 3 produces some signals to control an external LED flasher (low battery warning).

@lvale That's interesting for sure, as there's no need for parsing through all messages anymore ... I hope it gets implemented in 3.3

[mrpuzzler]

@lakeroe thanks, looks cool. I try to compare it with latest 3.3 to check how many changes you have here.

[robustini]

@mrpuzzler, i've a big problem with your script and my Taranis Plus because when load the LUA overwrite my first logical switch, my first special function and lock my first timer, please check. Obviously are functions that I have assigned and overwrites those, not good! ;-) Just for example see the first "RSSI" and "SD LOG", in my original model in those locations there's other function :

[lvale]

@robustini What version of OpenTX do you have on the radio. 2.0.15 is the latest. There were problems similar to what you describe on previous versions.

[robustini]

2.0.15... tested with different Taranis, same problems. Check "ApmTelem.lua", need some fix... ;)

[lvale]

@robustini I would open an issue with OpenTx. Ping https://github.com/bsongis

[lakeroe]

@robustini I think you meant me (not mrpuzzler) some posts above. The LUA script includes some code to automatically start data logging as soon as receiver and transmitter are connected (RSSI-RX > 10).

That's the reason why the first logical switch and the first special function gets overwritten. I don't know (yet) why the first timer gets locked.

If this is not what you want just delete everything underneath "Telem_ACTIVE = true" in "local function init ()" in ApmTelem.lua.

Sorry for the troubles !

Best regards, lakeroe

[mrpuzzler]

Ok, I have just completed my custom inverter.

Trying to plug it into s.port, and X8D immediately stops, pixhawk reports errors and taranis loose signal. Anyone got such troubles? I even did not plug it into pixhawk, only s.port.

[lakeroe]

As far as I can tell from the picture your wiring is wrong, please check it again ...

[mrpuzzler]

@lakeroe, could you please clarify you thoughts? Connectors from top: + RX SP TX -

[lakeroe]

it's actually not the wiring, it's the pcb. RX is only connected to 4k7 resistor. it also has to go to the drain of the n-channel fet ...

[mrpuzzler]

@lakeroe, yeah, thanks! Fixed now. And I'm ready for tests.

[magicrub]

That's a really nice picture, great focus!

On Tue, Mar 31, 2015 at 7:53 AM, Andrei notifications@github.com wrote:

@lakeroe https://github.com/lakeroe, yeah, fixed now. And I'm ready for tests. [image: img_0778_crop] https://cloud.githubusercontent.com/assets/5765729/6921636/c432bec2-d7ce-11e4-8171-947b9ac62d89.jpg

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

[mrpuzzler]

It seems 3.3-RC1 should has native support for s.port telemetry. But can't activate it. I select 4 for SERIAL2, but nothing. Can anyone check it, who has working it with modded firmware?

[mrpuzzler]

@lakeroe, could you please clarify, how to connect, RX on converter -> RX on Pixhawk, and TX on converter -> TX on Pixhawk, or vise versa?

[lakeroe]

@mrpuzzler, that's the correct wiring: RX on converter (=OUTPUT) -> RX on Pixhawk (=INPUT) TX on converter (=INPUT) -> TX on Pixhawk (=OUTPUT)

[furynick]

Same problem here, no output from SERIAL2 with SERIAL2_PROTOCOL=4 even with a FTDI connected on it and sending 0x7E 0x22 to Pixhawk. After some research in the code I cannot figure out if the AP_Frsky_Telem::sport_tick is called by PX4Scheduler::_run_io as there's no output from hal.console->printf (maybe the threaded solution break access to console).

[mrpuzzler]

As far as I can see it should be called. See AP_Frsky_Telem::init and line hal.scheduler->register_io_process(AP_HAL_MEMBERPROC(&AP_Frsky_Telem::sport_tick));

[furynick]

Well, I already saw all thread creation processus and handler registration. I now have response on serial port with another FTDI ... but I haven't good ones. I verified the protocol is set to FrSky S-port (added init message on console in second condition of AP_Frsky_Telem::init and shown it). So, using HTerm at 57600,8,N,1,no flow when I send 0x7E,0xC6 (DATA_ID_SP2UR) the reply should be something like 0x10 (prime), 0x05 (sats number id), 0x00, 0x73 (LSB), 0x00 (MSB), 0x00, 0x00, 0xnn (crc). I only have 0x00,0x00 first time and 0x00,0xFF the second time and so on. Maybe I'm wrong somewhere but can't find my mistake and there's definitely no output on terminal from sport_tick nor frsky_send_byte.

[badzz]

I will check master tomorrow. Sorry if there is a bug there

[furynick]

I doubt there's a bug, I checked the code several times and I don't see any problem. I'm pretty sure it's the method I use to simulate but I can't find any clue of what mistake I do. Moreover, one friend encounter the same problem (no telemetry sent thru X8R) and another friend get all info using 3.3-dev. I also cannot understand why hal.console->printf_P don't work within a thread, the object is initialised way before thread creation so it should be usable the same way ... I certainly missed something but took an eye to the code since few days only, I have many more to read.

[badzz]

@mrpuzzler : I tried 3.3Rc1 and it works fine when SERIAL2_PROTOCOL= 4 Wiring is here, others have used other system (see above) http://copter.ardupilot.com/wiki/common-frsky-telemetry/#what_you_will_need_for_x-receiver For some reason I had updated the wiki but screw up , the new parameter has been submitted to the wiki and will be updated once the modification is validated.

[mrpuzzler]

@badzz, do you use lua script from @lakeroe ? can you see cell/cells voltage without this script?

[badzz]

The code in arducopter is not compatible with the lua script(yet). It is only compatible with the teensy boardhttp://diydrones.com/forum/topics/amp-to-frsky-x8r-sport-converter

[mrpuzzler]

@badzz, I use custom converter ... so, it's not supported? Also, I try to use default http://www.open-tx.org/2014/06/27/telem1-lua/ lua screens, nothing

[badzz]

Inverter is needed but not enough as explained here :http://copter.ardupilot.com/wiki/common-frsky-telemetry/#what_you_will_need_for_x-receiver Those LUA script, I do not know. Try to display Telemetry normally first to see if data comes in

[mrpuzzler]

I can't see any data on normal Telemetry screens, can't see any data on lua too. Can anyone with same converter check it? Maybe my converter is broken ...

@robustini, can you check it on your side (without lua and with default lua scripts from link above)? I saw, you have same converter.

[badzz]

@mrpuzzler : If you are using the normal firmware it wont work with the lua script. @robustini is using a special firmware modified by virtualrobotix as far as I know. When checking the telemetry, you have to use the old metrics : T1, T2 ,... not the new ones like T1+, T2+ ,..

[mrpuzzler]

@badzz, can you suggest any update/fix for the current master to use T1, T2?

@furynick, could you please clarify, how is your friend get telemetry? what does he uses, converter or teensy?