Mav2PT stores settings in EEPROM, and it’s possible/probable that the old settings were retained when you tested with v2.66.02.
If you want to use V2.66.02 (it has better features, some bug fixes), then you could try building/flashing with
#define Reset_Web_Defaults // Reset settings in eeprom
Flash and run one time to update the eeprom setting to your default defined settings, then comment this macro out again, and flash a final time. I should probably streamline the eeprom reset process. 
Thanks for the info! I did like the telemetry info being shown in the OLED display in the newer version… lol I can try again.
For what it’s worth, I did erase the eeprom using ESP32 flash tool, when testing, but I’m not sure that’s as effective as using “#define Reset_Web_Defaults”.
Hold fire before you try it Keith, I found a problem with UDP in the latest version. When I added S.Port UDP out I broke something in UDP Mavlink out.
Keith you can try v2.67.00 now if you have the time. Thanks again for the feedback.
i did test v2.67.00 cant log into the web interphase
what is the default user and password ?
user mav2pt
pass admin
?
even if i change it in the config.h sill cant log in
admin / admin
I’ve added a comment in the config.h
Sorry for the late reply! I’ve only recently signed up here and I’m only allowed 4 comments per topic apparently… lol I had to delete one above and wait 24hrs to reply again here. Is there some other means of communication you’d like to use if I need to follow up again? (email, skype, discord, github, etc.?) I’m not sure how long the restriction is in place for new accounts here.
Anyway, I compiled v2.67.00 and I’m still seeing the same problem. I get Mavlink data into the ESP32, it’s showing some data on the OLED screen, and the message “Mavlink good!” momentarily before switching to the telemetry data. I am still not getting anything via UDP, though the ESP32 is connected to my network, and I’m able to load the web GUI. I’m also not getting any telemetry over the 2.4GHz FrSky relay into my radio.
Again, I’m using relay mode, ESP32 is set to STA, not AP. I’ve included my config.h here just in case I’m setting something wrong. The only thing I’ve changed here are my passwords and SSID. https://pastebin.com/v4V1dPAG
Keith, I’m also on github/zs6buj
The bug I found related to AP access.
The problem I have is that the hotspot I currently have access to is not managed by me and is blocking most ports, so testing STA mode is not possible . I do have a 4G router somewhere, so I’ll try to set that up for testing. STA.
Keith, I tested STA again this morning. I started a hotspot on my android phone, connected mav2pt/esp32 to the phone (in STA) using UDP local port 14555, remote port 14550, then connected my tablet to the same phone. QGC connected immediately, using default port 14550
I can reply here again, yay! lol
Could it be that I have something set up wrong in the config.h I linked to above? There’s a few more options there than in the older version that I do have working.
It all looks ok. Perhaps your setting stored in EEPROM are out of date.
You should try this, but with v2.67.01
Sorry for the late reply, I was caught up with some other projects and just got time to try this again.
I tried both versions 2.66.02 and 2.67.01 without success. I tried both with UDP targeted and broadcast (#define UDP_Broadcast commented and not). I used #define Reset_Web_Defaults.
The one thing I did notice that’s strange, and could be related… I was able to get FrSky telemetry working into the radio and yaapu by changing #define FrSky_Port_Type from the default of “3” for s.port / legacy, to “4” for auto. I’m guessing it’s detecting either f.port v1 or v2. I have it connected to a Radiomaster R161 receiver’s s.port pin, and it worked as s.port in previous versions as far as I know. Just for be sure, I replaced the R161 receiver with a FrSky XRS receiver, and got the same results.
If I fall back to 2.62.7 everything works fine. I’ll just keep running that older one unless we can figure something out… lol I’m happy to help diagnose in whatever way I can, but I’m out of ideas.
@Keith, thanks for this feedback! I have a good idea where to look for the problem. Auto also detects serial polarity and baud. If you compare the monitor logs, it should show where auto differs from non-auto.
How do I log? I can try to get that and compare and report back if needed.
Is this what you need, logged with FrSky_Port_Type set to both auto and s.port / legacy to compare? I’ll try to get that later today.
Hi Keith, yes please
OK, here’s some logs, I think they explain a lot… lol
Here’s a working 2.62.7, everything looks good as expected: https://pastebin.com/YjZWdSRQ
Here’s 2.67.01 with #define FrSky_Port_Type 3: https://pastebin.com/QPELCzWg
A couple of things stand out to me. “S.Port at 57.6kb/s selected on rxpin:13 is IDLE_LOW, inverting rx polarity” probably explains why telemetry back to the radio isn’t working. I have a hardware inverter and diode connected to pins 13 and 14, this works with the older version of mav2pt,but if this newer version is inverting then I probably just need the diode and not the hardware inverter. Also, “UDP for STA started, local 192.168.0.55 remote 192.168.0.255” suggests that UDP is broadcasting to the whole network rather than listening for clients as in the older firmware. That could explain my GCS not connecting via UDP.
Here’s 2.67.01 again, but with #define FrSky_Port_Type 4: https://pastebin.com/Tx30FgMT
Now I see “Sensed serial port pin 13 is IDLE_HIGH, regular rx polarity” so it is working with s.port is it should, just not inverting the signal and letting the hardware external I have in place do the inversion. That explains that… lol I still see “UDP for STA started, local 192.168.0.55 remote 192.168.0.255” even though #define UDP_Broadcast is commented out. Could this be why I have no UDP connection to my GCS? Maybe my router is blocking it in broadcast mode or something, but shouldn’t it be listening for clients if I have #define UDP_Broadcast commented out and work like the old firmware did?
Hi Keith
Good to see we are making progress!
UDP can work in broadcast or non-broadcast mode. In non-broadcast mode Mav2PT has no way to know what the IP of your GCS host is, until it gets a message from that GCS (say QGC). So it broadcasts to all adapters on the subnet, QGC sees a packet and replies. At this point Mav2PT remembers the IP of the GCS, and from there on stops broadcasting and targets that IP. This happens for every possible client GCS or tracker or whatever. If you keep watching the monitor log, it shows this process unfolding.
The GCS never connects though if I’m using the newer firmware. With the older firmware I see in the serial log that it’s listening, then sees the GCS connect and everything is good. With the newer firmware is seems that UDP starts broadcasting even though it’s setup for ip-targeted mode. (UDP for STA started, local 192.168.0.55 remote 192.168.0.255) Looking at the code in utilities.ino, this seems normal that it starts broadcasting until a GCS connects.
UDP_remoteIP = localIP; // Initially broadcast on the subnet we are attached to. patch by Stefan Arbes.
UDP_remoteIP[3] = 255; // patch by Stefan Arbes
That same code is present in the older 2.62.7 as well so I don’t think the problem is there, maybe it’s just logged different in the serial monitor. The older firmware never logs anything about broadcasting, just listening. I’m in over my head trying to understand the code and exactly what’s happening though… lol All I know for sure is that it works with UDP in targeted mode with the older firmware but not the new one.