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

Blog
281

This is the code for fetching the battery capacities:

  #if (Battery_mAh_Source == 1)  
  // Request battery capacity params 
  if (mavGood) {
    if (!ap_bat_paramsReq) {
      Param_Request_Read(356);    // Request Bat1 capacity   do this twice in case of lost frame
      Param_Request_Read(356);    
      Param_Request_Read(364);    // Request Bat2 capacity
      Param_Request_Read(364);    
      Debug.println("Battery capacities requested");
      OledPrintln("Bat mAh from FC");    
      ap_bat_paramsReq = true;
    } else {
      if (ap_bat_paramsRead &&  (!parm_msg_shown)) {
        parm_msg_shown = true; 
        Debug.println("Battery params successfully read"); 
        OledPrintln("Bat params read ok"); 
      }
    } 
  }
  #endif

You should be able to follow the process on the debug monitor

282

I expect that the txmod should pass the request through

283

here is the start s-port working fine have not work out all the pin yet to cold in the shed 6c and cooling and its 1.00 AM

1Untitled
1Untitled1920×1224 190 KB
2Untitled
2Untitled1920×1224 184 KB

284

Lol. You need a heater in there mate.

285

I did today on its way :+1:

286

First, yes: the Crossfire occupies the s.port pin (pin 5) of the module bay of the FrySky for its own csfr protocol. That’s the cause why you have to separate pin 5 physically from the Crossfire.

Second: At the moment, the internal ESP8266 in the newer module adapters of Crossfire does not route any Mavlink. It does some things regarding the multi binding feature and TBS cloud.

I contacted TBS several times, and I got the answer that Mavlink (and Mavlink2) routing via the wifi module is in planning, also (eventually) mavlink output via tha expansion port of the Crossfire (there is the UART connecting to the Wifi module). But they did not give me any time line for that. And now, at the moment, it is not possible yet.
(I’ve heard, that Trappy mentioned something regarding Mavlink last few days in one of the “couch sessions”, but I do not know anything concrete)

1 Like
287

well may be you take from RX pin on the Bluetooth module on the crossfire feed it to teensy
from the teensy to frsky S-port receiver and turn on the TX Internal module as well ?
has any one tried to turn on 2.4 module at the same time

288

Yes, but I’ve heard Trappy talk about mavlink multiple times during couch sessions, but never see much action.
I have a feeling not much Crossfire users use (or ask for) mavlink features anyway.
It’s a shame because it could be a nice compact system this way.
On the other hand it would also be handy if ardupilot just supported crossfire and crossfire telemetry like it does with betaflight and inav.
Then there is no need for any converting or whatever.
With my smaller inav and betaflight quads it just works.
Then with ardupilot you have mavlink as an option if you want to use a ground station anyway.
It’s a shame, I love crossfire… and I love ardupilot… but using both feels too much like a hastle.
I might just put an x8r in my bigger drone for now to save some time.

289

I’m sure you noticed my careful way of expressing myself regarding the given statements :slight_smile:

Nevertheless, Crossfire Mavlink (despite of being perfect) is a working solution as long as you can handle the disadvantages (being limited to Mavlink1 and the paket loss mechanism for longer distances).
The biggest problems imho are the issues with the Bluetooth connection. With Linux and most Android systems it works as it should, Windows is a instable nightmare, iOS is not possible.

Ardupilots upcoming support of the csfr is useful for the most important telemetry (as even now, some limited telemetry handover to OpenTX is working out-of-the-box), but no real substitution for a complete Mavlink(2).

It would be so easy for TBS to allow simple Mavlink forwarding to the expansion port UART and to disable the csfr s.port injection by a simple menu entry. But obviously the do not see the advantages.

But at the moment, the only possibility seems to be to get the Mavlink from the Bluetooth, use a ESP32 or (seems to be more stable in my case) a Raspi, and then route the Mavlink to various downlinks.

290

That would be possible, but requires additional programming. The data stream to the internal bluetooth module is not pure Mavlink, but a communication protocol with the module. The module is documented (I cannot remember the manufacturer at the moment), so it should be possible. Nevertheless it requires soldering and writing a translation (or filtering) program.

291

never mind my bad lol

292

Has anybody had random resets with a heltec wifi kit 32? The sport conversion works perfectly, I’m able to edit settings via the wifi portal, but as soon as I try to connect via qgroundcontrol the board resets itself over and over after downloading 2 or 3 parameters. It’s powered off of a 8 amp regulator so it’s definitely not browning out. The r-xsr connected to the same reg doesn’t brown out and the voltage telemetry coming from that is a solid 5 volts constantly.

293

I also have dropouts (but no reboots) during flights. It seems a little bit to me, that in my case, the ESP32 has problems with parallel data load on Bluetooth and Wifi. Is it possible, that Bluetooth and/or WiFi (or operating parallel) is not very stable on ESP32?
Also, sometimes (not always) I have reboots while accessing the wifi settings page.

294

Guys, could you make sure you don’t use pin 12 for s.port. Also I have found that many pins do not like floating high when WiFi/BT is enabled. Just a touch of your finger is enough to trigger a reboot. Seems to come with the territory, but maybe will get fixed in newer esp-idf releases.

Keep in mind that there is no point in enabling BT (or WiFi) if you don’t plan to use it. The BT stack especially is heavy on resources. WiFi UDP is the lightest.

Stefan, remember that if you change settings in the Web interface, a reboot is required and is triggered automatically. Also, if WiFi mode is set to STA/AP fail-over, and esp cannot connect to the hotspot, when it fails over to AP mode a reboot is triggered for subsequent stability.

295

Speaking of bt: how exactly do I use it? None of my devices seem to like it for some reason. I can pair, but can’t actually connect on windows or android. With the translator running and paired, qgroundcontrol on Android doesn’t see a serial port, and neither does windows. I’m sure that I’m doing something wrong.

296

image

As above, give the link a name, do the scan, select and save.

1 Like
297

I’ve found a workaround for my issues with windows. For whatever reason, even though the network that this firmware creates is to wifi spec, and even though it works with android, ios, and macos, windows refuses to connect on three completely different windows 10 machines with 3 different wifi cards from different manufacturers. After more debugging it seems that this is an issue in windows.

If anyone else is having this issue, the workaround is to use the windows wifi hotspot feature, and connect the converter to the hotspot in STA mode. This maintains the ability to have internet while also remaining connected to the UAS. I actually find this better than directly connecting to the converter, or connecting the converter to a separate wifi network. This works with android hotspot too.

298

Eric it looks like rfd added s-port passthru i just tested it works fine i have Version 1 on Version 2 they have added the S-port plug from a 4 pin to a 5 pin

d1761d3448070b4228828ce91df85c890945b93e
d1761d3448070b4228828ce91df85c890945b93e1469×1102 436 KB

299

well have look at the Credits page buddy on the txmod :wink:

Untitled
Untitled961×950 67 KB

1 Like
300

Thanks for the feedback Colin. Makes me happy that more people benefit from the work.

They sent me a pair of RDF900+TXMOD to play around with last year. I should flash to new fw, but I guess I’ll have to do without the 5 pin socket.