@zachary-lowell-0 That worked perfectly, thanks!

Assuming your Stinger SKU contains an ExpressLRS modem (ModalAI M0184 Gemini RX), you will want to follow the ExpressLRS Binding procedures. Firstly, to put the receiver into "binding" mode, you'll want to either press the bind button for at least 1.5 seconds, and you must do this at least a few seconds after the battery has been inserted (or anytime later). You can also put the receiver into binding mode by powering on and off the Stinger 3 times quickly, though this can be unreliable. You will also need to make sure your transmitter is compatible with the receiver, and in a compatible mode. The M0184 by default comes with firmware based on ELRS 3, so you will need to verify that your GX12's internal ExpressLRS firmware is also on major version 3, otherwise you will need to downgrade to V3. Furthermore, the GX12 comes with a dual-band transmitter which supports 2.4GHz and 915MHz operation. To work with the M0184 you must make sure the selected "RF Band" parameter is "915 MHz", and the packet rate is 50 Hz 100 Hz, or 200 Hz. Other packet rates are not supported on the older modem in the M0184.

Hi @김다연 The INA260 is not supported. M0041 is designed around the INA231 and our power monitoring software expects that part. The two are not drop-in compatible. They differ in register map, device ID, and the INA260 has an integrated shunt rather than the external shunt the M0041 uses, so it is a board change as well as a driver change. Supporting it would require a new driver and a new M0041 variant, neither of which exist. If you need power monitoring on VOXL 2, use M0041 as designed, or take battery voltage and current telemetry from our ESCs, which report it over the ESC UART.

Hi @czarsimon Flickering is not acceptable and it is worth chasing before you fly it. DS1 is driven by the 5 V eFuse on VOXL 2. Solid green means power good with no fault. Any flicker means the eFuse is toggling power-good or asserting a fault and recovering, so you are operating right at the edge of a trip. The system may look fine on the bench and then brown out when something shifts, such as a colder battery, a warmer ambient, or a transient load. Two questions before we can tell you which fault it is. Are your peripherals powered from the same upstream VBAT supply as VOXL 2, or from VOXL 2’s own 5 V output connectors? And can you scope VDCIN_5V at J4 pin 1 while the flicker is happening? What you are looking for is whether the rail is sagging or spiking. Sagging points at supply capacity: VOXL 2 expects 5 V ±5%, and the power module is set to 5.08 V no-load specifically to absorb cable drop. Adding load on the same supply eats that margin. Spiking above 5.6 V trips the eFuse overvoltage protection instead, which is a transient problem at the peripheral rather than a capacity problem. Also note our cable-connector power outputs are rated 1 A each and the system cannot supply 1 A on all connectors simultaneously: https://docs.modalai.com/voxl2-connectors/#power-inputoutput-important-note If it is droop and the total load is genuinely beyond one power module, separate the peripherals onto their own supply (using a second power module regulated from your VBAT) rather than sharing the VOXL 2 feed. If it is overvoltage, more supply capacity will not help.

Thanks! I'll get back to you if I have any more questions.

Hi @john-keller , Glad to hear that it works As for the other issue, its possible that this is just a transient bus error somewhere that is causing the problem. If you encounter it again it would definitely be worth taking a closer look. Feel to open another post and tag me in it and I will take a look. Thanks!

It is saying that your throttle is not at lowest position. Is that the case? Can you calibrate the RC in QGC and see all of the sticks moving as expected?

Potentially try to register using another email address. Our public files (including CAD files) are located here https://modalai.filecloudonline.com/ui/core/index.html#/

Thanks for sharing this. The details about the Mission Planner reconnect issue and how it affects the VOXL ArduPilot setup were really useful. Hopefully, the troubleshooting discussion here helps others facing something similar.

It's not really a priority for us at the moment but our platform is open and you should be able to adapt Crazyswarm2 to work with PX4. But there are no plans at the moment to design a new drone specifically for that use case.

@Nick-Stroumtsos The Zorro Blue does not have any audio capabilities. It is built with custom electronics which do not include support for a speaker so no firmware can enable audio features.

@Zachary-Lowell-0 Thank you for testing it out and for fast response. I am also feeling it is a network issue. I will also try to replicate the same test condition as yours, also will verify the bandwidth. Thanks!

Hi Alex, Thanks for clarifying the direction. For UAS → GCS with your current voxl-vtx 1.7.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. 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. 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. 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.