|
|
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 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:
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) 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) 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 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.
|
|
|
|
|
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.
|
|
|
|
|
Is this the same protocol that the Craft&Theory code runs against?
|
|
||
|
Quote:
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! |
|
|
||
|
|
|
can you publish file hex for stm32f103 ? i can not compile source code
|
|
|
|
||
Thread OP
|
Quote:
I built it as a ground mode version, with Emulation_Enabled, and NOT Aux_Port_Enabled. Let us know how it works out |
|
|
||
|
||
|
Quote:
|
|
|
|
|
|
|
||
Thread OP
|
Quote:
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 |
|
|
||
|
||
|
Quote:
|
|
|
||
|
Quote:
1. RS232 <-> TTL converter Link here 2. diode Link here And this is how its wired: Looking at the Craft&Theory adapters, it appears that they are using these exact components also! Cheers, Paul |
|
|
||
|
|
|
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.
|
|
|
|
|
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.
|
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 |