Hi @john.almasi , Can you please let me know which output stream(s) you are using for the IMX412 camera. For example: preview, small_video, large_video, misp, etc.. If you are using small_encoded / large_encoded, then those are going through the ISP and will automatically adjust the decoding for the bayer pattern from RGGB to BGGR (because the image read-out is backwards, the pattern flips). See the directions below. If you are using MISP output, then your current camera server version does not support this method and will show incorrect colors (red and blue swapped). The rotated version of the driver is available in this zip : https://storage.googleapis.com/modalai_public/temp/imx412_test_bins/20250919/imx412_fpv_eis_20250919_drivers.zip Directions: unzip back up your current com.qti.sensormodule.imx412_fpv_1.bin and com.qti.sensor.imx412_fpv.so on your voxl2 (in /usr/lib/camera/). -- you need to rename or remove them from that location copy the new com.qti.sensor.imx412_fpv.so and com.qti.sensormodule.imx412_fpv_flip_20250919_1.bin to /usr/lib/camera. restart voxl-camera-server. the rotation is done (in this case) by adding a configuration register in the sensormodule file, which instructs the camera to send the image backwards. The sensormodule file also has information to tell the ISP to debayer the image properly as BGGR (rotated) as opposed to RGGB (normal). If you are using MISP streams, then we will need to do some update to your camera server. Final note, If you are using GPS with your drone, we recently found that old IMX412 drivers (including what i just linked) interfere with GPS signal. The non-flip drivers for IMX412 that fix the GPS interference issue can be found here : https://storage.googleapis.com/modalai_public/temp/imx412_test_bins/20260529/imx412_drivers_20260529.zip. Please let me know if you are using GPS and we can go from there. Alex

You are welcome! By the way the Starling 2 Max plastics kit (linked above) contains both types of front camera mounts (with and without the TOF sensor).

A picture of the board: [image: 1783360109929-%E5%9B%BE%E7%89%87_20260706134745.jpg]

Hi @Alex-Kushleyev, I wanted to follow up on this as we are currently in a critical phase of our commercial pilot deployment, and having the Starling 2 grounded is severely impacting our timeline. Given the voxl-imu-server logs and the pictures provided, is there any specific software workaround, service configuration, or hardware adjustment we can try to restore the IMU functionality? If you determine that the board requires factory repair or replacement, please let us know how we can expedite the RMA process to get operational again as soon as possible. Thank you for your support, Luis

@Ebenezer-Afrifa , sorry, but Starling 2 Max is not capable of carrying such a large payload. We currently do not offer any platforms capable of carrying 3-4 pounds. Alex

@nickanick is this the right place to ask these questions?

@NikosMav Yes, things will get hotter when running QVIO. But once you arm and start the props everything will cool down. When reflashing the SDK I would grab one of the official releases from our downloads page and not a nightly.

Hi team — just bumping this in case it slipped through. We're ready to buy one evaluation unit and would really appreciate a quick steer: can the Stinger Vision FPV run AUTONOMOUS VIO/SLAM + AprilTag precision landing, or would Starling 2 / Starling 2 Max be the better evaluation platform for the requirements above? I've also emailed sales@modalai.com in parallel, so whichever channel is easier works for us. Thanks!

if no internet is available onboard llm+NPU can help repairing-agent to fix the issue or provide reason of failure.

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

@voxltester As I tried to explain before, don't wait for voxl-mavlink-server to connect to your application. You need to have it initiate the connection to voxl-mavlink-server.

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

@zaimin78 , I am sorry for the long delay, we somehow missed this post. Can you please let me know which kernel variant you are using? (you can check it using voxl-version and look at mach.var. There is no good way of making this configuration work, because the default function of J6U is actually disabled by default in favor for using a stereo camera setup, as shown here : https://docs.modalai.com/voxl2-camera-configs/#c-10-front-stereo-only-ov7251 . So the kernel variant that is compatible with the M0135 / M0076 interposers, cannot be used for any camera in J6U camera slot (slot 1). However, the J7U and J7L should work. The way to make the 4th camera work is to use either M0135 or M0076 to connect it to J8L (slot 4) instead of J6U. I am not sure why your J7U (slot 3) did not work -- can you try connecting without extension cables? Alex

@Jetson-Nano Can you rebuild to add UAVCAN? The code is here: https://github.com/modalai/px4-firmware/tree/v1.14.0-2.0.133-dev