@swickliff No, it hasn't. Supposedly all of this is fixed in latest mainline but we haven't tested it. But we do have a mainline build available to try: http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/voxl-mainline-px4_1.16.0-1.0.0-202502271326_arm64.deb

@modaltb Support is hard! I am not sure I could do it.

@Will , this is great to hear! Thank you for your patience as we are resolving this issue. It does sound like you are ready for flight testing.

Meanwhile we will continue testing of the fix and will release an official firmware update to resolve the issue soon (probably this week). However, you don't need to wait for it, the test firmware you already have should be sufficient.

If you run into any other ESC-related issues, please let us know!

Alex

@ejohnson01 Can you try bringing this commit into your build and see if it resolves the issue: https://github.com/modalai/px4-firmware/commit/f945d29064b4ab26617a3fb15fc770f5dcb993e9

Typically hires is the only pipe with encoding enabled by default, but in this case tracking is being used. Can you make sure encoding is enabled for the tracking camera in voxl-camera-server.conf ?

Or, can you just see if hires_enc is working in QGC first? That's what we ship by default on a fresh install hires_enc to QGC should by enabled by default.

@riteshsharma you are welcome. If the current approach initializes and works fine (is able to allocate all the buffers), the performance should be stable. I am a bit surprised so many buffers are needed for the encoder, there is probably some other settings in our software to change that... However since it is actually working with 11 buffers, maybe there is no need for me to test / fix that. If you do encounter any other issues, let me know..

@Alex-Kushleyev
Thanks for the help, as I was calibrating the ESCs I did notice those messages, which confused me as to why we weren't able to get that information in PX4. On Monday it suddenly just started working despite my changing nothing. Gotta love when things fix themselves

@craigphoenix , I think the SDK install is failing somewhere in the middle (but goes unnoticed) and the ESC update and wifi issue is a result of that. We have not see this behavior before, so it is best to send the board back for inspection.

Thanks!

Alex

@tom
P.S. I am currently working with the Drone Sentinel VOXL 2 and the drone is connected via LTE but without Wi-Fi, because there is no wifi dongle.

@Bernhard @James-Strawson @Zachary-Lowell-0 @Alex-Kushleyev @nuallaino

I have a brand new Starling 2 Max (received 3 days ago), and I'm having the same problem described by nuallaino and Bernhard (no GPS even when outside for a long time).

My system info and results of px4-listener are pasted below.

I did unplug the Lepton 8-pin JST SH connector as suggested by James Strawson, but that had no effect.

Everything else seems to work fine (haven't tried 5G comm yet), but I'm hesitant to fly without GPS functioning properly, so at this point I'm stuck.

Any suggestions would be most welcome.

Thanks for your help !

system-image: 1.8.02-M0054-14.1a-perf
kernel: #1 SMP PREEMPT Mon Nov 11 22:47:44 UTC 2024 4.19.125
hw platform: M0054
mach.var: 1.0.1
voxl-suite: 1.4.1
current IP: wlan0: 10.0.0.19

voxl2:~$ px4-listener sensor_gps

TOPIC: sensor_gps
sensor_gps
timestamp: 841732144 (0.020669 seconds ago)
timestamp_sample: 0
time_utc_usec: 0
device_id: 11272245 (Type: 0xAC, SERIAL:6 (0x00))
lat: 0
lon: 0
alt: -17000
alt_ellipsoid: 0
s_variance_m_s: 999.00006
c_variance_rad: 3.14159
eph: 4294967.50000
epv: 3796926.25000
hdop: 99.99000
vdop: 99.99000
noise_per_ms: 64
jamming_indicator: 15
vel_m_s: 0.00000
vel_n_m_s: 0.00000
vel_e_m_s: 0.00000
vel_d_m_s: 0.00000
cog_rad: 0.00000
timestamp_time_relative: 0
heading: nan
heading_offset: 0.00000
heading_accuracy: 0.00000
rtcm_injection_rate: 0.00000
automatic_gain_control: 0
fix_type: 0
jamming_state: 0
spoofing_state: 1
vel_ned_valid: False
satellites_used: 0
selected_rtcm_instance: 0

voxl2:~$ px4-listener sensor_mag

TOPIC: sensor_mag
sensor_mag
timestamp: 861420482 (0.006257 seconds ago)
timestamp_sample: 861420007 (475 us before timestamp)
device_id: 527625 (Type: 0x08, I2C:1 (0x0D))
x: -0.04417
y: -0.32142
z: 0.42167
temperature: nan
error_count: 0
voxl2:~$

@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.

@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

@greg_s That would explain a lot what's happening.

If you start fresh and connect to the drone with voxl-portal and goto the VIO tab/menu option, you should be able to pick up the drone and perform a bench test.

Considering Figure 8 is not working, you will need to inspect the front and downward camera, tighten/remount any loose parts and possibly check camera focus & calibration.
Worse case if the forward camera is good and not changed from factory, you can edit /etc/modalai/vio_cam.conf on the drone and disabled the faulty camera (disabled the down camera).
You'll have degraded precision (mainly bad vio in fast yaw motions), but should be able to perform a figure 8 and should get you running until you repair that bottom sensor.

@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.