ModalAI Forum

OK, thanks for checking. maybe there was a typo before

@Vinny we recently experienced wifi disconnection issue with the m0213 board. During flight the wifi just completely disconnected with does not regain connectivity. It seems that the wifi chipset stopped working. We had to do a complete power cycle to regain connectivity. It happened several times during our test. Could you suggest how to resolve this issue? Or is there a way to do soft-reset of the board if we detect wifi connectivity loss?

Great to hear @mikhail-mayers . I tested the module you sent back and it baffles me... must be some internal silicon damage to the IC since it had all in-spec inputs, and no faults on any outputs, but it was just not turning on... so, it is now one of my Mechanical Samples Glad we could get that resolved for you and thanks for your patience.

@patkirkmartin , let me double check with the team what the process for this will be and the timeline. I will get back to you soon. Since the plan would be to provide the source to the public, it would be posted on gitlab, the feature-related discussion can happen there. We will certainly be able to help review the code and perform some testing. Alex

@zaimin78 , It looks like I got this working. I modified the kernel to do the following not use the combo mode for J6L and allow using J6U as independent camera GPIO109 is used as a shared reset for cameras in slot 1 and 3 (because that's how the signal routing works on VOXL2 + M0135), so the kernel knows that this reset pin is shared this setup is not set up for camera sync - all cameras are running independently I have not tested any cameras in J8U, it may not work - but it should be possible to enable it, just need to test it. You will need to update the kernel on your voxl2: https://storage.googleapis.com/modalai_public/temp/quad_ov7251_boson/qti-ubuntu-robotics-image-m0054-boot-quad-ov7251.img this kernel is based off the kernel that ships with SDK 1.6.3 you can test it before overwriting the current kernel: https://docs.modalai.com/voxl2-kernel-build-guide/#test -- you should do to reduce the chance of bricking your VOXL2 (just in case) HW Configuration: VOXL2 four OV7251 plugged in to J6L. J6U, J7L, J7U via two M0135 adapters without any mods boson320 plugged into J8L via M0194 (you can use M0181 also) there are no shared CCI buses between the ov7251 cameras - slots 0-3 use CCI 0-3 respectively, so no CCI slave address conflicts SW configuration appropriate sensormodules placed into /usr/lib/camera/ -- you can get them from /usr/share/modalai/chi-cdk/ov7251 and ../boson folders: com.qti.sensormodule.ov7251_0.bin com.qti.sensormodule.ov7251_1.bin com.qti.sensormodule.ov7251_2.bin com.qti.sensormodule.ov7251_3.bin com.qti.sensormodule.boson_4.bin use provided voxl-camera-server.conf : https://storage.googleapis.com/modalai_public/temp/quad_ov7251_boson/voxl-camera-server-quad-ov7251-boson.conf may need to modify your Boson resolution from 320x256 to 640x512 if you you have Boson640 Testing after you have all the cameras connected, boot using the test kernel test to see if all cameras are detected: voxl-camera-server -l ... DEBUG: Cam idx: 0, Cam slot: 0, Slave Address: 0x00E2, Sensor Id: 0x7750 DEBUG: Cam idx: 1, Cam slot: 1, Slave Address: 0x00E2, Sensor Id: 0x7750 DEBUG: Cam idx: 2, Cam slot: 2, Slave Address: 0x00E2, Sensor Id: 0x7750 DEBUG: Cam idx: 3, Cam slot: 3, Slave Address: 0x00E2, Sensor Id: 0x7750 DEBUG: Cam idx: 4, Cam slot: 4, Slave Address: 0x00D4, Sensor Id: 0x00FF ... start voxl-camera-server inspect sterams: voxl-inspect-cam ov7251_0 ov7251_1 ov7251_2 ov7251_3 boson [image: 1785341477366-ee693f10-dcf2-4b76-8181-a11a78db9546-image.jpeg] Please give it a shot and let me know if it works! Alex

And the latest build of our fork with this fix is here: http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/voxl-px4_1.14.0-2.0.146-202607161052_arm64.deb

the hexagon sdk has been unlocked. It is under the miscellaneous folder: https://modalai.filecloudonline.com

Hi @Eric-Katzfey Thank you for your help! I got it to work on J19 through PX4.

That red light is for the M0184 ELRS receiver. A constant slow blink from the light means it is disconnected. It will turn solid with a connection. Other LED states are documented here.

Yes, the beta release is fine. It was beta only for some features that are not used on our development drones. Otherwise it was a stable release.

Hello @Alex-Kushleyev , This is exactly what we needed ... thank you for turning the combined flip + GNSS-fix driver around so fast! Confirming our plan against your docs: We're on the encoded (ISP) path ... large_encoded for the pilot's low-latency FPV feed, not MISP ... so the ISP should pull the reversed bayer from the flip sensormodule and debayer correctly (no R/B swap). We'll run the version-agnostic combo: the flip sensormodule + en_rotate = true, plus maxRAWSizes=20 in camxoverridesettings.txt. Bit rate: going with 2088 Mbps. Our GNSS is a Septentrio mosaic dual-antenna running moving-baseline heading, so GPS L1 integrity is critical for us ... your analysis showing 2088 sitting ~10 MHz off L1 center with only a 1–2 dB drop is exactly the margin we need. We'll keep our FPV mode clear of the three forced-2200 modes (staying 1080p ≤120 fps). We'll validate by logging the Septentrio C/N0 and satellite count with the camera streaming vs. off, in representative daylight (noting your point that under-exposed frames worsen the interference). One quick check: for our single hires IMX412 on the M0173, is the default i2c 0x34 the right choice, or is there a scenario where we'd want the 0x20 variant? I'll report back the before/after GNSS numbers once we've tested ... happy to share the data if it's useful. Thanks again, John

@moderator Any reply will be much appreciated.

@brahim Hm, after a few reboots and trying again a few days later it is working. Do you know where this package lives so I can inspect the source code? I am not sure what the ros2 node is doing but I do see topics relating to imu and camera data. I have the Starling2 Max C29 config in regards to sensors. ing2-max (D0012):~$ ros2 run voxl_mpa_to_ros2 voxl_mpa_to_ros2_node Found new interface: yolo11_tflite_data 2026-07-28 21:25:30.085 [SUBSCRIBER Error] Deserialization of data failed -> Function deserialize_change Found new interface: hires_front_large_color 2026-07-28 21:25:36.819 [SUBSCRIBER Error] Deserialization of data failed -> Function deserialize_change Found new interface: hires_front_large_encoded Found new interface: hires_front_large_grey Found new interface: hires_front_small_color Found new interface: hires_front_small_encoded Found new interface: hires_front_small_grey Found new interface: hires_front_snapshot Found new interface: tof_conf Found new interface: tof_depth Found new interface: tof_ir Found new interface: tracking_down Found new interface: tracking_down_bayer Found new interface: tracking_down_misp_encoded Found new interface: tracking_down_misp_grey Found new interface: tracking_down_misp_norm Found new interface: tracking_front Found new interface: tracking_front_bayer Found new interface: tracking_front_misp_encoded Found new interface: tracking_front_misp_grey Found new interface: tracking_front_misp_norm Found new interface: yolo11_tflite Found new interface: imu_apps Found new interface: imu_apps_body Found new interface: imu_apps_notemp Found new interface: imu_apps_raw Found new interface: imu_mavlink Found new interface: tof_pc Found new interface: voa_pc_out Found new interface: voxl_mapper_aligned_ptcloud Found new interface: vvhub_body_wrt_fixed Found new interface: vvhub_body_wrt_local Found new interface: ov Found new interface: vvhub_aligned_vio

@zauberflote1 Hi ZBFT, reagardng your fitst question: yes, we have added few elements: 2d Lidar 50gram above the gps bridge 2 x light ilumination (front, down - we are flying and dark tunnels next to tracking cameras) props guards the are seen by the tracking camera we have added tof camera, moving from C28 to C29 ( currently its not working or wired in sw), we have changed the extrinsix.conf file in /etc/modalai accordingly. all of those changes did not effect our filght and we had good flight with good vio during the flight. rerding youe second point: we did not fly with logs. that is the first thing we are going to do Sunday morning when we will be back in the lab. hope to understand more from logs. if not we will send it to you hopefully you can enlight us. regarding your third point I dont actualy know the answer: as I wrote first time I started this thread, we are monitoring the px4 using mavlink status and we see the horizontal position was lost in the middle of flight after starting a manuver to the right which is using position hold. but even when we tried to position hold from code we so vio is lost. I want to emphasize we had a stable system hw and sw wise and suddelny it degregated and we cannot put our finger what has changed. BR, Roy

@RoyAzriel 1.6.4 release is tested on Starling 2 now, go ahead and use that from the link I emailed you.

@Ben-Linne I'm likely able to perform those updates. A fix is good, but root cause understanding of the issue is better at this point, so I will try updates once all other debug opportunities are spent if I can't reach a deterministic resolution. receiver antenna [...] understood and checked out. I've confirmed the umcc(u.fl) connection is fully seated and no damage is present anywhere. If the transmitter is showing signal but the drone is not responding it's possible you are bound to another transmitter. this is a state I will confirm. So far though, I believe the failure mode is observable with no other transmitters powered, but i will confirm. Thanks.

That'a a calibration parameter that is set automatically by the mag calibration procedure. Normally it should properly detect the orientation / rotation and set it. I'm not sure why that wasn't happening for you when you calibrated the mag.

What is the physical connection between the Optical flow unit and the FC? Is it a UART? Which optical flow unit are you using?

MCBL-00084-180 (26-pin Micro-Coax Cable): Operating temperature 0°C to +70°C; Storage temperature 0°C to +70°C. MSU-M0161 (EO Camera): Operating temperature 0°C to +70°C; Storage temperature 0°C to +70°C. (The Sony IMX412 image sensor guarantees image performance from −10°C to +60°C.) VOXL 2 / MDK-M0154-1-00 (Flight Computer): Operating temperature 0°C to +70°C; Storage temperature 0°C to +70°C. MDK-M0155-1-00 (Image Sensor Micro-Coax Adapter): Operating temperature 0°C to +70°C; Storage temperature 0°C to +70°C. MDK-M0062-3-00 (VOXL2 Ethernet & USB Hub Adapter): Operating temperature 0°C to +70°C; Storage temperature 0°C to +70°C.

Yes, use the normal RC port. But cannot use an SBUS receiver with that port.