PeterMilani

  • 17 Jan
  • Joined Jul 13, 2023
  • 1 best answer
  • Hi @jakaskerl

    The schematic (from the OAK 4P FFC) shows that:

    BOOT0, Pulled up, 1

    BOOT1, Pulled up, 1

    BOOT2 Pulled Down 0

    BOOT3 Pulled Down 0

    BOOT4 Pulled Down 0

    that gives me 00011, which are bits 4:0 what part am I not reading correct?

    cheers

    Peter

    • Hi

      I'm trying to reconcile the schematic for the oak som pro boot modes. The mode shown in the schematic doesn't match any described in the datasheet. Which is correct and I assume if it is used via USB connection that the USB boot mode should be selected.

      Schematic:

      Data sheet:

      • Hi Jaka,

        would the OAK Som Pro modules be manufactured in Taiwan?

        Are the OV cameras manufactured in Taiwan? It would be good to get an idea of the part numbers that are compliant.

        cheers

        Peter

      • Hi I'm going to bump this topic as NDAA is changing constantly. Currently it is a bit broader than just a couple of companies. For US govt work, typically components, including cameras and AI cannot come from covered countries. Of which China is one.

        A more reliable source for NDAA compliance as it relates to Drones is on the DIU website. https://www.diu.mil/blue-uas-policy

        Here it states that cameras manufactured in China are not compliant. This causes issues with the Luxonis components as almost everything is manufactured in China. I think the camera chips are also manufactured in china which makes the omnivision camera non-compliant. The on-semi cameras should be okay (they are Taiwanese) as long as the modules are not assembled in China.

        It would be very handy if you guys could provide some NDAA compliant offerings as I really like your cameras, but our customers are making NDAA compliance a requirement.

        • jakaskerl a pdf footprint would have been awesome.

          Even after working out how to open it up in Altium Viewer, which the support AI helped with. I still needed to use the dimensions in the datasheet to complete the design.

          A dimensioned and labeled footprint in the datasheet is what is needed.

        • @erik @jakaskerl just an update, my integration was not successful. I got the footprint wrong for the SOM, basically ass about and the only way I could tell that is by examining the number of differential pairs leading from my board and comparing it to the DD2090.

          I'll be fixing it but it would have been really great if there was a "luxonis correct" KiCAD footprint for this part if the plan is for users to easily integrate it into their own designs, it would have saved me some significant number of work. At the moment I wouldn't recommend people try, as the documentation is too sparse/non-existent. e.g. there is no footprint in the datasheet.

          Before I send this off for production, I would really appreciate an "idiots guide"footprint for the the SoM-Pro. Even a PDF will suffice.

          cheers

          Peter

          EDIT: It seems that the actual error is in the hole layout. As the A an B headers are not marked in the datasheet mechanical layout, the hole locations given in the datasheet really have no good reference. I think I could reverse the SOM to test the rest of my circuit just the holes wont line up.

          EDIT2: Actually I don't think my pin numbering is correct… so really need that "idiot's guide" footprint.

          • Hi All,

            I note the SoM-Pro exposes I2S interfaces for microphones. Is there any software available for capturing and transferring sound via the OAK-Som-Pro?

            cheers

            Peter

            • Hi All, just a quick discussion on the supply voltage for the camera modules. The schematic for the OAK-FFC-4P shows only 3V3 being supplied to the camera modules.

              However the hardware documentation

              shows that the supply voltage is 5v. Should I just pass 5V to the cameras instead and assume theres a LDO doing the 3v3 supply?

              Thanks

              • jakaskerl replied to this.
              • PeterMilani
                I looked through the designs, there is LDO for 1V8 and 2V8, but the supply should be 3V3. Likely a mistake in documentation.

                Thanks,
                Jaka

              • Okay, thanks, for simplicity, for an external connection, I've used a separate USB3 device. So I think I should be good. Thanks for clarifying.

              • Hi @erik, just a little confused regarding the switch… is this just to interrupt the USB2 signals to the SoM, ie switching away from the default device? If so, is this something I would explicitly need to trigger using a generic io port to do the selection or is there a pin in the USB2 implementation that would handle this automatically?

                If not, in what instances would this be necessary, ie when would I need to trigger this, at the start of a OAK-AI program? In this application we're applying, power cycling would be fairly regular, would that be sufficient?

              • Thanks a lot @erik, just to clarify, does the OAK-Som-Pro require flashing and or updating. I know, the luxonis OAK devices do update the firmware during use (ie, not explicitly from an operator intervention) as the core is updated. Is this the kind of flashing updating they are referring to? Therefore does this mean that the MUX/Switch for the USB2 lines is required in all cases? And only the D- and D+ require the mux, not the super speed lines?

                • Hi All,

                  just trying to finalise a schematic for Som-Pro integration with another compute som, such as a RPi CM4. I'm connecting via USB 3.1, but its all entirely on the board, ie the CM4 and the OAK Som share the same carrier board.

                  Looking at the example of the FFC-4P, and doing some reading, I don't think that I'll need to really add any filtering caps or chokes, or esd diodes. I also don't think I need the USB Mux Switch or Controller, I've seen them on a few different schematics, but for a straight 1:1 matchup of ports I don't think they are needed either?

                  Is omitting these components a reasonable assumption? Also I assume the OAK-Som is fix in device mode with the USB*OTG*ID pulled low?

                  • Hi @PeterMilani ,
                    From our EE team:


                    You can connect both USB 3.1 ports to each other between different SoMs. Just be careful, that you connect TX from one side to the RX on other side and vise versa. USB 2 lines should just go straight, no crossing needed.
                    No muxes/switches needed. Except if the USB2 is needed for flashing/updating device, then a MUX/Switch for USB2 lines is needed. Default should be routed to the connector and then switched in SW once booted.
                    Caps should be placed on both sides, usually close to the TX pins. But this depends, if the capacitors are not already populated on the SoM. If they are, then they are not needed to be populated on the carrier board.

                • I moved this post to a separate question. As the above has been answered.

                • @erik Just looking at the fab outputs for the ffc 4P, The answer is alternating each side down the connector from the camera DP circuits, matching the numbering in the datasheet:

                • @erik thanks, what is the numbering internal to the connectors? Do you set them incrementally increasing down one side then the other, or does the pin number alternate?

                • @jakaskerl any luck with a footprint for the Som Pro?

                  Is connector A on the right and connector B on the left?