I’m having some trouble with my bait boat setup and could really use some advice. My UDP connection seems to be only partially working, and I’ve run out of ideas.
Because this is a bait boat project, my ultimate goal is to use QGroundControl (QGC) wirelessly at the waterfront, but due to this issue, QGC is completely unusable for me right now.
My Setup:
FC: Mateksys F405-WTE
Firmware: ArduRover V4.6.3
GCS: QGroundControl (QGC)
WiFi/Telemetry Routing: TX1 → ERX and RX1 → ETX jumpers are in place!
Full Parameter List (Stalls out and fails to load in QGC)
What IS working (Partial telemetry is coming through):
Virtual horizon works perfectly.
It sees the boat’s GPS signal and places it accurately on the map.
Some basic settings/commands still work.
What I’ve tried so far:
I’ve changed and tested various Baudrates both in ArduPilot and on the web interface, but the issue persists. It just won’t pull the full parameters.
Has anyone experienced this kind of partial data loading over UDP with QGC using this ESP firmware? Any ideas on what parameters or hardware settings I should check next?
I would suggest to check whether Settings > Telemtry > Stream Rates is set to “Controlled by Vehicle”. If this feature is disabled, you should be getting telemtry as this overrides the settings in ArduPilot.
If enabled and you would like to keep it so, try setting the telemetry stream rates in ArduPilot to atleast 1Hz and test to see if it works.
Baudrate for the Serial port on the FC used, SERIALx_BAUD, and the MAVLink WiFi Bridge setting to 921600 for starters. I use thoese on lots of models and it’s straight forward. Here is one I just connected:
Well one reason is that we may need more range. I haven’t tested at 921000 because 115200 already works for me. I am using it for guided missions but you may be using it as a substitute for USB.
My point being it unlikely the OPs’s issue is due to low baid rate. AFAIK, it should work perfectly well even at lower baud rates
I’ve found the source of the issue! Since one of the jumpers bridges RX1 and ETX on the Mateksys F405-WTE to enable WiFi Telemetry, while the radio control signal cable is connected to the RX2 port, they are conflicting.
Why does RX2 “knock out” the WiFi RX1 port on the Mateksys F405-WTE?
Port Mapping: In the architecture of the Mateksys F405-WTE, RX2 defaults to the SERIAL6 port in ArduPilot and is dedicated to the RC (radio control signal) input.
Data Overload: Modern radio control protocols (such as SBUS, CRSF, or IBUS) send high-density data packets hundreds of times per second (up to 400 Hz).
Hardware Suppression: If the radio receiver is connected to RX2, the microcontroller’s Direct Memory Access (DMA) channel and interrupt handler become so overloaded with the continuous decoding of incoming RC signals that it physically suppresses the interrupt requests arriving on the adjacent RX1 port (the WiFi MAVLink channel).
Crosstalk: Additionally, the power draw or signal noise from the high-frequency RC receiver module can cause crosstalk on the closely routed RX1 and RX2 traces on the PCB.
The perfect solution to resolve this:
Since the RX2 port hardware-wise “drowns out” the RX1 port, you simply need to separate them physically on the board!
