Skip to content

Ask your questions right here!

2.3k Topics 11.6k Posts

Note sure where to post? Ask questions here for direct access to the ModalAI engineering team

Subcategories


  • 163 Topics
    746 Posts
    Maxwell SchaeferM
    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.
  • Do you have a great idea for our products you would like to see implemented?

    27 90
    27 Topics
    90 Posts
    Serhii RovnyiS
    Hello everyone, I am looking for some expert advice on a VOXL 2 companion computer setup for a long-range platform. I have two main integration challenges: Challenge A: VIO at Higher Altitudes To solve the motion blur and pixel density issues at higher altitudes, I am planning a 6-camera configuration. I want to use 4 downward-facing sensors (2 daylight + 2 IR) equipped with narrow-angle lenses, alongside 2 standard wide-angle sensors (front and rear). Could you advise on the best supported sensors (e.g., IMX series) for this? Has anyone successfully tuned the voxl-qvio-server for narrow-angle lenses, and what were the altitude limits you achieved? Challenge B: LAN Integration & WireGuard The payload data flow will be: External RTSP Camera -> Ethernet -> VOXL 2 (WireGuard encryption) -> Ethernet -> Digital RX. Because VOXL 2 lacks multiple LAN ports, I will need a miniature industrial Ethernet switch. Does ModalAI have any tested hardware recommendations for this? Furthermore, what is the best practice for routing this VPN traffic through the VOXL 2 Ubuntu environment without bottlenecking the CPU? We are currently evaluating the VOXL 2 for a broader fleet deployment and want to ensure the ecosystem can support this custom optics requirement. Any feedback on off-the-shelf solutions or standard configurations for this use case would be greatly appreciated. Thank you!
  • Are you looking for a 3D model of one of our products?

    33 86
    33 Topics
    86 Posts
    Alex KushleyevA
    @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 [image: 1781036132877-376bf0dd-494a-4bf1-8d92-1b2d91afb83d-image.png]
  • VOXL ADB or Wi-Fi no longer communicating!?!

    Pinned Locked
    1
    0 Votes
    1 Posts
    3k Views
    No one has replied
  • 0 Votes
    8 Posts
    77 Views
    nickanickN
    Log taken with PX4 running, flight battery connected, ESCs energised, aircraft disarmed on the bench. battery_status was still unpublished during this window
  • GPS performance noted on the sales page

    1
    0 Votes
    1 Posts
    14 Views
    No one has replied
  • 0 Votes
    10 Posts
    2k Views
    Alex KushleyevA
    Thanks for your patience, I will try to test this today.
  • 1 Votes
    2 Posts
    31 Views
    E
    Hi @kristi, I'm experiencing a similar, though maybe not identical issue. Would you mind sharing the repeatability of your problem? is it consistent? thanks.
  • Starling 2 VOXL 2 - Suspect 5V bus power margin shortage

    3
    0 Votes
    3 Posts
    45 Views
    VinnyV
    Hi @electroAJ, thanks for the detailed writeup and follow-up SKU info. From a hardware standpoint, the 200mV droop you are observing on VDC_5V_LOCAL and VDC_5V_LOCAL_USB1 during ToF activity is not a concern at the rail level. That kind of transient is most likely localized contact/pin loss at the connector interface rather than a bulk supply issue. On a 5V rail, 200mV is well within normal operating margin. The eFuse on that rail does not assert until approximately 4.4V, so a 200mV droop from 5V puts you nowhere near that threshold. Downstream logic is regulated from a 3.8V VBAT rail that has demonstrated margin well above the minimum needed, and that rail is permitted to droop past 3.3V before any real issue occurs. The ToF-induced droop is not your RC dropout culprit. Additionally, the M0129 VOXL Mini ESC power stage has been proven to the same load capability and test rigor as our standalone M0041 power module, using the same parts, so the supply itself is not a suspect to me. Would hate to see you chase a red herring. The I2C errors and UART dropout sequencing are worth looking at together as they may share a common upstream cause. Beyond that, this one is likely better handled by our software team who can dig into the dmesg and service state in more detail. I will flag this thread for them.
  • Starling 2 - RC link dropout debug assistance

    4
    0 Votes
    4 Posts
    40 Views
    E
    @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.
  • Starling 2 - Mag Alignment

    4
    0 Votes
    4 Posts
    48 Views
    Eric KatzfeyE
    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.
  • M0213 Wifi board pinout and availability

    15
    0 Votes
    15 Posts
    4k Views
    Muqing CaoM
    @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?
  • Longer Camera cables between M0173 and M0166 / M0161

    1
    0 Votes
    1 Posts
    33 Views
    No one has replied
  • PX4 Beta Sofware

    6
    0 Votes
    6 Posts
    106 Views
    Eric KatzfeyE
    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.
  • Lost the original Zorro Blue model

    2
    0 Votes
    2 Posts
    70 Views
    Maxwell SchaeferM
    @Omri-Eival The Zorro Blue User Manual should answer most of your questions, with a shell script to copy all of the latest data to a handset in the provided zip file. While you are there, if your firmware is out of date it may be worth going through the update process.
  • Re: [voxl2 is not booting](/topic/4984/voxl2-is-not-booting)

    3
    0 Votes
    3 Posts
    77 Views
    tomT
    @Jetson-Nano Given the crash and hardware issues I'd recommend sending this board in for an RMA
  • 0 Votes
    2 Posts
    422 Views
    Jetson NanoJ
    @ModalAI-Team Help me out here . I want to purchase some new components, but with out having a clear idea on the architecture I won't be able to do it. Please guide me here.
  • 0 Votes
    1 Posts
    28 Views
    No one has replied
  • 0 Votes
    1 Posts
    29 Views
    No one has replied
  • 0 Votes
    1 Posts
    50 Views
    No one has replied
  • IMX412 M12 Lens difference?

    3
    1
    0 Votes
    3 Posts
    232 Views
    Alex KushleyevA
    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
  • 0 Votes
    1 Posts
    66 Views
    No one has replied
  • IMX412-Flip

    12
    1
    0 Votes
    12 Posts
    5k Views
    J
    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