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

Blog
441

Look at mav2pt as a conduit, like a multi-way cable, I believe this issue will still present.

Two or three GCSs ask the single FC for parameters, starting at different times. All telemetry, including parameters, is streamed to all GCSs. Mavlink should resolve who gets which parameter. If you are firing up multiple instances of (say) QGC, they all have the same Mavlink identity. When they receive apparent duplicates they complain. When one or more determines missing parameters, it/they ask for them to be resent. Eventually they are all happy, despite the chaos.

I’m not keen to intervene in the Mavlink logic.

442

As mentioned above: in this test Mav2PT gets the data from a Crossfire via Bluetooth, which gets the data from a FC. Crossfire acts here as a transparent bridge. Mav2PT then outputs the data to a WiFi and is the only GCS with Mission Planner active.

No. I have given both Mission Planner and QGC their own Mavlink ID. But I can’t say if this ID is used in Mav2PT. In the test only one GCS, in this case Mission Planner, was active.

This is not due to the Mavlink logic but to the implementation in Mav2PT. If I set up an ESP8266 with the MAVESP8266 Firmware and then access it with Mission Planner and QGC at the same time, no “Already Got param” will appear.

443

mav2pt itself reacts a a ground station and requests parameters. It is not a true transparent bridge.

444

That’s right Stefan, but that’s not the point … In MAVSP8266 for example a broadcast is sent, a GCS answers and from this point on a communication takes place only between two IP addresses. Look at the code …

I did not write that Mav2PT is a transparent bridge, but Crossfire acts as a transparent bridge for me (I can set Mavlink or Bridge in CF TX).

445

Ok, I accept what you say. :slight_smile: I will check further.

446

Reinhard, what version of Crossfire firmware do you use actually?

The 4.x beta firmware of Crossfire is some kind of crap at the moment. The actual 4.x implementation is extremly laggy and somewhat problematic.

The Mavlink brigde of Crossfire is not really a transparent bridge, and the overboarding „already got message“ issue is very likely not an issue of mav2pt.

The telemetry bandwith of Crossfire was never wide enough for a 57600 stream, but with the versions before 4 is was somewhat usable. The actual Mavlink2 implementation is simply not stable and imho unusable.

Btw. I looked at the mav2pt source code, and I apologize that, on default settings, I was wrong. Mav2pt itself does not request any params with default settings. Sorry for that.
Nevertheless the mavlink implementation of mav2pt should be reviewed. As far as I could see, there is a mixture of sysid‘s for example.

447

Crossfire Full TX with older (good!) FW 3.54

448

I did some work on this this morning, and yes it is clear that mavlink routing needs to be tidied up.

Purely looking at the translator from mavlink to frsky passthru, there are a few special situations where I need to request information from the FC, for example mission waypoints, and optionally battery capacity. In those circumstances, with only one mavlink connection, I got away with simple fudging of sysid and compid. Mavlink routing was a non-issue.

Then we add WiFi and BT I/O, and as long as we simply pass across the packets one-to-one, routing should remain intact, as long as we are data agnostic. We don’t change anything in the packets and they simply go point to point.

Now we go a step further, and implement multiple clients, and multiple GCSs, and routing is definitely required, and in between the normal traffic now, I still might request data from the FC as described above with fudged sysid and compid.

I have used this documentation now as the basis for tracking source and target identities, and generally tightened up on my own internal requests for data from the FC (or the GCS).

Further, up to now, I have used a mock heartbeat to the FC to trigger data flow when no GCS is present. This is still in place, but stops when at least one GCS comes on line and triggers telemetry flow.

Nevertheless, I’m still seeing “Already Got param” from time to time. I compared the Mission Planner TLog (extracts) with my own debug log, and they match exactly. MP requests all the parameters, appears the get them all correctly, but still asks for certain parameters to be resent. These parameters are requested twice each, and two replacements arrive. Why twice I don’t know, but the MP logs and my logs show the same thing.

