ModalAI Forum

Thanks — to clarify, we are not asking about MAVLink over ELRS.

Direction we need: UAS → GCS (aircraft companion → ground laptop), not ground → UAS.

Link we mean: MVX VTX → VRX (SoftAP off / VTX on), then VRX Ethernet to the GCS. ELRS stays RC-only (CRSF_RAW / M0184).

Questions still open:

With VTX on, does stock autopilot telem already forward VTX→VRX→Ethernet UDP (gcs_ip / port 14550)?

Can an onboard companion inject custom MAVLink (TUNNEL / similar) into that same VTX telem path so it appears at the GCS?

If custom injection is not supported, what is the supported way to get ~0.5–2 KB @ 1 Hz observations to the GCS while VTX video stays up (without SoftAP)?

Also still need the SoftAP-off question: can the aircraft join an external WiFi network as a client while VTX RF video is active, or do SoftAP/client and VTX mutually exclude on wlan0?

Hardware: VOXL 2 Mini (M0104) on a Stinger. SKU /data/modalai/sku.txt: MRB-D0013-6-V1-C33-T8-M26-X8 (X8 = Lepton). ADB serial 6299769b. USB VTX dongle Realtek 0bda:8812, product string "VTX Gen 1.5". Paired ModalAI VRX (same vtx.key, 5825 MHz).

Software version: Full flash today of voxl2-mini_SDK_1.6.4.tar.gz (MD5 12c726bed8e72d68ec489533e15ba9ef), /data preserved, SKU reconfigured as above. Last confirmed after flash (bird is offline now, so this is not a fresh voxl-version paste):

• System image 1.8.08-M0104-14.1a-perf
• voxl-suite 1.6.4 (was 1.5.0)
• voxl-lepton-server 1.4.0 (was 1.3.3)
• voxl-vtx 2.2.27 (was 1.4.7)

Configuration / services: SoftAP off. voxl-vtx and voxl-lepton-server enabled and active. VTX RF: 5825 MHz, bandwidth 20, FEC on, STBC 0, /data/modalai/vtx.key present. Active VTX source was switched between hires_low_latency_misp_encoded and lepton0_encoded. Lepton config is stock SPI bus 0, en_rotate: true, shutter_mode: manual.

What I am trying to do:

Send the downward Lepton to the VRX using the stock SDK 1.6 path: voxl-lepton-server publishes /run/mpa/lepton0_encoded (H265), and voxl-vtx uses that pipe as its profile source. RGB already works on the same radio and VRX.

What actually happens:

lepton0_raw and lepton0_color publish live frames (RAW8 / RGB, 160×120, ~8.8 fps). /run/mpa/lepton0_encoded/info exists and reports string_format: H265, 160×120, 9 fps, server voxl-lepton-server. voxl-inspect-cam lepton0_encoded stays at "Waiting for Server" indefinitely. No encoded frames, with or without voxl-vtx subscribed.

voxl-lepton-server log:

WARNING: OMX SetTargetBitrate: H265 CBR requires bps >= 3.0Mbit (1000000 bps provided). Using FPS hack. scale = 3.000000
H265 encoder initialized (160x120 @ 9 fps)
WARNING: ion buffer pool exhausted — reusing idx N (age=~455ms, gen=…)

The ION warning repeats on every frame from first boot. Verbose run also prints "Received a complete frame, publishing" for the raw path, then the same ION exhaustion, and the encoded client still never receives a frame.

Pointing VTX at lepton0_encoded makes the VRX drop to signal lost. Pointing it back at hires_low_latency_misp_encoded restores video immediately (same frequency, same key). So the RF link, key, and VRX are fine. The encoded Lepton pipe is empty.

Steps to reproduce:

1. Flash VOXL 2 Mini SDK 1.6.4, preserve /data, configure SKU MRB-D0013-6-V1-C33-T8-M26-X8.
2. Confirm voxl-lepton-server is running and voxl-inspect-cam lepton0_raw shows ~9 fps.
3. voxl-inspect-cam lepton0_encoded — stays "Waiting for Server".
4. With SoftAP off and VTX on a channel the VRX already locks (here 5825), voxl-configure-vtx -s hires_low_latency_misp_encoded — VRX shows video.
5. voxl-configure-vtx -s lepton0_encoded and restart voxl-vtx — VRX loses signal. lepton0_encoded/info is present; voxl-inspect-cam still waits.

Question: On SDK 1.6.4 / voxl-lepton-server 1.4.0, is lepton0_encoded supposed to emit H265 for a 160×120 Lepton, or is the encoder known not to produce frames (ION pool exhausted, OMX 1 Mbit vs 3 Mbit CBR warning)? Release notes for 1.6.6 only say lepton-server 1.4.1 is a rebuild against libvoxl-codec 0.1.1 ("OMX parity with camera-server"). Is that the fix for this, and can you provide voxl2-mini_SDK_1.6.6.tar.gz (MD5 5e412872759cca0c5252aa02c29b31ef)? 1.6.6 is not on the public download page.

Hello Community,

We are building our first mission software. We have questions about potential data communication path from a stinger to a proposed ground station (windows laptop).

Questions:

WiFi - Can we TCP/IP link to the Stinger over a WiFi network while also enabling VTX video transmission to a fpv headset? We wish to leave SoftAP off and meet a static IP assignment request too as a client of a wifi network.

RF - What is the supported way to send companion-generated observation data over this MVX RF link: approximately 0.5–2 KB per observation at 1 Hz, as compact binary or small JSON? Video and normal flight telemetry must continue operating. The onboard service may eventually run in a container with a native host adapter if required.

Hardware:

