Thread Tools
Jun 07, 2018, 08:01 AM
Registered User
Thread OP
Discussion

Mavlink To FrSky Passthrough Converter


Welcome to the MavlinkToPassthru (Mav2PT) discussion thread

This thread was created for anyone building or planning to build the Mavlink To Frsky Passthru converter.

The GitHub project is here and the wiki is here

This page updated 2019-09-06

VERSION 1.00 RELEASED
VERSION 2.00 BETA. Unified source for different boards. ESP32 board supports WiFi, Bluetooth

What is Mav2Passthru, and why do I need it?
  • Mav2PT is firmware to convert Mavlink telemetry to FrSky _Passthru_ telemetry.
  • Passthru is the name given to the FrSky compatible telemetry protocol characterised as "DIY", or non-proprietary.
  • Passthru protocol telemetry is the only telemetry that works with yaapu (Alex Apostoli)'s excellent LUA display
    scripts for the Taranis and Horus transmitters. See yaapu's GitHub
  • Passthru protocol telemetry is required for Craft & Theory's FlightDeck
  • Passthru protocol telemetry is optional (type=10) on Ardupilot, but not supported by the PX4 flight stack (as at July 2019). The older APM 5.2 flight controllers, and the Radiolink Mini Pix do not support Passthru (as at July 2019)
  • Many medium and long range telemetry / command radio systems support Mavlink, but not Passthru (as at July 2019)
  • Mav2PT firmware running in a micro-controller converts Mavlink (1 & 2) telemetry to Passthru telemetry

Mav2PT can be configured to run in one of three modes:

Ground Mode

In ground mode, the Mav2PT converter is usually co-located with a long-range XJT radio long-range module in the back bay of the Taranis/Horus. It accepts Mavlink telemetry from the XJT module, converts it into Passthru protocol
telemetry, and feeds that into the S.Port of the Taranis/Horus. Since there is no FrSky receiver to provide sensor polling, a routine in the firmware emulates FrSky receiver sensor polling.

Air Mode

In air mode, the Mav2PT converter is located on the aircraft between the Flight Controller and a FrSky receiver. It converts Mavlink out of a Pixhawk or APM flight controller and feeds Passthru telemetry to the FrSky receiver, which in turn sends it to a Taranis/Horus on the ground. In this situation it responds to the FrSky receiver's sensor polling. This mode is necessary for older Arducopter and PX4 flight controllers which cannot natively send Passthru telemetry.

Relay Mode

This hybrid mode is useful where an air-side LRS tranceiver (trx) (lDragonLink , RDF900 , Orange..) communicates with a matching ground-side trx located in a "relay" box near using Mavlink telemetry. The UHF trx in the relay box feeds Mavlink telemetry into the Mav2PT converter, and the converter in turn feeds FrSky Passthru telemetry into a FrSky receiver (like an XSR), also located in the relay box. The XSR receiver (actually a transceiver - trx) then communicates on the RC band with a Taranis/Horus nearby. In these circumstances the converter need not emulate sensor polling, as the FrSky receiver will provide it. However, the converter must determine the true RSSI of the air link and forward it, as the RSSI forwarded by the FrSky receiver in the relay box will incorrectly be that of the short terrestrial link from the relay box to the Taranis.

Suitable uController Boards

The Mav2PT firmware is configurable to run on three broad platforms:
  1. ESP32 Dev board and other variants
    This is the most powerful platform, with snappy performance and rich features including an OLED display, WiFi and Bluetooth I/O and SD card support. It is slightly more costly, and physically larger. Includes S.PORT inversion, but still requires an external converter to single-wire for S.Port compatibility.
    The board used for this project is described as "Official DOIT ESP32 Development Board" and has 30 pins. See here. I have seen variants with the same or similar descriptions advertised on-line, with widely differing prices and quality. Pin counts varying from 28 to 38 as the board maker may choose to exposed more or fewer pins of the embedded SOC. Remarkably all the ones I have bought have worked. Physical pin markings vary according to the whims of the board makers, but the numbering generally relates back to the Espressif SOC's GPIO numbers.
  2. Teensy 3.1 or 3.2
    Fairly snappy performance in a very compact board. Less affordable that the STMF103C boards. Includes S.PORT inversion and single-wire S.Port conversion.
  3. STM32F103C variants like Blue Pill and Maple Mini
    Acceptable performance and affordable, in a slightly larger format. Requires a bi-directional inverter/single-wire converter for S.Port compatibility.

