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

Hi Jorge,

I can’t see anything obvious here, but I have to say I have been out of the DL loop for some time now. It’s great kit, but I just have not had much time to myself.

I looked through my (old) notes, and found this image of settings once used:

image

Perhaps that will help. I’m sorry but I don’t remember the meaning of the settings anymore, and I’m on my phone here. lol. Also, the mav2pt firmware has S.Port inversion as an option. So, if you are wiring directly to the backbay of the handheld controller, then internal (DL esp32) inversion is a must.

One other thing, if you can find the uart0 tx0 pin, take it through a ttl-usb adapter, and you could view the (serial0) log real time. Last thing, if you can beg/borrow/find an oscilloscope, look at the s.port signal. It should be idle-low (zero v at rest, pulses rise up to 3.3v).

Last, last thing. I recently acquired an edge TX, but I just have not gotten 'round to setting it up fully yet.

Hi @Eric_Stockenstrom

Im just wondering, on my mav2pt setup (Dragonlink on relay), it works almost perfectly with yaapu telemetry on ethos. However, I noticed that I dont get any data for power and efficiency. all the rest works just fine. Is it something not included in mav2pt?

I can confirm it works if im not using my mav2pt+dragonlink. With my Frsky R9 and crossfire, Im able to fetch those data.

Hi Erwin,

can’t you just put the smartport output of the DL on the S.Port of the 2G4 RX? Should work without Mav2PT …

You can’t if you want to run yaapu telemetry on the frsky radio, it needs to convert the mavlink telemetry from Dragonlink to frsky s.port telemetry, thus the mav2pt.

Hi Erwin, I hope you are well

I can’t immediately think of a reason, so I’m going to suggest that you flash and run with two debug macros:

#define Debug_Batteries
#define Debug_Relay_Mode

and then please post the full monitor log.

I tried it myself yesterday … You are right that it does not work. But, the DL outputs S.Port telemetry. But for the Yaapu script S.Port Passthrough is needed and DL can’t do that, therefore Mav2PT.

DL also has a transparent serial port. If I simply feed S.Port Passthrough from the FC (Arduplane) there instead of Mavlink, it might work. But I don’t know yet if this will be output unaltered at the DL TX.

@Eric_Stockenstrom is Mav2PT running fine in relay mode with David’s latest fixes?

Truthfully, I just don’t know. I’m travelling a lot and don’t always have access to my test rig.

Ok, I will give it a try :grin: what FW version are you suggesting?

Does DL Really outputs s.port telem? I think it’s just mavlink. Thus you need the converter for the passthrough to s.port. yaapu doesn’t recognize it unless it is converted, as you said, it needs to be passthrough.

Yes, you can configure in the DL and give to the S.Port of a 2G4 Relay-RX. The telemetry can then be seen normally in the transmitter.

Even Yaapu works partially with it, but essential passthrough data is missing, so you can’t use the Yaapu widget with S.Port data only.

Btw, didn’t you want to give me the mount with the GPS boom for the Mini Crossbow ;-).

yeah, there’s just one problem, it should be frsky s.port, perhaps DL s.port isnt the same as frsky s.port? Yaapu works perfectly with frsky s.port/F.port (using my R9, or even my older 2.4GHz Frsky modules)

by the way, here’s the crossbow mount, sorry if i may have overlooked this :sweat_smile:

https://drive.google.com/file/d/1qv175RQB1rjQ45HGlGc74oxaEKtsVT3J/view?usp=sharing

With the Dragonlink TX, the option is called “Taranis” … Software-wise, everything is a bit old, but I’m not telling you anything new. :rofl:.

ah haha!yeah that is if we dont use Yaapu. From Yaapu page it listed down what ever is compatible, i guess taranis telemetry/Dragonlink Mavlink (which is different from Radio modem option in DL) is not really supported :slight_smile:

Wait, I recall doing this stuff about 4 yrs ago :grin: it acquires some data but not those stuff needed by yaapu script

1 Like

@Eric_Stockenstrom

Any updates on Teensy 4.0 support? According to PJRC Teensy 3.x is practiaclly EOL due to high manufacturing cost.

