ModalAI Forum

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.

Hi team,

I'm trying to get object avoidance working on a VOXL 2 Mini (SDK 1.6.3, ArduPilot) and hit a wall
getting voxl-dfs-server running. Wanted to share what I found in case it saves someone else the
digging, and hopefully get a fix published.

THE PROBLEM

Starting voxl-dfs-server immediately spams this and never produces the dfs_point_cloud output:

ERROR only support STEREO_RAW_8 images right now

I checked the source on GitLab (qrb5165-dfs-server), and the code itself is actually fine - it
checks the correctly-named format constant IMAGE_FORMAT_STEREO_RAW8 (the underscore only shows up
in the printf error text, that part's just a cosmetic typo, not the real bug).

The real issue is that the shipped binary is stale. Looking at the repo's tags, sdk-1.1.0 through
sdk-1.6.0 all point to the exact same commit from 2023-09-22 (tag v0.2.0) - it's never actually
been recompiled since then, even though voxl-camera-server has moved forward two major version
lines in that same window (1.8.x back then, 2.2.x now).

I also checked whether a newer build exists anywhere that just hasn't been documented:

• dev channel has a rebuild dated 2025-10-09, but its binary still has the identical error
  string - the rebuild changed some dependency versions but didn't touch this
• the "stable" sdk-1.7 channel file has a May 2026 timestamp, but its MD5 hash is byte-for-byte
  identical to the 2023 build already on my board - just a re-touch, not a real recompile
• checked staging, and the separate qrb5165-2 line too (that one's for a different Ubuntu 20.04
  image and doesn't even ship this package)

So as far as I can tell, no build anywhere actually matches the current image-format naming.

My guess: IMAGE_FORMAT_STEREO_RAW8 is a compile-time constant, and libmodal-pipe has moved from
~2.9.x (when dfs-server was last built) to 2.14.11 today. If that enum's value shifted in that
window, dfs-server would be comparing against a stale integer even though its own source code
symbol name is correct.

WHAT'S ALREADY RULED OUT

• Stereo cameras themselves are fine - calibrated, streaming, confirmed via voxl-inspect-cam etc.
• voxl-dfs-server's config is correctly pointed at the stereo pair with valid calibration files
• voxl-vision-hub is correctly configured for VOA and just waiting on the dfs_point_cloud pipe
• Not attempting a local downgrade of voxl-camera-server to fix this - it would risk breaking
  ABI compatibility for every other service that links libmodal-pipe, and per
  voxl-configure-pkg-manager's own docs, mixed package versions aren't a supported configuration
  anyway

THE ASK

Since the source looks correct and this seems like a simple stale-build issue, could
qrb5165-dfs-server get recompiled against current libmodal-pipe and republished? Happy to test a
new build on my SDK 1.6 board if one becomes available.

Board info: VOXL 2 Mini, hw platform M0104, voxl-suite 1.6.3, ArduPilot flight stack.

Thanks!

Hello I am in the process of integrating your voxel 2 mini. I need to connect to it wirelessly or wired if i am able to log into mission planner via the ADB connection /USB C port?

J3 - USB3 10-Pin JST
MCBL-00022-2 is recommended.
Example using a wired ethernet adapter connected to J3 (Cable Creation USB to Ethernet)
Example using a wireless ethernet adapter connected to J3 (Alfa Network AWUS036ACS 802.11ac AC600)
Also do you have a pinout for the wiring on a Doodle Labs RM-1700-22M3 ?
Thankyou for your time.

Hello,

I need to confirm compatibility and required adapters for a VOXL 2 Mini with the MCCA-M0178-1 Starling LIOW2 ToF adapter board.

Current setup:

J6 and J7 are occupied by the MDK-M0188-2-00 Stinger image adapter
Connected to that adapter:

-2x MSU-M0166-1-01 AR0144 cameras on J6 and J10
-1x MSU-M0186-1-09 Caddx Polar camera on J1

• Also using a Doodle Labs Mini as the data link

Since J6 and J7 are already in use, I believe I may need the M0188 VOXL 2 Mini Sparrow Imager Adapter to interface through J2, J3, or J8.

Can you please confirm:

1. Whether the MCCA-M0178-1 is compatible with the VOXL 2 Mini
2. Which adapter is required
3. Which port should be used in this configuration

Thank you.