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

Ok, sorry for the delay. It’s been busy here.

Using the stack decoder on your reboot error I get

0x40116085: _svfprintf_r at …/…/…/…/./newlib/libc/stdio/ vfprintf.c line 1430 0x4011410d: _snprintf_r at …/…/…/…/./newlib/libc/stdio/ snprintf.c line 68

0x400d5faf: ComposeSettingsPage() at C:\Users\Eric\Documents\GitHub\MavlinkToPassthru\MavToPass_v2.61.8/ WebSupport.ino line 194

which points me at his line in Mav2PT

sprintf(temp, "<input type='radio' class='big' name='_fc_io' value='WiFi' %s> WiFi &nbsp &nbsp", set.fc_io2);

which suggests that the sprintf() blew up trying to format set.fc_io2

which in turn suggests that your settings in eeprom are corrupt.

Run with this macro activated, but run one time, and the deactivate it:

#define Reset_Web_Defaults            // Reset settings in eeprom. Do this if you suspect eeprom settings are corrupt.
// USE THE ABOVE LINE SPARINGLY. IT CAN EVENTUALLY WEAR OUT YOUR EEPROM.

Please could you try MavToPass_v2.61.9 for WiFi in and serial out. It should work with either TCP or UDP. For TCP I had to add code to support a local client session, but UDP already worked as you indicated before.

The serial pins remain as per your esp32 board variant, so for the heltec wifi kit 32, the pins are

#define mav_rxPin 27 // Mavlink serial rx
#define mav_txPin 17 // Mavlink serial tx

We cannot support upstream serial (to the FC) and downstream serial (like to the GCS) simultaneously on the ESP32 as there are not enough uarts. Softwareserial is an option, but right now I can’t imagine why it’s necessary.

I had thought of that and activated the macro once. But the result has not changed.

Thank you! I will do one more test later …

Hi Eric,

serial data output seems to work now, the tracker receives data But it doesn’t track because apparently the right Mavlink data isn’t coming

Can you tell me if these messages are transmitted?
MAVLINK_MSG_ID_GPS_RAW_INT
MAVLINK_MSG_ID_GLOBAL_POSITION_INT

Further tests … Other application, also with a (different) Heltec Wifi 32 module with the following parameters:

Mavlink in: Bluetooth
Mavlink out: Wifi

Problems:
The monitor reports Serial In for Mavlink although Bluetooth is set.

It is shown that the Bluetooth master wants to connect to the slave “BT_Slave”. But my slave is still called “Crossfire 0277” …

Mavlink data is not transferred to Wifi.

Monitor-Log::
Starting MavToPass_v2.61.9 …
Display support activated
EEPROM initialised successfully
EEPROM settings read and adopted
Target Board is ESP32 / Variant is Heltec Wifi Kit 32
Ground Mode
Battery_mAh_Source = 3 - Define battery capacities in the LUA script
RSSI Override for testing = 70%
Mavlink Serial In
Mavlink WiFi+BT Out - WiFi mode is STA/AP
Protocol is UDP
Bluetooth master mode host DL_R8 is trying to connect to slave BT_Slave. This can take up to 30s
Bluetooth done
Mavlink serial on pins rx = 27 and tx = 17
S.Port on ESP is inverted on tx pin = 14
Wi-Fi mode set to STA sucessfully
Trying to connect to RHS_FPV_MOBIL.
WiFi connected!
Local IP address: 192.168.1.23
WiFi RSSI:-41 dBm
UDP started, local IP 192.168.1.23, port 14555
Web support active on http://192.168.1.23

config.h:
config.h (54.4 KB)

If you enable these debug options it will show you if those messages are coming through:

//#define Mav_Debug_GPS_Raw     // #24
//#define Mav_Debug_GPS_Int     // #33

Remember, mav2pt uses the settings saved in eeprom, for presentation to the web setup interface.

Since this macro is not enabled

//#define Reset_Web_Defaults

it is not taking your default settings, but those saved in eeprom, and I’m guessing that they call for serial-in and the old bluetooth host name.

I will try this again right away. Before I didn’t pay attention if there is a 3D fix and that is probably a prerequisite if I interpret the code correctly.

Yeah, I got that. Only if I go into the WebGUI, change settings and save them, the changed settings would have to be loaded the next time I started, right?

I have set the debug parameters. The system has a 3D fix. But no Mavlink debug messages are displayed …

But QGroundControl or Mission Planner can connect.

I write down the system configuration again, maybe you see a problem …

I have a Dragonlink system. There is an ESP32 in the Dragonlink TX. It has Mav2PT installed and gives Mavlink data to a wifi network.

The wifi network consists of a mobile router, a phone with QGroundControl and a laptop with Mission Planner. And a Heltec Wifi 32 module for the tracker.

All devices hang in this one Wifi network.

