Reproducible USB disconnect (LAN9500A/eth0) triggered by motor current transients — VOXL 2 Mini + Doodle Labs radio, 6S build

[Noah Heinen]

HARDWARE

• VOXL 2 Mini (M0104), voxl-px4 1.14.0-2.0.133 (PX4 v1.14), voxl-mavlink-server 1.4.14
• Doodle Labs Smart Radio RM-1700-22M3, connected per the Doodle Labs user guide:
  Port 1 (USB device) -> custom harness mimicking MCBL-00080 wiring but with
  ADDED LENGTH (D-, D+, GND on J3 pins 2/3/4, no VBUS; unshielded discrete
  JST-GH wires) -> VOXL J3. Radio appears as SMSC LAN9500A bridge -> eth0
• Radio powered separately: Port 4 from a 5V/5A Pololu buck (battery-fed)
• VOXL 2 Mini powered from the VOXL ESC's regulated output (supported config per docs)
• 6S pack, quad-X, VOXL 4-in-1 ESC (UART), ~40 A peak bench currents
• ESC firmware: as shipped (will attach voxl-esc scan output; can update from
  the voxl-esc repo if a newer build is recommended)

SYMPTOM
Every 2-5 s after arming (and reproducibly during motor transients), the USB
device drops off the bus and re-enumerates. ~2.5 s network outage each time ->
QGC loses telemetry, PX4 declares "Manual control lost" -> failsafe. dmesg shows
a clean detach with NO preceding errors:

usb 1-1: USB disconnect, device number 7
smsc95xx 1-1:1.0 eth0: unregister 'smsc95xx' ... USB 2.0 Ethernet
QTI:TETHERED link down
usb 1-1: new high-speed USB device number 8 using xhci-hcd
smsc95xx 1-1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x4DE1

No xhci transaction errors, no resets, no driver messages before any event.
Also occasional spontaneous flaps in the first minutes after boot (motors off),
often in bursts of 2-3 disconnects within seconds ("bounce storms").

KEY REPRODUCTION (no arming involved)
Stepping all 4 motors 0 <-> 65% via actuator test (props off) produces 2-6
disconnects per 8 steps, every run. Holding all 4 motors at a constant 45% for
20+ s produces ZERO disconnects. So it correlates with dI/dt (current change),
not current level, vibration, or the arming software path.

ELIMINATED BY DIRECT TEST

• Software: auto suspend disabled at all levels, no USB2 LPM on this kernel,
  rx_parse_errors=0, MAVLink v2 both ends, logging (SDLOG) A/B tested, arming
  logic excluded by the actuator_test reproduction above
• Radio supply headroom: 2.4A regulator replaced with 5A -> no change
• Harness: replaced entirely -> no change (both were unshielded JST harnesses)
• Power lead radiation: 12AWG battery leads bundled/rerouted -> no change
• Mechanical: J3 connector reseat + strain relief cured an earlier
  wiggle-to-disconnect sensitivity, but transient-triggered flaps persist
• VOXL on bench supply (instead of ESC output): background flaps stopped and
  pulse-induced flaps dropped ~6 -> ~2 per run, but not zero

CURRENT HYPOTHESES (in order)

1. ESC input bulk capacitor: this is a 6S build and the ESC's provided
   capacitor is installed at the battery connector, NOT at the ESC input pads
   (about to move it -- per @Alex Kushleyev's note that 6S without the cap
   causes "excessive noise")
2. Common-mode/ground transient across the unshielded USB harness (planning a
   bonded ground strap routed with the harness + snap ferrites)
3. Residual: VOXL-side rail dip when powered from ESC aux during transients

QUESTIONS

1. Is this failure signature known on VOXL 2 (Mini) builds with higher-current
   ESCs? Any documented fix?
2. Does ModalAI have a recommended ferrite / common-mode choke or shielded
   harness option for the J3 USB link in electrically noisy builds?
3. Is powering VOXL 2 Mini from the ESC regulated output advisable on a 6S
   ~40A-transient airframe, or is the M0041-4 power module strongly preferred?
