No, it’s not a problem. In fact, it is desirable because QGC and/or Mission Planner will respond to it. Or a future device that only Mavlink receives.
In my case the Mav2PT Tracker client only receives Mavlink but does not send anything. From Heltec Wifi 32 only the TX line goes to the tracker. RX is not connected.
Yes, that would be best in your case, though it should not really matter. It would be the default where mav2pt(2) would send before it has received anything.
Whether the definition of a “UDP_serverIP” in config.h might be useful? Then you could always give it to the UDP client and it would always work to send a client, if necessary.
I will do a complete test again later. If that’s ok, should I write something in the wiki for such specialties?
That would be great. I did a small writeup this morning but I value your perspective.
When I reinsert the code the Mav2PT tracker tells contact itself… 
.
So UDP does not work with Mav2PT client yet, no problem with QGC or MP.
The tracker must send a packet to the mav2pt(1) immediately after connecting.
Or it will not receive a packet and determine the remote IP
In my opinion no …
Mav2PT(1), where the tracker is connected via serial cable, must send a packet to the Mav2PT server. The tracker itself is stupid, only Mavlink packets arrive and that’s it.
I think that this code …
UDP_remoteIP[3] = 255;
… is responsible for the problems.
This will overwrite the remote IP of the Mav2PT server with the broadcast address and Send_UDP will go to all. From the point of view of the Mav2PT server this is correct, but in my opinion the Mav2PT client must directly address the server IP for a response.
As already mentioned, this already worked with v2.61.9.
The problem is tricky, but still fascinating. … 
Reinhard, I have restored the #define UDP_Broadcast from v2.61.9.
In v2.62.1
You probably need to de-activate it, so when the remote udp client sends a packet, mav2pt remember the IP and will target it in future.
I’ll have to leave you to tinker with this because I’m going to be very busy for the next few days 
Hi Eric,
thanks, I will test it again later.
Other things are certainly more important than Mav2PT, so no problem. Read you soon … 
Test result:
Mav2PT Tracker somehow doesn’t get Mavlink data. A “MavGood” never comes. But when Mission Planner starts on laptop, its IP appears as connected on the Mav2PT tracker. Probably also on the Mav2PT server, but I don’t have a monitor log of that. That seems to be ok.
QGC and Mission Planner work as usual with UDP.
With TCP it looks better. So both Mav2PTs are running without any problems and QGC and MP are working as well. What I personally don’t like about TCP is the dependency on IP addresses and I have Crossfire instead of Dragonlink, which is currently only UDP capable.
But the UDP problems can wait, especially since it is a special configuration with the LTE router. Without router with AP it works IMHO., but I am still testing that.
We need to keep a table of UDP_remoteIPs, because presently
the most recent one will prevail. I’ll see if I can fit this in today.
Starting stress tests in AP mode:
Starting MavToPass_v2.62.1 …
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 Bluetooth In
Mavlink WiFi Out - WiFi mode is STA/AP
Protocol is UDP
Bluetooth master mode host RHS_CF is trying to connect to slave Crossfire 0277. This can take up to 30s
Bluetooth done
S.Port on ESP is inverted on tx pin = 14
Wi-Fi mode set to WIFI_AP
AP IP address: 192.168.4.1 SSID: CF_AP
UDP started, listening on IP 192.168.4.1, port 14555
Web support active on http://192.168.4.1
hb_count=1
hb_count=2
hb_count=3
Mavlink good!
UDP client connected, remote IP: 192.168.4.2, remote port: 14550
[QGroundControl loads the parameters from here and stops at about 90%. After that the following messages appear:]
Mavlink to FC: #20 Param_Request_Read: gcs_target_system=1 gcs_req_param_id= gcs_req_param_index=39
Mavlink to FC: #20 Param_Request_Read: gcs_target_system=1 gcs_req_param_id= gcs_req_param_index=40
Mavlink to FC: #20 Param_Request_Read: gcs_target_system=1 gcs_req_param_id= gcs_req_param_index=41
[some lines deleted]
Mavlink to FC: #20 Param_Request_Read: gcs_target_system=1 gcs_req_param_id= gcs_req_param_index=195
Mavlink to FC: #20 Param_Request_Read: gcs_target_system=1 gcs_req_param_id= gcs_req_param_index=196
Mavlink to FC: #20 Param_Request_Read: gcs_target_system=1 gcs_req_param_id= gcs_req_param_index=197
abort() was called at PC 0x401c6797 on core 1
Backtrace: 0x40092874:0x3ffd5380 0x40092aa5:0x3ffd53a0 0x401c6797:0x3ffd53c0 0x401c67de:0x3ffd53e0 0x401b8fdb:0x3ffd5400 0x401b90ce:0x3ffd5420 0x401b9085:0x3ffd5440 0x400dc8db:0x3ffd5460 0x400d82d1:0x3ffd54a0 0x400d8463:0x3ffd54f0 0x400d9471:0x3ffd5530 0x400e35c9:0x3ffd5590 0x4008ef89:0x3ffd55b0
Rebooting…
ets Jun 8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1216
ho 0 tail 12 room 4
load:0x40078000,len:9720
ho 0 tail 12 room 4
load:0x40080400,len:6364
entry 0x400806b8
Starting MavToPass_v2.62.1 …
If the STA mode is used with an LTE router, it runs completely trouble-free. In AP mode and when Bluetooth and Wifi are active, resources are likely to be limited.
Hi Reinhard
Yeah, I got back onto this this morning, added code to target the UDP IP and it was working well until, crash.
This (in WiFiUDP.cpp) appears to be the problem:
int WiFiUDP::parsePacket(){
if(rx_buffer)
return 0;
struct sockaddr_in si_other;
int slen = sizeof(si_other) , len;
char * buf = new char[1460];
if(!buf){
return 0;
}
and more specifically:
char * buf = new char[1460];
So the unique pointer class is trying to create a memory object to parse the UDP packet and BOOM.
It should free the memory automatically when it goes out of scope, but?
I have another busy day here, but will look at ways to save memory space.
“new” does not auto de-allocate when it goes out-of-scope. You need to do that explicitly.
std::bad_alloc is the type of the object thrown as exceptions by the allocation functions to report failure to allocate storage.
You basically have run out-of-memory, because you constantly allocate without de-allocating.
Thanks for chipping in. The code is in the WiFiUDP class lib, but my understanding is that that is a unique class pointer.
I’m pretty sure we have run out of memory. It only seems to happen when I allow multiple UDP clients simultaneously.
std::unique_ptr is a smart pointer that owns and manages another object through a pointer and disposes of that object when the unique_ptr goes out of scope.