I have stashed some of the debug logs here. It might expire in a few days.

0x16 is a spreadsheet extracted from the TLog containing all the downloaded parameters.

0x14 is a spreadsheet extracted from the TLog containing all the parameter resend requests for mission planner.

mav2pt_debug_log.txt is self explanatory.

These logs are from tests using TCP, with a single STA connection through the lan to Mission Planner on a PC. When using UDP the results are the same.

EDIT:

I have used ESP8266 extensively, and for best results always used the HW flow control. Without it the serial link can drop a lot of packets.

I should do some tests with RTS/CTS cabled and implemented.

449

Hi Eric,

I mean that things are already running much more smoothly. “Already Got param” comes more often, but it doesn’t falter as often.

Are you sure this is the right documentation? This is about the internal ArduPilot communication. Here Mavlink can be output on different serial ports and there are also applications where a computer is mounted in/on the flight controller. The communication there is a little bit different than when communicating with a GCS on the ground.

450

During the last flights, I always had a repeating „Disarmed“/„Armed“/„Flight mode“ announcement loop. But the telemetry values were still received correctly.

Can you point me to the right direction to this issue?

Thanks,
Stefan

451

Hi Stefan

This is usually a problem with frame_type on the heartbeat. If you give me a TLog maybe I can resolve it for you.

452

Hi Eric,

Since I’m using on the downlink channel from the FC, I’ve changed the FC parameters as follow:
SERIAL2_PROTOCOL,2
SR2_ADSB,0
SR2_EXT_STAT,1
SR2_EXTRA1,3
SR2_EXTRA2,3
SR2_EXTRA3,1
SR2_PARAMS,0
SR2_POSITION,3
SR2_RAW_CTRL,0
SR2_RAW_SENS,0
SR2_RC_CHAN,0

and also enabled the Debug RSSI
Now, more data is coming out of the converter S.port. but still Taranis states “no data”.
By a monitor log you mean to enable “debug_all” ?

Thanks,
Yaniv.

453

Hi Yaniv

Hmm. This is strange. I see you are using RFD900. Are you using TXMOD, and are you using their latest firmware? If you are just using mav2pt, is it on ESP8266 or ESP32? Can you flash using Debug macros?

#define Mav_Debug_All
#define Frs_Debug_All

This will produce a heck of a lot of output but should give us an idea of the problem.

Also do this one:

#define Debug_Loop_Period

If telemetry is slow we will see it here.

454

Hi Reinhard

Yes, the px4 documentation is a bit better, but the same principles are applied regardless of the transport medium.

455

Hi Eric,

If I enable the #define Frs_Debug_All, there is compilation error:
In file included from D:\Teensy\MavToPass_v2.62.5\MavToPass_v2.62.5.ino:143:0:
C:\Users\Yaniv\AppData\Local\Temp\arduino_build_252314\sketch\SPort.h: In member function ‘void SPort::Push_Lat_800(uint16_t)’:
SPort.h:1088: error: ‘bit32Unpack’ was not declared in this scope
int32_t r_lat = (bit32Unpack(pt_payload,0,30) * 100 / 6);
^
C:\Users\Yaniv\AppData\Local\Temp\arduino_build_252314\sketch\SPort.h: In member function ‘void SPort::Push_Lon_800(uint16_t)’:
SPort.h:1126: error: ‘bit32Unpack’ was not declared in this scope
int32_t r_lon = (bit32Unpack(pt_payload,0,30) * 100 / 6);
^
C:\Users\Yaniv\AppData\Local\Temp\arduino_build_252314\sketch\SPort.h: In member function ‘void SPort::Push_Text_Chunks_5000(uint16_t)’:
SPort.h:1166: error: ‘MavSeverity’ was not declared in this scope
Debug.print(" "); Debug.print(MavSeverity(pt_severity));
^
‘bit32Unpack’ was not declared in this scope

