I'm working on an object tracking system comprised of 3 cameras. The cameras are up to 50ft apart, and each contains a raspberry pi 4, and an arducam OV9281.

I would like to synchronize the frames captured by these cameras to make triangulation simpler. Specifically I'm planning on using the OV9281 external trigger input.

I would like the sync pulse to be accurate within 100uS between the cameras.

The issue is, that I would like these units to be wireless if possible. The pi's can connect to each other via wifi without issues, but I'm not confident that I can synchronize the pi's with adequate precision over this network, and besides that I will still need some hardware in each box to generate the trigger pulses which will feed into the OV9281s. Again, I don't think the rapsberry pi GPIOs will be accurate enough to generate this pulse directly.

The backup option which I'm considering right now is to use 3.5mm audio cable to carry a sync signal.

What I'd like to do is use simple radio of some sort to transmit periodic pulses which each camera can receive, or receive a signal of this sort that already exists (even indoors).

Does anyone know of a method that could achieve this? I know this could easily be done with a custom radio, but I would like to use radio modules of some sort to keep the complexity down.

Edit: Just to clarify, the sync signal will go directly to the camera external trigger input, it will not go through the pi. I agree the pi would not be accurate enough for that with a regular task-scheduled os.

  • \$\begingroup\$ This question isn't a great fit here, because there are countless possible radio solutions. Really what it comes down to if you want to do this locally is finding radios where you have direct low level access. It's unclear that the pi's wifi hardware/drivers would give you that (though you might look if there's any access to raw air packets). Something like nRF24L01+ radio clones, or any of the many other types you could directly manipulate would. And then there are indirect solutions, like a GPS receiver with PPS at each node... \$\endgroup\$ Oct 19, 2020 at 18:33
  • \$\begingroup\$ Also note that sub-millisecond timing through the pi at all is going to be tricky; you may want to offload both the radio and the timing to an external MCU. Something like the Nordic BLE MCU's also let you use the radio in custom nRF24-like ways, and give you a programmable processor code with could fire the external input trigger line on your camera... But that's just one of many hardware choices, eg the ESP chips may also give you sufficiently low level options for the use of their radios. \$\endgroup\$ Oct 19, 2020 at 18:34
  • 1
    \$\begingroup\$ hackaday just had an article about the new rpi compute module, and one thing mentioned was the wifi module has support for IEEE 1588 Precision Time Protocol. Might be of some interest to an application like this, but it's wikipedia article claims submicrosecond accuracy. hackaday.com/2020/10/19/… \$\endgroup\$
    – vicatcu
    Oct 19, 2020 at 18:39
  • \$\begingroup\$ @vicatcu yeah, but Linux doesn't have IEEE1588 support for that chipset, so I'm not sure where HAD is taking that. Also, I think you're confusing something – IEEE1588 is mainly a wired ethernet thing, and the chip they refered to is an ethernet thing, not a Wifi thing. \$\endgroup\$ Oct 19, 2020 at 18:40
  • 1
    \$\begingroup\$ Is radio a must? You could use infrared remote control transmitters... \$\endgroup\$
    – bobflux
    Oct 19, 2020 at 18:52

3 Answers 3


The NNTP protocol can sync your R-pi's wall-clock times together and periodically correct for any drift. So at least at the system level there is a solution.

However,the R-pi CSI-2 connector specifically lacks any provision for hardware sync or master clock, so that kind of kneecaps the whole scheme. Without frame sync, over time each camera's framing will drift, ruining the frame correlation you need to properly sense distance.

If your camera has its own sync pins available you could possibly use another approach (e.g., infrared) to provide a master sync reference.

  • \$\begingroup\$ Thanks, the camera does have it's own sync pin. I agree, getting an accurate pulse out of the rpi would be difficult even if I could get the internal clocks of those syncronized. For now I assume it's impractical. \$\endgroup\$
    – Drew
    Oct 19, 2020 at 19:09
  • \$\begingroup\$ Here's an example from Arducam for Jetson Nano. youtube.com/watch?v=MbLOcaAJ7Ug \$\endgroup\$ Oct 19, 2020 at 19:12
  • \$\begingroup\$ Yeah that's my back up solution, basically I would like to transmit the sync signal wirelessly. \$\endgroup\$
    – Drew
    Oct 19, 2020 at 19:16
  • \$\begingroup\$ I think an IR extender-esque hack could do that. The signal is only at frame rate (60Hz or so.) But if you have reasonable NNTP sync then you can do a sideband frame sync directly from the Pi. \$\endgroup\$ Oct 19, 2020 at 19:22

The simplest solution might be to transmit an optical carrier using fixed <10 DEG LED in series aimed in each direction with IR Rx with AGC attached to each camera.

Since < 100us sync error is needed at 16kHz or similar carrier f with the desired square wave Vsync at 30, 60, 120, 180 Hz or whatever is used. WIth AGC remote Rx chips having a Q of 10 or BW=1.6kHz it is possible to achieve phase sync at 10% of this or 1/16 kHz which is less than 100us. As the rise time and comparator threshold of the output pulse will affect skew, one can tweak the threshold to phase align the sync edge (using the edge for carrier ON rather than off).

Thus the components from Vishay/Sharp @ Mouser would be my 1st choice if still avail. and any comparator to shift the edge into alignment for a slow rise or fall time, whichever has less jitter. If not, there are other delay methods for synchronizing edges with variable one-shots.

I have used these for a line of sight using 15 deg LEDs to 50 ft easily, but narrower LEDs with 100mA will give a better SNR and lower jitter.

How you generate the Vsync square wave doesn't matter to me but there are many simple ways to derive this for even variable rates by syncing off only 1 camera.

  1. IEEE 1588V2 protocol (client and server). It can sync nodes on a network using a master clock. This is a complex software solution (network and services setup, master clock setup etc).
  2. GPS - Each node can use a GPS receiver, usually these have 1pps signal. If the nodes are outside, this solution is the simplest (just add a GPS receiver to each PI). If these nodes are inside, the solution is slightly more complicated, and requires an external GPS antenna and an internal repeater amplifier.
  • \$\begingroup\$ notice how both can still fail if your GPIO latency is too high / non-deterministic. \$\endgroup\$ Oct 19, 2020 at 18:43
  • \$\begingroup\$ The GPS would definitely work and would not need to interface with the pi at all (just an MCU or PLL to convert the pulse frequency). But the lock time, and issues with indoor use are issue with that solution. \$\endgroup\$
    – Drew
    Oct 19, 2020 at 19:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.