Posts made by Vinny

@gerard I also just remembered we had a stint of bad MCBL-00010's a few months ago...
We have since cleared that up, but there is no telling how long ago you may have ordered that cable...
Please see this thread for guidance and if you do think your MCBL-00010 is at fault, we will replace your M0048, just reference both threads in your RMA (this one and this one -->) https://forum.modalai.com/topic/4632/flight-core-2-firmware-update-through-qgc?_=1781284416780

Hi @gerard
I asked my team for some extra assistance on the SW side, but if you suspect HW failure, we can diagnose with an RMA if you want to pursue that route.
If you had this working at one point, then it did not, it's most likely either a really bad SW change, or the HW got damaged.

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

If you want to wait and see if our SW team has any guidance first before doing an RMA, that is your call.

Hi @gerard
Your RPi needs power.
The USB on the Microhard Dongle is a Device/Peripheral Port, needs to connect to a Host PC/SBC.
I do not see any power input to your RPi device.

That can explain your behavior.

Hi @gerard
Do you not get these LEDs either?
https://docs.modalai.com/microhard-usb-carrier/

Without a Microhard module installed, the 5V LED and the USB Hub LEDs should all still illuminate.
When the MH is properly configured, then you should start to see the other Activity and RSSI/Status LEDS. Those not appearing indicate the module is not configured, not seated, or in error.
Images will help.
Thanks!

Hi @gerard
Can you share a photo of the setup, ideally with the working unit next to the problematic one?

A couple of possible causes come to mind, but we'd need a bit more information to narrow it down:

The modem module may not be fully seated in the socket. These modules can be difficult to install correctly, and if the thermal pad underneath shifted or lifted slightly during installation, it can prevent proper seating.
The socket may be cracked. It's fairly easy to damage the socket during module removal, especially with Microhard modules, which can lead to intermittent electrical connections.

A side-by-side photo of the good and bad units would be very helpful for troubleshooting.
Thanks!

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.

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!

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.

Hi @Jetson-Nano
The connectors between VOXL 2 and M0173 are DF40's. They are rated for 30 cycles:

The uCoax image sensor cables are also from Hirose, and are much more fragile. They are rated for 20 cycles, but to be honest, I break them after 3-5 cycles personally if I am not using a tool. With the use of the proper tool we specify here, you should get to 10-20 cycles.
https://docs.modalai.com/micro-coax-user-guide/

FCv2 uses a bunch of JST GH connectors. On the flip side, I've never broken one of those!
JST sadly does not specify the cycle count. So, any number we provide would be a guess. We use it due to DroneCode compliance intentions. They are pretty robust and never experienced any issues.

Hope this helps.

Hi @austin-c
Sorry I missed this message somehow.
I will email you to kick this off with your team.

Hi @irw
Can you please post High Res and clear photos of both sides of the VOXL 2?

Hi @Daehan-Won
To help us, what camera and how is it connected (cable details, with photo will help)
We want to first understand how much power it needs.

However, if it appears upon boot up, that is usually the worst power draw (in-rush), so I'm not inclined to think this is the case. It may be loose wiring, which is why a photo of your cable setup will also help. Even the slighest intermittent glitch on USB will create USB reconect events.
You can monitor that in a VOXL console (over ADB) with this command :

dmesg -w | grep -Ei 'usb|xhci'

Thanks!

Hi @saegsali
Yes, we are actively working on 3 other solutions with different vendors.
We understand the importance of having options here.

Nothing is in production yet, so please bear with us as we continue our development.
We hope to have some extra support by Q3 of this year with at least 2 other products, one being what you mentioned, and NOT over USB

Thanks!

Thanks @Nikos-Mavr for the drawing, that helped.
The thing to be careful about is the I2C voltage levels.
https://docs.modalai.com/voxl2-connectors/

J19 port I2C's are set to 3.3V with on-board pullups. So, I'm not sure what the 12S module I2C levels are, but be sure they are either (3.3V) or (set by host, i.e.: no pulls on the battery side)

I'm not sure what voltage is feeding into this portion... make sure it is limited to 6S:

Now that Eric has given you a bunch of guidance, let us know if there are still problems overall.

Thanks!

Hi @Nikos-Mavr
Please provide a drawing or sketch of your setup in question for the I2C interface, include as many details as possible so I can help you.
Thanks!
Vinny

@jmltt
Yes, that looks correct.
https://docs.modalai.com/voxl-2-wifi-setup/#overview

The dongle is expected to have the specific Realtek RTL8812/8818 part in there. You'll see the RTL part number in the serial console or ifconfig (I think, I'm not SW).

@jmltt
This:?
https://docs.modalai.com/cable-datasheets/#mcbl-00041
https://www.modalai.com/products/mcbl-00041

Hi @Jetson-Nano
Sorry for my delay, I was OoO when the first message came through.
In any event, I can only say we have no plans at the moment to explore this new Lepton, and I have not even reviewed the spec sheet, so I cannot offer any guidance on it.
Sorry I can't be of more help.

Hi @austin-c
yeah, and it will not.
There are dozens of changes between the two boards.
It's just easier and cheaper to order the correct version. We have no documents showing how to convert it is simply not doable for the cost and risk and time.

Not the news you wanted, but please trust me on that one.