PeterMilani

  • 17 Jan
  • Joined Jul 13, 2023
  • 1 best answer
  • In OAK-Som-Pro USB connection.

    Hi @PeterMilani
    Just to clarify on the USB2 MUX. If the USB 2 bus is only connected between two devices: from RPI to SoM (not further, for example to a port for outside communication), then a MUX is not required.
    Hope this clears things up for you.

    Thanks,
    Filip

  • In OAK-Som-Pro USB connection.

    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.

  • In KiCAD footprints for OAK-SoM Pro
  • In KiCAD footprints for OAK-SoM Pro

    Hi @PeterMilani
    SoM designs are not accessible on depthai-hardware. I'd suggest looking at carriers like FFC-4P which will give you an idea of how to design your own. Generally the pins (1 and 100) are marked on the PCB.

    Thanks,
    Jaka

  • In Support for On-Semi AR0144 camera.

    @PeterMilani I agree on the idea of a hardware abstraction layer for generic sensor support, we also thought about it, but unfortunately it isn't that easy to implement on RVC2. For the I2C config and list of registers to initialize and start streaming, that would be doable to add, but then the MIPI receiver settings have to be preconfigured as well, and that part is a bit hardcoded now per sensor mode. And some formulas may need to be described for setting the exposure, gain etc. With some sensors these may not be straightforward, not a simple scaling of the raw registers. But if I2C support would be exposed with a Script node, the user might be able to implement own logic.

    So at the moment it's only possible for us to add FW support for a new sensor. Once the hardware and datasheet/documentation would be received, it may need up to a week of work, including testing, debugging etc.

    Maybe on RVC4 it would be easier to add that generic support, not sure...

  • In Support for On-Semi AR0144 camera.
  • In Support for On-Semi AR0144 camera.

    Hi @PeterMilani
    Best to drive the FSIN with a GPIO pin. I think MXIO64 should be PWM, which allows for precise timing.

    Thanks,
    Jaka

  • In Blob converter yolov7 model Fatal Error.

    Hi @PeterMilani

    PeterMilani Actually able to get it to work without modification using:

    That is to be expected. The blobconverter is mainly used for custom network conversions and OpenVINO models. Tools are used to simplify the YOLO conversion since they run some additional pruning in the background to make sure the model works with the node.
    And yes, Yolov7 models don't need anchors and anchor masks anymore.

    Thanks
    Jaka

    • In Support for On-Semi AR0144 camera.

      Hi @PeterMilani
      Impossible to do on RVC2 without FW access, probably the same on RVC3, but I don't have enough knowledge to say for certain. Not sure which parts are needed to make it work.
      cc @Luxonis-Alex

      Thanks,
      Jaka