Ardupilot: 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

[lvale]

Reference also
https://github.com/lvale/MavLink_FrSkySPort

Also as a side note, OpenTX is about to have their telemetry handling refactored.
https://github.com/opentx/opentx/issues/1634

[lakeroe]

I've recently added some code for native FrSky telemetry. It seems to work quite well and I have done a few test flights so far. The LUA scripts (running on the Taranis) are similar to here:
https://github.com/wolkstein/MavLink_FrSkySPort/tree/master

It's also possible to display all text messages sent to the GCS. This is done by not sending the actual message but an ID instead. For this reason I made a quick and dirty hack in GCS_Common.cpp. I defined two global variables uint8_t textId and g_severity and added following code in
GCS_MAVLINK::send_text(gcs_severity severity, const char *str)

if (!strcmp(str, "ARMING MOTORS"))
    textId = 1;
else if (!strcmp(str, "PreArm: RC not calibrated"))
    textId = 2;
else if (!strcmp(str, "PreArm: Baro not healthy"))
    textId = 3;
     .
     .
     .
else if (!strcmp(str, "Throttle disarmed"))
    textId = 83;
else
    textId = 0;
g_severity = severity;

I think you'll get the idea !
As this code parses all possible messages (more than 80 so far) I think it's necessary to change this part to a more elegant way.
Because the FrSky Taranis is running a LUA script converting the message ID back to the actual text message, it's necessary to keep the text messages and their related IDs in sync.
For this reason it would be great to have all messages somewhere stored in a single place (file).
It's all a bit complicated to describe but I think you know what I mean.
I don't have the programming skills to do such a change but if somebody can do that, I'll do the rest ;-)

[lakeroe]

Hello,

some code for native FrSky telemetry for S.port capable receivers (X4/6/8R) is for download here:
http://www.adrive.com/public/U6yfYd/FrSky-Telemetry.zip
I tried to submit a "Pull Request" but for some reason it just did not work (Error: Failed to publish this branch).
I hope it's okay to append the patch as the changes are not too much (AP_Frsky_Telem.cpp and AP_Frsky_Telem.h can be overwritten completely, changes in the other 3 files are minor).

In order to make this work you need to connect your receiver (X4/6/8R) to your flight controller by an external inverter (https://github.com/TauLabs/TauLabs/wiki/User-Guide:-FrSKY-S.PORT-telemetry) or modify your receiver (http://eleccelerator.com/frsky-x4rsb-smartport-hack-naze32/).

Following parameters are important:
SERIAL2_PROTOCOL = 3 (FrSky S-Port)
BRD_SER2_RTSCTS = 0 (Disable flow control)

The code seems to work quite well and I have done a few test flights so far, but it's not 100% tested.
I have never done any RTOS programming before, so it would be great if an experienced programmer could have a look at the code.

For displaying messages sent to the GCS I made a quick and dirty hack in GCS_Common.cpp.
As this code parses all possible messages (about 80 so far) I think it's necessary to change this part to a more elegant way.
Because the FrSky Taranis is running a LUA script converting the message ID back to the actual text message, it's necessary to keep the text messages and their related IDs in sync. For this reason it would be great to have all messages stored in a single place (file).
It's all a bit complicated to describe but I think you know what I mean ;-)
Sorry I can't do that as my programming skills are limited.

By using some LUA scripts it's possible to display following values on the Taranis:

Armed/Disarmed state
Flight mode (incl. Simple and Super Simple mode)
Battery voltage
Battery current
Flight time
Output throttle
Horizontal speed
Vertical speed
Height
Heading (absolut and relative to home)
Altitude mode (climb, sink, hold)
GPS fix type
GPS hdop
GPS position (latitude, longitude, altitude)
Distance from home
Number of satellites used for GPS
Artificial horizon
All messages sent to the ground station (incl. severity)
Further more voice alerts can be played on various events (flight mode change, battery low, message received ...)
All telemetry data also gets logged on the internal SD card

Sample screenshots

Some info about timing:
Receiver polls us ~ every 12 ms (83 Hz) and we have to answer within a certain time, so it's necessary to run the main loop with 200 Hz (100 Hz does not work). Our sensor ID get's polled every second time (24 ms) and because we send 16 different values the update rate (on the Taranis display) is ~ 16*24=384 ms (2,6 Hz)

This is tested on FrSky Taranis (OpenTX 2.0.13), X4R. Current is untested because I have no current sensor.

What do you think ?

[robustini]

I think is time to test it... lakeroe, you're the man!

[lakeroe]

Would be great if you can do some testing once the code gets integrated. I will publish the lua scripts and some more (wiki) documentation than as well ...

[robustini]

Can you give me some info about the "external inverter" circuit?
I see two mosfet in this schematic but component name is missing.

[lakeroe]

Every standart logic level MOSFET should work. I'll post the FETs I used this evening ...

Here's another inverter schematic:
http://www.multiwii.com/forum/viewtopic.php?f=8&t=4507

[robustini]

Thanks!
About your commit: at the moment there's big changes in the px4firmware layer (3.3-DEV version), can you align your patch with the latest Copter/Plane release and share a zip with your patch?
Remember also the LUA script used in your example... ;-)

[lakeroe]

What's the problem in detail ?
It should be enough to overwrite AP_Frsky_Telem.cpp / AP_Frsky_Telem.h and add the few minor changes in the other 3 files.
Maybe do a simple file compare. My changes are based on 3.2.0.

I'll have a look at 3.3-DEV later.
By the way: 3.3-DEV version ist the same as the master branch, right ?

[lakeroe]

The FETs I use are:
BSS138 (https://www.fairchildsemi.com/datasheets/BS/BSS138.pdf) and
FDN338P (https://www.fairchildsemi.com/datasheets/FD/FDN338P.pdf)

The LUA scripts are for download here:
http://www.adrive.com/public/augCDt/LUA%20scripts.zip

I also just tried the latest master branch (3.3-dev) and it compiles without problems. I didn't test it "in real" though ...

[razorbac91]

Hi,
first of all thank you for your work =) And now the question: is possible to use this project with normal APM 2.6 or i need the pixhawk?

[lakeroe]

This is PixHawk only, for APM you could use the "external" solution:
http://diydrones.com/forum/topics/amp-to-frsky-x8r-sport-converter

[razorbac91]

Ahah as usual i'm not lucky at all xD anyway actualy i use this project http://www.itluxembourg.lu/site/ that allow me to take the mavlink data on the serial port of the tx orange 433 module and send it to pc trough bluetooth module. If i put the teensy in parallel to the bt module and send the telemetry data to the taranis serial port on the battery tray (setted in telemtry mode obviusly) this can work with yours scripts?

[lakeroe]

My scripts work only with my source code posted above.
In order to display all the different values you see in the sample screenshots above I have to send different values than the teensy solution ...

[razorbac91]

Mmmm ok this is bad beaucause i realy like the graphics of yours script :/

[lakeroe]

If you can do some (probably) simple changes in the teensy source it shouldn't be a big problem to get it working with my scripts ...

[razorbac91]

Mmm i have to try :) thank you for all

[Loreagle]

I use a code with an Arduino Mini Pro on my APM 2.6 and it works very well....I really love your LUA scripts, would be nice if someone can modify this code for our old apm users to have the correct output for your LUA scripts, here the link: https://github.com/vizual54/APM-Mavlink-to-FrSky

[badzz]

Looked at your code but the thing is plane and rover do not have 200hz scheduler
see :https://groups.google.com/d/msg/drones-discuss/1gwvlmR8XkA/C4X6rW_lMBoJ

I implemented it using a separate thread as recommended by tridge: https://github.com/diydrones/ardupilot/pull/1800
if you want different sensors id , send me some PR on my branch, I will see what can be done.

[lakeroe]

Hello badzz,

I also had a quick look at your code.
Apart from using a separate thread your code is also compatible to standard opentx telemetry values.

Because I wanted to transmit more values I gaveup opentx compatibility, but have to use some LUA scripts instead.
If your and my version should be integrated I think we need some kind of switch.

I think it's also necessary to do some code changes to transmit a message id as I wrote some posts above ...

What do you think ?

Best regards,
lakeroe

[robustini]

Lakeroe, I tried everything but I can not get this thing working with Pixhawk, i correctly set the parameters:

SERIAL2_PROTOCOL = 3 (FrSky S-Port)
BRD_SER2_RTSCTS = 0 (Disable flow control)

All the connections are ok, tx/rx to Telem2 port and the three pin to the S-Port (X8R).
The external inverter work fine, tested with uBrain with the same code (adapted for this baord), everything works as expected.

[badzz]

Marco
Did you try to connect this way http://copter.ardupilot.com/wiki/common-frsky-telemetry/#X-Receiver_setup .
Lakeroe,
You are talking about the teensy solution ? I am indeed planning to do a compatibility mode at some point.
Thx

[robustini]

I use this simply inverter, Q1 and Q2 are common NPN, BC182:

With "Virtualrobotix uBrain" work fine: https://www.youtube.com/watch?v=VZvY5z89-fs&feature=youtu.be

[badzz]

Ok..
What modification has been done on uBrain ? Any git commit I can look at to understand what is different ?
I will check beta build this week end as well to see if anything is wrong. I know that Randy committed SerialManager that could impact frsky driver.
Matthias

[badzz]

@marco: try 4, serialmanager modified the way this parameter is handled. I need to update the doc https://github.com/diydrones/ardupilot/blob/master/libraries/AP_SerialManager/AP_SerialManager.h#L75

[robustini]

Already tried, same result.

[badzz]

Just to make sure : which code are you using ? The one in master ?
On 30 Jan 2015 23:52, "robustini" [email protected] wrote:

Already tried, same result.

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

[robustini]

Yes...

[badzz]

ok, and you are not using the LUA script . The code in master shows the
standard metrics : T1 (mode) T2 (Sats), voltage, amps ,...
I just tested in sitl, and it seems ok with SERIAL2_PROTOCOL=4

On Sat, Jan 31, 2015 at 12:18 AM, robustini [email protected]
wrote:

Yes...

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

[lakeroe]

@Marco
Can you try this firmware (Pixhawk version compiled for a quad) ?
http://www.adrive.com/public/h3TuJH/PixHawk_3.2.0.zip

It's 3.2.0 including the FrSky telemetry patches and another small change to use a LiPo flasher at auxilary output 3. No other changes !
I use this version for some time now without any problems ...

@Matthias
Have you thought about adding the ability to transmit status messages (like in my code) as well ?
How do you handle the unavoidable echo you get on the 1-wire s.port ?

[robustini]

@lakeroe
Tried now, same result, it doesn't work.
I use your firmware and your parameters file.
Here the connections, I'm doing the bench test, only with usb connected.
Someone else can try with this simple inverter?
Maybe I'm doing something wrong, in the afternoon I try with another inverter.

[lakeroe]

