H2-1. What a Sync/Trigger & Timing Hub Owns in a Vision Cell

This page “owns” three truths that engineers can verify on a scope and in logs: Timestamp Truth (offset/drift/PDV), Trigger Truth (skew/jitter/delay error), and Long-run Truth (holdover/wander vs temperature).

Why the boundary matters: In machine vision, “sync” failures are often mis-attributed. A robust hub prevents the common trap: diagnosing a timing problem as a link/PHY problem, or chasing ISP effects when the root cause is clock domain instability.

Three field symptoms → the minimum evidence to collect (no guessing):

• Cameras disagree on timestamps → inspect offset, drift direction, and PDV (packet delay variation).
  Signal of PDV: offset is “mostly fine” but spikes correlate with load/topology changes. Signal of drift: offset walks in one direction over time.
• Trigger-to-exposure latency is unstable → measure multi-drop skew (relative arrival), edge jitter (short-term), and delay residual after programming.
  Skew is a spatial problem (channel-to-channel). Jitter is a temporal problem (run-to-run). Residual is a calibration/quantization problem.
• Alignment drifts after warm-up / long runtime → record holdover curve, wander (low-frequency drift), and temperature vs offset.
  If the error tracks temperature, treat the oscillator/holdover path as guilty until proven otherwise.

What this page will deliver (engineering outputs, not theory):

• Accuracy budget that turns “we need 1 µs” into an actionable allocation across timestamping, distribution, delay quantization, and holdover.
• Pulse/trigger topology guidance for deterministic fanout (skew control) and programmable alignment (delay calibration loop).
• Validation & field debug playbook that maps symptoms → evidence → isolate → first fix.

References (do not expand here): high-speed interfaces and PHY robustness belong to Machine-Vision Interfaces.

H2-2. Accuracy Budget: From “Timestamp Truth” to “Trigger Truth”

Total timing error is the sum of multiple independent contributors:
Total ≈ Timestamp capture error + Network/Path variation (PDV) + Fanout skew + Delay quantization/residual + Oscillator drift (temp/aging).

Two time scales must be budgeted (or the system will “pass once, fail later”):

• Short-term (ns–µs): edge jitter, timestamp capture granularity, distribution skew.
  Impacts frame-to-frame alignment and trigger-to-exposure determinism.
• Long-term (minutes–hours): wander + holdover drift driven by temperature and oscillator aging.
  Explains “works at cold start, drifts after warm-up” and “fails after GM loss.”

Budget allocation template (use bullets if you avoid tables):

• Target: e.g., end-to-end alignment ≤ ±1 µs (or ≤ ±100 ns for tighter cells).
• Allocate caps (example structure—numbers depend on system):
  • Timestamping ≤ X (hardware timestamp point + correction accuracy)
  • PDV ≤ Y (P99 path variation under load/topology changes)
  • Fanout Skew ≤ Z (channel-to-channel arrival difference)
  • Delay Residual ≤ Q (tap quantization + calibration residue + temp drift)
  • Osc Drift ≤ R (holdover window + temperature gradient)

Decision point (where requirements force architecture):

• If the target is loose, software timestamps may look “okay” but are hard to prove and will fail under scheduling/load variability.
• If the target is microsecond-class, hardware timestamping becomes mandatory; PDV and distribution skew must be measured and budgeted.
• If the target is sub-microsecond / hundreds of nanoseconds, you typically need: hardware timestamps + jitter-cleaning PLL + calibrated programmable delays + strict validation matrix.

Evidence you must log/measure to claim a budget is met:

• Log: offset/drift statistics (mean + P99), servo state, GM switch events.
• Measure on scope: multi-channel skew (same TRIG distributed to multiple endpoints), and run-to-run jitter (edge spread over repeated triggers).
• Thermal correlation: temperature vs offset drift (especially after 10–30 minutes warm-up).

H2-3. PTP/IEEE-1588 in Vision: Profiles, Roles, and Where Determinism Breaks

Role map (engineering meaning, not protocol trivia): GM defines the time domain, BC segments the network into stable domains, TC reduces hop-induced uncertainty by accounting for transit delay, OC (end devices) consume time and expose timestamp evidence.

Where determinism breaks first (field reality):

• Queueing and congestion (PDV) → averages may look fine, but P99 offset/delay spikes ruin alignment.
• Multi-hop topologies → each hop adds a new source of residence/queue variation unless the hop is made visible/compensated.
• Timestamp capture not in hardware → scheduling/interrupt jitter enters the timing loop and cannot be “configured away.”

Role selection rules (a “choice tree” that stays in scope):

