Hi @Mihir-Bala
You will need a 2S minimum to satisfy all the requirements of our power module: https://docs.modalai.com/power-module-v3-datasheet/
Then, you need to do the math to support a 30Watt transient on power up... which equates to a ~5amp burst at the low end of the 2S cell ~6.4V.
So, if you have a 1,000mAh cell at 2S, that will require a 5C rating.
If you have a 2,000mAh cell, you need ~2.5C rating, and so on...
Hope this helped!
Hi @jacobcayetano1
Apologies for not updating some of the tech docs content about that test board we developed.
Here are some links:
https://docs.modalai.com/voxl2-dev-test-board/
That describes the board and provides schematics and other useful user info.
Since the test board is a very easy way to destroy your VOXL 2, we keep the sale of it on our Beta page to alert customers that it is an "at-risk" design since you can easily void your VOXL 2 warranties by over-stressing the VOXL2 and introducing ESD and other signal shorting risks.
That said, here is the purchase link:
https://www.modalai.com/pages/beta-voxl-2-b2b-breakout-board
It comes as a kit with many goodies for it's use including cables, a mounting case, and an SD card.
Now, as far as being able to use Microhard AND J5, we recommend using the standalone version ("dongle") of the Microhard board: https://www.modalai.com/collections/modems/products/mdk-m0048-2 since that will allow you to cascade it off any USB port we have (or one that you include in your design).
Here are some tips for designing a good USB port with our Voxl ecosystem: https://docs.modalai.com/expansion-design-guide/#usb-expansion-over-j3--j5
Should you go down the route of designing a custom VOXL 2 plug-in board, we will offer a courtesy review of your schematic to help you along! Feel free to tag me again when you are ready, and we will start an email exchange to share your data so you are not posting it on our forum (unless you wanted to).
Hope this helped.
Vinny
Hi @serviceberry
From a HW viewpoint (I am HW team) that sounds reasonable to use the hub the way you suggest. But I know for a fact from personal experience the Boson's are very dependent on VBUS rise times, and a very fast rising 5V supply may not allow it to enumerate properly. We have had an instance in the past where one particular VBUS port rose really fast, and the Boson did not enumerate until we slowed it down. It's one of those situations that may require testing to check. Our J3 10-pin host port has a nice moderate rise time that allows Boson to enumerate. So, when using a Hub, check the VBUS rise times compared to J3.
I do NOT expect J9 USB-C OTG port to work with Boson.
The Snapdragon SOC is very smart, and when in OTG mode, it will not provide more than 500mA to any device that enumerates as USB2 which I am lead to believe how the Boson enumerates. if the Boson could enumerate as a USB3 device and the drivers were all present in the Kernel for this, the Snapdragon will give it 900mA over VBUS letting it boot but I think this is a non-starter without the Boson being able to do that.
Our Boson kits use USB2 only and we provide 1A support to enable them to work without requiring enumeration to negotiate more current, hence why they work on the J3 ports and other expansion board ports that have more than 500mA: https://docs.modalai.com/expansion-design-guide/#usb-expansion-over-j3--j5
Hi Nikhil,
Sorry for our delayed response on this. I just recently joined our forum to help out with more HW centric question.
As Chad mentioned, this does require HW mods if you do not want the SW driver timestamp method (which would be our recommendation/preference).
The Lepton signal VSYNC (on GPIO3 most likely is what you are referring to) is running at the VIO voltage of 2.8V to 3.1V per Lepton specs. Our camera sensors are MIPI based, and as such all of those I/Os are at 1.8V, so a level translator would be required which makes connecting these a bit tricky, especially if you need bi-directional support with another sync controller/snoop device. This would need to be something done on a custom interface between the Lepton and the stereo sensors. We do not have such module but would be happy to give further guidance if you need it.
Thanks!
Vinny
@Ansel-Misfeldt Hi,
The approach we will take for CANBUS right now is similar to what we have. That is, to add CANBUS, it requires the use of a FlightCore Flight Controller. So, with Voxl1, you have Voxl-Flight which integrates the FlightCore, or you add on Flight Core independantly.
For Voxl2, you can still use a FlightCore, but we have some exciting news coming soon for a newer improved FlightCore, we will likely call it FlightCore V2 
It will retain CANBUS functionality but has a slew of other upgrades and user improvements added in, all in the same form-factor as FCv1.
Our Docs portal is just about ready for launch and I think we did a better job up-front on this one to help our customers get running quickly.
Stay tuned, we should be posting it for sale in the up-coming days!!
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.
Hi @dougmiller
If your VOXL 2 Mini is TrustZone Configured for UART over J10, then yes, there are 2 pins available as inputs.
https://docs.modalai.com/voxl2-mini-connectors/#j10---external-uart
You can see GPIO_40, GPIO_46 and GPIO_64 are input capable.
GPIO_40 and GPIO_64 are able to be configured to do wake events in the SoC so they have extra configuration to route to a power manager. Depending on how you write your IRQ routine, that may or may not help.
Hope this helps!
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!
Hi @John-Nomikos
Have you confirmed the issue we pointed to in the other forum post?
https://forum.modalai.com/topic/1356/sentinel-drone-randomly-reboots?_=1673383475709
Do you have Kapton or another insulating tape you can place on the J5 120-pin B2B connector on Voxl2 to help confirm the Microhard is not touching J5? We've seen it first hand that it triggers resets.
I doubt all 3 MCBL-00001 are all bad on you (although we do know they go bad fast from users pulling them out by the cable wires instead of the plastic shroud, but that's another issue).
Let us know.
Thanks!
Hi @dlee
All of our Doodle configs are only using USB2, not UART.
Hope that answers your questions.
Thanks!
@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:
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.