As far as I can tell from the picture the wiring should be okay.
As I could see in your video my changes are working with uBrain so I suppose the problem is the inverter circuit. Your pullups are at 5V level but PixHawk uses 3,3V.
Do you have an oscilloscope to check the signals or can you try my inverter circuit using FETs ?

[badzz]

@lakeroe
It would better to have a native id for those messages. Doing a check on
the strings would need quite a bit of maintenance and I do not think that
the maintainer would accept it (understandably so). Last time I talked with
randy about adding ids on the prearm status, he proposed to have this
unified in ap_motor library. I checked it and there is a fait bit work to
make that happen.
I checked Luis code already in the past and I can make it 90% compatible
with his lua script (barring messages as explained above). Are you ids
usage very different than his ones?
The idea would be to make it optional: standard frsky/lua script compatible.
On 31 Jan 2015 10:42, "lakeroe" [email protected] wrote:

@Marco https://github.com/Marco
Can you try this firmware (Pixhawk version compiled for a quad) ?
http://www.adrive.com/public/h3TuJH/PixHawk_3.2.0.zip

It's 3.2.0 including the FrSky telemetry patches and another small change
to use a LiPo flasher at auxilary output 3. No other changes !
I use this version for some time now without any problems ...

@Matthias https://github.com/Matthias
Have you thought about adding the ability to transmit status messages
(like in my code) as well ?
How do you handle the unavoidable echo you get on the 1-wire s.port ?

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

[lakeroe]

@Matthias
What do you mean with "Luis code" ?
Currently I use my own message id's, but it should not be a problem to change them to whatever.
The idea to choose between standard frsky / lua script compatible sounds great.
I can do the "lua script compatible" part if you want !

[CodeChief]

Hi I'm looking for the _best_ solution to get FrSky telemetry between a Pixhawk clone (HKPilot32) and an FrSky X8R receiver. It's down to three possible solutions of which yours looks the simplest.

1) Officially documented solution on the current APM Copter web site: http://copter.ardupilot.com/wiki/common-frsky-telemetry/ and I already have the SPC cable just finding it hard to find a FUC-1 TTL to RS232 converter. But it says it can only send "some" of the data. Is that true because then I won't waste my time (I want a full solution)? Or is that just a current software limit, is this effectively a more complex version of your adapter (but at least commercially available)?

2) The Teensy solution which appears to be the most high fidelity because you can also add more later, like battery balance lead connection for individual cell measurement, for example in the "wolkstein" variant. https://github.com/wolkstein/MavLink_FrSkySPort

3) Your solution is the simplest circuit and most integrated into the existing processor on board like option 1, which I like. I'm not so experienced with electronics yet, but think I could make your board. Before I start, I wonder is it as simple for me as using the existing SPC cable I have and wiring the TX and RX into the Pixhawk serial port? The SPC basically has a single diode after TX before joining with RX out to the S-Port. Or is additional inversion/resistance necessary?

I assume your solution is also able to provide support for all possible data exchange (maybe it's not coded yet but is this physically possible). You see I just want to get all the hardware sorted out properly then start work on software with all you other guys to improve things. I don't want to start with some hardware which is limited then end-up switching to the Teensy later.

Oh and by the way the cell voltage thing is not necessary because if we're going down the architecturally correct route to get Pixhawk/APM at the centre of everything then we should be finding other ways to get new information, e.g. new Pixhawk specific sensors or support for FrSky sensors on the same S-Port (bus) as this adapter.

If you can answer any of these questions that'd be much appreciated!

p.s. oh yes and please add shots of the other side of your boards, for a newbie to electronics it helps :-)

[badzz]

I'd like to redesign the way metrics are being handled to have an array of
metrics to be sent. This way you could switch between different models.
Luis code is quite popular afaik :
https://github.com/lvale/MavLink_FrSkySPort
On 31 Jan 2015 15:43, "lakeroe" [email protected] wrote:

@Matthias https://github.com/Matthias
What do you mean with "Luis code" ?
Currently I use my own message id's, but it should not be a problem to
change them to whatever.
The idea to choose between standard frsky / lua script compatible sounds
great.
I can do the "lua script compatible" part if you want !

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

[robustini]

@lakeroe
News: with another inverter all work fine, i'm sorry, need to check the other one (identical)...
Tried with the "Plane" version (latest master) and work only the LiPo voltage.

[lakeroe]

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

@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 FUL-1 TTL to RS232 converter + SPC cable or one of the different inverters mentioned above.
In your post you wrote FUC-1 but you definitly need a FUL-1 converter.
http://www.banggood.com/FrSky-Receiver-Upgrade-Lite-FUL1-p-930265.html
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 ...

@Marco
Can you again try my compiled firmware ?

[robustini]

Where is your compiled firmware for the Plane?
I repeat, with your compiled version for Copter now all work fine.

[lakeroe]

No I mean the copter firmware I posted this morning ...

[robustini]

Yes, all work fine now with your compiled version.

[lakeroe]

Great to hear that ...

[badzz]

And with master ?

On Sat, 31 Jan 2015 17:11 robustini [email protected] wrote:

Yes, all work fine now with your compiled version.

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

[badzz]

@robustini: with master, you should have gps, t1 (mode), t2 sats, speed,
course, altitude,..
On 31 Jan 2015 16:42, "robustini" [email protected] wrote:

@lakeroe https://github.com/lakeroe
News: with another inverter all work fine, i'm sorry...
Tried with the "Plane" version (latest master) and i've only the LiPo
voltage.

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

[robustini]

Oh nice, so with the master the LUA script doesn't work for this reason?

[lakeroe]

Yes, the code for working with the LUA scripts is NOT in the master branch (yet) ...

[BjoernKellermann]

Does it make sense to invert the signal in software in order to use standard logic level shifters?

To physically connect Pixhawk serial 2 and S.Port on FrSky X-series receivers, we need a logic level shifter from 5 to 3.3 Volt and we have to invert the signal from high to low and from low to hight.

Logic level shifters are easy to buy, e.g. From sparcfun fir apr. 2-3 USD. I haven't found an inverter.

[lakeroe]

Inverting the signal in software is not possible, the processor has no support for that :-(
If you can do some tinkering this inverter is possible the simplest one to try:

https://github.com/TauLabs/TauLabs/wiki/User-Guide:-FrSKY-S.PORT-telemetry

The FETs I use are:
BSS138 (https://www.fairchildsemi.com/datasheets/BS/BSS138.pdf) and
FDN338P (https://www.fairchildsemi.com/datasheets/FD/FDN338P.pdf)

The inverter further above using transistors (and pullups to 5v) also works fine.

[proficnc]

Is it possible to use the s.bus out for this? It has an inverter on it on Pixhawk. You would need to pass through the i/o chip, but it would get rid of the need for the inverter

[badzz]

Sbus output can only output, no input.
On 31 Jan 2015 22:38, "proficnc" [email protected] wrote:

Is it possible to use the s.bus out for this? It has an inverter on it on
Pixhawk. You would need to pass through the i/o chip, but it would get rid
of the need for the inverter

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

[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" [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected]
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" [email protected] 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:[email protected]]
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 [email protected] 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?

[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 [email protected] 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" [email protected] 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" [email protected] 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 [email protected] 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" [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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" [email protected] 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.

[epquilloy]

I see, I thought both sides are connected to each other. I will move the diode to one side of the board only. :) thanks again!

[erkki]

I originally thought as well :)

[epquilloy]

still no luck on making it work..

[erkki]

Can you post a new photo? Do you have a multimeter or a scope to test the voltages/signals?

[rmackay9]

@epquilloy, very nice. you should sell those ..

[epquilloy]

here's the latest modification. All connections on one side of the board. By the way, I am connecting this directly to telem 2 port. I suppose this is powered by 5V from pixhawk. I set on Mission Planner Serial 2 protocol to 4. Is this correct? how about the baudrate for this? When I power up the pixhawk, then the taranis, i cannot see the telemetry data on the telemetry page (long press PAGE button). I already added the parameters to be shown on this page on the taranis' settings.

[badzz]

Connections looks ok
Mime :https://plus.google.com/+MatthiasBadaire/posts/UaC1wmB11mg?pid=6144577061037466114&oid=111345306876503099445

You do not need to change the baud rate, it will be forced when sport code
initiailize
Indeed , SERIAL2_PROTOCOL should be 4 for X-Receiver with copter 3.3
which RX from frsky are you using ?

On Mon, Jun 29, 2015 at 1:08 PM, epquilloy [email protected] wrote:

[image: img_5174]
https://cloud.githubusercontent.com/assets/12706729/8406732/c16307d8-1e91-11e5-8f78-922f82b02381.JPG

here's the latest modification. By the way, I am connecting this directly
to telem 2 port. I suppose this is powered by 5V from pixhawk. I set on
Mission Planner Serial 2 protocol to 4. Is this correct? how about the
baudrate for this? When I power up the pixhawk, then the taranis, i cannot
see the telemetry data on the telemetry page (long press PAGE button). I
already added the parameters to be shown on this page on the taranis'
settings.

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

[epquilloy]

I am using X8R receiver. I connected the module to the SPort of the x8r, but I cannot make it work.. Maybe the problem lies with the taranis settings?

[epquilloy]

Is there a guide for setting up the taranis for the native telemetry support for frsky?

[badzz]

I do not see what could be wrong on the taranis side.
You have nothing on T1 or T2 on the telemetry screen while changing flight
mode ?
Do you receive the rssi info at least (this is not related to the pixhawk) ?
Can you take a picture of the cable plugged, in case of...
On 29 Jun 2015 16:12, "epquilloy" [email protected] wrote:

I am using X8R receiver. I connected the module to the SPort of the x8r,
but I cannot make it work.. Maybe the problem lies with the taranis
settings?

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

[badzz]

http://copter.ardupilot.com/wiki/common-optional-hardware/common-telemetry-landingpage/common-frsky-telemetry/
On 29 Jun 2015 16:18, "epquilloy" [email protected] wrote:

Is there a guide for setting up the taranis for the native telemetry
support for frsky?

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

[epquilloy]

Thanks for the guide :)

[epquilloy]

Here's how I wire it up.

[epquilloy]

It seems that the telemetry is somehow working. When I switch flight modes, the T1 value changes. Other parameters seem to be not working? Or am I doing anything wrong? The cells are not shown too.

[badzz]

whoa . that looks ok to me.
Cells,cell, AccZ is not implemented, see the doc for what is present.
Try the other values from the documentation, it should work.

On Mon, Jun 29, 2015 at 4:59 PM, epquilloy [email protected] wrote:

[image: image]
https://cloud.githubusercontent.com/assets/12706729/8410611/f4081c6c-1eb1-11e5-8e3b-9d387ec6f884.jpg

It seems that the telemetry is somehow working. When I switch flight
modes, the T1 value changes. Other parameters seem to be not working? Or am
I doing anything wrong? The cells are not shown too.

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

[furynick]

You need to have a GPS Fix to get other values

[epquilloy]

I see, thanks everyone :) I got it working now.

One thing I noticed, the fuel is zero?

[badzz]

Did you connect a flight battery or just via usb ?
Connect to MissionPlanner and check what percentage it tells you there. The
value is calculated by the APM code.
There might be a bug there.

On Mon, Jun 29, 2015 at 5:15 PM, epquilloy [email protected] wrote:

I see, thanks everyone :) I got it working now.