NOTE: 16 bit AVR boards like the Mini Pro, and even the ATmega boards are not recommended for this application.


Connections to ESP32 Dev Board are: (Pin numbers equate to GPIO numbers)
Code:
   0) USB           UART0                   Flashing and serial monitor for debug
   1) SPort S       UART1   <--rx1 Pin 12   Already inverted, S.Port in from single-wire combiner from XSR or Taranis bay, bottom pin
   2)               UART1   -->tx1 Pin 14   Already inverted, S.Port out to single-wire combiner to XSR or Taranis bay, bottom pin             
   3) Mavlink       UART2   <--rx2 Pin 16   Mavlink source to ESP32 - FC_Mav_rxPin
   4)               UART2   -->tx2 Pin 17   Mavlink source from ESP32 
   5) MavStatusLed                 Pin 02   BoardLed   
   6) BufStatusLed                 Pin 13   Buffer overflow indication 
   7) startWiFiPin                 Pin 15   Optional - Ground to start WiFi of see #defined option      
   
   8) I2C/SDA                      Pin 21   For optional OLED Display 
   9) I2C/SCL                      Pin 22   For optional OLED Display 
   
  10) SPI/CS                       Pin 05   For optional TF/SD Card Adapter
  11) SPI/MOSI                     Pin 23   For optional TF/SD Card Adapter
  12) SPI/MISO                     Pin 19   For optional TF/SD Card Adapter
  13) SPI/SCK                      Pin 18   For optional TF/SD Card Adapter  
  
  14) Vcc 3.3V !
  15) GND

Connections to Teensy3.2 are:
Code:
    0) USB                         Flashing and serial monitor for debug
    1) SPort S     -->tx1 Pin 1    S.Port out to XSR  or Taranis bay, bottom pin
    2) Mavlink_In  <--rx2 Pin 9    Mavlink source to Teensy - FC_Mav_rxPin
    3) Mavlink_In  -->tx2 Pin 10   Mavlink source to Taranis
    4) Mavlink_Out <--rx3 Pin 7    Optional feature - see #defined
    5) Mavlink_Out -->tx3 Pin 8    Optional feature - see #defined
    6) MavStatusLed       Pin 13   BoardLed
    7) BufStatusLed  1
    8) Vcc 3.3V !
    9)
Connections to Blue Pill STM32F103C are:

0) USB/TTL UART0 -->tx1 Pin A9 Flashing and serial monitor for debug
0) USB/TTL UART0 -->rx1 Pin A10

1) SPort S UART1 -->tx2 Pin A2 Serial1 to inverter, convert to single wire then to S.Port
2) SPort S UART1 <--rx2 Pin A3 Serial1 To inverter, convert to single wire then to S.Port
3) Mavlink_In UART2 <--rx3 Pin B11 Serial2 Mavlink source to STM32 - FC_Mav_rxPin
4) Mavlink_In UART2 -->tx3 Pin B10 Serial2 Mavlink source STM32
5) MavStatusLed Pin C13 BoardLed
6) BufStatusLed Pin C14
7) Vcc 3.3V !
8) [/code]

Connections to Maple Mini STM32F103C are:
Code:
    0) USB                          Flashing and serial monitor for debug
    1) SPort S     -->tx1 Pin A10   Serial1 to inverter, convert to single wire then to S.Port
    2) SPort S     <--rx1 Pin A9    Serial1 To inverter, convert to single wire then to S.Port
    3) Mavlink_In  <--rx2 Pin A3    8  Serial2 Mavlink source to STM32 - FC_Mav_rxPin  
    4) Mavlink_In  -->tx2 Pin A2       Serial2 Mavlink from STM32 
    5) MavStatusLed       Pin B1    33     
    6) BufStatusLed       Pin       34 
    7) Vcc 3.3V !
    8)
Importance of RSSI