• If the timing path crosses multiple switches / segments: prefer BC/TC patterns so each segment remains bounded.
• If the design needs hop visibility / transit accounting: TC has value because it makes intermediate residence behavior measurable instead of a black box.
• If the network is simple and controlled: OC endpoints can still work, but PDV must be proven under load (do not rely on idle tests).

Minimum evidence to collect (to confirm the role choice is working):

• Logs: offset and path-delay statistics (mean + P99), servo state transitions, GM change events.
• Correlation test: offset spikes vs traffic/load changes (spikes that track load are classic PDV).
• Cross-endpoint check: compare offsets across multiple cameras/nodes—large divergence usually points to topology/hop effects or timestamp capture differences.

Scope note: interface PHY/SerDes robustness is referenced by Machine-Vision Interfaces and is intentionally not expanded here.

H2-4. Hardware Timestamping: Where the Timestamp Must Be Taken

Two engineering truths (must be explicit):
1) Software timestamps are rarely provable for determinism because scheduling/interrupt jitter is unbounded.
2) Hardware timestamps can still be wrong if clock domains, FIFO behavior, or compensation parameters are mismanaged.

Why software timestamps lose determinism:

• Scheduling noise enters the timebase: interrupt latency and CPU load widen the timestamp distribution.
• P99 is the killer: mean offset may look stable while P99/max spikes grow dramatically under load.
• Evidence pattern: offset/jitter becomes correlated with OS activity rather than network timing behavior.

Why hardware timestamps can still be wrong (common “advanced” failure modes):

• Clock domain mismatch: timestamp counter domain differs from capture/transfer domain → deterministic bias or temperature-linked drift.
• Timestamp FIFO congestion: high traffic causes FIFO delay/overflow → bursts of “missing / late” timestamps and a degraded P99 tail.
• Latency compensation error: fixed-delay correction parameters are wrong → stable-looking but consistently biased time.
• Counter rollover handling: wrap-around not handled → rare but catastrophic discontinuities in logs.

Hardware timestamp readiness checklist (fast self-audit):

• Timestamp taken at? MAC-adjacent latch (preferred) vs driver/app (avoid for deterministic claims).
• Correction/compensation applied? fixed latency terms configured and validated with measurement.
• Clock ID stable? time domain and clock source stability verified across warm-up and role changes.
• FIFO behavior verified? no overflow/latency anomalies at worst-case traffic and message rates.
• Rollover handled? counter wrap tested and logged (including long-duration runs).

Minimum proof set (stays in scope):

• Logs: timestamp capture stats, servo state, missing/late timestamp counters.
• Stress test: apply CPU/network load and compare mean vs P99 offset/jitter.
• Calibration check: validate compensation by comparing two known reference events (scope + log alignment).

H2-5. Pulse/Trigger Distribution: Fanout, Skew, and Signal Integrity Without PHY Deep Dive

Two proof-grade measurements (minimum evidence set):
1) Use a multi-channel scope to measure multi-end arrival time → skew.
2) Keep the same trigger source but change cable length / load → observe Δt shifts and edge distortion.

Topology choice (what changes in timing behavior):

• Star fanout: best chance to keep channel-to-channel skew bounded because paths are explicit and comparable.
• Daisy-chain: delays and uncertainty accumulate per hop; the last node inherits every upstream imperfection.
• Hybrid: often a practical compromise—keep critical endpoints on short, comparable branches.

Cable delay (the “fixed” part of skew):

• Rule: length differences create predictable Δt. Treat cable delay as a first-stage coarse alignment tool.
• Evidence pattern: if Δt is large but stable across runs, it is usually dominated by fixed path delay (length/topology).

Termination and reflections (how edge shape turns into timing error):

• Engineering consequence: reflections and ringing can shift the effective trigger time by creating a second threshold crossing.
• Evidence pattern: “same cable, different load” changes both Δt and the waveform shape near the decision threshold.

Ground reference and return path (high-level, no standard deep dive):

• Engineering consequence: if the reference/return path is unstable, the trigger threshold becomes effectively time-varying, raising jitter.
• Evidence pattern: trigger jitter worsens when high-current events occur (lighting strobe, motion events), even if the nominal cable length is unchanged.

Practical integration rule that keeps the next chapter easy:

• First make topology and physical paths predictable (coarse alignment), then use programmable delays for fine alignment (H2-6).

H2-6. Programmable Delays: Fine Alignment for Multi-Camera + Lighting + Motion

Absolute delay vs relative alignment: Absolute end-to-end delay can drift with temperature and component variation. Relative alignment targets the residual differences between endpoints, and is typically what makes multi-camera + lighting + motion deterministic.