One thing I noticed, the fuel is zero?

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

[epquilloy]

You're right, it seems that the calibration for current was lost when I updated to the latest 3.3rc7.. :) oh well, at least i see this working now. Thanks my friends!

[furynick]

I guess it's vfas not fuel (there's no fuel sensor for ardupilot)

[epquilloy]

Current is also zero :) caused by the lost calibration for current, I will do the recalibration ASAP :)

[badzz]

Vfas shows volts
Fuel should show a percentage of the remaining amps in a battery based on
consumption (same as in mp)
On 29 Jun 2015 17:30, "furynick" [email protected] wrote:

I guess it's vfas not fuel (there's no fuel sensor for ardupilot)

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

[furynick]

Thanks Mathias, I missed that :)

[Johnex]

Glad you got it working @epquilloy :).

[epquilloy]

Yeah :) not without help from you all. Thanks again!

[epquilloy]

hopefully we can develop scripts for this too. this is very promising as the teensy approach.

[Johnex]

Yes as soon as 3.3 final comes out i plan to modify Chris' lua script (its the one i use always) so it works with the native values, shouldn't be too hard. Unfortunately i think all the arming warnings will be gone which are nice to have that Chris has working with the teensy.

[ptsneves]

Hey
It seems you have got quite a head start but at Airborne Projects we have developed a APM MavLink to FrSky SmartPort Converter that can takes the MAVLink messages and converts it to FrSkySmartPort format and can directly be connected to the Taranis Radio.

We include all the cables necessary - UART or USB Serial possible for the Navio - and it features a hardware modified version of the Arduino Nano so it can be powered directly from the Taranis receiver, from 5-10V (actually theoretically you can go to 20V but that voltage is not standard in RCs).

You only have to load the Taranis telemetry modules and configure in mission planner. No soldering required. We have produced a manual that we would enjoy feedback on.

As said, it is based on the Arduino Nano and the software is open sourced GPL on GitHub based on the work of ScotFlys' code.

It could also do the exact same thing a Serial to SmartPort does in the X configuration with no soldering or additional wiring involved if there is interest in it.

In sum our additional feaures are:

• True verification of arming status directly from the correct heartbeat flag MAV_MODE_FLAG_SAFETY_ARMED and sys_id check.
• Verification of arming status from the correct heartbeat sys_id
• An ArrowHead with Relative heading regarding arming orientation, so you can always know where your aircraft is pointing regarding it's arming position in real time.

We apreciate your feedback
Paulo Neves
Airborne Projects

[rmackay9]

@ptsneves, nicely done, looks good. I think we should at least mention the product on the ardupilot FrSky telemetry wiki page as an alternative for people.

[mr-sneezy]

Just made the two transistor interface and fitted to an X4R, and it works well.

Where could I find links to copter LUA scripts for the Taranis (a Plus with FW 2.1) ?
I can't seem to find a link to the OP's LUA here...

[aldoir]

I modified this script http://rcsettings.com/index.php/viewdownload/13-lua-scripts/205-iris-telemetry-script to be compatible with 2.1, plus I've added some graphics to show battery and RSSI

Discover your sensors then rename the Temp sensors to T1 (Sats and Fix) and T2 (Flight Mode), I didn't find a way to access them by name without renaming. On 2.1 there is no safe way to access getValue() by ID, you have to use their names.

https://drive.google.com/file/d/0B6QwWe5rj4cJTTBYdGRXcmY2cEU/view?usp=sharing

[epquilloy]

Hi aldoir

is there a correct way to execute your script? I am having a problem loading it. I already copied the telemetry script into folder for my model, but my taranis x9d plus fails to load it..

[ptsneves]

@aldoir I
Airborne Projects produced a patch that will correctly disambiguate the
temp sensors to tmp1 and tmp2. It is already merged and will be available
in the next opentx release. At Airborne Projects to avoid that renaming we
simply provided a firmware update to use another sensor and this way be
already compatible with 2.1.3.

By the way our converters and scripts are now compatible with 2.1.3 and
master branch and have a manual to help user migrate to the new version.

On Sunday, October 25, 2015, epquilloy [email protected] wrote:

Hi aldoir

is there a correct way to execute your script? I am having a problem
loading it. I already copied the telemetry script into folder for my model,
but my taranis x9d plus fails to load it..

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

[aldoir]

@epquilloy,

You have to explicitly tell OpenTX which script you want to use for each screen, there is no naming convention anymore. Open you model's telemetry page and set the screen 1 type = script, then choose the script you saved.

@ptsneves,

That's nice, I'll watch and update the script.

Do you know if is there any movement to make additional variables available? I'd like to see the FUEL variable, as I did a lot of calculations trying to guess the remaining battery percentage with no luck.

PreArm error codes would be nice as well.

[ptsneves]

@aldoir Our script has supports uses the battery remaining value from Ardupilot, but the getValue("fuel") exists in 2.1.3 with no changes. Hope it helps.

For now with don't have PreArm codes active but we have status text displayed

[aldoir]

@ptsneves. Do you know if is there any configuration required on ardupilot to make it sending the fuel variable? The sensor never appears on OpenTX's "Discover new sensors". Your script/converter is amazing, but for my needs the standard RS232/TTL adapter is enough

[epquilloy]

@aldoir

I have already tried setting the script, but it says no scripts on sd. But I have already placed the script under the model which I created

[epquilloy]

I have a teensy 2.0 setup before, it has A very comprehensive telemetry data. Even pre arm Checks were voiced out, as well as all errors. Even the flight modes were spoken out, Apparently, on opentx2.1 and AC3.3, they scrapped the support for teensy2.0. I am ordering a teensy 3.1 now ;)

At the moment, the simple rs232-ttl is also enough for me while I wait for the teensy 3.1

[aldoir]

@epquilloy Telemetry scripts aren't located inside the model folder anymore.
See the item 7 on this post: http://openrcforums.com/forum/viewtopic.php?f=45&t=7239

[ptsneves]

@aldoir I do not know how the FrSky telemetry is sent on the Ardupilot. I imagine that not all sensors are sent due to the way the SmartPort works (slow update). Maybe somebody could weigh in. We can also produce a quotation for that feature, open source of course. Just that feature it should not be anything outrageous.

[aldoir]

@ptsneves According to the wiki this informationn should already be sent
http://copter.ardupilot.com/wiki/common-frsky-telemetry/#protocol_information, but it does not work.

[ptsneves]

@aldoir I checked the code and it seems the code in Ardupilot still uses the old FrSky IDs. To be honest I don't even know how this works. In my code the fuel sensor is discovered by ID 0x0600 not 0x04. Notice that the ID is 16bit not 8bit even

[floaledm]

@ptsneves With the new FrSky IDs, the "first" FUEL sensor is on ID 0x0600 ("last" is 0x060f), whereas, as you already know, the old FrSky ID for FUEL is 0x04. This allows sensors of the same type to be connected on the same bus, yet have different IDs that OpenTX will be able to differentiate.

[epquilloy]

@aldoir

the script now works, but not everything. the VFAS, RSSI, altitude, current, heading are updating. but the Sats and other numbers on the script does not update. I am using the telem1.lua from the link that you gave.

update:

i think I know the problem, i have renamed the sensors which may have affected the scripting, though this is just a theory, I will try to delete all sensors later and set this up again :)

[aldoir]

Yes, you must rename Temp sensors to T1 and T2 (see my original post). If you rename others, you must change the name on the script as well.

[epquilloy]

@aldoir
got it working now, except for the timer. :) what do i need to do to fix the timer? thanks again

[aldoir]

@epquilloy It's only displaying the Timer 2. You must set up your radio to start/stop/reset this timer

[furynick]

Still trying and unable to get it work.
Using v3.3.1 on AUAV-X2 serial 2 (USART 3) with SERIAL2_PROTOCOL=4 connected to X4R S-Port.
No more success with a FUL-1 nor with an X8R.
Using this converter :

[epquilloy]

@aldoir

got the timer working :) thanks again! almost as good as my previous teensy setup. only warning prompts are missing :)

[epquilloy]

hi! i noticed, when I try the logging function, what is saved on the memory card on my taranis is not the important info such as altitude, gps coordinates, etc. but only the states of switches and sticks rather.. Is this normal? or is there any work around to let my taranis record all necessary data?

[R-Lefebvre]

I don't think this is a great place to be discussing the firmware in the Taranis radio.

[epquilloy]

ok please disregard it, I thought this was an issue related with the opentx 2.1.3 and native telemetry adapter combination. Anyway, It's working fine now. Not really related to the adapter

[berin-aquaquad]

lakeroe thanks to your 3.2.0 build for the pixhawk and .param file my telem is finally working. at least its showing a heart beat. I'm using the ful-1/spc adapter now that thats working I'm tarified of updating any software. currently 3.2.0 pixahwk your build, opentx 2.0.17. I believe I have spent a month or more trying to get the telem up and running.
The only thing I need to figure out now is why lat and long are not displaying, I dont know if its just some simple stupid setting or what the issue is.

[floaledm]

My company sells a FrSky Telemetry cable for the Pixhawk (DF13) HERE. This cable is a functional equivalent to using both the FrSky FUL-1 and FrSky SPC.

The cable is compatible with the FrSky X6R and X8R receivers (not the X4R or the D-type receivers).

The cable (if purchased on Craft and Theory’s website) comes with this state of the art user interface, which is compatible with any Taranis RC transmitter running OpenTX 2.1.x:

The interface displays the following information on the Taranis LCD:

• Flight mode (+Simple/SuperSimple)
• Flight timer as determined by autopilot (paused when landed)
• RC link signal quality
• RC transmitter battery voltage
• Heads-Up display (HUD) – similar to Mission Planner’s HUD and extremely fast 24+Hz update rate!
  
  
  
  • Heading and compass bezel
  
  
  • Pitch and roll
  
  
  • Altitude and horizontal speed
  
  
• Battery information (requires power module and battery mAh to be configured in Mission Planner)
  
  
  
  • Battery pack voltage
  
  
  • Average cell voltage (or lowest cell voltage if a FrSky LiPo voltage sensor is connected)
  
  
  • Current/power draw
  
  
  • Number of cells in battery pack
  
  
  • Lowest recorded or nominal battery pack and cell voltages
  
  
  • Highest current/power draw
  
  
  • Remaining battery capacity bar
  
  