• Aircraft: ModalAI Stinger Vision, VOXL 2 Mini; reported hardware platform M0104.
• Device-reported SKU: MRB-D0013-6-V1-C33-T8-M26-X0.
• VTX: M26 configuration, identified as MVX/M0185.
• RC receiver configuration: T8, M0184; RC=CRSF_RAW.
• Ground receiver: MVX VRX, currently used with an FPV headset; exact installed receiver SKU and firmware have not been collected.

Software version:

Saved output of voxl-version from the aircraft:

────────────────────────────────────────────────────────────────────────────────
system-image: 1.8.06-M0104-14.1a-perf
kernel:       #1 SMP PREEMPT Wed Oct 22 05:43:49 UTC 2025 4.19.125
────────────────────────────────────────────────────────────────────────────────
hw platform:  M0104
mach.var:     2.0.2
SKU:          MRB-D0013-6-V1-C33-T8-M26-X0
────────────────────────────────────────────────────────────────────────────────
voxl-suite:   1.6.0
────────────────────────────────────────────────────────────────────────────────
Packages:
Repo:  http://voxl-packages.modalai.com/ ./dists/qrb5165/sdk-1.6/binary-arm64/
Last Updated: 2023-03-02 13:09:22
List:
libfc-sensor                   1.0.8
libmodal-cv                    0.6.0
libmodal-exposure              0.1.4
libmodal-flow                  1.0.3
libmodal-journal               0.2.7
libmodal-json                  0.4.8
libmodal-pipe                  2.14.8
libqrb5165-io                  0.5.0
libvoxl-cci-direct             0.3.3
libvoxl-codec                  0.0.1
libvoxl-cutils                 0.1.6
modalai-slpi                   1.2.2
mv-voxl                        0.1-r0
qrb5165-bind                   0.1-r0
qrb5165-dfs-server             0.2.0
qrb5165-imu-server             1.2.3
qrb5165-mini-tof-server        0.2.2
qrb5165-rangefinder-server     0.1.6
qrb5165-slpi-test-sig          01-r0
qrb5165-system-tweaks          0.3.11
qrb5165-tflite                 2.17.2
voxl-bind-spektrum             0.1.1
voxl-camera-calibration        0.6.1
voxl-camera-server             2.2.16
voxl-ceres-solver              2:2.0.0-2
voxl-configurator              1.0.8
voxl-cpu-monitor               0.7.4
voxl-docker-support            1.3.1
voxl-elrs                      0.4.14
voxl-esc                       1.5.7
voxl-feature-tracker           0.5.2
voxl-flow-server               0.3.6
voxl-fpv-px4                   1.14.0-8.121.0
voxl-gphoto2-server            0.0.10
voxl-io-server                 0.0.6
voxl-jpeg-turbo                2.1.3-7
voxl-lepton-server             1.3.3
voxl-lepton-tracker            0.0.4
voxl-libgeographic             1.0.0
voxl-libgphoto2                0.0.4
voxl-libuvc                    1.0.7
voxl-logger                    0.6.0
voxl-mavcam-manager            0.6.0
voxl-mavlink                   0.1.6
voxl-mavlink-server            1.4.12
voxl-modem                     1.2.1
voxl-mongoose                  7.19.0
voxl-mpa-to-ros                0.3.9
voxl-mpa-tools                 1.5.3
voxl-open-vins-server          0.5.6
voxl-opencv                    4.5.5-3
voxl-osd                       0.2.0
voxl-portal                    0.8.4
voxl-px4                       1.14.0-2.0.121
voxl-px4-params                0.8.9
voxl-qvio-server               1.2.2
voxl-remote-id                 0.0.9
voxl-reset-slpi                0.0.1
voxl-state-estimator           0.0.5
voxl-streamer                  0.8.0
voxl-suite                     1.6.0
voxl-tag-detector              0.0.5
voxl-tflite-server             0.5.0
voxl-utils                     1.4.9
voxl-uvc-server                0.1.7
voxl-vision-hub                1.9.19
voxl-vtx                       1.7.1
voxl-wavemux                   0.0.3
voxl2-io                       0.0.3
voxl2-security-hardening-utls  1.0-r0
voxl2-system-image             1.8.06-r0
voxl2-wlan                     1.0-r0
────────────────────────────────────────────────────────────────────────────────

Relevant saved configuration values:

/etc/modalai/voxl-px4.conf:
  RC=CRSF_RAW

/etc/modalai/voxl-vtx.conf:
  udp=false
  frequency=5805
  bandwidth=20
  enable_fec=true
  enable_pit=true
  mavlink_telem_rate_hz=30
  active_profile_idx=0
  profiles[0].source=hires_default_misp_encoded

These are observed settings, not a claim that RF forwarding was running. The 30 Hz value is a configured telemetry cadence, not measured application throughput. No Docker executable was found during this inspection; container deployment is planned.

What I am trying to do:

Send timestamped, identified observations from an onboard companion application to ground control station (GCS) laptop over the existing MVX RF link while video and pilot RC remain active. Each observation is approximately 0.5–2 KB at approximately 1 Hz. The GCS will reassemble/validate observations and distribute them to local subscribers. We need the supported injection interface, payload envelope, forwarding behavior and matching firmware versions.

What actually happens:

We have not yet identified and exercised a supported companion-to-VTX injection API. Static inspection shows MAVLink handling through mavlink_onboard and suggests batching by message ID, but neither observation establishes end-to-end custom-payload delivery. The receiver has not been connected to our diagnostic computer for a packet capture. There is therefore no reproduced custom-message error or confirmed packet-loss measurement to report; this is an integration/support question before implementing the transmitter.