Connecting External Devices to VOXL 2

Table of contents

1. Processor Ownership
2. Decision Guide
3. Apps-Processor Route (Linux Devices)
4. PX4 (DSP) Route (Flight Sensors)
5. MAVLink Devices Over UART
6. GPIO
7. Known Limits

Processor Ownership

VOXL 2 is a split-processor system: most of PX4 runs on the sensors DSP (SLPI), while Linux and your applications run on the applications processor. Every external bus belongs to one side or the other, and that decides everything about how you talk to a device:

• JST board-to-cable connectors (J18, J19) are DSP-owned — they exist for flight-control peripherals. Devices there are only reachable through PX4 drivers (started with qshell), never from Linux. i2cdetect, voxl_i2c, and /dev/tty* will show nothing on these ports — the most common “no clock activity on J19” confusion.
• Board-to-board connectors (J3, J5) and J10 are apps-processor-owned — reachable from Linux via standard /dev nodes and libqrb5165-io. Expansion boards (the Dev Test Board, M0141 breakout, modem carriers) fan these out to usable connectors.
• DSP UARTs cannot be used outside PX4 while PX4 is running, and the DSP’s single SPI port is hardwired to the onboard IMU — SPI peripherals always go to the apps processor.

Full pin-by-pin bus reference: VOXL 2 Linux User Guide (UARTs, SPI, I2C, GPIOs) and VOXL 2 Connectors.

Decision Guide

Apps-Processor Route (Linux Devices)

What Linux sees out of the box:

• Program them with libqrb5165-io (C library + voxl_i2c, voxl-gpio and example apps), or standard Linux interfaces. A real-world SPI example is voxl-lepton-server.
• Quick UART bench test — set the baud, then watch or type:

stty -F /dev/ttyHS2 115200
cat /dev/ttyHS2            # watch incoming data
screen /dev/ttyHS2 115200  # interactive (ctrl-a k to exit)

Jumper TX to RX on the connector and typed characters echo back — the standard loopback sanity check.

voxl_i2c and i2cdetect only scan apps-processor buses. If you probe J19 with them you’ll see nothing and no bus activity — that’s the expected result, not a fault. J19 belongs to PX4.

PX4 (DSP) Route (Flight Sensors)

The DSP’s external I2C lives on J19: bus 1 on pins 4/5 (where the standard GPS unit’s magnetometer connects) and bus 4 on pins 7/8 (the spare); bus 5 is internal (onboard barometers). Drivers are started in /usr/bin/voxl-px4-start with qshell, e.g. qshell ist8310 start -R 10 -X -b 1 or a PWM expander with qshell pca9685_pwm_out start -b 4.

To add a driver that isn’t in the build:

1. Add it to the board config: boards/modalai/voxl2-slpi/default.px4board (DSP buses) or the plain voxl2 board (apps-processor ports) in voxl-px4.
2. Start it in boards/modalai/voxl2/target/voxl-px4-start (installed as /usr/bin/voxl-px4-start).
3. Build and install as a deb package rather than copying files.
4. Verify in the foreground: systemctl stop voxl-px4, then MINIMAL_PX4=1 voxl-px4 -d, and use px4-qshell <driver> status / px4-listener <topic>.

I2C notes:

• 400 kHz clock works; 1 MHz is in-code supported but untested by ModalAI; 3 MHz fails to open the port (a failed open does not crash PX4 — a crash means driver code, not the bus).
• Prefer batched multi-byte reads: every single-register read costs ~3 bytes of bus time, so reading a sensor’s six axis bytes in one transaction is ~3x faster.
• A sensor that needs unplugging/replugging to enumerate usually has a power-up race with the driver’s probe — add start-up delay tolerance in the driver.
• An apps-side GPS is possible (gps start -d /dev/ttyHS2, or SPI: gps start -i spi -d /dev/spidev14.0) — but the compass driver is DSP-only, which is why the standard wiring splits a GPS unit between an apps UART and J19’s I2C.

For the supported external GPS/mag wiring itself, see VOXL 2 Offboard Sensors.

MAVLink Devices Over UART

For a peripheral that speaks MAVLink, give PX4 a dedicated MAVLink instance on an apps UART by adding to /usr/bin/voxl-px4-start:

mavlink start -x -d /dev/ttyHS0

This connects the device directly into PX4 (voxl-mavlink-server is not involved — that’s for GCS/onboard routing, and routing it out a UART “TELEM-style” is untested territory).

GPIO

• Exposed apps GPIOs are listed in the Linux User Guide GPIO section and driven with voxl-gpio (from libqrb5165-io). The sysfs interface is provided by the voxl-gpio-mod kernel module — if /sys/class/gpio is empty after a custom kernel build, check dmesg | grep voxl-gpio-mod (commonly a debug-vs-perf kernel/module mismatch).
• Repurposing arbitrary pins as GPIO is not generally supported — pin muxing is locked by TrustZone plus device tree, and changing it means a kernel rebuild at minimum, with some pins simply off-limits. The Dev Test Board exposes the B2B pins so you can test what’s actually available before designing hardware.
• Practical escape hatch when you need more/faster IO: a microcontroller bridge — e.g. a Raspberry Pi Pico or Arduino on an apps UART, receiving simple commands from VOXL 2 and doing the pin-wiggling itself.
• If you’re repurposing a bus pin for GPIO-like use, prefer SPI/UART pins over I2C pins — the I2C lines have pull-ups fitted, which ruins rise times.
• Designing an expansion board? See the Expansion Hardware Design Guide — ModalAI offers courtesy schematic reviews.

Known Limits

• PX4 has never been integrated with apps-processor SPI devices by ModalAI — the posix-side SPI driver path is uncharted; bring an oscilloscope.
• RTK GPS is unsupported; there is a known issue where RTCM corrections don’t reach a DSP-hosted GPS driver (apps-hosted works).
• Only one PMD ToF sensor per VOXL 2 is supported.
• DSP UART/I2C internals are Qualcomm-proprietary — DSP-side console output needs mini-dm from the Hexagon SDK. DSP UARTs have hardware FIFOs (64 bytes on UART2, 128 on UART6/7), no DMA, and proven throughput of 2 Mbaud at 800 Hz packet rates.