Mavlink to FrSky S.Port Passthru Converter for LRS or PX4 Pro

Sure, a picture would help. If you only see 2 sensors than either the cable is not working or it’s not connected to serial 2.
Perhaps try exchanging tx and rx on the flight controller side if the cable

Daniel, I had mixed results with those converters. I started to type a simple alternative for you, but then realised this converter is likely between the Pixhawk and the airbourne receiver. In that case I resorted to using a pair of transistors to invert and convert to single wire.

Good morning to all and a huge thank you to all it finally works. The devil is sometimes in the detail. 3 ttl to rs232 converters had to die because I found the error. the problem was that the solder pads on my board were only connected to the controller from below but I had used the upper solder pads. Now everything is displayed super. Only the mah and the Ah indicate 0.00, would be super if you could tell me how I can still solve the problem :slight_smile:

Ok just seen I need the mAh and Ah display not at all you could remove the from the script nicely and if yes how do I do that :slight_smile:

you need to recompile the script to remove them, there no option in the config menu to hide mAh and/or Ah

Hi Mathew

My understanding is you want to convert Mavlink passthru telemetry out of the RFD (on the ground) to FrSky telemetry, then feed it into S.Port of the Tarnis. In this case you need to flash Ground Mode. The led should blink when the converter sees good Mavlink telemetry.

Use Mission Planer to set he Pixhawk serial port telemetry to the Mavlink 1 or 2 protocol at 57600 b/s.

The alternative is Relay Mode. Can I suggest you read up on that in the Wiki and decide if that is what you want Mathew :slight_smile:

Ok, the example in the diagram was presented by one of the guys using ULRS, which sends telemtry at 19.2k b/s. In your case, susbstitue the RFD for the ULRS, and I believe you may use 57600 b/s.

So you want to use relay mode, the bottom option in the diagram. This differs fro ground mode in that you have a typical FrSky receiver, like an XSR, to relay the telemetry to the Tatanis. By doing this you avoid wires dangling out of the Taranis and leading to the RFD900 receiver. (I don’t have an RFD900 and my knowledge of that system is limited).

When the Mavlink 1 telemtry emerges from the ground RFD900 you convert it with the Teensy, and synchronise with the XSR receiver, which sends the data stream to the Taranis in native FrSky mode.

Note when you scan for sensors on the Taranis, two RSSIs should show up, one for the long RFD link, and one (unwanted) one for the short, XSR <–> Taranis link. I normall simply delete the unwanted one.

I might not be back on the net for a few days as I’m travelling.

Hi Eric, I’ve got this minor issue running a Teensy 3.2 With Alex’s LUA. I have both Tx and Rx connected to FC and #define Battery_mAh_Source 1, yet even after a few flights, battery cappacity is displayed as 0.00Ah. Everything else works.
Two copters, both sporting regular Pixhawk clones, one I’ve updated to 3.6.9, on the other I only had time to update the Teensy and Taranis, else running 3.5.7 iirc.

Hi Cornel

Battery_mAh_Source means battery capacity when full in mA hours. It can be read from the FC , as you have chosen, which means it was entered through Mission Planner battery setup.

Battery consumption, also in mAh is calculated as the integral sum of all the differential di/dt measurements during the flight, and this is deducted as you fly, from the reported battery capacity.

So, is your reported battery capacity when full correct, before you fly? Or is the consumption wrong during your flight so that the remaining capacity is reduced to zero too quickly?

Hi Eric.

Battery cappacity is correctly entered into the parameters list, and Mission Planner on the laptop shows correct percentages remaining.
It’s only on the RC, running Alex’s script that consumption is shown against a zero value. It doesn’t get the cappacity from the FC, so it displays like “3.71/0.00Ah”
I haven’t tried anything below 10.000 mAh tho’ :slight_smile: so I can’t say where lies the problem. His satcount, for instance, displays 15+ for anything above, which for a regular NEO-M8N is OK, but with a ZED-F9 and 42 sats locked, that 15+ won’t do, anymore :dark_sunglasses:

Hi Cornel

Could you please send me a TLog.

Hi Eric.

Will a TLog from the laptop do ? Because I’m unfamiliar with logs stored on Taranis SD card.

Hi Cornel, yes, that’s what I need.

So I gave up on the ESP32 version of this a while back when I could not get my flavor of ESP32 working properly – Teensy is still going strong! I have now broken down and just ordered the same one that is referenced in the Git repo (with OLED and SD card). In the meantime I thought I would try again with my Wemos ESP32 Lolin. It is this one here.. The salient point is it is has OLED SDA/SCL on pins 5 and 4 of the ESP32.

The latest version of the code is now using the Adafruit library for the 1306 display. For the life of me I cannot see how to define the i2c pins used. That at least I had managed to get working in the previous version! We used to have:
#include “SSD1306Wire.h”
const uint8_t oledSDA = 5; // TTGO = 5; ESP Dev = 19; Other = 21;
const uint8_t oledSCL = 4; // TTGO = 4; ESP Dev = 18; Other = 22;
SSD1306Wire display(0x3c, oledSDA, oledSCL);

