Posts made by Vinny

Hi @joseph-vale
This is not my wheel house, but maybe @Alex-Kushleyev can give you some pointers.
Thanks!
Vinny

@Ashish-Kumar
Few things:

1. Please stop trying with only USB-C, that is invalid. Think of this as your smartphone... there is always a battery present (our power module) before you insert a USB-C cable.
2. Please remove USB-C, Plug in the power module when it is OFF, then turn the power module ON.., then insert the USB-C cable. Our Hardware is not hot-swappable. Only USB ports can tolerate an active host connection, but all power supplies must be OFF when plugged in, then turned ON.
3. Your power module was delivered with clear heatshrink. What happened to it? That would not be a covered RMA since the HW of the power module is now compromised.
4. Can you confirm if you have tried multiple USB cables and multiple ports on your PC? (or even another PC?). We often see that fix some folks issues, either a lose cable or bad port... happens more than you would think.

After those steps are confirmed, then I think @tom can guide you further.

Thanks!

Hi @Aaky
You just went one page in too far
https://docs.modalai.com/voxl-escs/
Hope this helps!

@Ashish-Kumar
With ONLY USB-C, the board will not boot, so that is normal behavior.
VBAT is always required.
D1 (Green LED) says the VBAT is present and our local 3.3V is ON.
With just that LED on, it tells me your board is likely stuck in QDL mode and needs reflashing, so the steps Tom provided will help confirm that.

Hi @dylangresham
Stinger is intended to be a complete drone package for developers, integrators, and system providers who do not require additional customization. We believe it includes all the necessary functionality for the FPV use case.

Starling 2, Starling 2 Max, and the PX4 Developer Editions, on the other hand, are designed to be customizable platforms that developers and integrators can modify to suit their specific products and use cases. By design, these are not fully Blue List–certified turnkey drones, since any additions, removals, or changes made by the end developer would require recertification.

That said, because most (if not all) of the subcomponents used in these platforms are already listed on the Blue UAS components list, the end-user certification process should be straightforward. ModalAI parts will pass screening easily thanks to their existing certifications.

I hope that clarifies the rationale.

Hi @snowt33nshi
All of our ucoax based image sensors use the same cables.
Be careful mating adapters to sensors as they are not all compatible as noted here:
https://docs.modalai.com/micro-coax-user-guide/
Hope this helps.

Hi @snowt33nshi
note there are multiple lengths we offer:
https://www.modalai.com/collections/cables-1/products/mcbl-00084?variant=48956821602608

Hi @Jetson-Nano
Here is our info for Doodle Labs support:
https://docs.modalai.com/cable-datasheets/#mcbl-00085
Sorry it's buried in a cable page, but it makes the case clear (we think) how to support Doodle

regarding probing USB signals, unless you had a USB decoder on the scope, I do not think that will prove anything useful. You may be better off running usbview:
Windows:
USBTreeView by Uwe Sieber — uwe-sieber.de/usbtreeview_e.html
It shows enumeration hierarchy, configuration descriptors, endpoints, VID/PID, power requirements, etc.
Linux equivalent:
Use usbview — it’s essentially the same utility (GTK front-end to lsusb).

Hope that helps!

Hi @will-huang-oksi
Are you willing to share some pics? Might be a cabling issue (GND loop or lack of a common GND), or some other intermittent connection causing your problems.
It really is hard to debug without seeing the setup.

Thanks!
Vinny

Hi @Nando75
For the Boson portion of the Hadron, you need a 2L MIPI CSI config and for the EO portion you need a full 4-L MIPI CSI port, so you will be consuming an entire "Camera Group" from VOXL 2 for this.
You will want to assign the "lower" group to the Boson Portion in 2L mode and the full 4L "upper" group to the EO portion such that our SW matches up easily. Here are some mapping tables we constructed early on for this you can use as a guide (color based mapping, so hopefully that comes through OK).

However, please double check this and also let us know when you are ready for a SCH review. Tag me again on the Forum when you are ready, then I can email you at the address used for your Forum registration so you can share your SCH with me for a review.

Hope this helped!
Thanks!

Hi @Nando75
A shielded, impedance-controlled flex was our go-to solution in the early days, and we still offer a few legacy adapters that use it. These provide excellent signal integrity and EMI shielding. However, they’re limited in deployment flexibility; each flex must be meticulously designed for a specific routing path.

Coax, on the other hand, greatly improves routing versatility and can be deployed across many platforms. The trade-off is reduced signal distance and slightly degraded signal integrity compared to a tuned flex.