• Vehicle position
  
  
  
  • Orientation relative to home position
  
  
  • Distance from home
  
  
  • Distance above ground (if equipped with a range finder)
  
  
• GPS signal quality
  
  
  
  • GPS fix indicator (no GPS, no fix, 2D, 3D)
  
  
  • Number of satellites or HDOP
  
  
• MAVLink messages
  
  
  
  • Alerts and error messages (same as Mission Planner)
  
  
  • Failsafe flags
  
  
  • Information messages
  
  

MAVLink statustext, system_status, and ekf_status_report messages (as would appear in Mission Planner) are shown in the bottom panel of the LCD for ten seconds after being received, but the list of received MAVLink messages can also be viewed on a second page:

The scripts also provide audible sound alerts consisting of:
• Flight mode (e.g., “stabilize,” “loiter”),
• “Normal/simple/super simple mode,”
• “Armed”/“disarmed,”
• “Landing complete” each time the copter lands (which pauses the flight timer)
• “Message received” each time a MAVLink message is received,
• “Battery at 50%,”
• “Battery warning” when 25% is left,
• “Battery low” if the lowest cell voltage is below the [LowVx10] value,
• “Battery critical” if the lowest cell voltage is below the [CritVx10] value,
• “Battery failsafe” which repeats every [RepeatT] seconds if triggered,
• “EKF failsafe” which repeats every [RepeatT] seconds if triggered.
The parameters in brackets can be configured from the Taranis, and the sounds can be disabled altogether.

While the cable by itself works with official ArduCopter v3.2 and above, the interface requires flashing the Pixhawk with what is for now a modified Copter v3.3.1 RC1 firmware. The modified firmware still supports the legacy “Frsky D-PORT” and “Frsky S-PORT” protocols which have been available since v3.2 in the official firmware (if you set SERIAL2_PROTOCOL to “3” and “4” respectively) but a new Smart.Port protocol (named by C&T as "Frsky X-PORT”) has been introduced along with a number of code and bandwidth optimizations. Frsky X-PORT is activated by setting the parameter SERIAL2_PROTOCOL to “9.”

We sincerely hope this new protocol and related firmware modifications will soon become part of the official firmware. The modified ArduPilot v3.3.1 firmware (Copter-3.3 branch) is available here. See pull request #3186.

[Johnex]

@floaledm would be nice if you could compile the tricopter firmware, since it has some compile flags that are needed, its not possible to change to tricopter via settings from the quad firmware.

[floaledm]

@Johnex: Thanks for your feedback. The source Copter v3.3.1 would allow you to compile your own, but I've just added the tri configuration firmware for you convenience (along with other copter configurations). You can get it here.

[Johnex]

@floaledm really fast reply thanks :) i was mostly thinking about other people that have other aircraft apart from quads its all :)

[aldoir]

@floaledm Nice to see someone making this task possible, I always thought it was a waste having a processor in the middle only to convert messages to FrSky (the Teensy approach).

While I agree you can profit your work, I'm not willing to buy another RS232-TTL converter, international shipping and wait its arrival. How about providing only the software stuff for a reasonable price for those like me already have the hardware stuff working?

[CodeChief]

I think off the shelf hardware converters are okay because people can see what they do and decide whether to build their own depending on the complexity/effort/price.

But the software part should not become proprietary for open source hardware, so long as all it does is enable it to function fully/integrate properly. To be fair the people making money off hardware should remember they would not have a product at all if it wasn't for the existence of the open source system in the first place!

Nobody expects a commercial product to make it's additional tools free. But if they are not willing then somebody else in the community should (hopefully will) create and share a similar solution which enables the same functionality of the (open source) device.

[ptsneves]

@aldoir and @CodeChief It is true that the converter is wasteful. The problem is if we don't sell the converter we are forbidden by GPL of not releasing the code. There is no way around it. The only way of profiting of adding functionality for an open source is consulting, customizing or kickstarter style.

[aldoir]

@ptsneves I think you can/should release your work as a donationware, because if you don't, sooner or later people will make their own LUA script using your modified Ardupilot code and RS232 converter.

[ptsneves]

@aldoir Our converter and LUA is already open source. We would not even bother of having a donationware implementation of our converter. The problem is we need to spend resources doing that convertion with no way of getting our effort rewarded. What I thought is that we can create a kickstart with requirements laid out by the community to be implemented by us.

[aldoir]

@ptsneves I think I missed something. Your LUA script is the only part not open (password protected ZIP). Sooner or later people will make a script and release it publicly anyway.

Give people the option to buy the complete package (converter, pre-configured images) or a donation link to use your work.

[mpaperno]

@aldoir I think you're confusing different offerings from @ptsneves and @floaledm . Since when have GH issues become an advertising platform anyway?

[Johnex]

@aldoir
@ptsneves has made the opentx 2.1.3 compatible teensy telemetry solution and is totally open source, while @floaledm has made some changes to apm 3.3.1 adding the XPort protocol, with a lua script that is in the password protected zip and not open source and wants 25 dollars for it.
Clear? :)

To be honest i think @floaledm should open source the LUA script and still have the 25 dollar "bundle" for convenience. Seeing that @badzz worked really hard on making DPort and SPort native, and was working on XPort but hasn't had time to work on it on his free time, i'm guessing @floaledm probably checked out @badzz code. On the other hand LUA scripts for this have been available as well for the teensy, so @floaledm probably checked out that code also, but still wants money for his? :(

I don't think making money out of other ideas based on open source software is the way to go....

[lvale]

@Johnex
Last I've seen, there is no such thing as a XPort on FrSKy.
There is a DPort telemetry protocol and a SPort telemetry protocol, this XPort thing is an attempt to collage to the X series of receivers, but in fact is SPort.
@badzz has been maintaining the code for SPort and DPort and even rechecked everything before the Copter 3.3x release to verify if would still work with the latest OpenTX 2.1.x

[Johnex]

@lvale ok sorry, in that case then there is no real need for @floaledm code right?
With @badzz SPort i am not getting the FUEL value on the taranis, but it might just be one of the opentx bugs that will be fixed for 2.1.5. Do you have any plans to make your own native telemetry? I am free to help, i helped @chsw with a GPS speed bug and the high quality sound files.

[Johnex]

@lvale from what i understand SPort wasn't fully implemented, @badzz was working on it here: https://github.com/badzz/ardupilot/commit/a95794641204d44dd6a5229364e84327fb1b8f0a

[lvale]

Hi @Johnex,
Yes I remember you from when Christian and I were messing with the Teensy :).
The Teensy alternative has evolved and some of the people that used the original project have been busy and evolving the features and we've gathered all separate efforts on a single project still free and Open Source like the original here: https://github.com/Clooney82/MavLink_FrSkySPort.

[Johnex]

