Posts made by Vinny

@SDSU_Drones
Just to close this out, I emailed you a review report. Hope that helps you along your way.

Thanks!
Vinny

Hi @SDSU_Drones
You bet.... emailing you now!
Thanks!
Vinny

Hi @wetherbeej
We still never actively pursued support due to lack of demand.
Additionally, one of our other customers that is very savvy with QC chips tried for a few months and then gave up... seems this may be a fundamental QC QRB5165 issue that we may not be able to solve or even push for resolution either. It would not be the first SoC feature that was promised but then never supported. I think the lack of UFS cards in the market is a key indicator this product segment is going to eventually be left to dry.
Sorry I do not have better news for you.

As we push towards a later Ubuntu release, we can try again, but those efforts have been slow going and tedious.

Our other customer went towards a SSD over PCIe using J5 PCIe interface. That seems to be also where the market is heading... PCIe and USB-C based SSD's, but predominantly USB-C.

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.