First the mobile router is started. Then the transmitter with the Dragonlink TX. This connects automatically to the router via Mav2PT. If QGC is started on the phone, a Mavlink connection is established immediately.

If I now start Mission Planner on the laptop, no connection is established. Only when QGC is finished does Mission Planner work. Is it normal that only one GS can be active?

Maybe the Heltec module for the tracker does not work because the connection is already busy? With Bluetooth it would be clear, but via Wifi several endpoints should be able to connect, right?

I seem to recall you are using UDP. UDP is set up to broadcast to all possible 255 devices on the subnet, like 192.168.1.X for all X. I’m not sure how the FC would know which GCS asked for parameters, for example. In mav2pt I keep track of only one remote IP, being the one from most recent incoming packet.

Perhaps tcp would be better, because each client starts it’s own unique session, managed inside the client class.

I’ll look closer tomorrow to see if I can find a problem affecting the gps messages

Here I’m getting the gps messages no problem:

Web support active on http://192.168.4.2
hb_count=1
hb_count=2
hb_count=3
Mavlink good!
Mavlink from FC #24 GPS_RAW_INT: ap24_fixtype=3 3D Fix  sats visible=6  latitude=-25.9461008  longitude=28.0435008  gps alt amsl=1456.5  eph (hdop)=528.00  epv (vdop)=298.00  vel=1.570  cog=193.3  alt_ellipsoid)=0  h_acc=13858  v_acc=7402  ap24_vel_acc=1212  ap24_hdg_acc=0
Mavlink from FC #33 GPS Int:  ap_lat=-25.946109 ap_lon=28.043501 ap_amsl=3 ap33_alt_ag=2.5 ap33_vx=3.95 ap33_vy=-0.06 ap33_vz=0.69 ap33_gps_hdg=203.8
Mavlink from FC #24 GPS_RAW_INT: ap24_fixtype=3 3D Fix  sats visible=6  latitude=-25.9461168  longitude=28.0435008  gps alt amsl=1457.4  eph (hdop)=528.00  epv (vdop)=298.00  vel=1.200  cog=198.1  alt_ellipsoid)=0  h_acc=13983  v_acc=7444  ap24_vel_acc=1401  ap24_hdg_acc=0
Mavlink from FC #33 GPS Int:  ap_lat=-25.946117 ap_lon=28.043501 ap_amsl=3 ap33_alt_ag=2.5 ap33_vx=3.02 ap33_vy=-0.19 ap33_vz=0.54 ap33_gps_hdg=204.1
Mavlink from FC #33 GPS Int:  ap_lat=-25.946118 ap_lon=28.043501 ap_amsl=3 ap33_alt_ag=3.1 ap33_vx=2.14 ap33_vy=-0.32 ap33_vz=0.47 ap33_gps_hdg=205.1

This is with the gps on the window sill, and using one ESP Heltec 32 with serial from a Pixhawk and WiFi Out, and a second ESP32 with WiFi-in / Serial out settings. The debug messages are out of the second ESP32.

EDIT: Protocol setting I’m using is TCP/IP

Hi Eric,

I can’t seem to get it to work…

I have reconfigured the ESP32 in the Dragonlink to TCP/IP and can access it via phone with QGC if I configure a connection on port 5760 to IP 192.168.1.91.

If I now configure the Heltec module for the tracker to TCP/IP as well (all other parameters as before), I get the following in the protocol

Starting MavToPass_v2.61.9 …
Display support activated
EEPROM initialised successfully
NOTE! ALL SETTINGS IN EEPROM SET TO COMPILE_TIME DEFAULTS!
EEPROM settings read and adopted
Target Board is ESP32 / Variant is Heltec Wifi Kit 32
Ground Mode
Battery_mAh_Source = 3 - Define battery capacities in the LUA script
RSSI Override for testing = 70%
Mavlink WiFi In
Mavlink Serial Out
WiFi mode is STA
Protocol is TCP/IP
No Bluetooth options selected, BT support not compiled in
Mavlink serial on pins rx = 27 and tx = 17
S.Port on ESP is inverted on tx pin = 14
Wi-Fi mode set to STA sucessfully
Trying to connect to RHS_FPV_MOBIL.
WiFi connected!
Local IP address: 192.168.1.94 port: 5760
WiFi RSSI:-44 dBm
Local outgoing tcp client connect failed, retrying
Local outgoing tcp client connect failed, retrying
Local outgoing tcp client connect failed, retrying
Local outgoing tcp client connect failed, retrying
Local outgoing tcp client connect failed, retrying

Where do I have to tell the Heltec module to pick up the data at 192.168.1.91?

Or do I have to reconfigure the network for TCP/IP to 192.168.4.x?

Actually … I reconfigured the network to 192.168.4.1 and also changed the server address in config.h to 192.168.4.91 (ESP32 in Dragonlink TX).

