@Alex-Kushleyev Thanks for letting me know! I'll have to give it a try

@valvarez , the usage for the test tool is as follows:

voxl2:/$ qrb5165io-uart-test -h Description: runs hardware loopback test on specified bus Usage: qrb5165io-uart-test -d <device ID> (eg 3 for /dev/ttyHS3)

So you should run your test as:

voxl2:/$ qrb5165io-uart-test -d 2 [INFO]: success!

@antenna-eng What hardware do you have connected to the VOXL 2 board? Cameras etc.

@Kessie Excellent, glad to hear you got it working! And thanks for adding the details on what you had to do to the posting!

@Alex-Kushleyev That was it! I first tried with a lower baud rate of 250K on PX4 and I started getting the battery info. Then as you recommended, I uploaded new parameters to the ESC. I used:

python3 voxl-esc-upload-params.py --params-file ../voxl-esc-params/D0014_starling_1504_3000kv_ms_props/D0014_starling_1504_3000kv_ms_props.xml

because I will be using it on a drone of similar size and performance. Then with 2M baud rate in PX4, I was able to make it work!

Thank you.

@berayksl Hi there, to address your questions:

The inconsistent VIO performance between flights

appears the inconsistent vio behavior on multiple arm/disarms is due to the way voxl-open-vins-server re-initializes after a disarm event. Are you still using in the voxl-open-vins-server.conf option "en_vio_always_on": false and "en_auto_reset": true?

If so, the next thing that can be an issue is takeoff speed. To ensure VIO has the correct origin (0,0,0) we have a conf parameter called: "takeoff_accel_threshold": 0.5, This is essential a takeoff detector and is set for a aggressive take off (>80% throttle)

If you are taking off very slow and gentle, it's possible the detector is not being tripped. Try lowering it from 0.5 to 0.3.

The “Yaw estimate error” message (should I be concerned if QGC shows no error)?

If the error doesn't repeat, it's just VIO telling PX4 to reset it's heading and PX4 complains on reset. This can be ignored. BUT if QGC keeps repeating the announcement, you have a PX4 yaw_gate issue--make sure in PX4 the param EKF2_EV_CTRL has the 'yaw' option checked.

And as a sanity check cause you are seeing an R/C issue: goto the radio tab in QGC and confirm your pitch/roll/yaw inputs are calibrated and centered such that you are not sending biased commands.

The drone ignoring RC inputs during the second flight

Are you getting a r/c "manual control lost" announcement in QGC or just lack of control when trying to move the drone? On the former case we have notice users in environments with lots of metal (e.g. warehouse) will have RF interference issues.

At this point, we have numerous improvements in SDK 1.5.0 for Max and it maybe worth the upgrade if your system design allows it. It has improvements with the vio-always-on issues, vio resets, and some PX4 altitude improvements.

Hello everyone,

We’ve been following this discussion with great interest — especially the insights about the mast kit and the copper shielding solution. We also tried similar approaches on our side and wanted to share our results to contribute to the thread.

We purchased four Starling 2 Max drones for our project at the beginning of the year, and like others here, we are experiencing difficulties with GPS stability outdoors. To mitigate interference, we designed and 3D-printed our own GPS mount to move the antenna away from the main body, and we added a copper shielding layer around it.

We then tested the u-blox M10 GPS outside, under clear sky conditions, with the drone powered on (connected via Wi-Fi to use VOXL-Portal). Over about 10 minutes, the best observation we captured showed 18 satellites with an average SNR around 30–35 dB.
vlcsnap-2025-07-25-14h33m43s700.png
image474.png

However, despite these results, we still cannot achieve a stable outdoor localization, which currently prevents us from flying the drones properly outside. At this point, we’re unsure whether the problem comes mainly from the GPS performance or possibly from the barometer.

We’d really appreciate:

Being included in your support list for this GPS issue, since it affects multiple units on our side (as mentioned by @Alex-Kushleyev). Any guidance or recommendations on how to debug further (extra shielding, hardware setup, barometer validation, software settings, etc.).

