# Correct way to hardware synchronize and phase lock with a global shutter camera

**URL:** <https://community.ouster.com/t/correct-way-to-hardware-synchronize-and-phase-lock-with-a-global-shutter-camera/313>\
**Category:** Software\
**Tags:** ptp, time-synchronization\
**Created:** [April 3, 2025, 11:55pm UTC](https://community.ouster.com/t/correct-way-to-hardware-synchronize-and-phase-lock-with-a-global-shutter-camera/313 "2025-04-03T23:55:13Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![abo](https://avatars.discourse-cdn.com/v4/letter/a/fbc32d/32.png) [@abo](https://community.ouster.com/u/abo)\
**Post date:** [April 3, 2025, 11:55pm UTC](https://community.ouster.com/t/correct-way-to-hardware-synchronize-and-phase-lock-with-a-global-shutter-camera/313/1 "2025-04-03T23:55:13Z")

</div>

I am looking to hardware synchronize the lidar with a global shutter camera such that the lidar is phase-locked to point at 0° at the precise time that the camera’s global shutter exposure begins.

Right now it appears that the suggested way to do this is to configure the lidar to use the timestamp mode TIME\_FROM\_SYNC\_PULSE\_IN and provide into the GPIO port a sync pulse at 1 Hz.

From the documentation on TIME\_FROM\_SYNC\_PULSE\_IN:

> A free running counter synced to the SYNC\_PULSE\_IN input counts seconds (# of pulses) and nanoseconds since sensor turn on. If `multipurpose_io_mode` is set to `INPUT_NMEA_UART` then the seconds register jumps to time extracted from a NMEA $GPRMC message read on the `multipurpose_io` port. Reported at ns resolution (both a second and nanosecond register in every UDP packet), but min increment is on the order of 10 ns.

However in my system there is no GPS attached and therefore no NMEA GRPMC message available, so it currently uses PTP synchronization to provide time to the lidar. Because of this, the behavior described above in the TIME\_FROM\_SYNC\_PULSE\_IN mode desciption is not suitable for the use case.

So the question is: is it possible to do phase locking using an external sync signal, while still using PTP time synchronization to keep the clock synchronized to some non-GPS PTP master?

---

<div class="post-metadata">

**Author:** ![yggdrasil](https://yyz2.discourse-cdn.com/flex004/user_avatar/community.ouster.com/yggdrasil/32/44_2.png) [@yggdrasil](https://community.ouster.com/u/yggdrasil)\
**Post date:** [April 9, 2025, 5:11am UTC](https://community.ouster.com/t/correct-way-to-hardware-synchronize-and-phase-lock-with-a-global-shutter-camera/313/2 "2025-04-09T05:11:06Z")

</div>

Combining a sync pulse in for phase alignment while using PTP time syncing is not possible. One option is to spoof the NMEA message from your client computer which itself is time synched.

A second option is to reverse the direction of the sync to have the lidar trigger the camera as many cameras have a digital input frame trigger. In this situation, you can set the multipurpose IO to `OUTPUT_FROM_ENCODER_ANGLE` - [Multi-Sensor Synchronization — Ouster Sensor Docs documentation](https://static.ouster.dev/sensor-docs/image_route1/image_route3/time_sync/time-sync.html#external-trigger-clock-source)

And then set the firing angle to 360° which will cause the lidar to generate 10 pulses per second to the camera.

---

<div class="post-metadata">

**Author:** ![YerALaserHarry](https://yyz2.discourse-cdn.com/flex004/user_avatar/community.ouster.com/yeralaserharry/32/276_2.png) [@YerALaserHarry](https://community.ouster.com/u/YerALaserHarry)\
**Post date:** [January 8, 2026, 1:21am UTC](https://community.ouster.com/t/correct-way-to-hardware-synchronize-and-phase-lock-with-a-global-shutter-camera/313/3 "2026-01-08T01:21:48Z")

</div>

My ibox wasn’t configured correctly, but after I moved the shunt connectors over everything worked.

 ![Screenshot 2026-01-07 at 5.21.09 PM](https://canada1.discourse-cdn.com/flex004/uploads/ouster/original/1X/69503a29f3fd090838cec497aa7dd06fb26f621b.jpeg)