The LUA scripts from yaapu and Craft and Theory (FlightDeck), running on a Taranis or similar TX, expect to receive a regular telemetry frame reporting adequate RSSI (rf signal strength). In the absence of such a frame, the Taranis reports "Telemetry Lost".

This converter receives the RSSI information from the Flight Computer via Mavlink telemetry, and creates a Frsky sensor frame type 0xF101 for the Taranis and LUA script to interpret. This must be done at a frequency less than 1Hz to be effective.

Mav2Passthru supports three popular methods of determining RSSI

1. Receiver protocol - the RSSI is embedded in the FrSky sensor telemetry - default.
2. A designated RC PWM channel. ULRS, QLRS and some other long-range telemetry systems use a configuration tool to
designate an unused RC channel that carries the RSSI value.
3. SiK telemetry modems, and long-range systems like RFD900x that use the SiK firmware, inject a special RSSI record into
the Mavlink telemetry carried by the system.

Before compiling and flashing Mav2Passthru, select the RSSI source by un-commenting the applicable line of code

Code:
#define RSSI_Source         0         // default FrSky receiver

//#define RSSI_Source         1         // designated RC PWM channel - ULRS, QLRS....

#define RSSI_Source         2         // frame #109 injected by SiK radio firmware into Mavlink stream - `

//#define RSSI_Source         3         // Dummy RSSI - fixed at 70% - use for debugging only
Note that in Relay_Mode, two RSSI instances are reported:
1. The RSSI of the received signal at the aircraft - instance 28
2. The RSSI of the Taranis/Horus signal received at the relaying FrSky receiver (say XSR) - instance 25

Normally you would want 1. above to be reported on your transmitter screen, and not be particularly interested in 2.
Delete all sensors on your Taranis/Horus, then discover new sensors. Be sure to un-tick "Ignore Instances". Two instances, as per 1. and 2. should be discovered for RSSI. Use OpenTX to delete instance 25.

OLED Display

The ESP32 version of MAV2PT supports a 0.96" OLED display module

This particular display module receives data through the 2 wire I2C bus, as opposed to some alternative ESP32 boards which already have 4 pin SPI driven displays. Either type should work, but some changes to the Adafruit_SSD1306 library would be required.

The SDA and SCL pins are wired to the ESP32 Dev Board default I2C pins 21 and 22, plus VCC (3.3V) and GND. If you have a different ESP32 board, look for the default I2C pins on the schematic diagram.

Using the Adafruit_SSD1306 library, MAV2PT displays general status information in 21 characters x 8 scrolling lines:


Last edited by zs6buj; Sep 06, 2019 at 07:57 AM.
Sign up now
to remove ads between posts
Jun 07, 2018, 10:19 AM
Registered User
So glad you created this thread. Brilliant project.

I have posted in the DL thread to request the simple firmware mod required so all Dragon Link v3 users can use your project.

Can this work passively using only the TX line? I understand that you are also grabbing the battery capacity from the autopilot. Is this why we need to connect to the RX so we can communicate with the autopilot? Can this value be input directly into the LUA on the LUA setup screen.
Last edited by Marc Dornan; Jun 07, 2018 at 10:32 AM.
Jun 07, 2018, 11:15 AM
Registered User
Thread OP
Quote:
Originally Posted by Marc Dornan
So glad you created this thread. Brilliant project.

I have posted in the DL thread to request the simple firmware mod required so all Dragon Link v3 users can use your project.

Can this work passively using only the TX line? I understand that you are also grabbing the battery capacity from the autopilot. Is this why we need to connect to the RX so we can communicate with the autopilot? Can this value be input directly into the LUA on the LUA setup screen.
Hi Marc, thanks for the kind words. Yes you can use the TX in passive mode, and yes I use Teensy TX to Orange RX to request battery capacity parameters.

Yes, the mAh can be input directly into the LUA.

This simple bi-directional inverter to single-wire S.Port converter works well for me (revised Feb 2019):





Example of the Taranis display:



Below is a close up of the Teensy 3.2 wiring:




Below is the final wiring diagram for GROUND-SIDE version. The BlueTooth module is optional, of course [/CENTER]