4. Any known sensitivity of the QRB5165 USB host (xhci) to ground transients
   that would argue for specific layout practice?
5. Is there a current VOXL ESC firmware release with improvements relevant to
   6S electrical noise / switching behavior, and is updating recommended here?
   (Happy to flash latest from the voxl-esc repo if so.)
6. Baseline parameters: for a custom 9-inch VOXL 2 Mini build, which platform
   file should be the starting baseline? The candidates in
   voxl-px4-params/params/v1.14/platforms are:
   • VOXL_2_defaults.params
   • VOXL_2_fpv_defaults.params
   • M500_FCV1.params
   • M500_FCV2.params
     My understanding is the M500_FCV* files target Flight Core hardware and
     should NOT be loaded on a VOXL 2 Mini -- can you confirm VOXL_2_defaults is
     the correct base for this board, plus frame-specific CA_/VOXL_ESC_ on top?
7. USB harness between the radio and VOXL J3: ours is a custom cable that
   mimics the MCBL-00080 wiring but is LONGER than the stock cable (unshielded
   discrete JST-GH conductors, no twisted pair). Is there a maximum recommended
   length for the J3 USB 2.0 HS harness in a noisy airframe? Does ModalAI offer
   (or recommend building) a shielded and/or twisted-pair version for longer
   runs, and could the added length alone plausibly account for transient-
   induced disconnects like the above?

Happy to provide full dmesg logs, ulogs, and the reproduction script.

[Vinny]

Hi @noah-heinen,

Thanks for the very detailed write-up and troubleshooting. There is a lot of useful information here, and this is a tough challenge. I hope we can help get it resolved with you.

The first thing that stands out to us is the custom extended-length USB harness between the Doodle Labs radio and VOXL 2 Mini. Before digging further into software, ESC firmware, or platform parameters, I would focus on that physical USB connection.

USB 2.0 High Speed is sensitive to cable construction and signal integrity. Extending the MCBL-00080 interface using discrete, untwisted, unshielded JST-GH conductors is not equivalent to extending it with a properly constructed USB cable. The added length also increases susceptibility to both radiated and common-mode noise, particularly in an electrically noisy environment such as a high-current multirotor.

We should also acknowledge that our standard development cables are not necessarily optimized for the highest-noise or final-production UAS environments. They are primarily intended to help get systems connected and operating during development. For final aircraft integrations, we generally encourage additional cable optimization where appropriate, including shielding, ruggedization, strain relief, and dedicated cable routing or cable channels that keep sensitive interfaces away from high-current and high-noise paths.

We have seen USB stability issues on aircraft when cabling and routing are not ideal, especially around ESCs, motors, and high-current battery wiring. The fact that your disconnects correlate strongly with motor current transients rather than steady-state current makes the custom USB harness and associated grounding/noise coupling particularly worth investigating.

I would recommend addressing the USB harness first:

Keep D+ and D- as a tightly coupled twisted pair and keep the run as short as practical.
Use a shielded USB-rated cable rather than individual discrete wires for the extended portion.
Adding shielding is absolutely a good approach here. Ideally, use the cable shield as a shield rather than simply adding another signal-ground conductor.
Keep the USB harness physically separated from ESC phase wiring, battery leads, and other high dI/dt paths.
Your plan to improve the ground path and experiment with ferrites is also reasonable, although I would first correct the basic USB cable construction before trying to solve the problem primarily with ferrites.

I would not assume there is a specific maximum J3 cable length where it suddenly becomes unreliable. Cable construction, impedance, routing, grounding, and the surrounding EMI environment all matter. A longer run made from discrete untwisted/unshielded conductors is certainly more susceptible than the stock harness, and yes, it could plausibly produce the transient-induced disconnect behavior you are seeing.

Moving the ESC bulk capacitor to the recommended location is also important, particularly on 6S, and I would still make that change. The improvement you observed when powering VOXL from a bench supply is another useful indication that conducted or common-mode noise may be contributing. There may be more than one coupling path here.

However, given the custom extended USB cable construction, I would correct that first and repeat your 0 -> 65% actuator transient test. That is actually a very good controlled reproduction test.