Looking back through the archived code, the parts relevant to UDP in utilities.ino changed after 2.63.3, I compiled that version and UDP works again. Anything newer than that, which appears to have the code changed for wifi connection to a FC, isn’t working for me.
For what it’s worth, I compiled the latest version set up for AP instead of STA mode, and connected directly to the Heltec module and was still unable to get data into the GCS via UDP. I wanted to rule out any problems with my router. I tried both with my PC running QGroundControl and Mission Planner, and with my phone running QGC. Both work fine with v2.63.3 or older in both STA and AP modes.
Keith, I noticed that you have the UDP switched around from the default config? This is the default:
uint16_t UDP_localPort = 14555; // readPort / MP and QGC expect to send to this default FC UDP port
uint16_t UDP_remotePort = 14550; // sendPort / MP and QGC listens & reads on this default port
This is from your log for v2.67.1, which you confirm works:
Begin UDP using STA UDP object read port:14550 send port:14555
This is from your log for v2.62.7:
UDP started, listening on IP 192.168.0.55, port 14555, which is correct.
I’ve not done anything to swap them, I double checked and they are set correctly as you posted above in config.h. However, knowing what to look for, I flashed v2.67.1 again and sure enough, local port was 14550 and remote 14555. When it boots it shows on the display that local port is 14550, and logging into the web GUI, they were set there as local 14550, remote 14555. I changed them in the GUI and saved/reboot, and everything started working as expected. Yay! The change persists after a reboot and after a power cycle.
Just to be sure, I erased the ESP32 with ESP32 flash tool, then uploaded the firmware again using #define Reset_Web_Defaults just to be sure no old settings were left behind somewhere. The ports were swapped around again, and changing them in the web GUI fixed it again. I don’t understand why they’re getting swapped, but at least we know where the problem is… lol
Great news. Yes the EEPROM/web settings prevail. You can reset them with
//===========================================================================================
// Most of the settings below are saved to EEPROM the first time mav2pt runs
//#define Reset_Web_Defaults // Reset settings in eeprom. Do this if you have changed settings below, or
// suspect eeprom settings are corrupt - USE SPARINGLY. Do not leave this macro active.
//===========================================================================================
i had to do this on TTG0 i had some issues on the latest this week
sorry i should said something yesterday but i forgot to post it yes this fixed my issue
i did even flashed the TTG0 update firmware it did not reset wifi
if you go 18 days you will my message i was having issues i was changing the config.h ( pasword ) and it was not updating it till i did #define Reset_Web_Defaults
I’ve been meaning to make NVM/EEPROM settings reset easier. From V2.67.2 you can reset eeprom settings to the default config.h settings on-the fly by holding a pin high (3.3v) for 10 seconds. The pin number depends on the variant, and is defined in the platform dependent settings in config.h.
I have a little strange problem and not 100% sure this is the right place.
I use the Horus X12, with an teensy and the latest mavtopass. Works fine, we changed on the drone the GPS module from I2C to a mRo Location via Canbus. Works also fine, but it does say after a while, GPS Lost and the yapuu telemetry shows “no lock” But it does have still GPS and shows it in Mission planner. All other telemetry works also fine on the Horus, just GPS.
If we connect the I2C GPS module again, this does not occur.
Any chance that somebody would know where the problem could be?
You don’t mention the type of flight controller, but I’m assuming it is a Pixhawk. Since the GPS data looks good on MP, there should be no problem, as this is the basis for the FrSky telemetry.
The quickest way to solve this is by looking at a TLog out of MP, while you are getting a good GPS display on the HUD. Could you please post the TLog here on this thread. A serial monitor log out of Mav2PT, from boot until good GPs status would also be very useful.
EDIT:
Alternatively, you can compile and flash Mav2PT with the following debug macros (in config.h) activated, and observe the GPS status on the serial monitor yourself, or post it here.
I am trying to use an existing Mav2pt setup with my Frsky X20 Ethos firmware. Unlike on opentx, discover sensors immediately populate the telemetry data into the sensor tabs. But on ethos, I need to add the sensors individually. Selecting autodetect shows the ID which are similar to what we have on the mav2pt firmware (e.g. ID 5000, 5001, 5002 etc)
But I tried the IDs detected, such as 5001 (which is AP_Status on mav2pt), and i found it to be equivalent to flight modes on Ethos. I got that working and was able to check the values change everytime I switch flight modes.
Next, I tried 5003 which should be Bat1, but apparently Im not able to retrieve voltage reading on the ethos telemetry page. the same thing happens when I try the other IDs… any ideas? hope to hear from you. thanks!
Erwin,
as I told you on RC Groups this won’t work.
There’s no way at the moment to use Ethos either with MavToPT or ArduPilot.
The MavToPT project creates the very same telemetry frames that ArduPilot uses for the passthrough protocol, it’s a protocol translator from mavlink to passthrough which is NOT a standard frsky telemetry protocol and as such cannot be “discovered” as sensors the usual way.
If you read carefully my wiki (the one you cited in the above post) you’ll note that my scripot “exposes” i.e. creates sensors after decoding the relevant info from the telemetry stream which cannot be decoded by OpenTX and thus requires a custom lua decoder. MavToPT has the very same requirements: it requires a lua custom decoder!
THat makes sense now, I thought we can have a workaround via mav2pt, since I was able to validate one of the ID (for flight mode changes), but yeah, apparently, it needs to undergo further decoding… no choice but to wait for an official LUA script for ethos
I noticed that FrSky are punting Ethos on their new RC controllers (TXs), but I don’t know much about it, other than what you published above (and a quick look on the web). So it looks like an improvement on the proprietary FrSky controller firmware, maybe to draw the RC community back into golden handcuffs and away from open OpenTX.
Yeah, apparently it seems that Frsky is try to lead us to that path haha! But nonetheless, if the LUA script will be developed soon, then I guess we are a step closer to introducing Alex’s Yaapu and your Mav2PT which i really loved on my X10s… It’s also the reason why I am still using the x10s even if i just got a X20 (gift from my wife )
Hi Eric,
yes general consensus is that it’s better than FROS and getting better with every release.
The author is Bertrand Songis which is also one of the core developers of OpenTX, I do have an early batch sample of the X20 and I love the form factor, it’s compact with the screen at the top.
The good thing is that Bertand is “listening” a lot to user requests, there’s a dedicated github site which is something really new for a closed source project, lua support is not yet there though.
Thanks for the background information Alex. It certainly looks the business, and reading between the lines you expect lua support at some point. Erwin, I’m going to drop a hint that my friend Erwin’s wife gifted him a Tandem X20, and see what happens. I’m guessing that my wife might want to know what happens to all the existing kit that was “essential” last year. I actually bought and installed the ISRM and Para upgrades for my Horus X10 earlier this year. It’s hard to keep up with all the changes at FrSky, but perhaps at least the telemetry standard will settle on F.Port2 for a while. The new receivers are quite expensive, and so are the transmitters, so one would expect to use them confidently for a few years, no?
Alex, I was wondering if the new FrSky transmitters have upgraded processors and memory, so when/if lua comes along you are not pushing the hardware boundaries again.
Hello. After i made my telemetry working on my qx7. Now please is there a way t connect esp32 devkit to sport of r9m. To make it transmit the telemetry data through Bluetooth. To my android phone using telemetry view app. I looked everywhere and couldn’t find any helpful info. Like wiring and code. All i found was through hc05 Bluetooth. And unfortunately i don’t have it. Plus the transistor too. Can you help me please
There you will find firmware for most ESP32 boards that will take the S.Port telemetry signal from the R9M, and optionally send BT or WiFi. The telemetry structure and content remains unchanged, so hopefully the phone app can use it (though I can’t guarantee it will work). Maybe try it and see. The pin wiring depends on the board you use. See config.h for a variety of pupolar boards, and their pin configuration. You need S.Port and ground wires only, and maybe power for the ESP32 board.
hey eric, im trying the 2.67.05 version on my heltec relay setup. it was working a bit right. im receiving batt voltage, sat count, gps coordinates… im able to connect with qgroundcontrol. but i cant get yaapu telemetry on my horus x10s. also, rssi is stuck at 70%… rolling back to 2.62.8 made everything work again…
these are the lines that i have modified (aside from the ap name and password)
line 52 #define FrSky_Port_Type 3 // S.Port / legacy
line 76 #define Relay_Mode // Translator between LRS tranceiver (like Dragonlink) and FrSky receiver (like XRS) in relay box on the ground
line 98 #define GCS_Mavlink_IO 2 // WiFi - ESP32 or ESP8266 only - auto selects on ESP8266
line 115 #define FrSky_IO 1 // Serial
line 141 #define ESP32_Variant 4 // Heltec Wifi Kit 32 - Use Partition Scheme: “Minimal SPIFFS(Large APPS with OTA)” - contributed by Noircogi select Heltec wifi kit
for some reason, it seems that the frsky s.port is not working if I flash it with 2.67.05… rolling back to the 2.62.08 works just fine…I have noticed that on 2.62.08, there’s a frsky baud line: #define frBaud 57600 // S.Port baud setting - default 57600
which is not found on the 2.67.5… also, theres no Frsky s/fport i/o settings on the 2.62.08…
thanks!
I’m guessing that my wife might want to know what happens to all the existing kit that was “essential” last year. I actually bought and installed the ISRM and Para upgrades for my Horus X10 earlier this year. It’s hard to keep up with all the changes at FrSky, but perhaps at least the telemetry standard will settle on F.Port2 for a while. The new receivers are quite expensive, and so are the transmitters, so one would expect to use them confidently for a few years, no?