Now we have:
#include <Adafruit_SSD1306.h> //#define SSD1306_128_64 ///< DEPRECATED: old way to specify 128x64 screen
// Dev board default SDA = 21;
// Dev board default SCL = 22;
#define SCREEN_WIDTH 128 // OLED display width, in pixels
#define SCREEN_HEIGHT 64 // OLED display height, in pixels
// 8 rows of 21 characters

// Declaration for an SSD1306 display connected to I2C
#define OLED_RESET -1 // Reset pin # (or -1 if sharing Arduino reset pin)

So how do I get my my I2C pins declared? I cannot see any such parameters and I even looked at the Git repository for this library. I am missing something.

And while I am at it I also find the connection from the Taranis SPort teleletry input and ESP32 SPort Telemetry output to be confusing. The FrSky telemetry output pin declarations are not with the rest of the setup but are in the FrskySportPassThru file.

frSerial.begin(frBaud, SERIAL_8N1, 12, 14); // rx=12 tx=14

I do not think I have to change these as I have 12 and 14 available. What does confuse me a little is we have defined a two wire connection here. Which one is connected to the Taranis SPort input pin? I know this is probably a fundamental misconception on my part but I have simply never grasped this with the ESP32 version of this project while it was never an issue with the Teensy version. Literally what pin do you connect to the Taranis telemtry input (bottom pin JR port)? Is it the TX 14? If we want bi-directional SPort telemetry then we would use a converter and use both pins?

Hope I can have the veil of confusion lifted! And thanks again for such a magnificent project.

(This is a cross post in the RCGroups forum. Not sure which one you check most.)

The latest version of the code is now using the Adafruit library for the 1306 display. For the life of me I cannot see how to define the i2c pins used

Marc, I found that the Adafruit SSD1306 library has a more readable font, and supports more vertical lines while remaining legible. It also supports SPI OLED displays, in addition to the I2C ones we currently use.

Your exasperation regarding pin definition is well founded. Lol. I can’t say I have put much effort into accommodating esp32 variants before, but you will be pleased to know I’ve just posted v2.28 with all the definitions in one place.

The Adafruit SSD1306 library picks up SDA and SCL from the Wire Class, and the default was 21 and 22. They are now defined explicitly in

   #if (Target_Board == 3) 
     Wire.begin(SDA, SCL);

I do not think I have to change these as I have 12 and 14 available. What does confuse me a little is we have defined a two wire connection here. Which one is connected to the Taranis SPort input pin? Hope I can have the veil of confusion lifted!

Yeah, it can be a little tricky. In summary, it works like this:

In Air Mode and Relay Mode, the Mav2PT converter talks to a FrSky receiver (say XSR), and interleaves sensor packets into the sensor stream going down to the Horus/Taranis. In order to interleave a packet at exactly the right moment, it has to READ from the XSR and slot into a suitable gap in the stream. So the data read must get back into the Mav2PT.

However, in Ground Mode, when the Mav2PT talks to the Taranis/Horus and not a receiver like the XSR, it does not need to interleave packets. It therefore does not need to read anything, and therefore only Mav2PT txPin to Tarnis/Horus S.Port (rx) pin is sufficient. The OpenTX simply reads the sensor packets, and combines them with any sensor packets received from the receiver on the 'craft. So, in Ground Mode, one wire (plus ground of course) is always enough. This is true of the ESP32, the Teensy 3.x and the STM32 variants.

All FrSky telemetry is inverted with reference to mainstream serial telemetry. FrSky pulses rise up from (nominal) zero to 3.3v, whereas conventional serial pulses drop down from 3.3v. Furthermore, FrSky encode both rx and tx signals on the same wire. So this means when we talk to an XSR, or a Horus or Taranis, we need one bi-directional wire.

The Teensy 3.x has the capability of inverting and converting to bi-directional single wire internally. No inverter needed. No bi-directional converter needed.

The ESP32 variants have the capability of inverting the signal, but not converting to single wire (as far as I know at this point). So we must still do the two-wire to single-wire conversion when talking to an XSR, because we need to slot in our packets

The STM32F103C variants have no capability of inverting the signal, and no capability of converting to single wire. So we must invert the pulses and also do the two-wire to single-wire conversion when talking to an XSR, because we need to slot in our packets.

In Ground Mode, the STM32F103C variants must naturally still invert the signal with an external inverter because they are talking to a FrSky device.

Hope that lifts the veil. :slightly_smiling_face:

1 Like

P.S. maybe I should include this explanation in the GitHub WiKi

It is like the blind man has had sight restored! Thank you for this explanation. I really appreciate it. You could copy and paste it into the git wiki.


I gave up on my current ESP32 efforts until the versions you recommend arrive. What really puzzled me was that I was able to compile and flash yet the SSID did not match the one I flashed. The oled was also confirming that Mavlink telemetry was being received regardless of whether it was being sent.

After flashing I am getting an error about missing headers in your patched ESP32 library. Yet it is compiling, seemingly.