Custom companion data Stinger → Ground Control Station

[Alex Z 1]

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.

[Moderator]

This is not currently supported. Right now the only data going to the UAS from the ground is via ELRS. We do have plans to support MAVLink over ELRS in the future.

[Alex Z 1]

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?

[Jacob Camarillo]

Hi Alex,

Thanks for clarifying the direction. For UAS → GCS with your current voxl-vtx 1.7.1:

1. Autopilot telemetry already goes VTX → VRX → Ethernet UDP:

• voxl-vtx subscribes to the autopilot's MAVLink stream from voxl-mavlink-server and sends it over the RF link next to the video. The VRX then re-sends it as UDP to:

  • destination: gcs_ip in /etc/modalai/voxl-vrx.conf (default 10.0.0.1), port 14550 (fixed in 1.7.1)
  • source: the VRX at 10.0.0.2
  • Give your GCS laptop 10.0.0.1 on the VRX Ethernet link (or set gcs_ip to its address) and listen on UDP 14550. QGC will pick it up automatically.

• This is a one-way telemetry snapshot, not a transparent MAVLink link. The VTX sends at mavlink_telem_rate_hz (30 Hz in your config) and keeps one message of each message ID per send window.

2. Custom companion data: not supported in this release.

• voxl-vtx only forwards what voxl-mavlink-server publishes on its mavlink_onboard pipe, and that pipe only carries messages received from the autopilot. If a companion app writes MAVLink into that pipe, voxl-mavlink-server sends it to the autopilot and doesn't publish it back onto the pipe, so voxl-vtx never sees it.

• Writing to the mavlink_to_gcs pipe doesn't help either: voxl-mavlink-server sends those messages out its own UDP sockets, and they have no way to reach the ground over the MVX link. There is currently no supported way to put your observation data onto the VTX → VRX link.

3. Upgrading to SDK 1.6.4, if these features are useful to you:
   Your voxl-vtx 1.7.1 is older than what ships in SDK 1.6.4, the latest SDK release for Stinger. SDK 1.6.4 includes voxl-vtx 2.2.x, which adds:

• Parameter, mission and FTP forwarding to the GCS, so QGC can read and set parameters and download missions over the MVX link.
• GCS → drone MAVLink through the VRX. MAVLink your GCS sends to the VRX on the GCS port is forwarded over the link to the aircraft, for example mission uploads. By default this forwarding stops while the vehicle is armed. To keep GCS → drone MAVLink flowing in flight, set this in /etc/modalai/voxl-vrx.conf and restart voxl-vrx: "allow_mavlink_forward_while_armed": true
  • Only enable this if you want the GCS able to send commands to the aircraft while it is armed. MANUAL_CONTROL messages are dropped.
• A configurable GCS port (mavlink_gcs_port), replacing the fixed 14550.
• None of these add a path for custom companion data, so they don't solve the observation use case.

4. WiFi client mode with the VTX active:
   On the Stinger the M0185 is the VTX radio, and it runs in raw injection/monitor mode while it sends video. It can't also join a network as a WiFi client. A TCP/IP WiFi link would need a second, separate WiFi adapter. Even then, running it on the same band as the video link could hurt video quality, so we'd advise against it for a flight setup unless you deconflict the frequency used by each network device.