• DepthAIHardware

  • Synchronization issues between the OAK-FFC4P module and the host clock

jakaskerl

I did a preliminary test with both of my devices and found a fixed offset of around 200us at 10Hz, so we can infer that the clock source is indeed synced to the host.

I can compensate for this bias a bit in the software, but to get the best fusion, I need the OAK device to sample perfectly to the host clock.

These are my test data:

First equipment

Second equipment:

The phase difference is obtained by subtracting the timestamp of the OAK device's 10Hz sampling data from the timestamp output of the 10Hz timer on the host computer.

thanks,

sky

      aiyangsky

      aiyangsky I can compensate for this bias a bit in the software, but to get the best fusion, I need the OAK device to sample perfectly to the host clock.

      You should be able to get a perfect sync by using a HW trigger to capture frames. Perhaps you already have one for the radar, so it would be best to just connect the two together to achieve synchronization.
      https://docs.luxonis.com/hardware/platform/deploy/frame-sync/

      cc @Luxonis-Alex Would this work on IMX as well since it doesn't support snapshot mode or would the drift still occur?

      Thanks,
      Jaka

            jakaskerl

            Thank you for your suggestion. In fact, we try to do this.

            However, the current radar uses PTPv2 to synchronize time with the host computer, and from the above results, he works very well.

            In order to simplify the hardware design as much as possible, we would like to compensate for the fixed offset in the device.

            At present, this offset value may be related to the hardware design? Does it perform the same on the same hardware? Maybe I could try to measure the offset first and then tell the device how to compensate.

            Thanks，

            Sky

                aiyangsky

                This also involves the synchronization problem of the IMU, which is known to be an integral system and very sensitive to time.

                We insisted that it was best to keep the whole system working on the same clock base as much as possible.

                Thanks，

                Sky

                  jakaskerl

                  @jakaskerl Yeah, I see all your devices are hardware synced using the FSYNC Y-adapter. I want to confirm, are the sensors connected to the FSYNC Y-adapter via external triggering?

                  Thanks,

                  Nav

                      jakaskerl Using hardware synchronization does not resolve our issue, as the four cameras cannot achieve complete synchronization. For more details, please refer to the other post: https://discuss.luxonis.com/d/5879-oak-ffc4p-external-hardware-trigger-asynchronization-problem/2.

                      We hope you can address this bug by implementing a software-based synchronization solution, where the cameras periodically sync with the main system clock. Thank you for your attention to this matter!

                        jakaskerl

                        hello, Jaka. I have carefully checked the API in depthai-core and found the settings related to host synchronization, but it does not work and the clock still drifts.

                          jakaskerl

                          I noticed that cam_B and cam_C share the iic bus, so their sampling is always synchronized. Can I make sure that the 4 Sensers are using the same CMOS by sharing the iic bus?

                          Thanks,

                          Sky

                              aiyangsky
                              AFAIK sharing the I2C bus will only affect the camera controls (3A and more) to be the same across all 4 sensors. The pairs still have separate clocks and separate FSYNC signals. Not sure if it's even possible to link more than 2 of the same sensors on the same i2c line (depends on how FW handles slave addresses) cc @Luxonis-Alex