I’ve attached a debug file without Frs_debug_all: Mav_loop.txt (590.4 KB)

Thanks a lot,

Yaniv.

456

Hi Yaniv

There were two fwd declarations missing for those debug options.

I uploaded a quick fix v2.62.6

457

Heltec Relay Problem:
Using pin 14 and 13 on the Heltec wifi board in relay mode does not work for me…I have verified that the inverter I have and RX work with my T16s and Yaapu script when connected to a FC telem port running passthrough…so that hardware is proven…

and the Heltec works in both station and AP mode sending/receiving Mavlink from my DL TX to various ground control stations over WIFI UDP…

just cant get the data out to Sport on the RX… any suggestions?

458

Hi Henry, can you post your serial monitor output.

459

I think I know how to do that…
08:02:28.781 -> rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
08:02:28.781 -> configsip: 0, SPIWP:0xee
08:02:28.781 -> clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
08:02:28.781 -> mode:DIO, clock div:2
08:02:28.781 -> load:0x3fff0018,len:4
08:02:28.781 -> load:0x3fff001c,len:1216
08:02:28.781 -> ho 0 tail 12 room 4
08:02:28.781 -> load:0x40078000,len:9720
08:02:28.781 -> ho 0 tail 12 room 4
08:02:28.781 -> load:0x40080400,len:6364
08:02:28.781 -> entry 0x400806b8
08:02:31.820 ->
08:02:31.820 -> Starting MavToPass_v2.62.5 …
08:02:31.865 -> Display support activated
08:02:31.865 -> EEPROM initialised successfully
08:02:31.910 -> EEPROM settings read and adopted
08:02:31.910 -> Target Board is ESP32 / Variant is Heltec Wifi Kit 32
08:02:31.956 -> Relay Mode
08:02:32.001 -> Battery_mAh_Source = 3 - Define battery capacities in the LUA script
08:02:32.001 -> RSSI Override for testing = 70%
08:02:32.047 -> Mavlink Serial In
08:02:32.047 -> Mavlink WiFi+BT Out - WiFi mode is STA/AP
08:02:32.138 -> Protocol is UDP IP-Targeted
08:02:32.727 -> Bluetooth slave mode, host name for pairing is DLTX
08:02:32.727 -> Mavlink serial on pins rx = 27 and tx = 17
08:02:32.727 -> S.PORT NOT INVERTED! Hw inverter to 1-wire required on pins rx = 13 and tx = 14
08:02:32.727 -> Use a 2-wire to 1-wire converter for Air and Relay Modes
08:02:33.270 -> Wi-Fi mode set to STA sucessfully
08:02:33.270 -> Trying to connect to HOME…
08:02:34.814 -> WiFi connected!
08:02:34.814 -> Local IP address: 192.168.0.104
08:02:34.860 -> WiFi RSSI:-68 dBm
08:02:34.951 -> UDP started, listening on IP 192.168.0.104, port 14555
08:02:34.996 -> Web support active on http://192.168.0.104
08:02:36.264 -> hb_count=1
08:02:37.261 -> hb_count=2
08:02:38.255 -> hb_count=3
08:02:38.255 -> Mavlink good!
08:02:41.389 -> S.Port scheduler buffer full. Check S.Port downlink
08:04:48.306 -> S.Port scheduler buffer full. Check S.Port downlink

so I have double checked the inverter connection to 13/14…and this inverter+XSR that I am using, if I connect to a FC works flawlessly with Yaapu script…

PS: I have also noted that the transfer rates over UDP are horribly slow…previously I just checked that it connected and not really paid attention to data flow…possibly the buffer stall is affecting the wifi side?

is there any way to disable the Sport code entirely and just use as a sophisticated WIFI bridge? others on RC groups have suggested that they use this only for WIFI/BT and use a Teensy for the relay since they could not get the Heltec to work in relay mode…

460

And the converter you use is which converter exactly?