@Alex-Kushleyev Sounds good, thank you!

@cguzikowski , thanks for following up.

I don't know why the ISP is outputting the jpeg with the issue - that is outside of our area of expertise. It could be a bug in the ISP or JPEG encoder.

I will get together some scripts i have been using for testing. I need add the LSC (lens shading correction) otherwise the colors look wrong and also image gets darker towards the edges. In order to apply LSC correction, we need a map (either look-up table or a poly fit) of each channel's response as a function of pixel coordinate (or radius) -- this needs to be calibrated (not for each camera module, but for each camera type + lens type). So after the calibration, my results should apply to your camera as well.

I will follow up early next week.

Alex

@ApoorvThapliyal Thank you for your help. also I was able to work with jazzy by only subscribing and printing with node. since error only occurred when I tried to echo the topic and not when another node is subscribing it. but using docker seems like most viable option to me since I m using ubuntu 24.04. Thank you for your help again

Hi Alex,
Thanks - As @Adnaan-Yunus mentioned, we switched over to the ALFA wifi and moved forward with that drone. But, we just received a new drone (model MRB-D0012-4-V4-C28-M36-T8-K2) and are experiencing similar issues. I managed to catch some log messages when the wifi went down. TLDR: it looks like the USB disconnected unexpectedly; the drone was stationary on a table top when this happened.

Some additional context: the only configuration changes we made since unboxing was via voxl-wifi and we altered the RTSP address in voxl-mavcam-manager.conf. QGC was running when the USB disconnected with RTSP video displayed. The drone was not armed.

Here's the configuration (everything looks as we expect).

