Frsky bidirectional telemetry implementation

I had some time to work on bidirectional telemetry and finally found a way to add COMMAND_LONG support.
For those interested in the details I had to create a minimal GCS_MAVLINK backend dedicated to frsky telemetry initialized with a dummy empty serial driver (this type of backend usually is tied to a FC serial port and handles all mavlink traffic between the vehicle and a GCS).

The equivalent mavlite structure for the mavlink COMMAND_LONG is:

  • 2 bytes for command id
  • 3 bits for parameters count (max 7 parameters)
  • 5 bits for confirmation counter
  • up to 7 parameters as 4 bytes floats

payload max size grows from 20 to 31

I do not blindly pass through all commands, right now I allow only


I also updated my FrskyLuaGCS script to support invoking command_long messages from my HORUS.

I updated my PR for bidirectional telemetry, the code is here

1 Like

@Eric_Stockenstrom I released a dev version of the Lua GCS, it’ here this version can send mavlite command long packets, I’m working on a simpler tool that just sends a specific command every couple seconds, it should make it simpler to work with the new mavlite command_long message.

Alex, I am playing with full camera control of a GoPro Hero 7 Black via Malvink, courtesy of @olliw42 Right now it is limited to only control via QGC but it looks like this could accommodate some basic camera control via Mavlink from the Horus.

Hi Marc, are you using a custom branch for your testing?
Do you have a list of the mavlink messages that you use to trigger camera control?

In order to use the mavlink control I do not even need a fork. All the autopilot is doing is relaying messages, so some extra ones need to be added to the common xml file:
(these are stable ones)
(I think these are WIP and not essential)

So I just paste these in to the common xml file and compile. Stable, Master, or whatever custom branch. I was hoping to be able to merge these but I cannot do this with submodules. The maintainer of mavlink in Ardupilot has basically ignored my requests to add the stable messages to the mavlink submodule. If it looks like we can use this in OpenTx I will directly ask Tridge to get them added – frankly I do not understand the point not merging stable Mavlink messages into Ardupilot.

@olliw42 has done some pretty fantastic work on this. At the moment it does requite a Storm32 board to handle these mavlink messages and an ESP32 to talk to a GoPro, but in theory an ESP32 could do it all if you were not doing gimbal stabilization. Rumor has it Olli is jetting a Jumper T16 Pro.

Right now it is just me an Olli on that thread on RCGroups.

Here is the same setup I have in action. I have a Storm32 micro board courtesy of Olli.

This may be too much info (you only asked for the Mavlink commands) but the ESP32 wifi stuff Olli has done is all in github.

Hi Marc, that’s a lot of information indeed :slight_smile:

Key aspects:

  • Ardupilot is only relaying messages from the GCS to the mavlink camera controller.
  • for the realy to work ardupilot needs to identify the messages so it requires an updated common.xml

I guess that QGC uses


to determine camera capabilities and then probably uses the camera microsystem commands to trigger image/video.

This is a very complex flow to replicate from OpenTX, so complex that misson planner has not even implemented it.

Anyway for this to work the frsky library would need to have access to the mavlink channel used by the FC to talk to the storm32 and read/write messages in that channel.
In ardupilot’s current implementation this is not easy at all.
Each vehicle has a GCS component which routes messages between the various mavlink channels created by reading the SERIAL_PROTOCOL settings. I could not find an easy way to read/write mavlink channels thru this GCS so I resorted to creating my own frsky mavlink backend.
Having a private backend let’s me process most of the messages locally but does not allow to talk with other devices via relay.

Handling this from ardupilot seems like a lot of work but it should be easier by going the MavToPT way.
The MavToPT firmware has acces to a real mavlink channel so it has native relay functionality provided the messages are targeted at the right ID.

@olliw42 does have this fully implemented in the daily build of QGC. I actually have just been testing this. It may not be feasible with OpenTX for reasons you describe. I am trying ti get my head around how MavToP would work since it does not have any UI component now – well I guess you can add switches or a button pad to the ESP2! Anyhow, I am pretty happy with what i have now actually as I can control a decent camera on longer flights. So I am not going to distract people with this just yet.

OpenTX would have the UI, via frsky would issue commands to mavToPt which in turn would issue mavlink to the target device

We would have to call a full committee meeting to even discuss that!

Hi Alex,

Happy New Year!

I am trying to understand the physical connections when using your bidirectional telemetry implementation with a Pixhawk 1 and FrSky X8R. Currently, I have the typical FrSky PassThrough setup as described in the Wiki along the the SBUS to RCIN connection for R/C control. This setup works great for Yaapu telemetry and your new mapping feature.

Are you using a bi-directional inverter as in Tridge’s FPort inplementation for F4 based FC boards?

One more question if I may, it seems the FPort implementation needs a receiver that supports the FPort protocol like X4R but your bidirectional telemetry implementation can work with an X8R. Is this correct?

Thanks and Cheers!

I was thinking about a pure lua based GUI.
With @Eric_Stockenstrom’s help we could build a full solution.
A lua based GCS would issue mavlite commands from opentx to the ESP32 via bidirectional frsky, the esp32 would convert mavlite to mavlink and forward to the FC. The FC would inspect the message and relay mavlink to the camera controller.

1 Like

Hi Greg, thanks, a Happy New Year to you too!

For bidirectional sport telemetry nothing special is required, if you have the yaapu telemetry script working you are all set.
Current master does not have bidirectional sport support, in order to test the feature you’d need to use my branch.

For fport you have 2 wiring choices:

  1. use RCIN on your board
  2. use a serial port with SERIALn_PROTOCOL = 23

Option 1 is oneway and only allows for RC control, it uses a full software serial implementation and tridge needs to extend it to be two way before we can have telemetry on it.

Option 2 allows both RC + telemetry on a single wire.
It’s two way but right now telemetry is one way only for I haven’t integrated my patches with the fport code.This option requires the very same options/adapters/inverters that are needed by sport, which options to use depend on the board capabilities. For an F4 board for example you still need an inverter ,check here for some examples.

Yes, for fport you need an fport capable receiver like the x4r.

For bidirectional sport X8R works just fine as well as any other sport capable receiver like the R9 series, xsr etc…

1 Like

The way you describe it makes it sound easy! (I was just being humorous…)

yaapuAlex Apostoli

@Eric_Stockenstrom I released a dev version of the Lua GCS, it’ here this version can send mavlite command long packets, I’m working on a simpler tool that just sends a specific command every couple seconds, it should make it simpler to work with the new mavlite command_long message.

Nice work Alex ! Impressive. I have some time to get into this again. Could you let me know when the new tool is ready?

Hi Eric,
this should help in testing the command long functionality (17.8 KB)

it sends MAV_CMD_PREFLIGHT_CALIBRATION #241 as a mavlite COMMAND_LONG by using

  • 2 bytes for command id (241)
  • 3 bits for parameters count, (3)
  • 5 bits for confirmation counter, (0)
  • 3 parameters as 4 bytes floats (0, 0, 1)


1 Like

Hi Alex, good to hear from you. :slightly_smiling_face:

Thanks for this. I have to admit that I have not gotten down to this properly yet. My intentions are good, but life has been getting in the way!

Hi Eric, lately I’m fighting with bidirectional fport :slight_smile:

…and life tends to get in the way here too :+1:

fport looks like a great idea, and I expect we can’t avoid it.

please any one tell me how can i add some values to SERIAL1_PROTOCOL v in full parameter list

Is it tends to be possible connect r9m to mobile device and control vehicle over qgroundcontrol via telemetry?