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

Target0815 · September 8, 2020, 6:07pm

Hi Eric,

You are a genius …!

Now several Connects work simultaneously. Both with UDP and TCP. Top!

I have tested like this:

Updated ESP32 in Dragonlink to v2.62.0
autom. connect from QGC via UDP
autom. connect from MP via UDP

If the flight mode is changed in QGC, it changes synchronously at MP! Top!

But there is still a problem when the tracker module should connect. This does not work yet. For TCP I have attached the monitor log. But it does not work with UDP either.

You would have to try if a module with WiFi-In can connect to a module with Wifi-Out, which worked yesterday, but not with v2.62.0.

Starting MavToPass_v2.62.0 …
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:-42 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

adcam · September 9, 2020, 6:25am

Eric
I am using openhd with ardupilot 4.0.5. radio is taranis x9d & crossfire
As I really like yaapu script, can I use your converter in this way :
Piground (tx/rx) ===> your converter ===> taranis sport in the bay

Thanks

Eric_Stockenstrom · September 9, 2020, 6:54am

Hi Reinhard, thanks for the kind words, but we are not quite there yet.

Mav2PT generally runs as a server. However, if Mavlink FC side I/O is selected, we become a client of the sending device. Mav2PT will host one, and only one, “outgoing” local tcp client session. Only one is possible, because you can logically only have one source of Mavlink telemetry to translate and pass on.

If we select Mavlink WiFi GCS side I/O, and remember we are a server, we now accept multiple “incoming” remote tcp client sessions. These could be QGC, MP and a tracker and so on. Each remote client device would need to initiate a proper tcp client session before it could receive and send tcp traffic over that socket.

To date we have not supported WiFi FC side I/O AND WiF GCS side I/O simultaneously, though the code is there if we choose to activate it. Mav2PT would then be a WiFi RELAY, in addition to a S.Port translator. In our options right now, both default and web settings, we make FC wifi I/O and GCS wifi I/O mutually exclusive.

EDITED for clarity.

Target0815 · September 9, 2020, 7:25am

Hi Eric,

I thought I had already explained that …

Mav2PT in Dragonlink TX is the server and works now with several clients as tested yesterday. The Mavlink data is output via Wifi.

Mav2PT in the tracker is a client which accepts Mavlink via WiFi and sends the data to the tracker via serial.

You had tested exactly this constellation successfully. But with v2.62.0 this does not work anymore. But with v2.61.9 it does.

Eric_Stockenstrom · September 9, 2020, 7:29am

Sorry, Reinard, I’m not clear about the ESP in the tracker. Is this the one with WiFi in and serial out?
EDIT: Did you update both firmwares?

Eric_Stockenstrom · September 9, 2020, 7:39am

Hi adcam

Do you mean Pixhawk :

Yes, you can use Mav2PT in ground mode in the back bay of the Taranis. I suggest the Teensy 3.2 version,

EDIT: or esp if you want to connect to the DL wifi.

Target0815 · September 9, 2020, 7:41am

Yes Eric, the ESP in the tracker ist the one with Wifi in and serial out and i have update both firmwares. Also with deleting the config ram.

Eric_Stockenstrom · September 9, 2020, 7:46am

Ok, I get it now. Sorry, it’s a bit hectic here right now. So I need to look at the “Local outgoing tcp client connect failed, retrying” message. Will do.

Eric_Stockenstrom · September 9, 2020, 8:12am

I just tried it here:

Starting MavToPass_v2.62.0 .....
Display support activated
EEPROM initialised successfully
EEPROM settings read and adopted
Target Board is ESP32 / Variant is Dev Module
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/AP
Protocol is TCP/IP
Mavlink serial on pins rx = 16 and tx = 17
S.Port on ESP is inverted on tx pin = 4
Wi-Fi mode set to STA sucessfully
Trying to connect to MavToPassthru.
WiFi connected!
Local IP address: 192.168.4.2  port: 5760
WiFi RSSI:-25 dBm
Local tcp client connected to remote server IP:192.168.4.1 remote Port:5760
TCP server started
Web support active on http://192.168.4.2
hb_count=1
hb_count=2
hb_count=3
Mavlink good!

EDIT: Maybe your boards were very close? Or there was some other interference?

Target0815 · September 9, 2020, 8:19am

With TCP, a server must be addressed by IP address. The Mav2PT server does not have the IP 192.168.4.1 but is a Wifi client in the network of the LTE router with the client ID 192.168.4.91.

Do I have to change the server IP address for the Mave2PT in the tracker?

With UDP a broadcast is sent, server/client connect automatically, there is no actual server IP, only the broadcast address .255. But also a UDP connection of Mav2PT in the tracker is not possible.

You can connect two Mave2PT modules to your own wifi network if available. There you see the problem.

Target0815 · September 9, 2020, 8:26am

Can I somehow debug where, to which IP address, the client wants to connect?

The Mav2PT modules have a distance of about 3 m. This is not critical.

Eric_Stockenstrom · September 9, 2020, 8:58am

Line 705 in Utilities tab

while (!newClient.connect(TCP_remoteIP, TCP_remotePort)) {

Target0815 · September 9, 2020, 9:27am

If in your constellation your Mav2PT client wants to connect to 192.168.4.1 via WiFi, your Mav2PT server will run with the IP address 192.168.4.1 as access point. Correct?

But if your Mav2PT server is configured as STA/AP and is connected to a WiFi router as a client, what would you change on your Mav2PT client side to allow it to connect to the Mav2PT server?

Eric_Stockenstrom · September 9, 2020, 10:30am

Assume mav2PT (1) is the DL esp32 in STA mode and received IP 192.168.4.X from the LTE router, and will probably have gateway 192.168.4.1

Then we have mav2pt(2), the tracker esp32, also in STA mode. It also connects to the LTE router and receives IP 192.168.4.Y.

Do I have this correct now?

So with mav2pt(2) we must create a local outgoing client to connect to 192.168.4.X, on port 5760

Line 705:

while (!newClient.connect(192.168.4.X, 5760)) {

Target0815 · September 9, 2020, 10:33am

Yes, that is correct.

Eric_Stockenstrom · September 9, 2020, 10:45am

So this should work:

Line 855 in config.h

IPAddress TCP_remoteIP(192,168,4,X);

Line 705 in Utilities

while (!newClient.connect(TCP_remoteIP, TCP_remotePort)) {

Reserve the static Ip 192.168.4.X on the LTE router for mav2pt(1) so that you never get a duplicate, and hard code local ip in mav2py(1)

Target0815 · September 9, 2020, 10:48am

Yes this now works with TCP. Top!

But UDP does not work yet. What has to be changed?

adcam · September 9, 2020, 11:00am

thanks a lot
Piground is the raspberry Pi 3 that I am using for openhd (not sure you use it)

I just purchased a teensy 3.2

Adolfo

Eric_Stockenstrom · September 9, 2020, 11:03am

For UDP, mav2pt(1) should broadcast on 192.168.4.255.

All IPs on your LTE LAN 192.168.4/24 will receive the packets. Is this a problem?

The router might block broadcasts (usually optional).

In mav2pt(2) you will also broadcast back on 192.168.4/24, but that is probably a bad idea.

In v2.61.9, main tab, around line 1263 I had:

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

What this did was on Read_UDP() remember the sending udp IP, and use it when replying. Could you try it?

Target0815 · September 9, 2020, 11:07am

Yes, I will check that later.

What about these lines in the config.h?

   IPAddress UDP_remoteIP(192, 168, 1, 255);   
   WiFiUDP UDP;                                 // create UDP object

Perhaps 192.168.4.255 …?