Below is the wiring diagram for AIR-SIDE version:



Below is the wiring for testing the HC-05 BlueTooth module. Note the elegant 433MHz "dummy load" antenna



The little black blob on the red wire from the Taranis 8.4v supply is a small 7805 linear regulator to feed 5v to the HC-06.



Here is final alternative 5v wiring option

[

Last edited by zs6buj; Sep 06, 2019 at 06:41 AM.
Jun 07, 2018, 12:21 PM
KD2PBU - Fly No Evil
davidbitton's Avatar
Is this the same protocol that the Craft&Theory code runs against?
Jun 07, 2018, 02:49 PM
RC fanatic
Quote:
Originally Posted by davidbitton
Is this the same protocol that the Craft&Theory code runs against?
I hope I can do this answer justice! The passthru protocol is indeed the same one that was developed by C&T. It is actually integrated within the Ardupilot code now, and also inside the LUA interpreter of OpenTx 2.2, such that by setting SERIALx_PROTOCOL = 10 will output the FrSky passthru protocol from the chosen (x) serial port on the flight controller running AP, and if connected to the smartport of X series Frsky Rx, ends up on the Taranis/Horus, accessible via a suitable LUA telemetry script - such as either the C&T script, or the free one in the OP by yaapu - its pretty awesome! (not tested this on the C&T script myself - maybe someone else can chime in if they have?

The difference between this project's implementation and the C&T code in Ardupilot, is that this one converts a standard Mavlink telemetry stream to FrSky passthru protocol, whereas the C&T code in Ardupilot accesses its data from not just Mavlink but also from other sources within the ardupilot code directly before it reaches Mavlink - so theoretically it has more scope for data access. The beauty of this project however is that it takes the conversion process to the external teensy module, which if placed airside, it allows the PX4 flight stack to produce Frsky passthru (which it doesn't currently support), and more importantly (for me at least) it allows ground side placement of the teensy on my ULRS system, meaning I can pass down the regular mavlink 1 data stream from Ardupilot, over the ULRS serial port, feeding this into the teensy ground side, resulting in both mavlink and passthru protocol access at the ground station - passthru to the Taranis LUA screen, and Mavlink via Bluetooth for Mission Planner/QGroundControl etc on a laptop. So its a great solution providing a lot of scope!
Jun 07, 2018, 06:56 PM
Registered User
can you publish file hex for stm32f103 ? i can not compile source code
Jun 08, 2018, 08:44 AM
Registered User
Thread OP
Quote:
Originally Posted by rc my life
can you publish file hex for stm32f103 ? i can not compile source code
Ok, I tidied up the STM32F103C version, and added the binary to GitHub

I built it as a ground mode version, with Emulation_Enabled, and NOT Aux_Port_Enabled.

Let us know how it works out
Jun 08, 2018, 06:24 PM
KD2PBU - Fly No Evil
davidbitton's Avatar
Quote:
Originally Posted by zs6buj
Ok, I tidied up the STM32F103C version, and added the binary to GitHub

I built it as a ground mode version, with Emulation_Enabled, and NOT Aux_Port_Enabled.

Let us know how it works out
Which board are you using for this chip? Perhaps an old flight controller? Reduce, reuse, recycle.
Jun 08, 2018, 06:27 PM
KD2PBU - Fly No Evil
davidbitton's Avatar
Quote:
Originally Posted by athertop
ULRS system
If by that you mean Dragonlink, I tried passing FrSky Passthrough using the RS232<->TTL adapter w/ no luck.
Jun 09, 2018, 12:32 AM
Registered User
Thread OP
Quote:
Originally Posted by davidbitton
If by that you mean Dragonlink, I tried passing FrSky Passthrough using the RS232<->TTL adapter w/ no luck.
I'm personally using the Teensy 3.2 and an Orange 1W UHH unit. I included the STM32F103C because they are much cheaper and generally available, like here

Since this STM32 serial port/uart can't switch to single wire inverted mode, you need an outboard inverter, but it must be capable of half duplex operation. In other words, it must pass telemetry both ways, like this


Jun 09, 2018, 10:57 AM
KD2PBU - Fly No Evil
davidbitton's Avatar
Quote:
Originally Posted by zs6buj
I'm personally using the Teensy 3.2 and an Orange 1W UHH unit. I included the STM32F103C because they are much cheaper and generally available, like here

Since this STM32 serial port/uart can't switch to single wire inverted mode, you need an outboard inverter, but it must be capable of half duplex operation. In other words, it must pass telemetry both ways, like this


interesting
Jun 10, 2018, 09:47 AM
RC fanatic
Quote:
Originally Posted by zs6buj
I'm personally using the Teensy 3.2 and an Orange 1W UHH unit. I included the STM32F103C because they are much cheaper and generally available, like here

Since this STM32 serial port/uart can't switch to single wire inverted mode, you need an outboard inverter, but it must be capable of half duplex operation. In other words, it must pass telemetry both ways, like this


Might be worth noting - the Pixracer FC has a dedicated FrSky telemetry port which has an integrated inverter for this very purpose. Alternatively I have built inverters very cheaply, and very easily using just 2 components which are available from aliexpress:

1. RS232 <-> TTL converter Link here
2. diode Link here

And this is how its wired:
Name: 35470481-8663e486-034a-11e8-80c5-00538f5c835d.JPG
Views: 361
Size: 274.9 KB
Description:

Looking at the Craft&Theory adapters, it appears that they are using these exact components also!

Cheers, Paul
Jun 10, 2018, 10:11 AM
RC fanatic
Quote:
Originally Posted by zs6buj

Here is an alternative 5v wiring option



I use these regularly in RC (in place of your 7805 regulator) it supplies up to 3A with variable voltage (just dial in what you need on a tiny pot, then drop a dod of CA on it to fix it from changing). Find it great in place of a BEC also as good enough to power Rx and a couple of 9g servos (usually dial in just under 6v for this), for say a small flying wing.
Jun 12, 2018, 03:56 AM
Registered User
Thread OP
urlu75 has requested support for a Relay Mode. I recall reading about athertop proposing a "repeater station" here along the same lines.


Consider the situation where an air-side LRS UHF tranceiver (trx) (like the Orange),
communicates with a matching ground-side UHF trx located in a "relay" box using Mavlik
telemetry. The UHF trx in the relay box feeds Mavlink telemtry into our passthru converter, and
the converter feeds FrSky passthru telemtry into the FrSky receiver (like an XSR), also
located in the relay box. The XSR receiver (actually a tranceiver - trx) then communicates on
the public 2.4GHz band with the Taranis on the ground. In this situation the converter need not
emulate sensor polling, as the FrSky receiver will provide it. However, the converter must
determine the true rssi of the air link and forward it, as the rssi forwarded by the FrSky
receiver in the relay box will incorrectly be that of the short terrestrial link from the relay
box to the Taranis.

Here is urlu75's diagram:


So the three modes now supported from v0.37 are:

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.

Air_Mode
In air mode, it is located on the aircraft between the FC and a Frsky receiver. It converts
Mavlink out of a Pixhawk and feeds passthru telemetry to the frsky receiver, which sends it
to Taranis on the ground. In this situation it responds to the FrSky receiver's sensor polling.
The APM firmware can deliver passthru telemetry, but the PX4 Pro firmware cannot.
Un-comment this line #define Air_Mode like this

Relay_Mode as described above. To enable Relay_Mode :
Un-comment this line #define Relay_Mode like this
Last edited by zs6buj; Jun 12, 2018 at 04:04 AM.
Jun 16, 2018, 05:59 AM
RC fanatic
Hoping this might help someone with wiring. My test bed.


Quick Reply
Message:

Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Discussion Mavlink on 9xr via 3dr radio without frsky or openlrs. jt41time Multirotor Drone Electronics 4 Oct 17, 2014 07:51 PM
Discussion 9XR mavlink mod help.... No modules, No FrSky... jt41time Multirotor Drone Electronics 6 Aug 28, 2014 06:42 PM
Discussion Anyone know how to convert DX7 to FrSky 2.4Ghz using the DIY module from FrSky?? roberted5 DIY Electronics 6 Sep 09, 2011 10:43 AM