$ voxl-wifi WiFi is currently set up as follows: Mode: station Hardware: Concurrent STA+AP capable (AP:uap0, STA:mlan0) Station: Active on mlan0 - "WAVLINK" SoftAP: Disabled $ iwconfig ip6tnl0 no wireless extensions. sit0 no wireless extensions. ip_vti0 no wireless extensions. mlan0 IEEE 802.11-DS ESSID:"WAVLINK" [11] Mode:Managed Frequency=5.6 GHz Access Point: ********************* Bit Rate:175.5 Mb/s Tx-Power=24 dBm Retry limit:9 RTS thr=2347 B Fragment thr=2346 B Encryption key:****-****-****-****-****-****-****-****-****-****-****-****-****-****-****-****-****-****-****-****-****-****-****-****-****-****-****-****-****-****-****-**** Security mode:open Power Management:off Link Quality=5/5 Signal level=-43 dBm Noise level=-93 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:462 Tx excessive retries:12 Invalid misc:24 Missed beacon:0 dummy0 no wireless extensions. ip6_vti0 no wireless extensions. lo no wireless extensions. bond0 no wireless extensions. uap0 IEEE 802.11-DS ESSID:"" Mode:Master Frequency:2.437 GHz Access Point: Not-Associated Encryption key:off Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 $ ifconfig bond0: flags=5123<UP,BROADCAST,MASTER,MULTICAST> mtu 1500 ether e6:71:39:a5:83:a1 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 dummy0: flags=195<UP,BROADCAST,RUNNING,NOARP> mtu 1500 inet6 fe80::1f3:bbc4:ab69:16bf prefixlen 64 scopeid 0x20<link> ether 6a:c1:84:76:8c:1c txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 12 bytes 3016 (3.0 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) RX packets 104854 bytes 11086017 (11.0 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 104854 bytes 11086017 (11.0 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 mlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.30.104 netmask 255.255.255.0 broadcast 192.168.30.255 inet6 fe80::a637:6051:853a:6d93 prefixlen 64 scopeid 0x20<link> ether 8c:1f:64:69:da:d2 txqueuelen 1000 (Ethernet) RX packets 302 bytes 23251 (23.2 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 3784 bytes 1942045 (1.9 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

On another machine, we can ping and access to the web frontend http://192.168.30.104 looks good.

64 bytes from 192.168.30.104: icmp_seq=280 ttl=64 time=114 ms 64 bytes from 192.168.30.104: icmp_seq=281 ttl=64 time=126 ms 64 bytes from 192.168.30.104: icmp_seq=282 ttl=64 time=123 ms 64 bytes from 192.168.30.104: icmp_seq=283 ttl=64 time=123 ms 64 bytes from 192.168.30.104: icmp_seq=284 ttl=64 time=114 ms 64 bytes from 192.168.30.104: icmp_seq=285 ttl=64 time=118 ms 64 bytes from 192.168.30.104: icmp_seq=286 ttl=64 time=107 ms 64 bytes from 192.168.30.104: icmp_seq=287 ttl=64 time=108 ms 64 bytes from 192.168.30.104: icmp_seq=288 ttl=64 time=104 ms

However, with a few minutes the ping's stopped. I monitored dmesg -w and here's what was output when the wifi went down:

[ 433.066912] usb 2-1: USB disconnect, device number 3 [ 433.068450] Card is removed: -108 [ 433.068644] EP 2 Tx URB status failure: -108 [ 433.068701] EP 2 Tx URB status failure: -108 [ 433.068748] EP 2 Tx URB status failure: -108 [ 433.068794] EP 2 Tx URB status failure: -108 [ 433.068839] EP 2 Tx URB status failure: -108 [ 433.068885] EP 2 Tx URB status failure: -108 [ 433.068937] EP 2 Tx URB status failure: -108 [ 433.068985] EP 2 Tx URB status failure: -108 [ 433.069031] EP 2 Tx URB status failure: -108 [ 433.069085] EP 2 Tx URB status failure: -108 [ 433.069140] EP 2 Tx URB status failure: -108 [ 433.069190] EP 2 Tx URB status failure: -108 [ 433.069317] Card is removed: -108 [ 433.069344] Card is removed: -108 [ 433.069369] Card is removed: -108 [ 433.069393] Card is removed: -108 [ 433.069419] Card is removed: -108 [ 433.069446] Card is removed: -108 [ 433.070472] Block woal_cfg80211_deauthenticate in abnormal driver state [ 433.083826] Error deleting the crypto keys [ 433.083851] Error deleting the crypto keys [ 433.083863] Error deleting the crypto keys [ 433.083874] Error deleting the crypto keys [ 433.083884] Error deleting the crypto keys [ 433.083895] Error deleting the crypto keys [ 433.356084] USB: unregister device [ 433.357228] Free module params [ 433.704223] usb 2-1: new SuperSpeed Gen 1 USB device number 4 using xhci-hcd [ 433.722038] usb 2-1: New USB device found, idVendor=1286, idProduct=2052, bcdDevice=31.17 [ 433.722048] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 433.722053] usb 2-1: Product: Marvell Wireless Device [ 433.722057] usb 2-1: Manufacturer: Marvell [ 433.722062] usb 2-1: SerialNumber: 0000000000000000 [ 433.725632] USB probe: idVendor=1286 idProduct=2052 bInterfaceNumber=0 [ 433.725665] VID/PID = 1286/2052, Boot2 version = 3117 [ 433.725694] Attach moal handle ops, card interface type: 0x404 [ 433.725721] rps set to 0 from module param [ 433.725733] No module param cfg file specified [ 433.725756] rx_work=1 cpu_num=8 [ 433.725771] Enable moal_recv_amsdu_packet [ 433.725807] Attach mlan adapter operations.card_type is 0x404. [ 433.727974] Request firmware: nxp/usbusb8997_combo_v4.bin [ 434.220193] fw_dnld: 597712 bytes downloaded [ 434.996176] USB: unregister device [ 434.996231] Free module params [ 434.996608] usb 2-1: Disable of device-initiated U1 failed. [ 434.996691] usb 2-1: Disable of device-initiated U2 failed. [ 435.180482] usb 2-1: reset SuperSpeed Gen 1 USB device number 4 using xhci-hcd [ 435.197429] usb 2-1: device firmware changed [ 435.205171] usb 2-1: USB disconnect, device number 4 [ 435.388251] usb 2-1: new SuperSpeed Gen 1 USB device number 5 using xhci-hcd [ 435.409284] usb 2-1: New USB device found, idVendor=1286, idProduct=204e, bcdDevice=32.01 [ 435.409293] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 435.409299] usb 2-1: Product: Bluetooth and Wireless LAN Composite Device [ 435.409303] usb 2-1: Manufacturer: Marvell [ 435.409308] usb 2-1: SerialNumber: 8C1F6469DAD2 [ 435.421408] USB probe: idVendor=1286 idProduct=204e bInterfaceNumber=0 [ 435.421523] VID/PID = 1286/204E, Boot2 version = 3201 [ 435.421537] woal_usb_probe: invalid endpoint assignment [ 435.421972] USB probe: idVendor=1286 idProduct=204e bInterfaceNumber=0 [ 435.422025] VID/PID = 1286/204E, Boot2 version = 3201 [ 435.422038] woal_usb_probe: invalid endpoint assignment [ 435.423075] USB probe: idVendor=1286 idProduct=204e bInterfaceNumber=0 [ 435.423095] VID/PID = 1286/204E, Boot2 version = 3201 [ 435.423123] Attach moal handle ops, card interface type: 0x404 [ 435.423145] rps set to 0 from module param [ 435.423157] No module param cfg file specified [ 435.423179] rx_work=1 cpu_num=8 [ 435.423193] Enable moal_recv_amsdu_packet [ 435.423228] Attach mlan adapter operations.card_type is 0x404. [ 435.425589] WLAN FW is active [ 435.425712] Download txpwrlimit_cfg=nxp/sparrow_power.bin [ 435.425916] Request firmware: nxp/WlanCalData_ext_sparrow_default.conf [ 435.593367] fw_cap_info=0x185cbfa3, dev_cap_mask=0xffffffff [ 435.593393] max_p2p_conn = 8, max_sta_conn = 10 [ 435.619603] Register NXP 802.11 Adapter mlan0 [ 435.619695] wlan: uap%d set max_mtu 2000 [ 435.622776] Register NXP 802.11 Adapter uap0 [ 435.623087] wlan: version = USB8997---16.197.121.p2-MX5X16505.p7.2-(FP197) [ 435.641209] IPv6: ADDRCONF(NETDEV_UP): mlan0: link is not ready [ 435.743762] wlan: mlan0 START SCAN [ 438.940152] wlan: SCAN COMPLETED: scanned AP count=21 [ 438.948662] wlan: HostMlme mlan0 send auth to bssid 82:XX:XX:XX:1e:03 [ 438.957472] mlan0: [ 438.957479] wlan: HostMlme Auth received from 82:XX:XX:XX:1e:03 [ 438.998547] wlan: HostMlme mlan0 Connected to bssid 82:XX:XX:XX:1e:03 successfully [ 439.105657] mlan0: [ 439.105663] wlan: Send EAPOL pkt to 82:XX:XX:XX:1e:03 [ 439.118805] mlan0: [ 439.118811] wlan: Send EAPOL pkt to 82:XX:XX:XX:1e:03 [ 439.122028] IPv6: ADDRCONF(NETDEV_CHANGE): mlan0: link becomes ready [ 450.142651] CAM_INFO: CAM-CRM: __cam_req_mgr_find_dev_name: 209 Skip Frame: req: 13272 not ready on link: 0x1e0117 for pd: 2 dev: cam-sensor open_req count: 2 [ 452.679713] CAM_INFO: CAM-CRM: __cam_req_mgr_find_dev_name: 209 Skip Frame: req: 13347 not ready on link: 0x1e0117 for pd: 2 dev: cam-sensor open_req count: 3 [ 454.406150] msm_vidc: err : ffffffff: .....: DBLP Set: status 0 [ 454.415602] CAM_INFO: CAM-CRM: __cam_req_mgr_find_dev_name: 209 Skip Frame: req: 13398 not ready on link: 0x1e0117 for pd: 2 dev: cam-sensor open_req count: 2 [ 455.350340] CAM_INFO: CAM-CRM: __cam_req_mgr_find_dev_name: 209 Skip Frame: req: 13425 not ready on link: 0x1e0117 for pd: 2 dev: cam-sensor open_req count: 2

If I now run voxl-wifi and enter the same settings, the wifi will come back online. I was able to reproduce this issue several times.

Hi Kim,

There are a couple changes required here that will make this work:

1. Rebuilding Kernel with SPI14 enabled
You're going to have to rebuild and flash the kernel with QUP14 enabled as SPI. There is also a directional level shifter on GPIO67 that needs to be set to high in order for SPI on QUP 14 to work. I created this branch for you that should have the kernel changes that you need:

feature/voxl2-mini-spi-qup14 (link)

In order to actually build and flash the kernel please follow the instructions from our public docs on how to build the kernel

https://docs.modalai.com/voxl2-kernel-build-guide/

When building the kernel, after syncing but before building, make sure to go to the cloned meta-voxl2-bsp directory and checkout the branch that I created (feature/voxl2-mini-spi-qup14).

Also there is a chance you may need to build a kernel variant depending on your device so also make sure to check this document to see if you have a -2 device which would require building the kernel with the -v var02 flag

https://docs.modalai.com/m0054-versions/#m0054-1-and-m0054-2

2. Configuring Trustzone with Correct QUP
I would recommend using the devcfg binary that comes from the `voxl2-mini_SDK_1.0.0.tar.gz. In order to flash devcfg you'll want to run the following command

fastboot flash devcfg <path/to/voxl2-mini_SDK_1.0.0/devcfg>/devcfg.mbn

You should flash the kernel and devcfg (Trustzone) during the same fastboot session to avoid running into any issues with the device booting.

Let me know if you have any additional questions or run into any issues!

@Alex-Kushleyev I reflashed 1.6.3 on the VOXL 2 twice and it seemed to fix it the second time. Weird that it fixed it and I am also unable to reproduce the issue again. At least it works now lol.

Hi @bschulzhf ,

voxl-inspect-cam -a command should not be generally used as it puts a lot of stress on the system. just use it to inspect the stream that you need, such as voxl-inspect-cam hires_down_large_color.

Also, in your camera config changes, it is not clear exactly what changes you actually made, since you did not provide a diff (but i can see that you probably disabled all the streams except for the preview stream). In any case, you should revert your changes and just inspect the stream you need to estimate the latency.

If you want to provide more information about your application, we can suggest appropriate camera server parameter changes. I do see that ae_desired_msv": 60 is potentially too dark (the target average pixel value for auto exposure control) - you can try increasing it and see if the image is too dark.

Alex

Hi @mtcbj
That is the flex stiffener. Our older image modules used stainless steel. Some of our newer modules use laminate.
Those holes are likely just flex/FPC air escapes during the backer lamination process. They do not provide any functional purpose after assembly.
I see no issue filling them with epoxy.
Hope that helps!

Hi @Jetson-Nano
Thank you for your request regarding MTTF and reliability data for the listed hardware components.

At this time, we do not publish formal MTTF/MTBF values for these products. The primary reason is that these systems (VOXL2, ESC, Flight Controller V2, Front-End Board, and Camera Modules) are delivered as development platforms intended for user-defined integration, testing, and operation. In the vast majority of use cases, overall system lifetime is dominated by application-specific factors such as mechanical stress, environmental exposure, power integrity, and crash events rather than intrinsic electronic wear-out mechanisms. As a result, standardized MTTF/MTBF metrics are not representative or particularly actionable for these platforms.

That said, the underlying silicon and design heritage for these systems is derived from high-volume mobile and embedded computing applications. These components are built on technologies that are broadly characterized for long operational lifetimes under nominal conditions, consistent with industry expectations for modern semiconductor devices.

Additionally, portions of the broader technology heritage have been evaluated in demanding environments, including public programs associated with NASA JPL (e.g., Mars Helicopter which is our design heritage, and CADRE lunar rover initiatives). However, detailed qualification data and reports from those efforts and other non-public efforts are not available for external distribution.

From a reliability perspective, our hardware is designed and validated using standard industry practices, including:

Functional validation across operating voltage and temperature ranges Environmental and stress testing at the system level (i..e: we and our customers put our drones into very demanding scenarios) Design margining consistent with mobile/embedded electronics standards, oftentimes far exceeding industry norm Production screening and quality control processes and test screening

For applications requiring higher confidence in operational lifetime, we typically recommend system-level validation under the specific mission profile, including environmental testing (thermal cycling, vibration, shock) and power/load characterization representative of the end use case.

Hope this helps.

@shiva-rv Try heating up the IMU by stressing the CPU then shooting it with air to create a large thermal gradient between the silicon of the VOXL2 and the IMU die itself, I predict you'll see the Z bias jump like crazy, but X and Y not so much.

You might also observe that the temperature gradient determines the bias, not the absolute temperature, hence using a temperature model for compensation is useless, and not applied by modal: https://gitlab.com/voxl-public/voxl-sdk/services/qrb5165-imu-server/-/blob/master/server/src/imu_interface.cpp?ref_type=heads#L168

If you're curious about the physics of why MEMs IMUs like ICM42688 act this way I'm sure your favorite AI chatbot could give you a nice explanation about the materials sciences at play here.

Practically, thermally isolate the IMU component as much as possible.

@Moderator Why is it not plug in play? I found the spot to connect to the board but configuring the SKU based on C29 did not work. Also, the connector seems really short so I am curious how the C29 config looks.

@Alex-Kushleyev this is super helpful. Thank you.