Hi,

I'm currently trying to hardware synchronize 4 OAK-D Pro PoE (IMX378) camera's using the the FSync Y-adapter. I followed the suggested here: https://docs.luxonis.com/hardware/products/FSYNC%20Y-Adapter

I also set the "setFrameSyncMode" as mentioned in the tutorial.

camRgb.initialControl.setFrameSyncMode(dai.CameraControl.FrameSyncMode.INPUT)

monoLeft.initialControl.setFrameSyncMode(dai.CameraControl.FrameSyncMode.INPUT)

monoRight.initialControl.setFrameSyncMode(dai.CameraControl.FrameSyncMode.INPUT)

Unfortunately, I'm not able to get the synchronization working. Anyone any experience or can point me in the right direction?

Hi @TommyTran ,
Did you follow the "External FSYNC signal" in that documentation? Feel free to share photo of the wiring.

BR, Erik

Hi @erik,

I have the exact same wiring setup as below. The cameras are then connected to a Unify PoE network switch.

Hi @TommyTran , that unfortunately won't work due to reasons described in "External FSYNC signal". Only OAK-D-SR-POE cameras would work the way you have wired devices, as it has updated FSYNC logic.

Hi @erik

Is there an alternative way to achieve a similar thing? My goal is to have 4 cameras such that I can hardware synchronize them.

Before this approach, I used software synchronization to get the RGB/depth images. However, the precision with software synchronization was not sufficient for our application.

@TommyTran unfortunately no, you have to supply +10v on fsync line, you could also utilize a small MCU (eg. via transistor to get 10v).

7 days later

@erik Just to be sure, once we are able to supply a +10v on the FSYNC line with small MCU at the same frequency as the camera is running (e.g 5 FPS). This should be able to synchronize each camera with a IMX378 sensor (RGB) and OV9282 (depth) in the daisy chain right?

@TommyTran yes, that's right. You can see our own wiring and timings in the documentation linked above.

@erik We managed to get it working. However I observed a strange behavior. I am only able to synchronize the cameras in this case 2x OAK-D Pro PoE IMX378, if I set the following frame rate for rgb, left and right.

  • rgb -> 10 FPS
  • left -> 5 fps
  • right -> 5 fps

I also get very weird artifact for the left and right images.

Hi @TommyTran ,
Could you share wiring photo/diagram, and how you are triggering FSYNC? Could you also provide the photo (screenshot), instead of taking a photo of the screen?

14 days later

Hello @erik,
I am a colleague of Tommy. We are able to trigger the cameras successfully using a signal generator. However, we are having some issues triggering them when using the GPIO of an NVIDIA Jetson with a transistor. You can see the circuit below for the triggering of 1 camera (2 resistors in parallel + photodiode are the internal circuit of the camera, as seen here). We assume that extra cameras connected via Y-adapters are in parallel to the 2 resistors in parallel + photodiode.

The Jetson generates a 4 +/- 0.001 Hz train pulse (error checked with an oscilloscope) which makes the BC517 Darlington NPN transistor switch between off and saturation (also checked with the oscilloscope that this happens). What we see is that when having two cameras connected with a FSync Y-adapter, only one of the two cameras triggers. The other doesn't trigger at all. Additionally, the camera that does trigger displays flickering artifacts every couple of seconds.

Do you have any idea about what might be going wrong? May the flickering be caused because the signal's frequency is not stable enough? And if so, what kind of error is acceptable? The BC517 has a very high gain, so based on my calculations it should be able to supply enough current for multiple cameras with the base current that we achieve with the 120k base resistor.

Thank you @erik. Let me know what they find out.

The link to the documentation page with the internal camera circuit in my previous message was wrong. I meant to share this one. The circuit I meant is under the "Connectors" section.

Hi @PV-FMartinez ,
A few possible solutions:

  1. Only drive up to 2 cameras per transistor
  2. Add a resistor in series to limit current
  3. Instead of adding a resistor, either replace R12 with larger resistor, or remove R8/R135 to increase resistance:

Note that we haven't tried any of these, so we aren't 100% it'd work.

    erik

    Regarding solution 1: maybe I was not clear enough, but we are already having issues when trying to drive 2 cameras. The issues I described were happening when testing 2 cameras, not 4. Out of the two cameras that I am trying to synchronously trigger with the transistor:

    • one does trigger, but the image occasionally flickers (it looks as if it were overexposed)
    • the other one does not trigger at all

    As for solutions 2 and 3, what is the logic behind them? Reducing the current through the input of each camera's optocoupler in case the transistor cannot supply enough current to trigger them both? Wouldn't solution 3 involve opening up the cameras and desoldering an SMD resistor (and also soldering a new one in the case of R12)? I would definitely like to avoid this and would prefer to design a new circuit that works with the cameras directly.

    For this however, I would like to understand why my current circuit is not working, so that I can avoid making the same mistake again. If my calculations are correct, the BC517 should be capable of supplying plenty of current to trigger 2-4 cameras. It has a minimum gain of 30000, which means that for a base current of ~16uA (set by the 120k resistor), we should be able to get up to 475mA of current through the collector while operating in saturation. Considering a max V_CE(sat) of 1V, and a typical forward voltage of the LTV-356 of 1.2 V, we should have a 9.8V drop through the 2x 4.7k resistors in parallel, leading to a 4.2mA current per camera. With 4 cameras in parallel it would be 16.7mA, far from the theoretical maximum of 475mA.

    There is another issue that I don't think is addressed by any of the solutions: the flickering of the images of the camera that is actually triggering. Could this be caused by a trigger signal that is of a frequency that is not stable enough? If so, what kind of frequency accuracy do we need in order to avoid flickering?

    Hi @PV-FMartinez , here's the response from EE team:
    There's way too little base current, they'd suggest to either:

    • Replace 120k resistor to some lower resistance, around 1.9k ohm, which, with 30k gain, would result in about 1A through fsync line. Flickering is likely caused because you only have 1uA on transistor base
    • Replace transistor to NMOS

    Hello @erik, thanks for your response.

    Unfortunately the Jetson can only produce up to 20uA, hence the choice of this high-gain Darlington transistor. BC517's V_BE(on) is 1.4V, as seen in the screenshot below, so with a 120k resistor we should have a base current of (3.3V-1.4V)/120k=15.8uA. This should be enough based on the datasheet.

    Below you can also see a graph with the DC gain. For a collector current of 8mA, which is approximately what we should have with two cameras based on my calculations, we have a gain of >30k. This means that with a base current of 8mA/30k=0.266uA we should already get a collector current of 8mA. The base current that we have is around 60 times that much, so it should work.

    In any case, I don't think it makes sense to discuss further what should happen without measuring what's actually happening. I plan to measure the base and collector currents that we are getting, but I can't do it at the moment because the cameras are in use and will continue to be for at least a week. If the base or collector currents are lower than expected, I think it's a good idea to try a smaller base resistor (although I'll have to generate the 3.3V pulse train with the signal generator, due to the Jetson's output current limitations). If the issue turns out to be that the actual gain of the transistor is lower than nominal and the Jetson just can't produce enough current to reach saturation, using a MOSFET instead of the Darlington transistor as you suggested is indeed a good choice.

    I will come back to you if I notice anything strange when doing the tests.

    erik
    We are using a reComputer J4012. The datasheet of the carrier board, which you can find here, specifies on page 18 a maximum current for GPIO pins of +/- 20uA.