ModalAI Forum

Hello, I would like to follow up on this topic. We are currently evaluating the feasibility of using Starling 2 for indoor autonomous flight applications in Japan. Understanding the recommended Wi-Fi configuration for operation in Japan will help us continue our evaluation. If anyone from the ModalAI team could provide guidance, we would greatly appreciate it. Thank you very much.

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.

Hello @jameskuesel , Sorry for the confusion about the lens change. Please see the details below. The original lens in the IMX412 modules (M0107 and M0161) had manufacturing issues where the internal components of the lenses were loose and vibrating in flight, causing shaky video. Due to quality / vibration issues of the original lens (part number M10000580) shipping with IMX412 (M0107 and M0161) modules, the default lens was changed to M10001028 (late 2025). However the new lens does have much narrower FOV. When purchasing the standalone camera, you have a choice of lens: M0161 with old lens (wide) : MDK-M0161-1-07 (3.1mm EFFL, M10000580 lens) M0161 with new lens (narrow) : MDK-M0161-1-08 (3.24 EFFL, M10001028 lens) It seems that there maybe some discrepancy in the manufacturer stated EFFL for the new lens (3.24 vs original 3.1) because the actual FOV change is more significant than the change in the effective focal length would result in. We are looking into this. Starling 2 and Starling 2 Max drones are currently shipping with the new lens (narrow FOV). We do currently have stock of the old (wide) lenses that should have no issues (according to the manufacturer), however we cannot provide any guarantees for this lens due to past history of issues. If you would like to update your drone / camera with the original wide lens, please contact us and we will make it available for you to purchase (lens part number M10000580). Alex

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

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.

@mrawding , I am sorry, but it looks like we are not going to be officially supporting Ubuntu2.0 Kernel on VOXL2, as we are working on enabling next gen hardware.. We did start the effort but it is not going to be finished for the general availability for VOXL2. 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

@alex-kushleyev @eric-katzfey Apologies for the direct mention — I hope you don't mind. I posted this question set about two weeks ago (and a related product question three weeks ago), but haven't heard back yet. We are preparing to purchase a Starling 2 Max (C29, with the PMD ToF) as an evaluation unit for an indoor GPS-denied inspection project, and just three answers would unblock our decision: Can VOXL SLAM / VOA (with the dense PMD ToF on the C29 configuration) reliably handle very narrow corridors — around 300 mm width? Any references to pipe/industrial inspection use cases in similar tight spaces would be very helpful. For repeated missions in the same indoor space, is voxl-mapper + AprilTag re-localization the recommended pattern to bound Open-VINS drift (no loop closure)? What is the practical minimum illumination for reliable VIO with the tracking cameras — and do you recommend onboard IR/LED illumination for dim industrial interiors? Even brief pointers to relevant docs would be greatly appreciated. Thank you for the great platform and documentation!

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

Wanted to check in again. Any advice on swapping spektrum RC for ghost atto on voxl2?