Enhancement: Add MavLink->FrSky Telemetry conversion (LoS Telemetry)

[careyer]

Dear Rodizio,

yesterday a useful idea came to my mind: I use EZ-WBC not only as a pure videodownlink solution but also to control all of my models via MavLink uplink (you know me as an EZ-WBC embasador by heart ;-). It works perfectly! However I do not perform each and every flight by means of FPV and also fly line of sight quite a lot.
But replacing the ordinary (telemetry enabled) RC-receiver with EZ-WBC yet has a big disadvantage: Without video-googles or HDMI monitor there is no way to see crucial telemetry data. (Battery voltage, height, distance, ...)

Here is my idea:
Would it be possible to add a MavLink->FrSky Protocol conversion to the GroundPi? There are lots of open source projects that do something similar. Most of them feed the MavLink telemetry stream from the FC into a Arduino/Teensy, parse the MavLink Protocol there, convert it to FrSky protocol and feed it to the Smart-Port (telemetry port) of a FrSky Receiver. From there the telemetry gets transmitted back to the ground and is displayed on the transmitters' display.
Here is the by far most popular solution: https://github.com/Clooney82/MavLink_FrSkySPort/wiki
(It works flawlessly with all APM, Pixhawk and PX4 based flight controllers).

Why FrSky? Among the OpenTX capable radios the FrSky transmitters (especially the Taranis lineup) has become the de-facto standard for RC hobbyists. They offer by far the best Price/performance ratio and you see them really everywhere nowadays.

Now lets assume that today MavLink is parsed at the GroundPi anyways (i.e. to render telemetry data for the OSD). Would it be possible to take this data and make a FrSky protcol out of it (The FrSky protocol is very well documented and most likely parts of the above project - especially the FrSky protocol generation - can be reused)? The GroundPi could then output this protocol at its' serialport and feed it to e.g. the module bay of a Taranis transmitter.

This would make for a perfect telemetry solution directly displayed on the transmitter - very much similar (or even better) to the Mavic Pro Controller. Now one can fly line of sight with comfort also without the need to setup all the video receiving gear.

I think this would be a great extension of the already ingenious solution and would be very welcome by the community. What do you guys think about it?

Best regards
Thomas

[rodizio1]

It's certainly possible, but a lot of work. And I don't have a Taranis for testing (actually, I sold it because I never used all the bells and whistles :)).

Wouldn't it be more straightforward to just send the Mavlink data to the Taranis and parse it there?

It seems there is work being done on that, but not sure of it's state:
opentx/opentx#5600

[careyer]

Thank you very much for your timely answer Rodizio. I am sad to hear that you have sold your Taranis. Indeed it can be a bit intimidating with all of it's features and I believe that only few people take full advantage of the functionality of this radio. However due to its excellent price/performance ratio it has become the de-facto standard for most pilots - i.e. it can do so much more than all the Graupner, Spectrum and Co. branded radios that cost double or triple the price.
It is especially popular among DIY builders because it is very flexible and hence very well suited for controlling full blown FCs like Ardupilot/Pixhawk (which all do MavLink btw ;-)).

Since EZ-WBC also targets the DIY builder it might be worth considering supporting this feature in an upcoming version?

Thank you for the link you provided. That indeed looks interesting. However compute resources on the Taranis micro controller seems to be a bottleneck here. The developer reports crashes when much data is being processed. On the contrary the GroundPi has plenty of spare compute power left. I tried the https://github.com/Clooney82/MavLink_FrSkySPort/wiki solution and it works flawlessly right out of the box. Maybe instead of re-coding everything from scratch, can you adapt the code for running on the Pi?
MavLink parsing and FrSky Encoding is readily available in the codebase of that project. But beware - I am a noob when it comes to coding and programming. But I am happy to assist anytime for testing.

BTW: Taranis and WBC bend very well :-) (Flying non of my models with regular RC-receivers anymore)
...

[Yes21]

I agree with this feature request.
I'm using Yaapu telemetry script with my Taranis X9E and a rs232 <-> ttl converter connected on my X8R. That's working like a charm.
But because the groundPi can't send Frsky telemetry directly to my Taranis, I'm obliged to preserve my X8R and can't use wbc RC. So I've to keep my Taranis/X8R in 2.4Ghz for RC, and ez-wbc in 5.8Ghz for video and telemetry.

[dposea]

Ardupilot was recently updated to send FrSky passthru data. I need to think about this more but it should be possible to use that or the FrSky data used for FrSky to Mavlink to make this work. Do you want data sent to the recievers telemetry port, assuming its taranis telemetry capable?

[dposea]

assuming the frsky data can be sent out a serial port there is an s.port connection on the taranis controller. I'm not positive but it may be possible to send the data directly to the controller bypassing the need for a receiver. The LUA script or open_tx may need updating to read the s.port data from the connector rather than data sent from a receiver. I can take a look. I have open_tx source somewhere.

[careyer]

This would be swesome! The original idea was to convert MAVlink->FrSky in the GroundPi (since it has lots of spare CPU power).

Now as far as I understand your idea is to command the Flight Controller to directly send Frky alongside MAVlink, right? Would that FrSky data travel encapsulated inside the MAVlink data or would that require a dedicated stream of data?
If this needs additional bandwidth we should maybe stick with the first idea because that does not require additional bandwidth and is also a bit more universal. It will also work with PX4 for example. and such not exclusively on ArduPilot. What do you think?

[dposea]

I was thinking it would be sent via serial port on the ground pi to the tanks directly. I'm not sure yet what would get sent mavlink or frsky. I think mavlink converted to frsky, which is already done in frsky passthru. We can use that code if necessary so all we really need to find out is where open_tx reads telemetry and can it read from the s.port on the taranis instead. Oh, we may need a converter to convert groundpi serial to s.port. you need a max2232 chip and a diode, under $5. We may not need that if the rpi uart can invert.

