ModalAI Forum

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

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

@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

Thanks for your patience, I will try to test this today.

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

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

@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

@alex-kushleyev Result: --id 255 isn't supported by my voxl-esc-tools (bin version 1.9) — it scans, finds IDs 0–3, then exits with ERROR: Specified ESC ID not found. Running ./voxl-esc-spin.py --id 2 --power 0 works and I do see BOARD_VOLTAGE and BOARD_CURRENT printed. So the ESC is emitting the battery telemetry message correctly. But PX4 still never publishes battery_status: VOXL2 M0054, voxl-suite 1.6.3, 4× M0138-1 ESCs on firmware 39, tools 1.9 BAT1_SOURCE = ESCs, VOXL_ESC_PUB_BST enabled in QGC POWER_MANAGER=none in /etc/modalai/voxl-px4.conf (was voxlpm; changed per the comment "use none for modalai mini-esc since the esc driver handles PM" — I have no voxlpm module, the ESC is my only sensing) px4-listener battery_status 5 → "never published", after systemctl restart voxl-px4 and a full reboot esc_status is healthy: 4 ESCs online, esc_voltage 24.055 (6S) Questions: How do I verify VOXL_ESC_PUB_BST on the flight side? px4-qshell param show VOXL_ESC_PUB_BST doesn't return anything readable in my terminal, so I can't confirm the QGC write reached the DSP. Does the voxl-esc driver poll ESC channel 2 for telemetry in my configuration? If its telemetry rotation depends on the motor mapping, could it be missing the one channel that sends the battery message? Is POWER_MANAGER=none correct for the FPV 4-in-1 (M0138), or is that comment specific to the mini ESC (M0129)?

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

Hey @Moderator , @ModalAI-Team I had few more questions regarding the same. Does the 3D map generated have the same quality has PMD TOF? Can the 3D map be used for P-to-P navigation from voxl-Portal? Can the TOF data be used for collision prevention? Can multiple maps be used together? Does Multiple TOF give collision prevention in multi direction? If you could provide a image of map generated by the new TOF, it would be great and help us to make a decision for our architecture. Thank you for your help and time, looking forward to your response.

I am able to download the log from the site along with all of the parameter settings. The accelerometer bias is clear in the log. Can you try to recalibrate the IMU with air flow on the unit to keep it from getting too hot? The yaw estimate error is not active during the log. However, to remove the interaction with VIO, try setting EKF2_EV_CTRL to 0 and see if that clears that occasional error. If it does then that helps narrow the issue to the VIO input versus the magnetometer / IMU input. Is the red light on the GPS unit or the RC receiver?

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.