@lvale yeah i have been following that, but we all want to just have a Lua script + native APM telem output :(

[ptsneves]

@Johnex As I stated above in this issue the problem with the fuel variable is a bit deeper due to the IDs in the ardupilot code being the old 8bit IDs. So it is not a OpenTX problem but a Ardupilot code problem.

[lvale]

@Johnex
Sure that would be the best, but at the moment is what we have. Things might change in a not so distant future ;) in Ardupilot ;) Have in consideration that is extremely difficult to keep 2 OpenSource projects (ArduPilot and OpenTX) synchronized (that's what the Teensy tried to do).

IMHO I still believe that the Teensy solution is the most versatile option because as it "speaks" Mavlink can be made to evolve easily, and even add features like the single cell monitor and drive the WS2812 RGB Led's and that's only a starting point.

There is a future development that could be made to combine OSD and FrSky telemetry https://github.com/diydrones/alceosd and, again IMHO, this might be the best solution going forward.

[furynick]

@lvale I think you misunderstood what X-Port is. It's not a new FrSky Protocol, it's a specific implementation of S-Port and OpenTx telemetry. If you look at the 3.3.1 patched code you'll see le X-Port option send alphanumeric data (8 bit coded characters) down to OpenTx so MavLink warning messages can be displayed.
floaledm didn't rewrite the S-Port code so he had to find another name for option 9 of SERIALx_PROTOCOL.
The idea is really great but, as Johnex said it's a pity to try selling 25$ an enhanced opensource LUA and a cheap piece of hardware (less than 1$ per piece for 10 pack on banggood).

PS : the alceosd is also closed source for now, no schematic provided so no one can build it.

[lvale]

@furynick AlceOSD is evolving and have initial schematics here: https://sites.google.com/site/alceosd/hardware/schematics and the all important source code at ardupilot/alceosd

I'm sure that when the developer is satisfied with the hardware the full schematics will be released.

[Johnex]

@lvale @furynick Nick means this: https://github.com/craftandtheory/ardupilot/commit/5cde388e8563ce9f5b5f219c306493f87494f92b#diff-40b772973674c13102f11e540766a8e8R201

[Johnex]

@lvale i like the AlceOSD but its is huge compared to a Micro MinimOSD + an rs232 with it's diode.
I also use a DigiSpark Pro to control APA102 leds (next gen after WS2812):
https://dl.dropboxusercontent.com/u/6749621/__14.jpg
https://dl.dropboxusercontent.com/u/6749621/__15.jpg

So osd, leds, telem and storm32 all fit in the layer under the pixhawk, i haven't seen any drone body be able to have all that inside.

[lvale]

Although this is not the right place for this discussion, here goes:
Last I've seen the X series of receivers poll a pre determined list of ID's that correspond to sensors (this list is visible on the OpenTX code and is determined by FrSky, and I've already spoke with Bertrand about asking to extend the list of sensor ID's to accommodate some more that the ArduPilot team discussed and thought appropriate) What has been done so far is to encapsulate data on existing sensorID's.

[mpaperno]

At this point I have to publicly state that it seems I, and others, have unwittingly provided more than just "inspiration" for @floaledm and Craft & Theory's FrSky Telemetry Cable product.

C & T has, without permission or even prior notification, used my personal, unreleased, copyrighted material in their Lua scripts, UI design, and even some of the images which appeared in the product announcement above. Further, I believe they are in violation of the GPL which governs some/all of the code they used, by not publishing all the derived code/modifications in public, and not giving proper credit to people, myself and others, whose work they obviously incorporated. This includes the technique of sending/receiving alphanumeric plain-text messages via SPort->Taranis->Lua, among other things.

Besides obvious similarities based on the posted images, I have also seen their source code and have e-mail from @floaledm stating that my code was used. I was hoping we'd hear from @floaledm himself here by now. I contacted him shortly after he posted the announcement here. He did not try to hide the facts, and I believe it was misunderstanding which led to this and that he is working to fix the problem. He has obviously invested his own time bringing pieces together, documenting, etc, and I do not wish to detract from that. However I don't think ignorance of copyright law, licensing terms, or the basic value of someone's work is a good excuse.

Sorry for the interruption. If anyone wants more information feel free to contact me directly instead of cluttering this thread.

Sincerely,
-Maxim Paperno
World Design Group, Inc.

[lvale]

@Johnex
This https://github.com/diydrones/ardupilot/issues/1707 will make all this discussion pointless. Perhaps focusing on this PR would be better :) just my 2c

[Johnex]

@mpaperno May i ask, how did @floaledm get a hold of your unreleased code?

[mpaperno]

@Johnex I should have clarified that I meant publicly released/published. I had given a pre-release version in confidence to a couple friends for testing, and one of them had passed it on. I found out after the fact but didn't object because copyright and license terms were already clearly stated in the code comments/etc., and I thought it was clear that it was an unpublished project.

[mpaperno]

For anyone interested, the first implementation of transmitting "freeform" alphanumeric messages via SPort telemetry that I know of is here: https://github.com/scottflys/mavsky/ (the encoding/sending code is for a Teensy but is simple enough to adapt). The basic concept is simple enough: at the sender you stuff two chars at a time ((chA<<8) | chB) into an unused U16 telemetry value, for example RPM, then do the reverse in the Lua script. Works surprisingly well.

[Johnex]

@mpaperno well i hope @floaledm does the right thing and releases the code without cost. If not you can do an DMCA on his site and here on GH before releasing your code especially since you say you have written proof from him that he used your code and is making money from it without your consent.

[Johnex]

@mpaperno so @floaledm deleted his repo here with the LUA and removed the images on his site, but it is still available to buy.

[aldoir]

@Johnex The ardupilot fork was not deleted. Is it possible to someone merge his code to the main branch?

I'm available to create a GPL LUA script to display the information

[Johnex]

@aldoir yeah i forked his code, might have prevented him from deleting his branch? (I'm not sure how github works for that)

[CodeChief]

If you merge his code shouldn't it extend the existing SPort implementation? Because as we learnt it is not a protocol. To me it appears to be just a private rewrite of an existing solution, disregarding the current design. Two SPort modes/implementations don't make sense.

On the FrSky/OpenTX side it would be nice to see them define the extensions, rather than APM code "miss-using" fields (e.g. RPM as character stream). Maybe there is even some abstraction possible so that LUA scripts can deal with a greater list of telemetry data than particular hardware/protocol limitations.

Just thinking ahead, how it could be less stress for everyone and a better architecture... In theory so long as the transport and API are standard open source, there is nothing stopping somebody from designing lots of pretty "LUA controls" and selling them like apps in an app store. That would be fair (and all the basic stuff would be free of course).

So who should define the SPort extensions for use in OpenTX? I think the OpenTX project? In theory other flight controllers could then use the same controls.

Alternatively for an APM specific solution how about a MAVLINK bridge over SPort and LUA scripts/code to decode it. It might even be possible then (with code) to send it out the back of the transmitter (I see a reserved port in the battery tray of the Taranis) to share with other ground station devices. That would save a whole radio link, assuming it was not too slow.

Just throwing some ideas in there ☺

[lvale]

The sensorID definitions are controlled by FrSky. Without general purpose or "specific Mavlink" sensorID's the "miss-using" of sensorID's is going to continue.

[Johnex]

If i remember correctly @bsongis said that if anyone wanted to implement Mavlink into OpenTX it was ok by him, but the OpenTX team wouldn't do it.
Technically that would be the best option, have OpenTX load the Mavlink library so it can be updated easily, not have it just hacked in. Mavlink is superior to FrSky telemetry anyway.

I summon you master @bsongis Bertrand, could you voice yourself on this matter? :)
@rmackay9 Randy, could you voice yourself, what do you think about OpenTX parsing Mavlink?

[floaledm]

Hi Folks,
We appreciate your feedback. It has always been our intention to share our XPort implementation with the ardupilot community, and have already made a pull request for its inclusion #3186. You are free to make your own cable and user interface, and you are free to benefit from the several improvements provided in our XPort implementation at no cost. We sell a cable and display script for those who would like a ready-made solution. As @CodeChief points out, LUA scripts should very much be considered like apps.

[Johnex]

@floaledm @mpaperno still said you are using his code for the LUA script without permission. Yes LUA scripts can be sold if they are not using other peoples code in anyway way.

[bsongis]

@lvale @Johnex I still didn't have time to have a look at the IDs needed for Mavlink sensors in the S.Port protocol. But I got the OK from FrSky to reserve some ID ranges.

[Johnex]

@bsongis if you have time please take a look. you are one of my favorite project leads here on github, would be so sweet if you could work with @rmackay9 (another one of my favorites) to link ArduCopter and OpenTX together once and for all :)

[CodeChief]

@bsongis wow you must have a good contact... When I was looking for documentation about the FrSky SBus protocol it was like looking for rocking horse s..t. I could only find reverse engineered stuff. The impression was people were put off proactive integration with them because an NDA was required (according to the forums), that brings with it the expectation of $$$ required and no interest in open source (for most manufacturers). But getting that kind of feedback from whoever your contact is in FrSky sounds very promising.

Am I missing something about getting into FrSky development/docs access? If we can truly interact and help extend the sensor IDs that would be the perfect solution. The OpenTX and APM solutions could then use official extension/pass-through channels, perhaps prioritized down not to disturb the FrSky control signals (I'd guess that would be the manufacturer's main concern).

If the guy at FrSky needs justification, then tell him if we get good APM integration with FrSky then they can sell all their SPort sensors as 3DR alternative APM compatible sensors. That's pretty big deal I think ;-)

[R-Lefebvre]

Just a request. I often see the RPM message being hijacked to be used for other purposed. I would like to actually have this available for helicopters. :)

[lvale]

@R-Lefebvre
This is what we've asked a few months ago for supporting Mavlink. All the standard FrSky sensors would be free, such as RPM...

[Johnex]

@lvale i think APM version should be added to that list. Since the text wont be sent for an error, just an ID, it would be good for the LUA script on the other end to know which version of APM is running, to give a message to the user saying it's the wrong version or something like that. The errors are really the only thing that will be changed between APM versions, but also the one that could cause issues.

[lvale]

@Johnex
Error messages become irrelevant with this https://github.com/diydrones/ardupilot/issues/1707, and one those messages is already version

[Johnex]

@lvale i hope it doesn't get pushed back into the future once more then :(

[CodeChief]

When they implement it I hope they really make new IDs and names like the well thought-put list from @lvale. Because that GH issue/feature is explicitly labelled "error codes". Not that we end-up with an API where data is being sent using a mechanism which is really intended for something else (e.g. RPM for text). A clean design would satisfy exactly the requirement @Johnex stated = initialization message with version. Not an "error".

Call me fussy but you can't beat clean code as a primary concern, things get messy and hard to maintain so quickly otherwise.

[Johnex]

@CodeChief @lvale I think the best thing would be for OpenTX to give Mavlink its own sensors, dedicated for what we want, just like FrSky has. This way we can just modify the FrSky telem code to send the dedicated mavlink stuff for us, regardless of anything else in the APM code. I think using https://github.com/diydrones/ardupilot/issues/1707 for our purpose will just become another RPM and T1 T2 like we have now, things used not as intended.

[Johnex]

When @bsongis has time to check the list that @lvale posted above (including APM version so we can keep track of LUA scripts) then i think our problems will be solved. OpenTX will see the mavlink ID's that are reserved for their purpose, and we can fix some APM code to send out those id's from the different telem info we want. The two projects would also be relatively synced, as long as ID's dont change then we are golden. On the APM side, if we use a variable for battery for example that doesnt exist when Randy or another dev removes something, then they will have to update that part of the code for it to even compile, so no issues there either. Error text isn't hard to store in Lua scripts, and with the APM version number we can keep track of the codes for that APM version.

[lvale]

@Johnex @CodeChief Any input is welcome on #1707, although this has been discussed at lenght some months ago.

[lvale]

@CodeChief @Johnex Things have been moving on ArduPilot. First thing (we must start somewhere) that has been done is a revision of message severities on the entire Ardupilot branch

https://github.com/diydrones/ardupilot/pull/3118
https://github.com/diydrones/ardupilot/pull/3119
https://github.com/diydrones/ardupilot/pull/3120
https://github.com/diydrones/ardupilot/pull/3121
https://github.com/diydrones/ardupilot/pull/3122

Any help on the following steps is always welcome

[epquilloy]

looking forward for a freeware version of those scripts. Things are getting a lot better even with our native telemetry adapters

[aldoir]

I believe the stage we are with a working solution for the Ardupilot side, it would be nice if devs could merge this PR and let we work on the telemetry screen.

I understand the code is messed, but feature-wise and hardware-wise it's a complete solution. If in future devs have time to clean up the code and use appropriate IDs for each event we can update the telemetry code to read those events easily. Until that, let us use it as is, it's a huge step compared to what we have

[Johnex]

@aldoir @lvale already has started the ball rolling on the proper solution. I don't think merging something temporary is the way to go. It's already possible to compile the code above, if you want to use it :)

Better do it right and not have issues later.

[CodeChief]

Yes the first version does not have to wait. The remaining hurdle is to rewrite this as a simple extension to the existing protocol bridge (serial mode = SPort) rather than the proprietary "XPort" logic (not a new protocol and with license issues).

Separate to that it's clear we need:
1) Compatibility and mapping table of all OpenTX and MAVLink/APM telemetry/message IDs. Like an expanded lost of what @lvale already made.
2) Request OpenTX devs add new IDs for missing MAVLink messages.
3) Request APM add missing functionality, e.g. extetnal sensor input.
4) Lomg term: Consider a raw serial pass-through message, maybe in both directions (maybe drone could use GCS devices, e.g. ground GPS for RTK and ground AHRS for boat/platform takeoff and landing/ILS).

[floaledm]

XPort is GPL licensed, just like the rest of ArduPilot, and PR #3186 was created for inclusion of XPort in ArduPilot. @CodeChief is correct in pointing out that XPort is not an extension of SPort. One of the reasons XPort has not been made as an extension of SPort is that SPort reuses sensor IDs reserved by FrSky for existing FrSky sensors, and therefore SPort prevents the concurrent use of some of the FrSky sensors. XPort, on the other hand, allows any of the existing FrSky sensors to be connected to the Smart.Port bus because XPort does not reuse any reserved sensor IDs. Reusing reserved sensor IDs results in other limitations, including:

• OpenTX performs conversions on some of the sensor data fields (e.g., RPM), which forces conversions back and forth in both the onboard device sending Smart.Port data and the associated LUA scripts on the Taranis. In some cases, this also results in loss of usable bits or loss of precision.
• OpenTX does not provide the output of certain sensors unless all data fields for that sensor are received by the RC transmitter module in the proper format (e.g., as in the SPort implementation, 11 different GPS packets must be successfully received for the GPS data to be accessible to LUA scripts)

PR #3186 retains full compatibility with DPort and SPort, but introduces several novel improvements, including:

