Hi Gaurav,
The PWM Output port J1007 provides 5V DC as a reference on pin 1. This same voltage connects to the main power 5V that powers Voxl.
https://docs.modalai.com/voxl-flight-datasheet-connectors/#j1007---8-channel-pwm--4-channel-dshot-output-output-connector
If you are providing a separate power source on the ESCs different from Voxl's 5V, then you should either insert a blocking diode on this or remove that cable position from J1007.1 and only use a 9-conductor cable, positions 2-10.
If you are using the same 5V supply on Voxl and the ESCs, then these are just shorts and do not matter.
We provide a variety of power tap-off options on Voxl and Voxl Flight and we know sometimes it can create tricky cabling solutions.
Let me know if you would like more info, and if you do, please provide us with the ESC part number you have.
Thanks!
Vinny

@gauravshukla914
Great, thanks for the response. Glad we could help.
Just FYI, that 2A 5V BEC will not properly power a Voxl, nor would any 5V supply though any of the JST or Hirose connectors, although you may see Voxl try to power up.
In those conditions, be sure to use our Power Module as the main 5V so it has a successful power up. This is the only connector that was designed to support the current demand Voxl needs during power up: https://docs.modalai.com/voxl-flight-datasheet-connectors/#j1013---5v-dc-power-input-i2c3-to-power-cable-apm
https://docs.modalai.com/power-module-v3-datasheet/

Be sure to reach out with any additional questions.
Thanks!
Vinny

Hi Steve,
Thanks for the compliment of that design. It is not an open source design, but we are also willing to share with partners with some type of license that we can provide to you (over email, we should be able to contact you in the next day or so).
Keep in mind, the parts on the power module are very (and I mean really very) hard to find and source.
If you do not already have a reputable supply of them, you might be creating more problems than to just keep buying our modules. To give you an example, the main DC/DC switcher on there we have been getting new quotes at over $80-240 EACH PIECE for new builds... (it was an $8 part 3 years ago).
So, something to keep in mind.
I'm sure Chad will reach out to you soon to discuss further and I would be your POC for the actual design details should you move forward with that course.

Thanks!
Vinny

Hi Andrew,
This is great info, thanks for clarifying.
Unfortunately, our current product offerings do not support the "Pixhawk" style APM ADC inputs for current and voltage monitoring.
However, I would bet that you could find source code for an Arduino or STM project where these ADC values have been converted to appropriate PX4 I2C digital formats that you can then feed into our products. Keep in mind, the I2C bus needs to be at 5V and you should provide the I2C pullups on your converter module (anything from 10K to 4.7K works well for our I2C translator).

Thanks!
Vinny

@wilkinsaf
Hi,
Practically speaking, if you can provide Voxl with 5V @ 6amps burst load (~15W quiescent), then you can use any power module/BEC you want (for your motor-ESC combo of course) to J1 (Voxl) or J1013 (Voxl-Flight).
For a FlightCore alone, you can get away with 5V @ ~1.5A turn-on burst (~400-700mW quiescent, use case dependent) on any connector with "VDCIN_5V_CONN" such as J1, J4, J9, J8, etc.
Our Power Module does just that with up to 6S support and the I2C based power monitoring.
Our Voxl/Voxl-Flight and FlightCore products expect that I2C to be at 5V matching the input supply.
Can you elaborate further on what issue you are having with the I2C port? Are you trying to use it or not use it? I might need to pull in a PX4 expert with some help there if related to SW.

For background info, ModalAI doesn't do 12S yet unfortunately due to OSHA voltage limits above 50V (12S fully charged LIPO is 50.4V) which require more advanced safety training, extra fire safety equipment, etc. Maybe in the future we will if the demand requires it.

Thanks!
Vinny

Hi Steve,
Thanks for the compliment of that design. It is not an open source design, but we are also willing to share with partners with some type of license that we can provide to you (over email, we should be able to contact you in the next day or so).
Keep in mind, the parts on the power module are very (and I mean really very) hard to find and source.
If you do not already have a reputable supply of them, you might be creating more problems than to just keep buying our modules. To give you an example, the main DC/DC switcher on there we have been getting new quotes at over $80-240 EACH PIECE for new builds... (it was an $8 part 3 years ago).
So, something to keep in mind.
I'm sure Chad will reach out to you soon to discuss further and I would be your POC for the actual design details should you move forward with that course.

