Hi @mtcbj
That is the flex stiffener. Our older image modules used stainless steel. Some of our newer modules use laminate.
Those holes are likely just flex/FPC air escapes during the backer lamination process. They do not provide any functional purpose after assembly.
I see no issue filling them with epoxy.
Hope that helps!

Hi @Jetson-Nano
Thank you for your request regarding MTTF and reliability data for the listed hardware components.

At this time, we do not publish formal MTTF/MTBF values for these products. The primary reason is that these systems (VOXL2, ESC, Flight Controller V2, Front-End Board, and Camera Modules) are delivered as development platforms intended for user-defined integration, testing, and operation. In the vast majority of use cases, overall system lifetime is dominated by application-specific factors such as mechanical stress, environmental exposure, power integrity, and crash events rather than intrinsic electronic wear-out mechanisms. As a result, standardized MTTF/MTBF metrics are not representative or particularly actionable for these platforms.

That said, the underlying silicon and design heritage for these systems is derived from high-volume mobile and embedded computing applications. These components are built on technologies that are broadly characterized for long operational lifetimes under nominal conditions, consistent with industry expectations for modern semiconductor devices.

Additionally, portions of the broader technology heritage have been evaluated in demanding environments, including public programs associated with NASA JPL (e.g., Mars Helicopter which is our design heritage, and CADRE lunar rover initiatives). However, detailed qualification data and reports from those efforts and other non-public efforts are not available for external distribution.

From a reliability perspective, our hardware is designed and validated using standard industry practices, including:

• Functional validation across operating voltage and temperature ranges
• Environmental and stress testing at the system level (i..e: we and our customers put our drones into very demanding scenarios)
• Design margining consistent with mobile/embedded electronics standards, oftentimes far exceeding industry norm
• Production screening and quality control processes and test screening

For applications requiring higher confidence in operational lifetime, we typically recommend system-level validation under the specific mission profile, including environmental testing (thermal cycling, vibration, shock) and power/load characterization representative of the end use case.

Hope this helps.

@ChrisB here is a system architecture to follow: https://docs.modalai.com/voxl2-d0014/

We do not support an RB5, that is a Qualcomm product

@Dan-Jennings Honestly, I don't think updating the SDK version will help this issue. But, we highly encourage everyone to be on the latest SDK, regardless, since that's where you'll get the latest fixes and features. And it's how you'll get the best support from us. but in this case I don't think a newer SDK will get you the battery_status. It's probably a hardware issue or a parameter issue. You swapped boards and that didn't help. What about the cable? Those 4 wire cables are notoriously fragile. Can you swap it out and see if that helps? The other item is parameters. You saw that other post about setting BATT_MONITOR to 21 and BATT_I2C_BUS to 1. If you don't see the BATT_I2C_BUS parameter then it must mean that BATT_MONITOR hasn't been set to 21. Make sure it is set to 21, then reboot, then you should see the BATT_I2C_BUS parameter. Then set it to 1, reboot, then you should see correct battery_status.

@DronAlan https://www.modalai.com/pages/rma

@Alan_S The voxl-vtx repository is currently private, the source code for both voxl-vtx and voxl-vrx are contained within.

@boron Please submit an RMA, https://modalai.com/rma and just refer to this thread. Include your shipping information and we'll send you a new one

OK @Daehan-Won
Yeah, I'd try to run one first on it's own before the hub to rule that out.
Keep us posted.
Thanks!

@Daehan-Won You would need to add the support to PX4 since you are using the DSP I2C pins and only PX4 can access those while it is running. There is some useful developer documentation here: https://docs.modalai.com/voxl-px4-dev-build-guide/. Also visit the PX4 documentation as well. At a high level you'll need to fork our repo, make a branch off of voxl-dev, add the driver to the default.px4board file for voxl2-slpi, build the image, and add a start command into the startup script voxl-px4-start

Hi @Daehan-Won
So, on the M0062 debug board, you do not need to connect an extra hub. You already have 3 USB ports...
Look at J10, J11, and J12..
https://docs.modalai.com/m0062-datasheet/#connector-callouts
Yes they are different connectors, but is a much easier system for you. We sell both 4 and 10-pin USB cables, and you can easily get Type-A breakouts from Adafruit or Digikey.
Can you try to remove the extra hub and see if you can get your system to work that way?

We cannot validate or debug third party hardware/modules ... we would only be guessing and do not want to lead you down the wrong path. However, I suspect in this case, that Hub is indeed your issue. It is most likely only supporting 500mA modes, and if neither of those two devices are enumerating perfectly, it may only allow 100mA per port before tripping a reset. Depends on how it is configured and designed.
You can use USB TreeView to read all the descriptors of that hub board, and look for the self vs bus powered reporting, and the downstream current allocations. I suspect this is not set for your system.
If you use our connectors, despite in various formats, you should be much better off.

Lastly, just to clarify, are your USB connections unique? Your drawing looks like they are the same USBD+/D- wires connecting to one port of the Hub.