• Removal of one of the FrSky telemetry scheduler tasks (which proved to be unnecessary),
• Proper handling of the transfer of values from other parts of the ArduPilot code,
• Various code optimizations to reduce computational burden and memory usage,
• Transmission via FrSky telemetry of the actual content of MAVLink messages of type status_text,
• Transmission via FrSky telemetry of some the content of MAVLink messages of type system_status and ekf_status_report, which are normally used to display errors on Mission Planner's HUD,
• A number of bandwidth optimizations (including priority handling) which allow the HUD on the Taranis to refresh at a rate exceeding 24Hz, as shown in this video:
  

According to FrSky, the telemetry link's bandwidth is limited to 1200 bps, which is insufficient for transmission of raw MAVLink messages. Instead of sending raw MAVLink data over FrSky telemetry, XPort sends carefully selected and packetized subsets of data which are sent at different rates based on priority.

[furynick]

@floaledm : you said XPort does not reuse any reserved sensor IDs but as far as I know de S-Port Rx polls only certain ID so how can data be transferred if they're not polled ?

[lakeroe]

@floaledm: Futher up you wrote your cable is NOT compatible with the X4R receivers. I think that's just a mechanical issue (different connector). The software should work though, right ?

[floaledm]

@lakeroe That is correct. The difference with X4R receivers is the type of connector. Otherwise, the XPort protocol we introduced works with all S.Port Telemetry receivers (FrSky X series) including the X4R, X6R, and X8R.

[kilrah]

wow you must have a good contact... When I was looking for documentation about the FrSky SBus protocol it was like looking for rocking horse s..t. I could only find reverse engineered stuff. The impression was people were put off proactive integration with them because an NDA was required (according to the forums), that brings with it the expectation of $$$

Not at all, all you have to do is contact them with a description of your project and yes sign an NDA but that does not mean $$$. All it means is that they want to have direct contact with people who develop stuff for their system, which is fair and normal even if only precisely for the coordination of IDs that is causing trouble and to make sure you don't break compatibility with mistakes. By having an NDA you agree not to give the specs further, so that the next guy has to go ask them directly too.

By the way, having looked at a #3186 the smart port implementation in ardupilot is not correct, what you're doing currently is answering to multiple IDs requested by the receiver while you should only answer to one as it that ID is meant to differentiate physical devices on the bus, not logical data types. Ideally that ID should be configurable, with the default outside of the range of those used by existing sensors (where offical coordination with FrSky would be welcome, given there are only 28 IDs to choose from).

Last, I agree that @floaledm has nothing to be selling a script that is pretty obviously based on someone else's ideas and work. Sell the interface if you want, and provide a "convenient packaging" with all needed files and things to those who buy it, but they should be available as open source for others too.

[furynick]

@kilrah : I disagree your thought about smart port implementation, APM/Pixhawk IS different devices, it's a GPS (and answer to GPS ID), it's a Current Sensor (and answer to CS ID) and so on. In my mind FrSky ID differentiate device types, not physical ones.

[floaledm]

@kilrah: the FrSky library currently in ArduPilot uses the same method of operation as #3186.

[kilrah]

@kilrah: the FrSky library currently in ArduPilot uses the same method of operation as #3186.

I know, but that doesn't make it right :)

In my mind FrSky ID differentiate device types, not physical ones.

That's what is wrong. These "Physical IDs" are really only intended to differentiate physically different hardware devices connected to the bus, to avoid bus conflicts. The pixhawk should be responding for example only to ID 17, allowing you to also plug for example an FrSky current sensor that answers to the default ID of 2 on the same bus, then a 2nd one that has had its ID changed to 13, etc, you could even plug 2 pixhawks if you wanted where both have a different physical ID.

[furynick]

Does the S-Port protocol can handle devices with tens of values (GPS, vario, current, status for now so 17 values) ?

[kilrah]

It doesn't care how many there are, only one is sent at a time anyway. Get a request from the receiver -> send a value, next request -> next value... it doesn't care if it's the same or another. You rotate the items and decide how often to send which the way you want (which is already how it's currently done for each given ID).

[mpaperno]

@kilrah This is an interesting take which I haven't heard before. My strategy (a fairly common one it seems) has been to "simulate" the FrSky sensors (the ones that exist anyway). That way if, for example, someone plugs in a FAS sensor, my code (running on the FC) would detect that sensor on the bus and stop sending flight pack voltage/current readings. This has worked great and prevents duplicating data types "automatically."

I guess my question is, with your example of multiple Pixhawks on the bus using different IDs -- could they still be sending the same data types, eg. pack voltage which typically would come from a single FAS sensor?

Thanks,
-Max

[kilrah]

I guess my question is, with your example of multiple Pixhawks on the bus using different IDs -- could they still be sending the same data types, eg. pack voltage which typically would come from a single FAS sensor?

Yep, and they'd be seen as separate sensors by OpenTX 2.1.

Basically, the smart port protocol has:

• A physical ID, of which the purpose is originally only to arbitrate the bus (given multiple sensors are connected in parallel on the bus obviously each must have a unique ID, if 2 had the same when a request for that ID was sent by the receiver you'd have both sensors trying to answer together causing a bus conflict).
• A 16-bit data ID, which defines what kind of data is being sent in a given packet. They are organised in "blocks" of 16 as can be seen in

#define ALT_FIRST_ID              0x0100
#define ALT_LAST_ID               0x010f

This, from what we could understand, was how FrSky intended to differentiate multiple sensors (one would send an altitude as 0x100, another as 0x101 etc). Unfortunately either we have trouble understanding it correctly or their logic was just broken when they thought of it, because:

• There is no publically documented way of changing that last nibble on a sensor you bought
• They do not sell sensors with it set differently to allow for multi-sensor configurations that way
• Even if there was a way to change it it would be useless because as said earlier if you connect 2 identical sensors on the bus they must have different physical IDs (and there is a publically available method to change it), and that is already enough to differentiate sensors, nothing better than a unique number for that.

The last nibble of the data ID thus to me has only one purpose left, if a single physical sensor wanted to send several values of the same type. I don't believe there is any example of that in the wild at this point, FrSky even didn't use it for their own sensors, for sensors that send 2 temperatures they defined one Temp1 group of 16 and one Temp2 group of 16 instead of making use of the last nibble - which is why I consider they didn't know what they were doing when they thought of that thing.

So given that we designed the telemetry system in OpenTX 2.1 to use the physical ID as a differentiator. That allows for multi sensor configs with the publically documented and available ways. A "sensor" i.e. individual value in OpenTX is identified both by its physical ID and data ID.

That way if, for example, someone plugs in a FAS sensor, my code (running on the FC) would detect that sensor on the bus and stop sending flight pack voltage/current readings.

If done right they can have BOTH the data from the FAS and the pixhawk, which is even better - they could even put a FAS per motor if they wanted readings for each motor current :)

[mpaperno]

Thanks for the explanation Andre, that is very clear.

A "sensor" i.e. individual value in OpenTX is identified both by its physical ID and data ID.

OK so then this is a pretty major departure from how it worked in OTx < 2.1, right? A good one, don't get me wrong. (Sorry, I admit some ignorance about "recent" OTx developments.) But before 2.1, there was only one possible value per data ID, so it made more sense to simulate individual sensors. Under the new paradigm I totally see your point and it looks like a much better way to do it.

I also always wondered about those blocks of 16 IDs for each data type... never saw any code that actually used them. Nice to get some background on that.

-Max

[kilrah]

Yes, the main difference between 2.0 and 2.1 is that telemetry handling has been entirely refactored.

Excerpt from OpenTX 2.1 telemetry system preview:

The main improvement for OpenTX 2.1 and result of a few months of work is a complete rework of how telemetry is handled.
The existing system in 2.0 and older is based on 2 old systems that imposed too many limitations compared to what today's equipment is capable of:

• The FrSky D system, which assumed a "frozen" environment with a given number of sensor types and count
• The 9X and its limited resources that required telemetry handling to be optimized to that system and tightly nested with the display and menus to save memory, making it very rigid with any modification being complex, not evolutive at all.

In 2.0 the physical ID was indeed completely ignored, anything coming in with a given data ID would be fed into the one "slot" for that ID and that was it. Now we have a 32-item sensor table, when we receive something we look if we already know of a sensor with that physical ID / data ID pair, if yes we update it, else we create a new entry for it.

In the 2.0 context,

That way if, for example, someone plugs in a FAS sensor, my code (running on the FC) would detect that sensor on the bus and stop sending flight pack voltage/current readings.

was actually a very good idea :)

[CodeChief]

That sounds great. If I understood correctly we don't need any new "protocols" just to use a static ID (configurable for multi-FC scenarios) and separately extend OpenTX with new mappings for new data types (sent from the same ID).

I wonder how easy it is to add new types to OpenTX. Coordination of new features is of course necessary but then so were specific LUA scripts. I think both the version/initialization data and one or two generic values would help with forwards and backwards compatibility.

[kilrah]

That sounds great. If I understood correctly we don't need any new "protocols" just to use a static ID (configurable for multi-FC scenarios) and separately extend OpenTX with new mappings for new data types (sent from the same ID).

Basically yes. What would be ideal however is to have a way to select which messages are sent, not all are necessarily useful in a given config. A set of checkboxes and corresponding bitfield to choose whether each supported message is sent or not, with a few selectable default configs (granularity TBD, whether each element is individually selectable or just groups like power, GPS, status...) a bit like what I did when I fixed the smart port telemetry in cleanflight where I added skipping transmission of values for disabled features, originally everything used to always be sent.

That would replace the bogus "new protocol" concept @floaledm likely used not because the protocol is different, but rather as a way to select between sending his stuff or the normal set of values.

I wonder how easy it is to add new types to OpenTX. Coordination of new features is of course necessary but then so were specific LUA scripts. I think both the version/initialization data and one or two generic values would help with forwards and backwards compatibility.

