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 @Gary-Holmgren
Yes, we did design VOXL 2 Mini to be powered by 1S capable source. But, we'll need @Alex-Kushleyev to respond regarding the MINI ESC and how that may need to be tuned for 1S operations.
For VOXL 2 Mini, here is the way it can work, and the few caveats to explain why we have not offered it yet in exactly that way. If I go in too deep on any electronics jargon, let me know and I'll try to clarify as needed 
The local 3.3V regulator for the UART, GNSS, and all other ports will start to drop-out at around 3.4V. So, even though the core electronics (Snapdragon, Memory, Cameras, USB) will work down to 3.2V, some of our extra circuits will not be happy. If you are powering modules from our 3.3V supply, and they can operate at slightly lower, like 3.2V or 3.1V, and you use our 3.3V as the VDDIO ref, then all is good there.
Our 5V boost circuit likes higher voltages. At 3.8V VBATT in, we can supply ~900mA of VBUS (to mimic USB3 VBUS specs). However, as that input VBATT voltage goes down, so will the capacity of that supply. Also, I have a UVLO setting on that rail to trigger the 5V boost to turn OFF if VBAT drops below 2.5V to prevent 1S battery continual drainage (deep discharge) in the event you disable the flight control stuff, but forget to disconnect the battery. However, the ramp ON has a very large hysteresis and it triggers at ~3.5V. So, if you try to start a power ON with less than 3.6V, that 5V boost may never turn ON. Now, if you are not using VBUS, or the 5V on the J19 connector, then it's a do-not-care. But, your ToF use case will require it....
TOF is not easy on VOXL 2 Mini, especially the new V2 one. Since we only have that 900mA of 5V (less at lower voltages), the ToF circuit may get starved of it's needed 5V if you start to use other stuff, like USB or lower input VBATT. So, we would only caution you to use 1 ToF module at max, and be prepared to lower exposure and frame rates at VBAT < 3.8V. Our ToF modules use that 5V to generate a local 3.3V, so we do get some power conversion gains, but we just have not done it yet on V2 Mini to capture all the other side effects.
Thermal, if you are using our Fan connector, that is powered by that same 5V supply IN mentioned above. So, if that does start to shut down, you'll get a fan OFF condition (possibly ON/OFF throttling like a forced PWM if the 5V comes back on), triggering thermal rise compared to the current 100% duty cycle ON as it is now.
Unplanned/Untested Software responses at VBAT <3.8V. As stated, we have not tested this config. The Snapdragon parts are very complex SoCs. When power input starts to go below a certain threshold, the underlying Power MGMT IC's (PMICs) will start to throw interrupts. I think the first one by default is around 3.3V VBATT, but they change based on platforms and chips. So, as we start to approach the "dead battery" SOC%, the system itself may start to react differently and we have not characterized that at all for our builds. It is electrically spec'd to operate, but SW may start nagging and doing weird stuff, like turning off functions such as cameras for example to conserve power.
Motor noise!!! This is the biggest one... 1S motors will draw a lot of current to equal similar power demands of higher 2S+ rated motors (there is some V*I correlation here to motor power, so the lower the V, the higher the I). This will result in a lot of noise on the VBATT power rail. These transients can go not only low (droop, triggering resets, 5V OFF, etc) but also too HIGH (back EMF, energy dumps, etc...) potentially damaging components on V2 Mini's front end power system. V2 Mini ABS MAX voltage in is 6V, at which point the PMICs will be damaged. This is the single biggest reason we have not tried to connect a battery directly to our electronics, and always opt to have some type of nice DC/DC to provide solid line-regulation protection. So, if you try to use a direct 1S VBAT, you will need a really good motor-noise transient protection, maybe even a fast acting Zener diode, set to ~5.6V or so. On a side note, we just started including a 5.6V Zener on a new Spin of V2 mini we are working on, but existing M0104 V2 Minis do NOT have that 5.6V zener. Details on a new V2 Mini will follow in the up-coming months, as teased here: https://docs.modalai.com/voxl2-mini-connectors/#j3-usb-3-10-pin
Those are my first thoughts... If I think of anything else, I will let you know.
I think it is doable.... V2 Mini was designed with micro-quads in mind, but there is some planning and design considerations that need to be done. We can help you along with the HW side of stuff, but I can't promise we'll have any SW support for issues possibly related to low VBAT in since we have no system to check against or develop with. That is why we only use 2S+ in our platforms (currently).
Hope this helped!
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 @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 @dlee
All of our Doodle configs are only using USB2, not UART.
Hope that answers your questions.
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 @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 @jacobcayetano1
Our Power Module is proven to deliver 30W continuous over the full industrial temperature range.
I'd be shocked if you can find a better module with all of it's features out there for this price point.
I encourage you to stress test it using a load box and you'll see how reliable it is. I'm happy to share a few of our validation plots if you wish. We also unit test every unit with a 3Amp load (15W) before shipping.
Let me know if you have any other concerns about the power module.
To add to what our Moderator has posted, the QGC "Avionics Power Low" feature and warning is useless. The ADCs on STMicro parts are frankly terrible, plain and simple. That is why we use a 16-bit INA231 on the power module for current measurement and reporting.
Additionally, You cannot power the FCv2 over USB fully featured as noted here:
https://docs.modalai.com/flight-core-datasheets-v2-functional-description/#power-supply-and-power-source-mux-details
That USB power option is provided as a convenience for programming w/o a bulky battery.
Hi @Alex-Kushleyev , @QSL 170-250mm is quite long. I'm not optimistic 250mm can even work, 170 would be risky.
We can offer our design services, but typically what that results in is a MOQ of a specific new item, such as 300-500pcs depending on the complexity (at normal MRSP which for flexes runs ~$50-80 each) and lead times would be ~14-18 weeks.
What we would need is a .dxf outline of your intended design and we can review that for feasibility and interest. If it really is 250mm, I'd prefer to no-bid it. 200mm might be the edge here (we do not have sophisticated Sigrity tools to confirm, so going on experience here).
M0170 is not ideally suited for back-to-back (the connectors are a bit offset from each other so the net result would be weird) but it may prove if 140mm can work + ~10 mm for the connector transition losses.
In situations like this, I encourage the ME/Industrial Design Team to reconsider placement of sensors and main electronics relative to each other. There are just some constraints the electronics cannot meet easily. Sometimes just simply re-prioritizing the system constraints helps solve the spatial/distance problems. To extend past ~180+mm, I would encourage you use an external design firm that knows how to do mipi repeaters and high speed design. We've had one customer successfully do that, but it takes some skill and we could do it ourselves, but we just do not have the design cycles to support it this calendar year.
Hope this helps and let us know what your thoughts are, and if pursuing us for a custom design is an option, we can reach out over email.
Hi @Jetson-Nano
Sch updates look correct. I'd still add a pull-up on the Lepton Reset to help control it during initial power-ON before the IO expander is configured.
To help further debug your existing setup, I'd need more tangible info such as pictures with all your cables, etc. Do you have a DMM handy showing the voltages of 1.2V and 2.8V, and an O-scope for the 25MHz?
Can you also post a pic of your board without components installed (so I can review the layout as best as possible)?
It's hard to give much further guidance without actual hardware in my hands.
Thanks!
Hi @Jetson-Nano
Happy to continue helping.
Regarding your updated design first:
"I2C Bus Configuration: Regarding the I2C bus, should the I2C lines be connected in parallel to both the Lepton Module and the I2C GPIO expander?"
-- Yes.
"Lepton Reset/Power Down Pins: Concerning the Lepton Module's RESET_N and POWER_DOWN_N pins, should the existing resistor-capacitor (RC) network connected to the RESET_N pin be retained, or can it be omitted?"
-- We do not have any RC delay on the reset line since it is all GPIO controlled.
"I2C GPIO Expander INT Pin: For the I2C GPIO expander, is it permissible to leave the INT (Interrupt) pin unconnected, or does it require termination?"
-- It is an output and we do not use it, so N.C. is fine
I2C GPIO Expander Software Configuration: From a software perspective, is the I2C GPIO expander a plug-and-play component, or does it require specific configuration?
-- It is supported at that HW address by default with voxl-lepton-server (I think that it what is called, Alex can correct me if I'm mistaken)
However, your updated SCH has a couple errors:
Your LDO input and output caps are not correctly done. They are in series, not shunts to GND as required:
The Pull-down R on the GPIO expander is not correct. The ADDR pin will always be HIGH due to the direct connection to 2.8V, but our default is LOW (see the snippet from above): 
Also, the GPIO expander is meant to drive the RESET input of the Lepton, not the PWR_DWN input: 
Now, as to your existing board not powering on, I have a clue for you...
Our very first lepton board we failed to notice the pin 1 hole in the Molex socket, and that is important since it sets a keying for the Lepton module. If the module is inserted incorrectly (90 or 180 off) it will clearly not power up. Pay close attention to the hole in the socket for pin 1 and two vs one slots in the socket which set the orientation.
Keep us posted and hope this helped.
HI @teddy-zaremba
That is the correct approach. We have no mentions of direct servo support from VOXL 2 or any HW. All servos, just like an ESC, need power from an independent battery source not from VOXL 2.
Thanks for clarifying here on the Forum.
Hi @Jetson-Nano
I do not see anything obviously wrong with your design, so we may be dealing with nuances that even we had to update our design for.
2a) There is a chance you have too much capacitance on the 2.8V rail. Our PMICs have limitations on the inrush specs and a 4.7uF I think puts that limit over the suggested amount by Qualcomm. I suggest lowering that to 2.2uF (what we use on our LDO) or even better 1uF. The 1.2V rail per specs (that I have which are a few years old) suggest the 1.2V rail only needs ~110mA
2b) We use a small LDO, not a DC/DC. Not sure if the Lepton is happy with the noise of a DC/DC compared to an LDO and having issues or not. For reference we use a 500mA LDO from TI (TPS7A11xx family)
2c) in relation to 2a above, what are the values of C3 and C2? If they are large (>=4.7uF) I suggest try lowering them to 2.2uF or 1uF's.
For debugging your exact setup, one thing we do is validate if we hear the shutter click (or see the micro actuator move) on power up. Does your HW give that noticeable clicking when you try to power on? If not, you have a more serious issue such as a wrong PCB symbol or incorrect assembly.
Hope that helped.
Last resort, just use our M0187 design that we have for this. I'm not seeing it online for sale, but I can inquire with the team if we plan to make that available for individual use (it is embedded in Starling 2's now).
Hi @AidanGallagher
That USB2 port Port, J12, on M0062 is not much different than many other expansion board USB ports. It goes through a HUB, and as Tom pointed out, if you use M0130, your setup will simplify.
M00130 is the only USB2 product we have that can power the Doodle directly: https://docs.modalai.com/expansion-design-guide/#usb-expansion-over-j3--j5
I'm not entirely sure either why your M0062 will not work, but I'm thinking it may be something with the grounding and VBUS connection due to the external board you use for power, and it not sharing a ground with the M0062 where the USB comes from. For example, our MCBL-00085-1 handles all that: https://docs.modalai.com/cable-datasheets/#mcbl-00085
Our USB3 debug board does not have a current limiting IC like M0062 has, and will not impact USB operations. However, with M0062, since it goes through the hub, and it has power control, if anything goes wrong with power or ground, the port may be disabled.
I would first try to see if your J12 port works normally, with a thumb drive for example (or I think you did that with a WiFi and were good). Then, if you want to try to share some more ground connections between your M0062 and the external power supply, that could be a good test.
But, we do suggest you change to an M0130 as you will have a much nicer setup long term.
Hope that helps.
Hi @Sam-Kiley
We do try to state on there directly the following:
So yes, if you bought a 5G card from us in the past for Quectel, it was a different SKU, likely MDK-M0090-3-01-00, not the current offering for Sierra MDK-M0090-3-02-00
We do not make the Quectel variants anymore since we source the Sierra's to be NDAA compliant.
Hi @olearypa
Oh wow, you are right.
I guess UFS never took off since SD cards are so awesome now....
Last year these little sharkfin cards were easy to get...
I guess not so much anymore.
Sadly, I'm not sure how easy it is to design a plug-in board with UFS discrete since it requires other signals that we did not expose (given at the time UFS cards were abundant). The core 1.2V power rail is not brought to J5, and we have not verified if you do your own 1.2V supply that the power on timing will be satisfied. It's a risk to do it since we have not verified it, but give yourself an option to adjust power on timing if you try it. I'm not sure how the device tree needs to be changed, but I'm thinking there should be a way to indicate a non-removable device such that the DET signal is not needed. But, as a back-up, you should give the option to GND it as if it was using a socket.
Hi @voxltester
Apologies you are having issues with the power cable.
We have expressed in several forum posts that care must be employed when removing and inserting any power cables to not tug on the cables themselves, but rather the large shroud/connector housing.
Pulling on any cable repeatedly will dramatically reduce it's service life as it results in frayed conductors at the pin crimp contacts. This is not an MCBL-00001 issue, but all cables in all electronics not just from ModalAI.
There are no plans to change this solution as it has been tried and true for over a decade. Some of my power cables are nearing 13 years old and every one can last that long if handled properly.
If needed, I can try to search through some forum posts where I think we have a picture showing the recommended methods of grabbing onto the plastic shroud instead of the cable conductors themselves. Our team is trained on this method as well.
Hope this helps.
@Alex-Kushleyev @Morten-Nissov , The team just posted the M0172 for sale.
Sorry for the delays....
https://www.modalai.com/products/mdk-m0172-1-00