Thanks!
Vinny

By default on all M0090 variants, all the transceiver/buffer circuits which take the 1.8V Kernel Debug UART to 3.3V TTL for J6 are DNI'd (not populated).
The only thing that can be done is to probe on raw circuit pad locations for TX and RX to get the signals at a 1.8V level.
Here are those snapshots to help guide you should you wish to pursue that route:

However, the ICs are located on the bottom side of the PCB, so when mated with Voxl2, you cannot probe directly, which would require soldering on wires to the PCB pads. That would likely violate any warranties on this specific PCB if you did that.

Hi Wilkinsaf,
Unfortunately, we do not support higher than 6S as an input to our power module.
The comments about various voltages are in regards to the 5V output setting. For example, 12V, 6V, etc... within the drop-out allowed by your 2S-6S VLIPO input. We have already configured and tested 12V versions of our power module as an FYI.
Sorry this does not solve your problem.

Thanks!
Vinny

Hi Ryan,
The J3 and J5 connectors are 5mm stack-height versions.
We recommend nylon spacers at 5mm and nylon hardware to hold the boards together.
You can use metalized if you want, the holes are non-plated, M2.5.
We also just posted a brand-new data package for customers who wish to design their own plug-in boards. It provides an Altium package of a starter schematic and PCB with connectors properly positioned.
https://docs.modalai.com/voxl2-connectors/#add-on-board-to-board-design-package

There is a small note that if you mate the boards without spacers, you will see a very slight tilt between the boards. This is a known Samtec issue where the Q-strip series and AHD series are actually about 0.1mm off from each other in regards to full seating depth, but the swipe length is sufficient at a properly controlled 5mm for both.

Let us know if you need any extra help!
Thanks!
Vinny

Hi Sakthivel,
I just heard from one of our SW engineers as follows:

Yes
https://docs.modalai.com/voxl2-linux-user-guide/#spi0---camera-group-0-spi
However, we are going to change J8 to a UART in next release.
The current download available is Voxl2 Platform Release 1.2.1-0.7 from downloads.modalai.com
release notes: https://docs.modalai.com/voxl2-system-image/#121
as of 1.2.0 the J6 and J7 SPI are available. J8 is too now, but next release it will become a UART.

We will update our docs accordingly, and I think we have future plans to make J6-J8 buildable by the end user as either SPI or UART. So this switch of J8 to UART is likely a temporary one for users.

Hi Sakthivel,
Thanks for the extra info.
I have a lot to write, so if anything is not clear, please let me know!

1. The power rails are SW programmable to an extent, but for initial discovery of what image sensor is on the bus, oftentimes the power sequence is just "all at once", and very little is it required to then disable power and turn it back on to the correct sequence. I've only come across one vendor with one MIPI based sensor who specified a power sequence that could not tolerate "any order". Are you able to share what sensor you are using so we can explore that as well?
   We keep a fairly comprehensive listing of sensors, their power requirements, MCLK reqs, etc. If you'd rather not say the sensor part number, we can email you (using the email you registered with) and ask if you prefer.

