Posts made by Vinny

@Peter-Milani
However, I am on vacation for a week starting in a few hours.
So, I will get to the review the week of 8/4 when I return (just to set expectations).
Thanks!

Hi @Peter-Milani
Yes, I will gladly review it!
Please reach out to contact@modalai.com (or this https://www.modalai.com/pages/contact-us) and let them know to please forward your email to me.

Thanks!!
Vinny

Hi @Jordyn-Heil
We try to keep this regularly updated, but sometimes miss some... in this case, M0173 is there https://docs.modalai.com/pcb-catalog/

Hi @jared
Presently they are integrated within certain drones...
https://docs.modalai.com/stinger-vision-datasheet/

I can poke the team to see if we can get it listed separately in the near future.

@KLindgren
OK, M0188 will not work with anything other than our M0187.
Thanks for clarifying.

Hi @KLindgren
You raise a concern and something I will run by the team, but if you are powering the M0187 at 3.3V directly, you are violating the FLIR specs for the Lepton and our system design constraints.

How are you connecting M0187 to M0188? Maybe your cable is introducing some extra losses giving you a lower than 2.8V supply?

Hi @Nate-The-great
Please do not delay any of your efforts or programs in anticipation of a VOXL 3 platform.
Our development roadmap is company confidential, but you can imagine we are working on many new and exciting things. One of the goals we have is to minimize disruptions should someone wish to "upgrade" platforms in the future. Similar to how we transitioned from VOXL to VOXL 2 by keeping mounting patterns the same, expansion compatibility (J13 -> J3), and plug-in board and sensor compatibility (M0048, M0030, M0084 & M0135 Camera adapters, etc), we would mimic that approach, but strive to make it even more seamless than before.

Therefore, there is very little to no risk to your system if you start developing on VOXL 2 today.

Hope that helped.

Hi @KLindgren
You must not hot plug cameras.
Think of this as a phone and when power is applied, all items must be securely connected. USB is the only architectural feature we include with hot-plug functionality.
All tests with hot plug are void and cannot be considered a solution, cause, or method.
Thanks!

Hi @Pete
If you go longer than 180mm, we can't guarantee your setup with our HW will work.
We have done a lot of analysis on the coax cables, including DC losses per inch, and I am not confident longer cables will work for you without an active repeater for the MIPI lines as well. It's likely you will need to design your own hardware adapters to counteract the extra DC losses and extra MIPI length. In which case, just use whatever coax cables and connectors you wish.
That being said, we explain more about our cables here: https://docs.modalai.com/micro-coax-user-guide/

As I say numerous times to folks on this forum, if you need to go longer than we offer for image sensors, the sUAS airframe design and sensor placement needs to be reconsidered for electrical constraints that cannot be violated. High speed and power cable lengths are not an arbitrary number that can be increased indiscriminately. Proceed at your own risk.

Thanks!

Hi @shawn_ricardo
That is more of a question for @tom

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.

1. FLIR suggest to connect MOSI (pin 11) to GND, per page 45 of their spec

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.

3. For reset, this is where we found the biggest issue with the Leptons. We actually have a I2C GPIO expander on our design to issue SW controlled resets of the Lepton. It is not the most stable sensor and frequent resets are required for good operation. Here is our circuit if you want to try it yourself:

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