Thanks a lot to the ModalAI team and to the community for the shared ideas — we hope our feedback helps others as well.

Best regards,

Quentin

@Eric-Katzfey I did the systemctl stop and started service again. I guess rebooting the board earlier did not have the same effect. The compass calibration in Q is working now (no more "no mag found" error) which I guess it means the mag is working now and our gps is working too.

here is the output of voxl-p4 -d by the way:

INFO [qshell] Send cmd: 'lis3mdl start -R 10 -X -b 1' INFO [muorb] [uORB] Marking DeviceNode(qshell_req) as advertised in process_remote_topic INFO [muorb] [qshell] qshell gotten: lis3mdl start -R 10 -X -b 1 INFO [muorb] [qshell] arg0 = 'lis3mdl' INFO [muorb] [qshell] arg1 = 'start' INFO [muorb] [qshell] arg2 = '-R' INFO [muorb] [qshell] arg3 = '10' INFO [muorb] [qshell] arg4 = '-X' INFO [muorb] [qshell] arg5 = '-b' INFO [muorb] [qshell] arg6 = '1' INFO [muorb] [drivers__device] *** I2C Device ID 0x51e09 335369 INFO [muorb] [drivers__device] Set up I2C bus mutex for bus 1 INFO [muorb] lis3mdl #0 on I2C bus 1 INFO [muorb] (external) INFO [muorb] address 0x1E INFO [muorb] rotation 10 INFO [muorb] INFO [muorb] [qshell] Ok executing command: lis3mdl start -R 10 -X -b 1

@modalab Hello, can you help me to resolve this problem?

The kernel build is posted at https://gitlab.com/voxl-public/system-image-build/voxl-build

@DillonAllen Without WiFi, the only way you'll be able to debug VOXL related things is via. ADB so I would follow this guide: https://docs.modalai.com/setup-adb/ in order to setup ADB on your host computer.

Sorry for the late response, I've been doing some testing. so I've narrowed it down to the error lying in the stereo cameras, I connected each sensor one at a time, reconfigured, and ran the voxl-streamer and was able to get footage for the hires and tracking, but when it came to the stereo it would not work. When I would reboot the system and inspect the services I would see that the voxl-camera-server is running, but once I tried to voxl-streamer -c stereo it would get stuck at the same place and the voxl-camera-server would stop running. I've confirmed that both of my extension cables are working by testing them with the hires camera. I checked the physcial connections on the stereo cameras and there are no creases in them, they look just as they were folded with the original setup, and I believe that if any of the connections were inverted then the VOXL wouldn't even start up.

@Matt-Turi thanks so much!

@Eric-Katzfey Ok thanks for the fast answer.

@Steve-Turner voxl-build allows you to build the kernel only which you can then flash on top of an existing system. Qualcomm licenses are required in order to build a full system image.

@hmlow Glad it worked! For future reference, the imx214_flip driver should be available internally from SDK 1.1 (system image 1.7) onwards. Rather than downloading from the above links, after SDK 1.1 is released the procedure will be as follows:

rm /usr/lib/camera/com.qti.sensormodule.imx214_3.bin cp /usr/share/modalai/chi-cdk/imx214-flip/com.qti.sensormodule.imx214_flip_3.bin /usr/lib/camera

@tom Thank you so much. It is done.

@tom I had the same idea, so I directly installed Mavproxy and related packages on VOXL2, and successfully resolved the issue with the serial library. However, when running the service, I still couldn't import the Python files related to Mavproxy. Even adding the paths of those Python files to the environment variables didn't solve the problem.

@19bpl At the very least you need to be able to ping the QGC computer from VOXL2 and VOXL2 from the QGC computer before attempting anything else.

@Kashish-Garg-0 It's possible your board has a QSM8250 (M0054-2) instead of a QRB5165 (M0054-1), see here for the diffs: https://docs.modalai.com/m0054-versions/#m0054-1-and-m0054-2

If that is the case then you will have to QDL using a different build, which you can download from downloads.modalai.com, look for M0054-2 Starling QDL Image 1.7.4 2024-02-09-1.7.4-M0054-2.zip under the "All" category