Some packet loss is common on a radio link, and since the FC is sending repeating groups of situational data many times a second, you likely won’t notice.
Nevertheless, understandably we would all prefer zero packet loss. Packet loss can occur and is measured between the FC and the GCS by detecting missing packet sequence numbers. In your case, if you are using WiFi, you have two radio links, possibly in the same room. Even radios on different bands, but with a few watts of power (30dBm) located within a few metres of each other will interfere. Wifi and Bluetooth both use 2.4 GHz and other nearby Wifi appliances could affect your Wifi link from the ESP to the GCS. Computers also generate a lot of rf hash. Try download Wifi Analyzer onto you phone and check which WiFi channels near you are occupied, and in MavToPT go to WiFi setup and try a different channel. I think I set the default to ch 9. Move your aircraft at least 20m away and set the radios to low power. Try to get the antennas in the clear, away from computers, routers or switches. Make sure no one is using a microwave oven nearby(ch 6 on the wifi band).
Lowered power to 10dbm on radios, moved plane away by 30 feet, and still getting huge amounts of packet loss.
Zero packet loss when using usb ftdi. Perhaps there is something wrong with the network setup? I’m using udp with broadcasting disabled - should I try tcp?
I have now tried another network with the exact same results. Unusably high packet loss, 25-50%. Do you think that it could be possible that my wifi kit 32 is doa?
Yes, it’s easy enough to try TCP/IP. Some cheap boards do have poor rf performance, but you would need to decide. Do you get lost packets when using QGC on an android tablet?
Got an issue with v2.61.7 i connect to GCS let it load works but as soon as turn on the TX after about 10 sec i get GCS Heartbeat lost GCS stops but Yaapo is working on the tx fine
Mavlink from FC #22 Param_Value: param_id=STAT_RUNTIME param_value=145298.0000 param_count=1065 param_index=-1
Mavlink from FC #22 Param_Value: param_id=GND_ABS_PRESS param_value=99466.6875 param_count=1065 param_index=-1
[E][WiFiUdp.cpp:183] endPacket(): could not send data: 12
[E][WiFiUdp.cpp:183] endPacket(): could not send data: 12
[E][WiFiUdp.cpp:183] endPacket(): could not send data: 12
[E][WiFiUdp.cpp:183] endPacket(): could not send data: 12
[E][WiFiUdp.cpp:183] endPacket(): could not send data: 12
[E][WiFiUdp.cpp:183] endPacket(): could not send data: 12
[E][WiFiUdp.cpp:183] endPacket(): could not send data: 12
[D][WiFiGeneric.cpp:337] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:353] _eventCallback(): Reason: 10 - DISASSOC_PWRCAP_BAD
and the only way i can get it to start again is reboot esp32 dont turn on the tx can only use one at time
buttons work great
i am trying to connect a tracker to the Heltec module. If Mavlink is received via WiFi (which works) and Mavlink is to be output via the pin on the Heltec module again, which pin is right for this? Pin 17?
I coded a serial out for completeness, but never finished it off. I guess I could not imagine your scenario with wifi (or BT) in and serial out. Let’s see if I can finish it off in the next day or two.
Mavlite is Alex’s lite two-way protocol using FrSky telemetry to support a LUA mini GCS on the Taranis etc screen. In mav2pt it is still work in progress.
, I was wondering why it didn’t work. I would be happy if that would work too, that’s what makes Mav2PT really round
I have also noticed that the module often crashes / restarts when the Web-GUI is called and if not at the latest when logging in to the Web-GUI. I did not integrate Bluetooth, because I know about the memory problem. In any case I never managed to call the configuration page. I can put my config.h at your disposal …
Starting MavToPass_v2.61.8 …
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 Out
Mavlink WiFi In
WiFi mode is STA
Protocol is UDP
No Bluetooth options selected, BT support not compiled in
S.Port on ESP is inverted on tx pin = 14
Wi-Fi mode set to STA sucessfully
Trying to connect to RHS_FPV_MOBIL…
Failed to connect in STA mode
No web support possible
S.Port scheduler buffer full. Check S.Port downlink
I’ve tried to setup the simple ground Teensy 3.2 converter (for Taranis telemetry with no GCS) but I think I’m missing something since the S. port has only two or maximum four messages every second - the same messages although the converter LED turns on (stop flashing).
If I understand correctly, the converter Tx line has to poll request the Cube FC (Mavlink 1/2 protocol) and the Mavlink answer from the FC enters the converter by its Rx line.
Is it possible just to use the downlink (Rx) channel of RFD900 for telemetry so that the uplink channel can be used for other usage?
The converter will work using the FC tx to rx only, with one or two drawbacks.
1 The converter cannot request battery capacity parameters from the FC, but you can work around that.
2 Yaapu’s great LUA script cannot request waypoints.
3 The converter cannot request data streams. You must setup the SRx parameters through Mission Planner
That’s about it I guess.
Two to four messages a second sounds far too slow. Have you selected Ground or Air mode? If you could post your monitor log, and perhaps a TLog would be helpful.
, I was wondering why it didn’t work. I would be happy if that would work too, that’s what makes Mav2PT really round 