2. Seems like your image sensor is pretty powerful to use that much current. Is that really 3.2W total!!? Technically, the HW on the design is capable of providing that much current, but the DF40 connector pins are not rated for that much current. Each pin is only rated for 300mA. The 1.2V DVDD total ICC is capable of 1,200mA, the 1.8V DOVDD rail is capable of 600mA, and the 2.8V AVDD is capable of 600mA. But this is combined across all DF40 connectors in total, not on each one at the same time. If you really need 800mA at 1.2V from just one connector, you might need to use the higher voltage rails of 3.3V or 3.8V or 5V, and sub-regulate down with a DC/DC (NOT an LDO since you'll still use the 800mA). For example, 800mA at 1.2V is 960mW, so at 3.3V, that is only 290mA which is less than the pin rating of 300mA (but of course, add in efficiency losses, and you might exceed 300mA, so 5V or 3.8V might be better).
   So, it sounds like you might need a simple adapter circuit as follows:
   5V DC/DC to 1.2V, 1.8V and 2.8V.
   Use the PGOOD of that 1.2V DC/DC to enable further DC/DC's for 1.8V and 2.8V.
   Due to the fact 2.8V is a higher voltage, it will take longer to ramp, thus likely meeting the spec of ramping after 1.8V to 90% final value.
   If you want to make sure your DC/DC's are only on when the board boots up fully and goes into discover sensor mode, you can use the 1.2V, 1.8V, and/or 2.8V from our DF40's as enables of your first 1.2V DC/DC, then cascade the PG like I mentioned above. If you are concerned your DC/DC's are too noisy to meet sensor specs, you can always regulate to 0.15V-0.25V above the target rail, and throw in an LDO to meet the exact spec.
   It's all doable, and fairly straightforward. We do it all the time (see our Framos adapter offerings for Voxl for example). The only trick will be the CCI I2C lines will need to have an isolation device to convert the 1.8V Voxl2 DOVDD pull-ups to your local 1.8V IOVDD pull ups to make sure there is no back-feeding across the design's power domains. We use a simple I2C translator for this, but not all part numbers can translate to the same voltage, so be careful with part selection. The other control signals (MCLK, RESET_N, etc) just need a simple TTL translation buffer to convert to the new local 1.8V domain to prevent back feeding across power domains.

3. SPI features are being added to these ports as that is the intended default scenario!! I'll have to pull in the SW team on this request to see if they can answer whether or not they are already enabled, or soon to be. I'll reply after I ping on them. I think we have other forum threads on that topic, so I'll report back.

Thanks!

Hi Sakthivel,
This is unfortunately not a straightforward answer.
Designing cameras based on MIPI CSI is not easy to do. So to help make sure your designs go smooth, please provide us with more info and we can help make sure you get it right.

#1: Each DF40-pin is rated for 300mA, however, not all pins can source all that current at the same time. So, you might need to help provide us with more info here. What power rails do you need to use, what image sensor(s) are you hoping to use? And how many sensors are you planning on using at the same time. Are you still using some of the ModalAI sensors too?
There are also SW dependencies on certain sensors working or not. Our SW team would have to check the device tree to be sure that sensor is supported and we have drivers for it.

#2, mixed answer. Some are controlled by SW such as the VDD/AVDD/DOVDD rails (see my comment about about SW support) and some are always on based on the board power distribution, such as the 5V, 3.3V, VPH_PWR 3.8V, and VREG_S4A_1P8. SW controlled ones are set once the driver queries the device to be sure it is providing the correct voltage(s). For the always on power supplies, they are all present after reset and will stay on until the main power is removed.

Again, you might need to let us know some more info. What do you need to use? We want to help validate your needs at the system level.

#3 is on the website here: https://docs.modalai.com/voxl2-connectors/
"All single ended signals on B2B connectors J3, J5, J6, J7, and J8 are 1.8V CMOS unless explicitly noted. All single ended signals on cable-to-board connectors J10, J18, & J19 are 3.3V CMOS unless explicitly noted."
Regarding the QUP/GPIOs on J6, J7, and J8, not all modes are enabled yet in SW and that is in process, so please let us know what you would like to use and we can let you know our status for that support.

Most often, we just design the sensor solution for our customers for a nominal NRE fee. We can then provide you with a tested and supported sensor solution to your mechanical specifications. We are actually in the process of trying to update our website for an image sensor flex submission form. No specific ETA yet for that, but your request is common enough to make us offer this service.

Thanks!
Vinny

Yes, this "can" work, but it is not ideal due to the many unknown variables on someone's host PC. Hence it is not a default option, and we would not recommend it. Issues can range from USB VBUS being out of spec (as it is, it is allowed +/- 10% which puts it in on the edge of our needs), and most "correctly designed" PCs will not provide more than 100mA unless a device is enumerated that asks for more. I'm not sure if all version of PX4 do that correctly. 100mA is insufficient for most use cases.
In a strictly "QGC config" mode, I can see this work, but it is not something we plan on supporting on this version board due to those risks above. This also opens the door for someone to leave that power feed in-place while then later connecting the power module which will create a serious power rail shorting problem between the module and the PC.
However, we do have a design already figured out that can take USB power for QGC/Config type of applications, and it validates the VBUS through a smart fuse/mux before using it. This will allows us to globally claim support, and if someone's system is not correct or out of range, we protect the HW.
Stay tuned!