Three programmable-delay parameters (and why they matter):

• Resolution (step): too coarse → residual error cannot be pushed below the budget, even after calibration.
• Range: too small → programmable delay cannot compensate for large path differences; coarse alignment must happen first (H2-5).
• Determinism: if delay behavior changes with load/edge quality/temp, a “calibrated” system will not stay aligned.

Calibration closed-loop (proof-oriented):

• Measure: capture multi-end arrival residuals (Δt between camera triggers, strobe, motion reference).
• Compute: convert residuals into per-channel compensation values.
• Program delay: apply delay taps (record tap values + conditions like temperature point).
• Verify: re-measure and confirm the residual is within budget, focusing on P99 behavior.

Main error sources (what prevents perfect alignment):

• Quantization (step): discrete taps leave a floor (residual cannot go to zero).
• Temperature drift: calibrated at one temperature but residual returns after warm-up.
• Input edge jitter: if the incoming trigger edge is unstable, delay cannot “fix” the source jitter.
• Phase noise coupling: fine alignment may be met on average, but tails grow if the timing source is noisy.

Alignment strategy (repeatable three-stage method):

• Coarse align: reduce fixed path differences via topology and cable planning.
• Fine align: use delay taps to remove the residual inside the accuracy budget.
• Maintain: compensate temperature drift (periodic re-calibration or conditional re-calibration after warm-up events).

H2-7. Jitter-Cleaning PLLs and Clock Trees: From Noisy References to Clean Outputs

Jitter vs wander (use-case split):
Jitter (short-term) degrades trigger-edge timing and tight exposure/lighting alignment.
Wander (long-term) erodes timestamp consistency over minutes to hours.

Why cleaning is needed (where noise comes from):

• Noisy references: upstream clocks can carry phase noise; network conditions can add timing variability.
• System consequence: short-term noise shows up as unstable edges; long-term drift shows up as growing timestamp offsets.
• Evidence hook: measure phase noise / integrated jitter at input vs output and correlate with edge stability.

How to choose loop bandwidth (filter vs track trade-off):

• Narrow bandwidth: stronger jitter filtering → cleaner downstream edges, but slower tracking of reference changes.
• Wide bandwidth: faster tracking, but more upstream jitter passes through to outputs.
• Evidence hook: after bandwidth changes, compare output integrated jitter and lock recovery behavior under stress (look at tails, not only averages).

Clock tree outputs (multi-output consistency is the real system value):

• Multi-output phase relationship: downstream determinism depends on the repeatability of relative phase/arrival across outputs.
• Distribution consequence: “clean” output still fails multi-camera alignment if output-to-output skew is not bounded and verified.
• Evidence hook: use a multi-channel scope to capture relative arrival and edge jitter across outputs simultaneously.

Scope note: No heavy PLL math is required here. The engineering outcome is controlled by measurable indicators: phase noise, integrated jitter, loop bandwidth, and holdover behavior.

H2-8. Holdover & Time Discipline: OCXO/TCXO/MEMS Choices and Temperature Reality

Field symptoms to map to evidence:
• Offset grows after 10–30 minutes → warm-up / temperature-induced frequency shift.
• GM loss causes offset to diverge → holdover drift curve dominates.
• The proof is a paired record: temperature vs offset/drift.

What holdover means (engineering, not marketing):

• Definition: maintain the local timebase when the reference is missing or degraded.
• System consequence: even if short-term jitter is cleaned (H2-7), long-term drift can still destroy timestamp consistency during holdover.
• Evidence hook: mark the GM-loss event and observe the offset slope change; compare slopes under different thermal conditions.

Oscillator selection principles (trend-based, not a part-number list):

• OCXO: chosen when the goal is the flattest drift curve (best long-term stability), accepting size/power/warm-up trade-offs.
• TCXO: chosen when size/cost are constrained; requires tighter calibration discipline and thermal awareness.
• MEMS (trend): attractive for rugged environments (shock/vibration); must be validated via drift-vs-temp curves for the target duty cycle.

Temperature reality (why “20 minutes later” failures happen):

• Warm-up: temperature ramps after power-up and shifts frequency, changing offset slope.
• Thermal gradients: local heating from nearby electronics can make drift non-uniform and repeatable only if measured.
• Evidence hook: log temperature and offset together and compare “cold start” vs “thermal steady state.”

Minimal operational discipline (keep it proof-oriented):

• Record: (1) GM loss timestamp, (2) offset curve, (3) temperature curve.
• Define a re-discipline trigger: if drift exceeds the budget, re-lock and re-verify multi-end alignment.