[Yes21]

FrSky telemetry is now only possible with an FrSky reciever (X6R, X8R, ...) and a FrSky RC (X9D, X9E, Horus, ...). A special wire with a RS232<->TTL converter is connected between a serial port of a PiwHawck (Passthrough FrSky Telemetry protocol) and the smartport of the X8R reciever. This allows to have all telemetry on the RC screen with a lua script like https://github.com/yaapu/FrskyTelemetryScript.

When one choose to use wifibroadcast RC, he can't anymore have FrSky telemetry on his Taranis.

It would be awesome if somebody could find a way to generate FrSky telemetry from Mavlink on the groudPi, and to send it to the RC usb ports.

[RespawnDespair]

I have no need for this, but i can see how it would be useful.
The problem is as stated by @dposea that the s.port on the Taranis expects and 'inverted' TTL signal.
@careyer The project you mentioned in your first post uses an Arduino to take a Mavlink serial stream and outputs a FrSky s.port stream, so that's exactly what we want isn't it?
Just let the GND Pi forward the mavlink to the serial port, attach the arduino (with the software from your first post), hook it up to the Taranis, no modifications needed on EZ-WFB.
Or am i missing some crucial consideration?

Edit: development seems to have moved to: https://github.com/yaapu/FrskyTelemetryScript

[Yes21]

The Arduino solution works with the smartport of a FrSky reciever.
With wifibroadcast RC, we haven't anymore a FrSky reciever.
So I'm almost sure that the only solution would be to convert Mavlink to FrSky telemetry on the groundPi, and send it to the Taranis trough usb.
Then we'll have to check (or ask for) that the lua scripts running onto the Taranis are able to read the FrSky telemetry from usb.

[careyer]

@RespawnDespair : Yes! Essentially we would need a solution to turn MAVlink telemetry (which is present at the GroundPi anways) into FrSky s.port and pipe this into the Taranis TX. That is exactly what the project I mentioned in the first post does. It was developed to accomplish the following:

FC (Mavlink) --> (MavLink) Arduino (s.port) --> FrSky RX (s.port) --> FrSky Radio link --> FrySky TX --> Taranis Display.

Now it would be awesome if we could accomplish this without additional hardware and wiring because the GroundPi should easily be able to convert Mavlink into s.port directly (it hardly uses any CPU power anyways). This would be the right way to do it:

FC (Mavlink) --> AirPi --> EZ-WBC radio Link --> GroundPi (Mavlink 2 s.port) --> Taranis Display

So essentially this would require to port the Arduino code from above project to the GroundPi.
Hopefully I explained it in a way that you guys can follow?

[RespawnDespair]

I think i understand, but taking a step back i think the following:

• It is not possible to generate 'real' s.port without additional hardware (the TTL levels are inverted, the Pi cannot achieve this without additional components)
• If we cannot send real s.port into the Taranis (because we want to limit the hardware) why not send mavlink data and rewrite the lua scripts on the Taranis to interpret mavlink data directly?

Am i wrong in my reasoning? Is it possible to recieve real s.port in a Taranis without an s.port reciever? As @Yes21 mentioned? Maybe the 'direct' mavlink approach would be suitable for a wider audience?

[careyer]

@RespawnDespair : Brilliant Idea! Interpreting MAVlink via a LUA script directly inside the Taranis would totally make a whole lot of sense. Just wondering how we can feed the Mavlink data into Taranis? Is there a serial port on it somewhere?

[Yes21]

If we decide to do it with a lua script, the better script I kow is this one. The developer (@yapuu) is very active and cooperative.
Perhaps we could contact him, and explain him our project ?

I don't feel myself to be able to explain all that things to him :-(

[careyer]

Food idea :-) Maybe he could help or even contribute. That would be awesome. Von meinem iPhone gesendet

…

Am 31.10.2018 um 21:11 schrieb Yes21 ***@***.***>: If we decide to do it with a lua script, the better script I kow is this one. The developer ***@***.***) is very active and cooperative. Perhaps we could contact him, and explain him our project ? I don't feel myself to be able to explain all that things to him :-( — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[Yes21]

I've contacted @yapuu. Here is his answer :

Hi,
to recap you have mavlink on the ground and you're asking for a good way to have frsky telemetry out of mavlink. Ideally this could be done in the RPi, technically is easy but the timing is critical, an frsky receiver is not necessary for polling can be simulated, just take into account that for a decent telemetry bandwidth you would need to send an frsky packet every 25ms, in that time window you would have to do full mavlink 2 decoding and parsing, By using an external converter you offload the RPi from doing it,
a well tested option that I actively collaborate with is

https://github.com/zs6buj/MavlinkToPassthru

Eric,
the author of that project is an EZWifibroadcast user, his converter firmware produces full frsky passthrough telemetry on the ground even without an frsky receiver.

The setup you are looking for is named "ground mode" in the project's wiki

The converter can work in one of three modes: Ground_Mode, Air_Mode or Relay_Mode

Ground_Mode In ground mode, it is located in the back of the Taranis. Since there is no FrSky
receiver to provide sensor polling, we create a routine in the firmware to emulate FrSky receiver
sensor polling. (It pretends to be a receiver for polling purposes). Un-comment this line #define
Ground_Mode like this.

[Yes21]

@careyer Why did you close this issue ?
The subject is always pending, and it could be a great improvement.

[careyer]

@yves: I am reverting things to be in the same state that it was before I contributed just bullshit and being a harm to the project. Thanks for asking. Von meinem iPhone gesendet

…

Am 23.11.2018 um 17:58 schrieb Yes21 ***@***.***>: @careyer Why did you close this issue ? The subject is always pending, and it could be a great improvement. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.