Hey Travis, regretfully not. I’m travelling a lot these days, and just not getting time. Sorry.

@Eric_Stockenstrom I noticed code referencing the RP2040 too, did that ever get anywhere? They’re readily available, cheap and fairly powerful so good be a good option, especially with some of the mini spin offs like the RP2040-Zero which are very compact at like the size of a coin. Thanks

@rc89: Hello, added support for the rp2040 back in 2021:

v2.66.02 Sats & rssi display fix
2021-07-04 Add support for Pi Pico board RP2040

and tested it at the time. However, we are now at v2.67.15 and I can’t guarantee that the rp2040 code will work perfectly. It might, but might not.

Un-comment line 54 in config.h, (and comment out the other boards)

define RP2040_Variant 1 // Raspberry pi pico select Raspberry Pi RP2040 Boards in Arduino IDE.

These are the pins I used at the time:

#elif defined RP2040                     // RP2040 Board Types

  //=========================================================================  
  #if (RP2040_Variant == 1)           // Raspberry Pi Pico RP2040 board with SSD1306 0.96" (128 x 64) display 
    #define MavStatusLed    25        // or LED_BUILTIN    
    #define InvertMavLed   false     
    #define BufStatusLed    99        // none  
    #define fc_rxPin         1        // Serial1 uart0 Mavlink rx - GPIO1  (2 × UARTs Only)
    #define fc_txPin         0        // Serial1 uart0 Mavlink tx - GPIO0
    #define fr_rxPin         9        // Serial2 uart1 FPort rx - GPIO9 - not mapped, but default
    #define fr_txPin         8        // Serial2 uart1 FPort tx - GPIO8
    #define startWiFiPin    99        // Trigger WiFi startup   
    #if defined Support_SBUS_Out 
      #define sbus_txPin     8       // SBUS out = tx pin  
    #endif    
    #if !defined displaySupport       // I2C OLED board 
      #define displaySupport
    #endif  
    #define SSD1306_Display         // OLED display type  
    #define SCR_ORIENT   1          // 1 Landscape or 0 Portrait 
    /* Below please choose either Touch pin-pair or Digital pin-pair for display scrolling
     *  Pin == 99 means the pin-pair is not used
     */ 
    #define Pup           21        // Board Button to scroll the display up - high(3.3v) = scroll
    #define Pdn           22        // Board Button to scroll the display down - high(3.3v) = scroll
    #define SDA            4        // I2C OLED board 
    #define SCL            5        // I2C OLED board
    #define i2cAddr      0x3C       // I2C OLED board
    #define OLED_RESET    16        // RESET here so no reset lower down    

  #endif

Hi Eric

I want to use an ESP Dev Board as a Mavlink switch to receive Mavlink via wifi from an ESP32 running Mav2P on my RadioMaster Tx16S and input Mavlink to my Pitlab tracker via UART. Can I add an alternative configuration in config.h? I cannot see an obvious issue in other parts of the code? Basically I want to use an ESP32 DEv board as a Mavlink Bridge from wifi to UART. I do not even need or want to use the gs_rxPin on 16.

#if (ESP32_Variant == 8) // ESP32 Dev Module with Mavlink out via UART
#define MavStatusLed 02 // Onboard LED
#define InvertMavLed false
#define BufStatusLed 99 // Mavlink serial tx 99=none
#define fc_rxPin 99 // 27 Mavlink serial rx
#define fc_txPin 99 // 26 Mavlink serial tx
#define fr_rxPin 13 // FPort- Not used in 1-wire mode DON’T use 12!
#define fr_txPin 12 // FPorttx - Use me in single wire mode
#define gs_rxPin 16 // Optional GCS rx3
#define gs_txPin 17 // Optional GCS tx3

Hi Marc, sure you can. One or two of the other guys have done this successfully. I suggest you use UDP. Remember, if you are using a 2.4 GHz module on your RadioMaster Tx16S, you are sharing the band with your ESP32 mavlink relay module. They work around each other fairly well, but different bands would be better.

1 Like