H2-9. Validation & Instrumentation: How to Measure Timestamp Accuracy and Trigger Skew

Minimum evidence set (must be collected together):
• Scope (2–4ch) for multi-end TRIG/FSYNC arrival.
• Logs for PTP offset/delay stats, servo state, GM switch/loss events.
• Temp log for warm-up correlation (the “20-minute drift” class of failures).

Optional enhancer (use when you need a single-number proof):

• Time-interval / frequency counter (TIE): turns “looks noisy” into a quantified stability metric over longer windows.

Test matrix (bullets format): scenario → observe → pass/fail

• Cold start: observe offset convergence + Δt stability + temp ramp → pass if convergence is stable and Δt remains bounded by the budget.
• Warm-up (10–30 min): observe temp vs offset slope + trigger edge tails → pass if drift slope stays within the budget and tails do not thicken.
• Network load stress: observe delay/offset distribution tails + servo state → pass if spikes/outliers stay bounded and servo does not enter unstable states.
• Cable swap / load change: observe Δt shift predictability + waveform shape → pass if Δt changes are explainable and edges remain single-crossing.
• GM loss / GM switch: observe event time + offset jump + re-lock time + holdover slope → pass if recovery is controlled and post-recovery alignment remains within budget.

Pass/fail thresholds should be derived from the accuracy budget (H2-2). Always evaluate tails (e.g., worst-case runs / P99 behavior), not only averages.

H2-10. Field Debug Playbook: Symptom → Evidence → Isolate → Fix

Allowed evidence sources (stay within this page): scope multi-end arrival, waveform edge quality, offset/delay stats, servo state, GM switch/loss event timeline, temperature correlation.

Symptom A — Large steady offset (timestamp shifted as a whole)

• First 2 checks: (1) offset mean and stability (logs), (2) GM/role + servo state (logs).
• Discriminator: lock to a known-stable GM/reference and check whether the offset returns to the budget.
• First fix: align roles/profiles and verify the timestamp path is hardware-based (not scheduling-dependent).
• Prevent: configuration audit checklist + GM switch event recording in every validation run.

Symptom B — Offset spikes / “jumps around” (PDV / queue-driven)

• First 2 checks: (1) offset/delay outliers and tails (logs), (2) correlation with network load or GM events (logs).
• Discriminator: reduce/reshape load or isolate the path; if spikes collapse, PDV is dominant.
• First fix: enforce deterministic timing path and confirm hardware timestamping is effective end-to-end.
• Prevent: keep a load-stress test in the matrix and evaluate tails (worst runs / P99).

Symptom C — Trigger alignment “sometimes good, sometimes bad” (edge / termination / ground reference)

• First 2 checks: (1) multi-end Δt spread across runs (scope), (2) edge shape near threshold (ringing / re-crossing risk).
• Discriminator: swap cable/load; if Δt changes nonlinearly and the waveform worsens, termination/reflection dominates.
• First fix: stabilize distribution first (topology/termination/reference), then re-run fine alignment (delay taps).
• Prevent: standardize cable/endpoint loads and keep a calibration/verification loop in commissioning.

Symptom D — Drift grows after warm-up (thermal / holdover reality)

• First 2 checks: (1) temperature vs offset slope correlation (logs), (2) holdover/reference quality events (logs).
• Discriminator: re-verify after thermal steady state; if drift slope changes with temperature, thermal stability is dominant.
• First fix: tighten holdover strategy and validate oscillator suitability with drift-vs-temp evidence.
• Prevent: warm-up window in acceptance tests + periodic re-validation after temperature transitions.

Symptom E — Big jump after GM switch (re-lock / configuration mismatch)

• First 2 checks: (1) GM switch timeline (logs), (2) jump magnitude + re-lock time (logs).
• Discriminator: pin a single GM; if behavior stabilizes, switching policy/config is the driver.
• First fix: unify profile/roles/priority and verify consistent discipline behavior across nodes.
• Prevent: include GM-loss and GM-switch scenarios in the test matrix with an explicit pass/fail rule.

H2-11. IC Selection Recommendations (Timing Hub BOM Blocks + MPN Examples)

3-step usage:
1) Lock the error budget and “tightest requirement” (timestamp vs trigger) in H2-2.
2) Pick BOM blocks based on topology + stress cases in H2-9.
3) Confirm with evidence: scope Δt, offset/delay tails, temp correlation, and GM events.

Note: MPNs below are representative examples to anchor categories and key specs. Final selection should always be verified against the latest datasheets and the H2-9 test matrix.