It's very easy, that's one of the main reasons we refactored for. What's a little more tedious is coordination with FrSky, but it's quite important if we want long-term stability (the IDs @floaledm chose are free, but all it takes is for FrSky to decide to use them in a new product not being aware he already does, which we'd likely only learn about when their sensor is already on sale, and then have to change not to clash with them).

I know @bsongis disccussed a bit with them but I never followed closely and don't know what he asked for. My idea was to ask for something like 32 IDs (in FrSky's view i.e. 32 blocks of 16) that we would manage "efficiently" in OpenTX. The first 16 would serve for new values (actually more than 16 because we'd dump the the group concept for values where it is for sure useless). The 2nd block of 16 would be used for raw binary data transmission, allowing to gain a byte of payload per packet (the 2nd byte of the ID), which would be presented directly to the lua environment in a dedicated buffer. That would finally allow for real 2-way binary communication between radio and onboard system, and make things like running a lua mission planner equivalent including configuration menus possible on the radio.
So all stuff that is meaningful to the user (real, numerical telemetry values) would use the standard OpenTX telemetry and be available in the custom screens, voice output/logical switches as usual, while "special" things OpenTX can't really do anything with like status and config messages, ACKs etc would go straight to the lua environment instead of cluttering the telemetry system like in @floaledm 's current solution.
The concept has been pretty well defined in my mind for >1 year but I've never opened an issue on OpenTX for the implementation details given that it obviously required someone to support the same concept on the remote side and I never found a block of time in which I'd manage to tackle both ends together... it seems now you guys are interested it's a good time to move forward on this. Feel free to comment.

[Johnex]

@kilrah I think you wrote exactly what everyone in this thread has been wanting plus a lot more.
@projectkk2glider do you have any thoughts on this matter?

I think everyone that even planned on buying the 25 dollar script from @floaledm should instead donate the 25 dollars either to the OpenTX team or the APM team.

[Johnex]

@kilrah APM already has a sort of config for parameter groups, which to send or not. Depending on what port you use on the Pixhawk or APM (SR0, SR1, etc), you can set it to send that telemetry group at what frequency, or not to send it by setting it to 0. So the sport and dport code we have now just has to take those parameters into account, right now they are ignored (since sport needs a specific send frequency). So we can just have it that if for example SR1_EXT_STAT is bigger than 0, then send it.

SR1_EXT_STAT ( waypoints, GPS raw, fence data, current waypoint, etc )
SR1_EXTRA1 ( attitude and simulation state )
SR1_EXTRA2 ( VFR_Hud data )
SR1_EXTRA3 ( AHRS, Hardware Status, Wind )
SR1_POSITION ( location data )
SR1_RAW_SENS ( raw imu sensor data )
SR1_RC_CHAN ( radio input or radio output data )

[kilrah]

APM already has a sort of config for parameter groups, which to send or not.

Ah cool, didn't know. I admit I've never had any APM hardware and thus never really looked at the code/operation either...

So we can just have it that if for example SR1_EXT_STAT is bigger than 0, then send it.

I'd go with 0 = disabled, and >0 = how often _not_ to skip sending the group. E.g if SR1_EXT_STAT = 5, only include that that group in the send queue only once every 5 loops over the list of things to send. That way there's still some kind of prioritization possible.

[lvale]

@kilrah
Andre, I raised that issue on OpenTX dev meetings and at the time we came up with a list of "nice to have" telemetry data on OpenTX that I discussed then with @bsongis .

I'm happy to take up the subject again.

Regarding the SRx values, the grouping is already done on each, and the number is frequency that each group is sent, so I believe that it "covers" one of your requirements.

If you want/care to take a shot at the current "hacking" solution I'm sure the lead devs would appreciate
https://github.com/diydrones/ardupilot/tree/master/libraries/AP_Frsky_Telem

Please take in consideration that there is also a rationalization effort on the messages here : https://github.com/diydrones/ardupilot/issues/1707

[R-Lefebvre]

"I think everyone that even planned on buying the 25 dollar script from @floaledm should instead donate the 25 dollars either to the OpenTX team or the APM team."

I think the OpenTx guys could use the money much more than us. My understanding is these guys are still doing their work totally for free, which is just absolutely incredible given the number of radio manufacturers using the firmware. Especially FrSky.

[kilrah]

We do receive support from the manufacturers we work with, don't worry :)

[Johnex]

Either way i still think the money would have better use in either OpenTX or APM :)

[R-Lefebvre]

Ah, OK, that's good to hear. Comments I saw on RCG seemed to suggest otherwise. Not to hijack further.

[bsongis]

Thanks @kilrah for explaining the S.PORT protocol better than what I would have done!

Just a little precision, in their latest spec, FrSky introduced for their Powerbox some fields which are a concatenation of many fields (so they share the 4bytes transmitted in a frame). I started to add the support for these in the bsongis/sport_powerbox branch. I think it will be interesting for you as it will allow to reduce the needed bandwith (for example you could transmit the armed status in the same frame than the flight mode)

[epquilloy]

will this work with APM Plane 3.4 firmware on Pixhawk?

[epquilloy]

got it working on Arduplane firmware, renamed some flight modes in the telem lua script

[astrohome]

I was reading this discussion for a while, but after all the changes in OpenTX 2.1 and Ardupilot 3.3 I couldn't find an answer for my question: Why couldn't Pixhawk convert a Mavlink data to appropriate format to be sent?

Do we already have the solution which may send all the status messages without using Teenesy?

I am sorry if it's not a good place to post this kind of questions. Thank you in advance!

[kilrah]

Why couldn't Pixhawk convert a Mavlink data to appropriate format to be sent?

It can and already does for a lot of stuff, the remaining discussion regards the messages for which there is no equivalent in the FrSky protocol to convert them into (yet).

[astrohome]

It can and already does for a lot of stuff

My bad - the question was not correct. I meant "status messages and arming status" because "Mavlink data" is a way too generic.

there is no equivalent in the FrSky protocol

Ok, I see.
So basically, I could modify AP_FrSky_Telem.cpp to send the status messages ids + severity using (overriding native) let's say "RPM" if I don't need it?

[kilrah]

Sure you can - but the point here is precisely to "do it right" and avoid this kind of kludges.

[astrohome]

@kilrah Thank you a lot, it's clear for me now!

[dk7xe]

Was there any progress made during the past two months. E.g. Reservation of ID's by FrSky. What you guys have discussed sounds promising.. let's keep the momentum ;)

Is there anything the User community can help on? E.g. providing Pixhawk boards to OpenTX dev's for future code testing.

Im really interested in a "do right" solution being available. And like to help If possible.

cheers, Gerald

[lvale]

Still waiting for @bsongis
I'll ping him.

[floaledm]

@bsongis implemented the telemetry passthrough function in opentx/opentx#3326 and merged it into the "next" branch. @bsongis should confirm, but my understanding is that the function will become standard as of OpenTX 2.2.0. The passthrough function relays telemetry data sent within a given range of data IDs (0x5000 to 0x50ff). That raw telemetry data becomes accessible directly within lua scripts. @bsongis is waiting for confirmation from FrSky regarding the range of data IDs.

We helped test the passthrough function using pull request #3434. With OpenTX 2.2.0 and the modifications found in that pull request, anyone can easily make lua scripts to access an extensive amount of Pixhawk information using the newly created luaTelemetryPop() function.

[CodeChief]

Fantastic, all we need now for a dream is to mirror the piggybacked information out the reserved serial plug or JR module then we don't need separate telemetry radios anymore 😊 Or is that not likely due to some other limitation (always wondered how much like a real serial link the FrSky bidirectional communication was). Can't be worse than the SiK radios at 56k baud?

[R-Lefebvre]

It's much worse than the SiK radios at 56k baud.

The FrSky telmetry is 1200 baud.

[CodeChief]

Okay thanks for the scope correction... then we should be happy with some official APM LUA scripts ;-)

[thedevleon]

Sorry to hijack this, but what is the current status on this? Is the lua script by craftandtheory the only one I can use or is there something for free?

[kilrah]

There are other similar scripts posted at the beginning of this thread.

[thedevleon]

The link to the lua script in this post is sadly no longer working, neither is the one is this one. Can someone upload this one for me again please? @lakeroe @kilrah

[lvale]

@thedevleon It depends also on the OpenTX version...

[lakeroe]

@thedevleon
Would you mind to post an email address ?
I can send you the lua script then ...

[Johnex]

@lakeroe did you make a new script that works on APM v3.3.3?

[thedevleon]

@lakeroe would you mind messaging me on Gitter please? (Username is thedevleon as well.) I would prefer not to post my email publicly, if you understand.

[CodeChief]

What's the big secret with thses scripts? How about making a folder and pull request to some subdirectory of the APM source. I would expect this kind of support software to be available at firmware.diydrones.com where all the other add-on files are. Doesn't have to be on the OpenTX web site as their scope is to provide the hardware and protocol. APM team/comminity should own the APM specific stuff. Maybe it's easier that way? Please share the goods 😆

[furynick]

Perhaps this script is in development state and not suitable for "production" use.

[CodeChief]

Ok thought it would be organized the usual way, maybe an initial commit of "alpha" code then one or two users branch and play with it until the APM team think it's beta/testing quality (accept a pull back).

Maybe there are some open questions anyway that should be agreed in advance by the APM developers like where does this stuff all belong. Maybe just commit an empty directory stucture and let the guys know who do the web site that they need new menu items/icons/all that and a couple of new pages in the documentation.

Specifically I'd like to see all this magic "protocol" which some people think demands payment writen down in an "as-is" form (regardless of official FrSky protocol until that converges into an ideal mapping for all interesting APM parameters). Put right next to a summary if the OpenTX functions used to obtain the data plus snippets of code which document the pricipal of how the solution works. Like a "OpemTX Telemetry LUA Data Access & Display" introduction/quick reference.

Given a clear specification and sample scripts I don't think this is so hard anyway. OpenTX did the hard work building a system with simple text and graphics functions. Considering the complexity of APM itself I'm a bit annoyed that a some basic scripting is so hard to come by and being sold like it's so special.

[aldoir]

