For visibility, since this seems related to the old BLE/VOXL discussion here:
https://forum.modalai.com/topic/1730/bluetooth-ble-communication-on-the-voxl-is-it-possible

I was able to get BLE 5.0 extended advertising scanning working on VOXL2 / Starling 2 with an ASUS BT500 / Realtek RTL8761B USB adapter by backporting newer upstream Linux Bluetooth HCI event parsing logic into the QRB5165 4.19 kernel tree. My understanding is future revisions of VOXL will have more up to date kernels that solve this issue without back porting.

The issue we were hitting was with LE Extended Advertising Reports. With BLE 5.0 beacons transmitting extended advertising, the older 4.19 Bluetooth path could mis-handle extended advertising report parsing / event-type bits, leading to bad report handling and, in our case, Bluetooth instability / crashes during scanning.

The relevant upstream Linux changes I used as reference include:

b48b833f9e8a - Bluetooth: HCI: Use skb_pull_data to parse LE Ext Advertising Report event ad38e55e1c89 - Bluetooth: hci_event: Ignore reserved bits in LE Extended Adv Report 0cadf8534f2a - Bluetooth: hci_event: Mask data status from LE ext adv reports

There are also related Realtek / extended-scan quirk changes upstream, but for our immediate case the stronger LE extended advertising parser backport was enough to stop the crash path and allow scanning.

Validated result:

VOXL2 / Starling 2 QRB5165 4.19 kernel ASUS BT500 / RTL8761B USB BLE adapter BLE 5.0 beacons using extended advertising btmgmt --index 0 find -l successfully reports devices and RSSI btmon captures LE Extended Advertising Report events no more Bluetooth NULL pointer dereference / hci_le_ext_adv_report_evt crash during the test observed all 16 expected beacons and repeated RSSI samples

I’m not proposing this as a merge-ready ModalAI patch, but I put the build changes and notes here in case anyone else needs BLE 5.0 extended advertising / RSSI collection on VOXL2:

https://gitlab.com/steven323/qrb5165-kernel-build-docker

Relevant upstream commit links:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b48b833f9e8a
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ad38e55e1c89
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0cadf8534f2a

@Alex-Kushleyev @Eric-Katzfey

I would appreciate any updates or recommendations regarding the integration and availability of the M0189 VOXL 2 Mini ToF sensor.

Thank you for your continued support.

@andrek Thanks for catching it! We just updated flat builds and now it contains m0054-2!

Hi @isagmz
That is indeed a cap. It is a 4.7uF 25V 0603 in support of the 5V input rail when sourced by J5.
0a20b27c-498c-4971-be16-f9c02719c08f-image.png
We have so much margin on the 5V power rail, I would not worry about one cap missing. My best advice is to clean up that area to make sure there is no FOD or ripped up pads that can cause a short on that 5V rail from the broken cap, and just keep developing.
Let us know if you have any other issues.
Thanks!

@Arunabh-Sharma ,

I believe the extrinsics file is correct. Here is an extrinsics file for Starling 2 (which can support up to 3 tracking cameras, depending on configuration). https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-tools/-/blob/master/misc_files/usr/share/modalai/extrinsic_configs/D0014_Starling_2.conf

tracking_down is the camera we want and the extrinsics are:

"parent": "imu_apps", "child": "tracking_down", "T_child_wrt_parent": [-0.08825, -0.0045, 0.0269], "RPY_parent_to_child": [0, 0, 180]

54bec293-dddc-48e7-903b-47dda8c48787-image.png

I have labeled the camera X and Y axes on the down-facing rear camera and the rotation matches up with 180 degree yaw with respect to the drone's body axes (X=forward, Y=right, Z= down)

Please note something that may add to the confusion. The front facing tracking camera is technically upside down (using our standard convention that i labeled for the down-facing camera), however we rotate the image 180 degrees in the camera itself during image read-out, so that the image looks right side up without any software work. This 180 degree rotation is selected in voxl-camera-server.conf with a rotation parameter, which instructs voxl-camera-server to set a special register in the camera to reverse the image readout. This is why you will see tracking_front and hires cameras having the same rotation extrinsics, while the tracking_front camera is physically upside down.

