Servers by jDrones

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

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

Well,

I think I have got the teensy 3.2 flashed correctly using the ardunio IDE and the teensey package on the website How do I know if I flashed my teensy correctly. I am running the same setup as @thatsnailguy is or at least I am trying to get it setup the same as him considering I use RFD900x with PPM passthru I don’t have any frsky on the pixhawk. I have setup the code to be in air mode with 57600 baud. Do I need to setup anything on the serial port that I have my RFD connected to, I see on the original yaapa blog they want you to set it to frsky passthru but thats when you are connecting the converter from serial to s port on frsky from fc. I have my tranais updated to the most current bootloader (2.2.3) with LUA and LUAC checked. I have read through the wiki and the million of pages here but there is so much to read on the blog post.

Should the teensy led still be flashing when I have the mavlink to frsky script ran?

I have gotten the telemetry screen and checked discover sensors but nothing shows up. When I go to the display to setup scripts then screen I also don’t get the screens choice but I do get a choice of yaapu9 or yaapu7.

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.

@Eric_Stockenstrom

I do not want to hook it to the back of the taranis s. port because I would like it to be mobile and not connected via anything. this is the way I have my ground station radio setup.

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:

@Eric_Stockenstrom

Which wiki are you speaking of? This one, or this one. I am not sure which one to read or where. I have read through the entire thread here about yaapu script. I have also read through the RCgroups forum here! I think I messed up and defined it as air mode when i compiled the script and after looking at the picture it looks like you are correct I do want relay mode but is the only difference in between ground and relay simply the fact that in ground you connect it all to the s port in the taranis back bay? In the below photo I see it says OTA slow link 19k baud is that simply because of the LRS and would not be the case for a RFD900x?

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.

@Eric_Stockenstrom

Enjoy your travels, hopefully its for pleasure and not work!! Appreciate the help!! Last question is in the script it notes connections as this (see below) but my question is does it matter where we put the ground? I am putting it to the teensy ground on the oppsite side of the Vin port just above the 0 rx1 port, does it matter where I ground it?
Connections to Teensy3.2 are:
0) USB Flashing and serial monitor for debug
1) SPort S -->TX1 Pin 1 S.Port out to Taranis bay, bottom pin
2) Mavlink <–RX2 Pin 9 Mavlink from Taranis to Teensy
3) Mavlink -->TX2 Pin 10 Mavlink from Teensy to Taranis
4) Aux_Mavlink <–RX3 Pin 7 Auxiliary Mavlink From BT Module to Teensy
5) Aux_Mavlink -->TX3 Pin 8 NOT NECESSARY - wire direct from Orange TX to BT RX
6) Vcc 3.3V !
7) GND

I have a big question about using this. I have my RFD radios which I understand @Eric_Stockenstrom has not used. I might be slightly confused maybe, but my rfd’s are setup to send raw data and not specifically configured for mavlink data even though mavlink is sent through the raw data stream, the reason behind this is to stream RTK corrections over the RFD to the UAV for precision camera exposure coordinates. Eric do you foresee this being an issue within the script? I have tried to get it working but have not been able. @thatsnailguy are your RFD’s setup to send mavlink or raw data? If raw data is an issue do you think i could ship an rfd900x to you Eric and see if you could add this?

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)
Adafruit_SSD1306 display(SCREEN_WIDTH, SCREEN_HEIGHT, &Wire, OLED_RESET);

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.

Eric

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.

Servers by jDrones