The point is the current S-Port implementation is very simple and is not working currectly (the VFAS variable doesn't work for example).

What Craft & Theory did was to write a new implementation using some "hacks" to transmit all the needed information to make a proper telemetry screen (including text messages, angles, etc). They're selling the script but they opened a pull request to merge their Ardupilot S-Port implemenation in the master branch. The pull request was denied because there is some talk about getting reserved IDs from FrSky to transmit the data.

But there is no progress on this "official" aproach and the C&T code is not accepted, and no other implementation is being worked on.

My suggestion would be to accept their implementation so we can work on a proper screen (I could do this job easily)

The point is: There is no way to make a proper telemetry screen with the current supplied information, we need to work on the ardupilot code first.

[thedevleon]

@aldor - actually there has been some recent development in the opentx next branch.
See https://github.com/opentx/opentx/pull/3326, https://github.com/opentx/opentx/pull/3426 and my current WIP PR for PX4 (https://github.com/PX4/Firmware/pull/4361) that implements those changes (along with a way of sending mavlink messages).

[aldoir]

@thedevleon glad to see there is an ongoing work on this feature. Subscribed for both and as soon it reach a more or less stable level will start to work on a telemetry screen (maybe joining your effort on the https://github.com/thedevleon/PixPilot)

[floaledm]

@aldoir is right. The rewrite of the FrSky lib in ArduPilot (#3434) unlocks unprecedented capabilities for telemetry screens. It leverages the recent developments @thedevleon is talking about. We actually tested/validated the OpenTX code before it was merged using that pull request (#3434). No SensorID/DataID problem, and no need for discovery… it’s essentially not a hack anymore, but the proper way to pass data using passthrough. The passthrough is accessible to any lua script. We’re happy to hold your scripts in our github repository with full license and authorship information.

We really enjoyed working with Bertrand and Andre at OpenTX to help getting the passthrough available in the next version. They did an amazing job. Please consider donating to OpenTX for their efforts. Everybody benefits from their great work and we should all support them so that they can keep providing new versions of OpenTX to the community. If you like something, it’s important to give back. http://www.open-tx.org/donations

[Johnex]

@floaledm you are totally right. I also hope your company donates some money from every script sold to all the wonderful devs that worked hard to make everything happen like Randy and Tridge and so on :)

[dk7xe]

donation http://www.open-tx.org/donations DONE. Since i'm also one of the demanding guys here i think we should give something back for the good work we receive for free.

[lakeroe]

@thedevleon
I don't know Gitter but please try to download the LUA scripts from here:
ftp://mmanner1:[email protected]/PixHawk.zip

They work using OpenTX V2.0.15.

[sandysoundy]

@lakeroe It asks for a username and password for those files... Can I please have access or suggest any other links?! I used to use a teensy for mavlink conversion but now I want to keep it simple. Coding is not my strongpoint and it is so hard to find these files!

EDIT: Nevermind, I tried it again and got the files. Cheers!

[athertop]

@floaledm - just a thought, but why not develop the code you currently merge into Ardupilot in your custom version (which produces your raw smartPort data feed), and make this run instead, on a small arduino board (like the pro-mini or teensy LC). This would replace your inverter in the cable connecting to the smartPort socket of the X series Rx... assuming you want to locate this on the air side... What this solution (call it your latest incredible product enhancement) would also provide, is a means of ground based conversion instead (of air based). So for example those of us using LRS solutions who can access mavlink on the ground would be able to run mission planner at the same time as have the mavlink data feed your converter and into the taranis smartPort to feed your cool telemetry screen.
You could open up a whole new market and also save the pain of having to integrate your code into Ardupilot. You would also have a universal solution which would work with any ground based Mavlink feed. For example, I am active in the UltimateLRS beta programme - we have a 19.2k Mavlink feed downlinked to a port in the back of our Tx module. I have taken the DIY teensy solution (https://github.com/Clooney82/MavLink_FrSkySPort) and allowed the teensy to be ground based taking that mavlink data feed, converting it to emulated smartPort sensors and feeding this diretly into the smartPort connection in the back of the Taranis radio (module bay). This (conventional) telemetry FrSky sensor data is then interpreted and using a telemetry LUA script this is displayed on a custom screen (not such a nice telemetry LUA screen as yours though). If you produced such a solution, I would certainly be interested as I know many more who would also. You could keep your solution closed source and you would not require any mods to AP. It would also work with PX4.
Worth a thought?

[CodeChief]

In the meantime many of the other popular 20$ FPV racer boards support FrSky telemetry without inverters. I read somewhere that a new OpenTX version will support serial pass-though and the receiver firmwares will support it. If that is true then it would be a waste of time to try to implement the same (then non-standard) protocol in parallel. I'd check with the OpenTX guys first then, maybe you just need to add some "piggy-back" code to ArduPilot instead of making your own protocol.

My preferred build is now no OSD because it's much better/compact/lightweight relying on telemetry. When you have an FrSky Lipo Voltage Sensor onboard you can also do the full per-cell monitoring too (previously one of the big selling points of the Teensy solution for me). It includes an OLED screen which is useful for pre-flight checks and is still much smaller than a Teensy and the crazy soldered resistor board you'd have to make to get cell monitoring. People who like OSD toys can still do that on bigger vehicles, at the ground station or just overlay later on their YouTube videos for an "augmented reality" type of black box analysis.

When you're flying you only really need occasional notices and critical alarms like low voltage/cells. Baud rate is not an issue then, if the packet logic is in the air and smart enough not to waste bandwidth. The current MAVLink method of non-contextual publisher-subscriber broadcasting is not going to work well unless you turn almost everything off and set updates super slow. Some "smart" new way of "subscribing" (i.e. not a subscription more of a ruleset) needs to replace it to achieve the efficiency required for low bandwidth RC serial downlink.

[floaledm]

@athertop Thanks for your suggestions! Looks like you've already got a working prototype which is exciting. Maybe you could blog about it so that others with a configuration similar to yours can do the same?

There's a number of reasons (some of which have already been discussed in this thread; CodeChief mentioned one more) why native FrSky telemetry is superior to MAVLink converters (whether in the air or on the ground) for those who want to display information on their RC transmitter instead of (or in addition to) having a ground station setup...

We've had great success working with the ArduPilot devs, appreciate their efforts and generally the opportunity to support ArduPilot.

[athertop]

@floaledm. My solution is actually one developed over a couple of years by a number of developers including Luis Value @lvale. I suspect it could possibly be in some way the inspiration for your product. Integrating the teensy solution with ULRS is already detailed in rc groups and the Ultimate LRS website features the solution with a link to the group post. The wiki on github also details the solution for ULRS integration.
I agree that native Frsky telemetry from the attopilot is a superior way to produce data, but the major con of this method is that it won't work unless you have Frsky X series tx/rx employed. ULRS v2 is kind of special in that it's the only LRS system available currently which provides a 19.2k dedicated data channel, and so this is adequate for fullly featured mavlink down and up linking. Given that there is only one data channel available we therefore need to choose whether we send mavlink or frsky telemetry over it. Of course we could enable option 10 to send data using your new protocol down to the tx, feeding this into the module bay s. port pin, and use your script to display that data - assuming that sensor polling is not required as we don't have it without an X series rx (or the teensy on the ground to look after this). The major drawback though is that we then are limited to having only frsky telemetry data feed at ground level. So no means if having mission planner. Or any other mission programming software hooked up without a second telemetry radio system.
My suggestion to you was to develop your own teensy solution to complement your standard solution. Looking at the way the LRS market is progressing I think there be a future market for it. In relation to your comments about mavlink converters, whether your code runs in ardupilot or on a teensy, it is still essentially acting as a mavlink converter! I am simply providing a suggestion for a means to have that conversion done on the ground (using your own code), then we have the ability to have both frsky (using your commercial solution) plus mavlink accessible at the ground, all over one LRS data connection - so fewer limitations than we have running your mavlink convertor code in AP. It's simply an option to extend your product and your audience.
Incidentally, I like the layout of your screen a lot but I would miss the radar screen in our current teensy solution. Maybe a product enhancement for your telemetry screen could be to allow a switch to alternate the display to switch the hud for the radar? Just an idea.

[floaledm]

@athertop Thanks again for taking the time to write about this and provide suggestions. One advantage of native FrSky telemetry is direct access to pretty much any ArduPilot variable, and as a matter of fact, the passthrough protocol outputs some data that is not accessible via MAVLink...

[CodeChief]

Yes even if MAVLink were the primary protocol it must be possible to send any sensor value as first class data, also evaluated in real time by the autopilot, no matter which cable it was received from (e.g. voltage from internal PixHawk ADC or external FrSky voltage sensor or cell monitor via FrSky cable/SPort/CAN/iBus/whatever).

A completely new standard protocol is most likely required. The guys at the ROS project built their message system around generic sensors and a message bus. If MAVLink2 were invented, it should have such principles at the centre of its architecture.

Best suggestion so far I saw was one spare MAVLink/FrSky message/slot containing the new v2 protocol, and the hard-coded messages (fixed to broadcast/subscriptions) being the v1 messages. That would be easy to filter/route and backwards compatible.

[sgofferj]

Just tried S.Port telemetry without success:

• Copter 3.4.3
• Serial -> TTL/RS232-converter -> FrSky SPC cable -> X8R
• SERIAL2_BAUD=57
• SERIAL2_PROTOCOL=4

Nothing arrives on the Taranis but the TTL/RS232 converter gets very hot. Tried another converter, also gets very hot. When I set SERIAL2_PROTOCOL to 3, still no data but the converter doesn't get hot anymore. Telemetry with a D4R works like a charm.

[sgofferj]

[sgofferj]

Not sure about the heat but I confirmed with a logic analyzer that nothing is sent when SERIAL_PROTOCOL is set to 4.

[lvale]

@sgofferj we can follow up this issue either on FB or discuss.ardupilot.org :)

[furynick]

@sgofferj : you have to use Serial1 instead of Serial2, I never get converter to work on Serial2 and always had success using Serial1

[furynick]

One detail, you didn't solder SPC module the right way, input and output must not be crossed.

[sgofferj]

Works now. Main issue was that I didn't consider that the RX requests the data, so without RX, no data were sent and the logic analyzer couldn't show anything. I'll post a blog about this soon.

[magicrub]

Are we ready to close this?

[athertop]

Depends on whether the C&T guys have completed all their commitments regarding documentation for their protocol - both from OTx side and also Ardupilot side. May be an idea to leave this issue open until they have.

[floaledm]

Seems like the topic has been extensively covered...

@athertop The related OpenTX code has been commented (and thus documented: luadoc) by Bertrand or by myself for OpenTX code contributed by C&T. For ArduPilot documentation, it's been submitted a little over a month ago and we're waiting for it to be merged: https://github.com/ArduPilot/ardupilot_wiki/pull/635

[robustini]

Doeas anyone has had random overheating problems of the RS232<->TTL converter?
I risked firing a VTOL in EPP, the converter has leaked part of the structure, LOL!
This issue is random, tested with "Fr-Sky X4RSB" receiver, sometimes it works, and others when i connect the mail power starts to heat up and obviously doesn't transmit anything to the Taranis.
The circuit with the two transistors and the five resistors I posted above always works.

[auturgy]

The max232/3232 inverts and level shifts the signal, but if you’re supplying both sides at 5v (as per the photo) it probably isn’t level shifting. Try cutting one or both of the 5v lines.
The Pixhawk uses 3.3v on the data lines but is 5v tolerant, so you just need to invert the signal. The rx uses 5v logic.

Regards,

James

On 27 Jan 2018, at 8:12 pm, Marco Robustini [e-mail] wrote:

Doeas anyone has had random overheating problems of the RS232-TTL converter?
I risked firing a VTOL in EPP, the converter has leaked part of the structure, LOL!
This issue is random, sometimes it works, and others just connect power starts to heat up.
The circuit with the two transistors and the five resistors I posted above always works.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[robustini]

Already tried with only the power to one side, same issue.
At the moment i put a 100 ohm resistor in series at the +VCC, and all work fine.

[epquilloy]

Doeas anyone has had random overheating problems of the RS232<->TTL converter?
I risked firing a VTOL in EPP, the converter has leaked part of the structure, LOL!
This issue is random, tested with "Fr-Sky X4RSB" receiver, sometimes it works, and others when i connect the mail power starts to heat up and obviously doesn't transmit anything to the Taranis.
The circuit with the two transistors and the five resistors I posted above always works.

Hi! I dont know if we use the same RS232-to-TTL module, but I did not have any overheating issues. I am still using the module like the one on my photo.