Some more info about our extrinsics and conventions : https://docs.modalai.com/configure-extrinsics/

Alex

@ey , we are working on making a replacement plastic kit available. It looks like you may have gotten a response from our team already, but moving forward we should have some kits available soon.

Alex

@John-Keller , please try https://docs.modalai.com/voxl2-unbricking/

@Engineer123

You can download all the necessary flat build files from our page: [modalai.filecloudonline.com](link url). Go into flat builds folder and download the m0054(154-1) flat build file

With regards to actually flashing the flat build, and using modal-qdl repo:

Make sure to put the flat build file properly in a correct folder as mentioned by the doc (./qdl/qfil_app/modalai). Make sure the file is unzipped (it should be m0054(154-1)/ all the files, NOT m0054(154-1)/m0054(154-1)/....) Some users have seen a higher qdl success rate when they ran install_dependencies.sh and run.sh with sudo commands. So sudo might work better Confirm that the voxl is in edl mode

@nl_vdi , if you log into developer.modalai.com, you will see the CAD models. the latest model we have is:

D0012-4-V3-C28-M36-T7-K0-Starling2-Max-V3-20260317.step

376bf0dd-494a-4bf1-8d92-1b2d91afb83d-image.png

@nickanick , can you please clarify which exact WIFI Dongle you would like to use?

@j-angel ,

We had a small batch of color AR0144, but those have run out and due to low demand, we do not have any stock.

I would like to clarify something. Motion blur is present when using any camera (global shutter or rolling shutter). Global shutter cameras also have exposure control and long exposure times will cause motion blur.

I think what you may be referring to, which is different in rolling shutter cameras (compared to global shutter), is the rolling shutter skew. Rolling shutter cameras use a technique where the start of exposure of each image row is offset slightly, so each row is essentially exposed over a different time frame. The offset is usually very small (4-30 microseconds per line, depends on the camera, mode), but from top to bottom, the rolling shutter effect can add up and be visible when there are moving features in the scene.

The fastest rolling shutter camera we have right now is IMX412 and in the 2x2 binning mode, the 1920x1080 resolution, the total frame readout time is 4ms. (https://docs.modalai.com/camera-video/low-latency-video-streaming/#camera-pipeline-latency-in-different-operating-modes). This means that the difference of the center of exposure between the first and last image row is 4ms.

Considering the information above, 4ms can seem a lot, but keep in mind that is the time delay across the whole image. depending on the size of features, the rolling shutter effect across a smaller image area will be smaller. Using the height of 1080, we can compute the time offset for each line, 4ms / 1080 ~ 4us.

Depending on the size of features that are being tracked, the rolling shutter may not create a lot of local skew. Additionally, the camera timing is deterministic, so it is possible to calculate the time offset of the center of exposure of each line (with respect to the first line). If you want to provide some more details on type of perception, I could provide more guidance.

Unfortunately, right now, we do not have a color global shutter camera option.

Alex

@jon You can use a J19 UART from the apps processor. Take a look at the code in voxl-elrs (https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-elrs/-/tree/dev?ref_type=heads), specifically the file src/elrs_slpi.c. This project accesses SLPI UARTs from an AP userspace process through voxl_io, not through POSIX termios. You cannot have a flight controller running at the same time though so PX4 / ArduPilot / etc. would need to be stopped first.

@Michael-Hatton Yes, you need to have a separate battery charger. I'll see if I can get a recommendation from the team on a good charger to use. I use a Hota D6 Pro, personally.

@Michael-Hatton Did you run through the voxl-configure-modem setup in order to configure APN, etc?

https://docs.modalai.com/voxl-modem/#usage

@wilkinsaf You can disable compass with SYS_HAS_MAG = 0 and EKF2_MAG_TYPE = 5. But if you enable it and it isn't healthy you won't be able to arm. Power compensation may work, it depends on your particular drone model and use case.