WiFi/UDP Tx blocked on Android?

I have PX-4 1.17, QGC 5.1.4 and 5.0.8. I am running Mavlink over ExpressLRS and connecting QGC using WiFi from the transmitter’s “backpack”. From my laptop this works. From Android 16 and 17, transmission from QGC to the UAV appears to be blocked. I can get telemetry from the UAV but nothing goes to the UAV. The best I’ve been able to get is the following sequence:

  • Power up the transmitter
  • Power up the UAV
  • Connect the android to the UAV using USB
  • QGC auto-launches and does the full parameter exchange
  • At this point everything works except that the UAV is on a VERY short leash
  • After the parameter exchange, connect the Android to the Tx’s backpack WiFi.
  • Disconnect the USB cable
  • Now telemetry continues to flow from the UAV to QGC, but no commands go to the UAV.

It all works fine over WiFi from a Linux laptop. Any help would be appreciated.

When you say it works fine over WiFi from Linux laptop. You are doing the exactly same sequence on the laptop:

  • WiFi disabled
  • Connect over USB
  • Enable WiFi
  • Disconnect USB

Is that correct?

No. Though I do sometimes hot swap between WiFi and USB on the laptop, it doesn’t require the USB jump start. QGC on Android will detect and receive telemetry without the USB step, but it fails at getting all the parameters and settings. The USB step is to achieve that initial exchange of information then hot swap over to WiFi to a one way data context, but at least the USB cable can be removed from the system.

I understand all of that. But unless you have done the exact same sequence of steps on both android and desktop there is no confirmation this is an android specific problem!

I have done the same thing. On the laptop I connect to the backpack WiFi and start up QGC and everything just works. If I do the same with Android, it gets some telemetry but stalls and fails to get all the parameters and any other data. I’ve run into this problem attempting to use QGC on Android with Ardupilot also.

It happens that I often connect QGC on my laptop over USB first because it doesn’t require plugging in the battery. Sometimes I then hot-swap over to WiFi because I need to disconnect from the cable. That works flawlessly on the laptop and it remains fully functional.

When I say that I don’t do the hot swap with my laptop, I mean that it isn’t normal practice and isn’t required because WiFi works as expected.

Ok, can you create an Issue for the Android problem with exact steps to repro. Firmware/Android/… version numbers? I’m not sure android recognizes an hot unplug of a USB connection like desktop does. Hence there is might never be a failover to WiFi. It sill talking bi-directional on a dead USB connection.

Is this with ELRS? ELRS telemetry is so crazy slow it’s hard to get things like params across that lik.

I am using Mavlink over ELRS. With Ardupilot, sometimes it would do the initial exchange at a reasonable pace. Sometimes it could take 5 minutes. I have much less experience with PX4 (haven’t gotten off the ground yet) but it seems to always (or almost always?) be quite quick. …but not at all fast enough for download of log files.

I will create a github issue.

Reading the issue you (@DonLakeFlyer ) linked in Discord, this message appears relevant:

Disabling mobile data results in two way communication. Rather than being a security issue, it may be a routing issue as @ClockeNessMnstr suggests.

I have not created a new issue as this appears to be the same one.

Hi @j3kestrel and @DonLakeFlyer,

The findings in QGroundControl issue #12579 seem to narrow this down significantly.

The fact that disabling cellular data restores bidirectional MAVLink communication, and re-enabling it breaks the outgoing path again, points toward Android network-interface selection rather than an ELRS bandwidth limitation alone.

I also noticed that @HTRamsey mentioned working on Android-specific interface management.

A useful regression test would be to keep the vehicle connected over Wi-Fi while toggling cellular data, then verify that outgoing UDP traffic continues to use the intended Wi-Fi network.

It may also be worth checking the behavior after Wi-Fi reconnection and when the Wi-Fi network has no internet access.

Is there already a PR or test branch for the Android network-routing fix? If so, I would be interested in reviewing the regression-test coverage.

Best regards,
Yiğitcan Öztürk
PAMILANGA LTD

Add yourself to that Issue with respect to helping out testing fixes. There is no fix yet for this.