Now the data arrive at the Heltec module for the tracker and also the tracker accepts the Mavlink data via serial connection.

But, I can either connect the Heltec module or QGC on the phone. Both at the same time is not possible (yet). How is that with you?

Monitor-Log:
Starting MavToPass_v2.61.9 …
Display support activated
EEPROM initialised successfully
EEPROM settings read and adopted
Target Board is ESP32 / Variant is Heltec Wifi Kit 32
Ground Mode
Battery_mAh_Source = 3 - Define battery capacities in the LUA script
RSSI Override for testing = 70%
Mavlink WiFi In
Mavlink Serial Out
WiFi mode is STA
Protocol is TCP/IP
No Bluetooth options selected, BT support not compiled in
Mavlink serial on pins rx = 27 and tx = 17
S.Port on ESP is inverted on tx pin = 14
Wi-Fi mode set to STA sucessfully
Trying to connect to RHS_FPV_MOBIL.
WiFi connected!
Local IP address: 192.168.4.94 port: 5760
WiFi RSSI:-50 dBm
Local tcp client connected to remote server IP:192.168.4.91 remote Port:5760
TCP server started
Web support active on http://192.168.4.94
S.Port scheduler buffer full. Check S.Port downlink
hb_count=1
hb_count=2
hb_count=3
Mavlink good!
Mavlink from FC #33 GPS Int: ap_lat=52.xxxxxx ap_lon=7.xxxxxx ap_amsl=44 ap33_alt_ag=-0.1 ap33_vx=-0.01 ap33_vy=0.00 ap33_vz=0.05 ap33_gps_hdg=18.6
Mavlink from FC #24 GPS_RAW_INT: ap24_fixtype=4 DGPS/SBAS aided sats visible=12 latitude=52.xxxxxx longitude=7.xxxxxx gps alt amsl=44.9 eph (hdop)=95.00 epv (vdop)=160.00 vel=0.310 cog=189.4 alt_ellipsoid)=0 h_acc=4787 v_acc=7298 ap24_vel_acc=1440 ap24_hdg_acc=0
Mavlink from FC #33 GPS Int: ap_lat=52.xxxxxx ap_lon=7.xxxxxx ap_amsl=44 ap33_alt_ag=-0.1 ap33_vx=-0.01 ap33_vy=0.01 ap33_vz=0.05 ap33_gps_hdg=18.6
Mavlink from FC #24 GPS_RAW_INT: ap24_fixtype=4 DGPS/SBAS aided sats visible=11 latitude=52.xxxxxx longitude=7.xxxxxx gps alt amsl=44.8 eph (hdop)=98.00 epv (vdop)=164.00 vel=0.070 cog=189.4

If the host (dragonlink) is in Access Point mode, it has IP of 192.168.4.1, it runs DHCP, which will hand out IP leases, starting with 192.168.4.2, and the .3, .4 and so on. Remember, the host is the GATEWAY in this scenario, and the gateway on your connecting clients should be set to 192.168.4 1 when they connect and accept the IP lease from the host. If you are hard coding the IP to 192.168.4.94 that is fine, but you must also hard code the gateway to 192.168.4.1.

No, the host (dragonlink) is normally not AP but STA on the mobile router. The router has the IP 192.168.4.1 and provides DHCP. Have a look at the monitor log …

So the gateway is the mobile router. There all devices connect.

And in this constellation, I wonder how Mave2PT has to be set up so that the other devices (phone, laptop) can use the connection too.

Ok, I remember now. :wink:

Well, I guess you need a router there then. I did some googling, and found that the class libraries do not automatically handle multiple clients. There are a few guys who have coded routing tables to keep track of client instances.

But I have it … This is a mobile LTE router, which I use when several clients need to access the Internet. And in this Wifi network the modules with Mav2PT should hang.

What happens in your constellation if you want to integrate Mission Planner or QGC there? Does that work?

At the very beginning we were able to build several connections at the same time. But I have always worked with UDP and it has worked before.

Does that fit together?

config.h:

#define UDP_Broadcast // Comment out if you will always have only one client UDP GCS at a time
// NOTE; UDP is not a session based protocol. To communicate with > 1 client at a time, we must broadcast on the subnet

Code:
#if (not defined UDP_Broadcast)
UDP_remoteIP = UDP.remoteIP(); // remember which remote client sent this packet so we can target it
#endif

If the define is not available you save the UDP_remoteIP. But the define is set by default, what are you doing then?

It’s an option, so it’s ok.

I will try to code multiple clients tomorrow Reinhard. I have some idea what to do.

Reinhard, I’ve added support for multiple incoming TCP clients. At this stage 5 simultaneous clients are supported, but it’s easy enough to add more.

I also tested multi clients on UDP and it works for me when I make simultaneous connections from my tablet and my phone, using QGC. I did not test MP.

v2.26.0. I would appreciate your feedback.