# Time Based Synchronization

Time based synchronization groups data by timestamps rather than by a shared trigger line. It does not alter the start of frame
capture or sensor readout. Instead, it performs best-effort grouping on the messages it receives, matching messages whose
timestamps fall within half a period of the reading frequency. It is the most broadly applicable synchronization method and is
often the baseline even when a deployment also uses [hardware synchronization
(FSYNC)](https://docs.luxonis.com/hardware/platform/deploy/data-sync/hardware-sync.md), or [PTP
synchronization](https://docs.luxonis.com/hardware/platform/deploy/data-sync/ptp-sync.md). When those incoming messages were
already aligned upstream by FSYNC or PTP, the resulting time-based groups are typically tighter and more reliable. Sensor data,
including IMU streams, is synchronized through this same time-based workflow, typically by grouping messages with the [Sync
node](https://docs.luxonis.com/software-v3/depthai/depthai-components/nodes/sync.md).

### Principles and theory

Time based synchronization compares message timestamps instead of driving capture from a shared FSYNC wire. On Luxonis devices,
camera frame timestamps are assigned at the MIPI Start of Frame (SoF) event, so all software grouping decisions should be
interpreted relative to that moment. This method does not move exposure start, frame capture, or sensor sampling; it only groups
messages after they are produced. For the underlying exposure and timestamp timing, see [Frame capture
graphs](https://docs.luxonis.com/hardware/platform/deploy/data-sync.md).

### When to use it

Use time based synchronization when:

 * you need to group outputs produced from the same image frame
 * streams run at different FPS and cannot be driven by one trigger cadence
 * sensor data such as IMU packets must be matched to image frames within a tolerance window
 * the pipeline needs host-visible timestamps instead of direct sensor trigger wiring

### Support and constraints

Timestamp-based grouping can include non-image messages such as IMU or other sensor outputs, but it works by selecting acceptable
time windows rather than forcing simultaneous exposure. In practice, this is a best-effort stage: it groups the messages it
receives when their timestamps fall within half a period of the reading frequency. The grouping quality improves when the incoming
streams were already aligned upstream at capture time or by device timing, for example by FSYNC or PTP.

### RVC2 and RVC4 implementation

RVC2 and RVC4 use the same timestamp-based approach for same-device message grouping. When a deployment also uses [hardware
synchronization (FSYNC)](https://docs.luxonis.com/hardware/platform/deploy/data-sync/hardware-sync.md), note that FSYNC applies to
supported RVC2 devices and all RVC4 devices. [PTP
synchronization](https://docs.luxonis.com/hardware/platform/deploy/data-sync/ptp-sync.md) applies only to RVC4 Ethernet
deployments. In both cases, time based synchronization remains the baseline method for grouping camera streams, derived outputs,
and sensor data inside a single pipeline.

 * Use timestamps to group camera frames, frame-derived outputs, and sensor data that belong to the same capture window.
 * Use timestamps when streams run at different rates, when sensor data must be matched to image frames within a tolerance window,
   or when messages need to be compared on the host.
 * Use the [Sync node](https://docs.luxonis.com/software-v3/depthai/depthai-components/nodes/sync.md) for in-pipeline grouping of
   camera, IMU, and other sensor streams, or host logic when you need custom matching rules.

Time based synchronization relies on DepthAI continuously syncing the device clock to the host clock. For more detail on that
behavior, see [device clock and host clock syncing](https://docs.luxonis.com/software-v3/depthai/depthai-components/device.md).