Stereo Sync & Depth Hardware for Dual Cameras
← Back to: ADAS / Autonomous Driving
I use this page to turn “two cameras” into a depth-capable stereo front end. Simply mounting a left and right camera is not enough: I need hard requirements on trigger, clock, delay matching, timestamping and the FPGA bridge that carries depth-ready data into my ADAS or robotics compute.
What Do I Actually Mean by Stereo Sync & Depth?
When I say “stereo sync and depth” on this page, I mean the timing layer only. My job is to make the left and right cameras behave like two perfectly timed sensors that share one timebase. Algorithms can change, but if the hardware timing is sloppy, every software team downstream will fight physics.
Minimal definition
Stereo depth relies on two levels of synchronization. Frame-level sync keeps the frame index aligned so both cameras see the same high-level moment in time. Sub-frame or line-level timing keeps exposure and readout aligned within that frame so disparity is computed from truly simultaneous samples.
In hardware terms the chain is simple but unforgiving: a clean trigger starts exposure, the sensors perform their readout, and a timestamp unit tags each frame or event against a shared clock. Everything on this page exists to make that trigger → exposure → readout → timestamp chain precise and repeatable across temperature, lifetime and units.
What is “good enough” sync for depth?
“Good enough” is not an abstract idea; it is a single maximum skew number that falls out of my use cases. I look at vehicle or platform speed, stereo baseline and the range of distances I care about, then translate those into the amount of motion that happens during a timing error.
A slow warehouse AGV with a short baseline can tolerate microsecond-level skew, while a fast passenger car with a longer baseline may need sub-microsecond alignment to keep depth errors within a few centimetres. The end result is a requirement like “end-to-end left-versus-right skew < 1 µs under all operating conditions”, which then drives every clock, trigger, delay and timestamp choice that follows.
Why Timing Skew Breaks My Depth Estimation
Depth is geometry on top of time. If the left camera captures an object at one moment and the right camera sees it a few milliseconds later, disparity is no longer a clean function of distance. The math assumes simultaneity; timing skew quietly violates that assumption and the errors show up as warped depth or duplicate edges.
Geometric view – how skew becomes depth error
I imagine a car driving towards a parked vehicle. At 50 km/h the ego car moves almost 14 m every second. A 10 ms skew means the left image might be taken 14 cm closer or farther than the right image, even though the algorithm is trying to treat them as one instant. That difference in physical position turns into a depth bias that grows with speed and range.
I do not need a full derivation on a whiteboard to see the risk. A small timing error translates into tens of centimetres of apparent motion at highway speed. For near-range robot navigation the numbers are smaller but still real. The safe way to design is to pick my worst-case scenario and back-solve a skew limit that keeps depth error inside a range I can tolerate.
System-level symptoms
In the lab everything looks fine: the rig passes static calibration on a checkerboard at room temperature. Problems appear only when I combine motion, temperature and exposure changes. Outdoor tests at speed show ghost edges, unstable depth on distant cars and seemingly random failures after power cycles.
- Indoor calibration works, but outdoor highway tests fail intermittently.
- Depth on static targets is stable, yet moving objects stretch or duplicate.
- Changing exposure or HDR modes in runtime suddenly breaks stereo consistency.
- Cold and hot soak tests show different depth behaviour with the same calibration file.
- Rebooting one camera or power rail sometimes fixes the issue temporarily.
When I see this pattern, I treat it as a timing problem until proven otherwise. A clean skew budget and a way to measure real skew on hardware usually explain more issues than another round of algorithm tweaks or re-calibration.
Where timing skew comes from
Stereo skew rarely comes from a single obvious bug. It is usually the sum of several small effects: two oscillators drifting apart, software-generated triggers with jitter, asymmetric cables and level shifters, and sensors that take different amounts of time to switch modes or power domains.
Independent clock sources and PLLs slowly walk away from each other over temperature and lifetime. MCU-driven triggers add microsecond-scale variation from interrupt latency and firmware load. Unequal cable lengths or different transceivers shift one edge by a few nanoseconds or microseconds more. Sensor power-up and HDR mode changes introduce hidden delays that only show up after certain sequences.
System-Level Architecture for Stereo Sync & Depth
Once I know why stereo sync matters, I need a clean system diagram that shows how the pieces fit together. My baseline architecture always starts with two equal image sensors, one shared timebase and a timing chain that covers trigger, programmable delay, timestamping and the FPGA or CSI-2 bridge.
The left and right sensors share the same clock and trigger information, but each path has its own small adjustment window so I can cancel out routing and pipeline differences. A timestamp unit sits close to the trigger source and measures all events against a single counter. The FPGA bridge then forwards the tagged streams into the SoC or ISP without hiding the timing details.
Baseline block diagram
In my mental block diagram, stereo timing flows from a master clock into a trigger and delay block, out to the sensors and down into a timestamp unit. The FPGA only acts as a structured pass-through: it knows which sample came from which camera and when it was captured, but it does not try to fix timing problems after the fact. Depth, perception and fusion algorithms all sit downstream of this hardware timing chain.
Clocking topologies
For the clock tree I normally choose one of three options. The most robust version is a single master clock feeding a fan-out buffer that drives both sensors, the FPGA and the timestamp unit. This keeps long-term drift and channel-to-channel skew mostly in the hands of the clock and fan-out vendors and makes PCB layout constraints very explicit.
A second topology lets one sensor act as master and export its clock to the other. That can be enough for slow robots or cost-driven designs, but for ADAS it is fragile: sensor mode changes, temperature behaviour and single-point failures now affect the entire stereo chain. A third topology appears when the vehicle already has a network time domain such as 802.1AS. In that case the stereo front end simply imports a reference clock from the sync domain and treats it like any other master clock, with clear jitter and stability requirements.
Trigger and exposure control
The trigger generator turns the timebase into actual exposures. For global shutter devices the trigger marks a frame start and both arrays expose in a tight window around that edge, so frame-level alignment is usually the main concern. For rolling shutter sensors the trigger only starts a scan; exposure walks line by line across the image, which makes line-level timing differences more visible on fast lateral motion.
When I sketch the architecture, I always label whether my depth use cases require frame-level or line-level accuracy. That single note keeps the conversation honest: layout, device selection and algorithms must all target the same timing objective instead of assuming that a generic “frame sync” signal is enough.
Timing & Delay Budgeting for Stereo Depth
With a max skew target in mind, I need to turn that single number into a timing budget that each block in the chain can understand. Instead of blaming a vague “sync issue”, I break the end-to-end skew into clock, PLL, trigger, sensor, cable and timestamp contributions and give each one a realistic share of the error budget.
This budget is not an academic exercise. It becomes part of my RFQ language and my internal design checklist: I can ask vendors about channel-to-channel fan-out skew, sensor pipeline delay, cable length matching and timestamp resolution using the same table that drives my hardware reviews.
End-to-end timing budget components
I start by listing the physical sources of skew. The master clock and PLL introduce jitter and long-term drift. Trigger distribution adds asymmetric delays through buffers and level shifters. The sensors themselves contribute different pipeline delays as temperature and modes change. Cables and connectors add propagation delay, and finally the timestamp unit adds a small quantization error based on its resolution.
Each of these shows up as a few tens or hundreds of nanoseconds in the real system. If I ignore them, they stack up until my stereo rig fails in ways that calibration cannot fix. If I capture them in a budget, I can decide where to spend money and design effort: a better clock, tighter layout, matched cables or a finer-grain timestamp counter.
Practical numbers and rule-of-thumb tiers
For planning I use three rough skew tiers. A target below 100 ns is for aggressive ADAS or long-range depth, where small errors turn into meaningful distance bias. A target below 1 µs suits most passenger-car stereo or mid-speed outdoor robots. Targets in the 1–5 µs range are usually fine for low-speed AGVs, indoor robots or industrial inspection where motion and distance are modest.
These are not standards, just sanity checks. If my calculated requirements end up much looser or much tighter than these tiers, I double-check the assumptions about speed, baseline and depth accuracy. The goal is to choose a tier that is tough enough to keep algorithms happy without demanding unrealistically perfect hardware.
Allocating budget per block
Once I pick a total budget, for example 500 ns, I divide it across the blocks in my architecture. I might give 100 ns to the clock and PLL, 80 ns to trigger distribution, 150 ns to sensor pipeline mismatch, 80 ns to cable and connector differences and 90 ns to timestamp quantization. The exact numbers can change, but the act of splitting the budget forces clear design choices.
That split directly shapes my BOM and layout rules. Clock and fan-out devices must guarantee a certain channel skew. PCB and connector drawings must protect the trigger and data paths from excessive asymmetry. Sensor selections and operating modes must keep pipeline differences inside their share of the budget, and the timestamp unit must offer a resolution fine enough that its quantization noise does not dominate.
Hardware Building Blocks & IC Roles
To make stereo sync work in real hardware, I have to pick concrete building blocks: clock generators and fan-out buffers, trigger and distribution logic, programmable delay elements, timestamp units and an FPGA or CSI-2 bridge that tags and forwards the data. Each role comes with a short list of IC parameters that matter for depth quality.
This section is where I map the “precision trigger and clocking, delay matching, timestamp and FPGA bridging” tagline onto real devices. The goal is not to list every possible part number, but to make it clear which kind of IC I need, what numbers I ask vendors for and how these choices keep my skew inside the budget from the previous section.
Clock generator and fan-out buffers
The clock generator owns the root of my timebase. It has to offer low jitter, good temperature stability and automotive qualification if the system sits in a vehicle. From there I use a fan-out buffer to drive both sensors, the FPGA fabric and the timestamp unit. Channel-to-channel skew on that fan-out is directly visible as stereo skew, so I treat its datasheet numbers as part of my timing budget.
In small prototypes I might start with a generic oscillator or MCU clock, but for a production stereo rig I plan for a dedicated clock tree from the beginning. That is the only way to keep drift and skew predictable over temperature, lifetime and across multiple units in the field.
Trigger generation and distribution
The next block is trigger generation. I prefer hardware timers in an FPGA or a safety MCU over software-generated GPIO pulses. Software triggers pick up jitter from interrupts, scheduling and firmware load, quickly eating into a nanosecond or microsecond-level skew budget. A clean hardware timer or dedicated timing IC gives me much tighter and more repeatable edges.
From the trigger source I build a small distribution network: direct CMOS routing for short runs, or differential pairs and line drivers for longer cables. Every buffer, level shifter and connector adds a little delay, and the asymmetry between left and right paths is what the delay matching block must later cancel out.
Programmable delay and phase alignment
No matter how carefully I route the board, the left and right trigger and clock paths will not be perfectly symmetric. That is why I always reserve a programmable delay element between the trigger logic and each sensor. In some designs that delay comes from dedicated delay line or phase shifter ICs; in others it lives as a calibrated delay chain inside the FPGA fabric.
The key parameters are the maximum adjustable delay, the step size and how much the delay drifts with voltage and temperature. I want enough range to cover realistic layout and component variation, and a fine enough resolution that I can trim skew down to the few tens or hundreds of nanoseconds that my budget allows.
Timestamp and timebase units
A timestamp unit provides the shared timebase that turns stereo timing into numbers. It usually consists of a free-running counter clocked from the same tree as my sensors and FPGA, plus event capture registers for triggers and frame boundaries. The important questions are the counter frequency, the resulting resolution, the bit width and how software reads and resets the value.
I design around the worst-case wrap-around time so that software can handle counter rollover cleanly. I also plan explicit registers or message formats that expose timestamps to the SoC. Without a visible timebase, algorithms and diagnostics are forced to guess at sync quality instead of measuring it.
FPGA and CSI-2 bridging, not aggregation
In this stereo sync context, the FPGA or CSI-2 bridge has a narrow but critical role. It terminates the physical links from the left and right sensors, attaches camera IDs and timestamps to each frame or line and forwards those streams toward the SoC or ISP. Basic integrity checks such as frame counters or CRCs are welcome, but heavy bandwidth management and multi-camera aggregation belong on a separate aggregator page.
Keeping this bridge simple makes timing behaviour easier to debug and reason about. When something looks wrong in depth, I want to know whether the bug is in timing, link integrity or a higher-level fusion layer. A minimal, well-documented bridge helps separate those concerns instead of hiding them.
Debug and observability hooks
Finally, I try to build observability into the design from day one. A test trigger output lets me probe jitter and skew directly with an oscilloscope. A debug path for timestamps and counters lets software log real timing behaviour in the field. An internal test pattern mode makes it possible to measure skew without relying on external scenes or motion rigs.
These hooks cost little silicon and routing compared to the overall system, but they often decide whether a stereo timing issue is solved in hours or drags on for weeks. I treat them as essential IC roles rather than nice-to-have extras.
Design & Calibration Workflow
Instead of treating stereo sync as a vague requirement, I run the project as a simple workflow. I start by writing down the depth and motion scenarios, then translate those into timing requirements. From there I choose a clock and trigger architecture, implement delay matching and timestamping and finally calibrate and verify the system in factory and field.
This step-by-step approach gives me clear checkpoints. Each step can be documented in a specification, validated on a bench and reused as a checklist for future projects or platform variants. The same steps also mirror the way I want to answer frequently asked questions and structure my stereo timing documentation.
Step 1 – Define depth and motion scenarios
I begin by capturing the physical context in numbers instead of vague phrases. That means specifying the nearest and farthest distances that matter for depth, the maximum speed of the vehicle or robot and the baseline between the left and right cameras. From those three numbers I can compute how far the platform moves during a given amount of timing skew and how that motion translates into depth error.
Step 2 – Derive timing requirements
With the motion picture clear, I use the rule-of-thumb tiers from the timing budget section to choose a maximum acceptable skew. If I need depth errors below a few centimetres at highway speeds, I will likely target a sub-100 ns or sub-1 µs skew tier. For low-speed or indoor work, a looser microsecond-level target may be enough. The result of this step is a single number that the rest of the design must respect.
Step 3 – Choose clock and trigger architecture
Next I pick a clock and trigger topology that can realistically hit that skew target. For demanding applications I lean on a dedicated clock generator and fan-out tree, with the trigger generated by an FPGA or safety MCU timer. For simpler cases I might reuse existing clocks or accept a more relaxed jitter budget. In every case I make the topology and its worst-case skew part of the specification, not an afterthought.
Step 4 – Implement delay matching and timestamping
After the high-level architecture is fixed, I implement per-channel delay matching and the timestamp unit. That includes selecting where the delay lives (FPGA fabric or external IC), deciding on the counter frequency and width, and defining how timestamps are exposed to software. I also decide where calibration data lives, whether in eFuse, internal NVM or an external EEPROM, and how it is applied during boot.
Step 5 – Calibrate in factory and verify in the field
Finally I plan for calibration and ongoing validation. In the factory I use static pattern boards and controlled motion rigs to measure real skew and trim the programmable delays. In the field I rely on built-in test patterns, timestamp logging and debug hooks to spot drift or failures over temperature and lifetime. If I design these steps up front, stereo sync becomes a repeatable part of the production process instead of a one-off debug effort.
Application Domains & Example Use-Cases
Stereo sync and depth does not live in a vacuum. I always tie my timing and skew targets back to real applications so I do not over-engineer for one project or under-spec for another. These example domains help me decide which skew tier I should aim for and which parts of the timing chain deserve the most attention.
ADAS front camera pair
In an ADAS front camera pair the vehicle can travel at highway speeds while looking tens of metres ahead. Every millisecond of skew turns into centimetres of apparent motion, and a small depth error can change how lane markings, vehicles and obstacles are classified. For these projects I usually target a sub-100 ns or sub-1 µs skew tier and favour robust clock trees and global shutter sensors wherever practical.
The car environment also pushes temperature, vibration and lifetime requirements, so my clock generator, fan-out buffers and timestamp units need automotive qualification and clearly specified channel-to-channel skew. When I talk to suppliers about an ADAS front stereo, I treat these timing details as core requirements, not optional extras.
Robots, AGVs and warehouse vehicles
For robots and warehouse AGVs the speeds are lower and the working distances are typically a few metres, but the platform still needs reliable stereo depth for docking, aisle navigation and obstacle avoidance. Depth errors of a few centimetres are often acceptable as long as the system can consistently avoid racks, pallets and people.
In this domain I often work with skew targets in the sub-1 µs or low microsecond range. That gives me more freedom in clock architecture and layout while still keeping stereo performance solid. It also makes it easier to reuse existing controllers and FPGA resources across a fleet of robots instead of building a bespoke timing solution for each platform.
Drones and inspection robots
Drones and inspection robots add fast attitude changes to the picture. The airframe can pitch, roll and yaw quickly while the cameras point at power lines, towers or building facades. Even if the translational speed is similar to an AGV, rapid rotation makes rolling shutter artefacts and timing skew much more visible as smeared or warped depth.
For these projects I tend to treat stereo timing almost as seriously as for ADAS. That usually means aiming for a skew tier closer to sub-1 µs or better, especially when I must rely on rolling shutter sensors for size or cost reasons. I also pay extra attention to lightweight, low-power clocking and FPGA solutions that fit inside the drone’s mechanical and thermal envelope.
Industrial stereo inspection
Industrial stereo inspection systems sit on production lines, sort items or measure dimensions in a more controlled environment. Line speed and accuracy requirements can still be demanding, but lighting, mechanical setup and targets are usually more stable than in a vehicle or drone. That gives me more options to trade between tight hardware sync and smarter calibration or software compensation.
In practice, some industrial systems need ADAS-level timing when line speeds and tolerances are aggressive, while others are comfortable with sub-1 µs or even 1–5 µs skew. I make that choice explicit in the project requirements and reflect it directly in the clock, trigger and delay specifications that go into the RFQ.
BOM & Procurement Checklist for Stereo Sync & Depth
When I send an RFQ or build a BOM for stereo, I no longer write a single line that says “stereo camera”. Instead I turn the sync requirements into concrete fields that suppliers can quote against. This checklist is what I use to capture those expectations so that timing and depth quality are clearly covered in the commercial discussion.
Timing targets
- Required end-to-end stereo skew (sensor to sensor) target, for example: < 100 ns / < 1 µs / 1–5 µs.
- Depth and motion assumptions that drive this skew target (for example: up to 120 km/h, 5–80 m depth range, baseline _______ cm).
- Whether the project requires frame-level alignment, line-level alignment, or both.
Clock and trigger chain
- Clock source type: dedicated automotive clock generator, reused system clock or imported network timebase (for example from 802.1AS).
- Maximum allowed clock jitter and long-term drift over the full operating temperature range.
- Required number of clock fan-out channels and the maximum channel-to-channel skew at the fan-out outputs.
- Trigger generation method: hardware timer in FPGA or safety MCU (no software-generated GPIO triggers).
- Expected trigger signalling (CMOS, LVDS or other), maximum line length and any constraints on routing symmetry between left and right cameras.
Delay and timestamp capabilities
- Required adjustable delay range per camera channel (for example: ≥ _______ ns of trim range).
- Required delay step size or resolution (for example: ≤ _______ ns per adjustment step).
- Acceptable delay drift with voltage and temperature across the full operating range.
- Timestamp resolution (counter LSB), for example: ≤ _______ ns / _______ µs per tick.
- Timestamp counter width and minimum wrap-around time at the chosen clock frequency.
- How timestamps and camera IDs are exposed to the host: SPI, I²C, memory-mapped registers or embedded in a diagnostic or image stream.
Interfaces, cabling and debug hooks
- Maximum cable length for clock and trigger paths to each camera, and the allowed difference between left and right cable length.
- Expected role of the FPGA or CSI-2 bridge: terminate two camera links, attach camera IDs and timestamps and forward streams without multi-camera aggregation or bandwidth merging.
- Required test trigger output pin for direct skew and jitter measurements in the lab.
- Required timestamp debug access (for example: readable counters, per-frame logs or a diagnostic bus).
- Whether a built-in test pattern or skew measurement mode is required for factory calibration and field checks.
- Target qualification level (automotive, industrial or other) and operating temperature range that the timing performance must hold across.
When I fill in these fields, suppliers can respond with specific clock, delay, FPGA and module options instead of guessing what “stereo sync” means. It also makes it much easier to compare quotes and designs across different vendors and platforms.
Request a Quote
FAQs on Stereo Sync & Depth
These twelve questions capture the core decisions behind stereo timing. Each answer is short enough to reuse in documentation, training material, support replies or search snippets, and together they cover how to set skew targets, choose hardware and keep stereo sync under control.
For a simple stereo rig, how tight does sync really need to be?
The required sync depends on how fast objects move and how much depth error the application can tolerate. For slow robots or indoor demos, a few microseconds of skew are often acceptable. For safety-related or high-speed systems, a sub-microsecond skew target is usually a safer planning point.
How can vehicle speed, distance range and baseline be turned into a timing skew requirement?
A practical approach is to calculate how far the platform travels during a small time offset. Multiply the maximum speed by candidate skew values and compare the implied motion with the allowed depth error. A conservative skew target can then be chosen and treated as the top-level design number.
When is choosing a global shutter worth it purely for stereo sync reasons?
A global shutter is most valuable when motion or vibration is strong enough that rolling shutter artefacts ruin depth even with good sync. If keeping line-level skew under control is difficult, or scenes contain fast lateral motion and thin structures, upgrading to global shutter can greatly simplify timing design.
Is it safe to rely on software-generated MCU triggers for stereo depth?
Software-generated triggers are usually too jittery for serious stereo depth work. Interrupt latency, scheduling and background tasks make edge timing unpredictable. They can be acceptable for lab experiments, but production designs generally use hardware timers in an FPGA or safety MCU to generate clean triggers.
Is a dedicated clock generator required, or can the SoC or MCU clock be reused?
Reusing a SoC or MCU clock only works if its jitter, drift and fan-out behaviour are well specified and within the skew budget. Automotive and demanding robotics systems typically benefit from a dedicated clock generator and fan-out tree so timing remains predictable across temperature, lifetime and platform variants.
Should the timestamp unit be placed in the FPGA, the SoC or a standalone timing IC?
Putting the timestamp unit in the FPGA keeps it close to triggers and sensor events, which is ideal for precision. Locating it in the SoC simplifies software access but adds link latency. A standalone timing IC is attractive when the same timebase must be reused across several platforms or ECUs.
How much programmable delay range and step size are needed per camera channel?
The delay range should comfortably cover realistic routing and cable mismatches plus margin. For many systems, tens to hundreds of nanoseconds per channel are sufficient. The step size should be small relative to the skew budget so trimmed timing can land near the target instead of oscillating around it.
How should a clock and trigger topology be chosen for a stereo system?
The topology should match application demands. High-end ADAS or drones often use a single master clock with fan-out feeding sensors, FPGA and timestamp units. More cost-sensitive robots may accept simpler trees, provided the worst-case skew and fan-out characteristics still fit the required timing tier.
How can stereo skew be verified and calibrated on the bench before field tests?
Bench verification typically combines electrical and image checks. Clock and trigger lines from left and right channels are probed with a scope to measure relative timing. Test scenes or patterns are then captured, timestamps from both cameras are logged and measured skew is compared against the planned budget.
How can stereo timing drift over temperature or lifetime be detected in the field?
Field drift often shows up as ghost edges, inconsistent depth and unexplained disparity noise. Logging timestamps, trigger counters and diagnostic flags across temperature and operating modes helps reveal slow changes. When those metrics move toward established limits, maintenance or deeper investigation becomes necessary.
What should an RFQ or BOM include so suppliers understand stereo sync requirements?
An effective RFQ or BOM lists the stereo skew target, acceptable clock jitter and drift, required delay range and resolution, timestamp resolution and width and any debug pins or test modes. Clear timing fields allow suppliers to propose concrete devices instead of guessing what level of sync is acceptable.
How can a stereo timebase be shared with a wider network sync domain safely?
When sharing a timebase with a network sync domain, the imported clock should be treated as a reference that must meet jitter and stability requirements. The stereo timing chain stays local and simple, locked to that reference, while extra uncertainty inside gateways and complex bridges is kept to a minimum.