Ultimately, it’s a system-level tradeoff. We’ve transitioned to coax as our mainstream solution in recent years, driven by customer demand for easier installation without the constraints of custom flex circuits.

Only your team can decide what's more important and hopefully we can enable you either way.

Hi @Nando75
If it was less than 200mm, yes. 200mm is at your own risk, and make sure your SW team knows how to reach out and request slower MIPI CLK speeds in the event of signal integrity failures (camera failures).
Keep us posted.
Thanks!

Hi @SKA
Apologies no one responded promptly.
From what I gather, these are best to be sent back as an RMA and we can try to recover them.

D1 (green) is an indication of the local 3.3V power being Good. So, that implies you have 3.8V input, and the 3.3V reg is OK.
DS2 (RGB) is controlled by Qty-3 GPIOs from the SoC. This can briefly blink on boot until the GPIOs are configured by apps software.
D2 (green) is the 5V USB VBUS USB1 (10-pin) port power indicator, which only comes ON after the QRB5165 boots and Apps controls the GPIO to turn the VBUS ON.

On failed SW loads, it is common to diagnose that by seeing DS2 or D2 blink, which indicates boot loops. D1 should NEVER go off, if so, something is wrong in HW or cabling.

We do caution any customer that sets up their own CI or internal validation automation to include a nice pause before repeated power cycles. A common 5 second rule is good to let the large caps discharge, or certain ICs will never fully reset. This is the most common cause of "bricking" devices.

The RMA is your best bet here and we can try to recover them for you, or diagnose for any other issues: https://www.modalai.com/pages/rma

Hi @QSL
OK, keep us posted!
Any, for any new issues, please be sure to start a new forum post so it is seen by the team.
Thanks!

Hi @QSL
Is your hub powered externally? You might be starving the VBUS if you are not powering the hub externally. The USB/UART board adapter does not have enough current to power a hub and additional downstream peripherals as well.

Hi @Nando75
Yes, that is a fundamental limit of ALL uCoax that is not Twinax Impedance controlled conductors. Therefor all IPEX, Hirose, Molex, TE, etc (you name it) coax will fundamentally be limited in performance compared to true 100-ohm differential controlled impedance you can get from flex circuits or Samtec's Twinax. It is one of the many tradeoffs in our design space we need to make. As such, that is why we are firm on keeping the coax short and we do not sell any option longer than 180mm since at some point that small impedance offset and tolerances between two 50-ohm conductors compared to a true coupled 100-ohm may play a role.

Hope this helps you.
Thanks!

Thanks @joseph-vale for the kind words.
We will continue to try our best
Our success only comes with your success.

Hi @will-huang-oksi

Sorry there is not much else I can offer. I'd need to have the HW in my hands to diagnose.

I'd start with the basics, Power. It is possible you blew the VBUS protection circuit that feeds J3 VBUS. It is also possible that GPIO_157 which enables VBUS on J3 is not correctly set in SW.
However, I still ask you discontinue use of M0151 for Doodle as you will have problems in the future and we cannot continue to support that.

Please follow the guidance listed in our cable page for Doodle. Those boards listed do not use the "VBUS" from J3 (rather we power switch the 5V DC Local with proper Hub monitoring), so you can likely recover proper functionality and continue with your efforts.
Thanks!

Hi @joseph-vale
Great, thanks for clarifying.
Apologies our website is not always perfect. It is maintained by us Engineers, so we often take some info for granted. I am a few years delinquent in adding image sensor design guidance to our tech docs
All our MIPI_CSI lines are indeed 100-Ohm Differential, so the IPEX mate will match.
We include ESD protection on all MIPI CSI and I2C and GPIO/MCLK signals at the VOXL 2 J6, J7, and J8 connectors, so no need to double protect (or you can impact the bus signal quality with the added capacitance).

When you get to the point of generating a schematic, I will offer a courtesy review. Ping me on this thread again and then I can email you privately to share if you wish.

One thing we did on our Coax design was plan on always using the same 26-pin cable, so it is our adapters that vary in pinouts, but our cable is always the fully populate 26 conductor DF56 series.
For Boson/Hadron, we use multiple conductors of 5V. We set that based on the DCR spec of our coax cable, so with your IPIEX cables, you can do something similar to achieve success.
We were also advised by Hirose to NOT use the outer shield as current carrying, so for every +DC path, we have a return GND conductor.

Keep us posted!

@joseph-vale I think a lot of FLIR's docs are public domain, but we did not receive them that way, hence our reluctance. If you can be more specific as to what you need, I'll try my best.