Each camera in the rig streams perfectly on its own. The moment the pipeline arms two or more sensors together, camera open fails and the log points an error at the frame-sync controller. That single-pass, multi-fail pattern is one of the most decisive symptoms in multi-camera vision: it clears the sensors, the optics and the individual data paths in one step, and it leaves exactly three shared suspects — sync initialization, pooled link bandwidth, and group power. This guide works those three in the order that settles the fault fastest, shows the arithmetic for each, and closes with the evidence a device maker needs when the firmware is the guilty party.
What the symptom already tells you
An open call for a sensor group does more work than an open call for one sensor. It programs the sync mode across the group, negotiates a share of the pooled link for every stream, and lifts all the imagers into their run power state at once. One rejection anywhere fails the whole call, and every sensor in the group reports the error, including the healthy ones. That is why the message names the first camera while the first camera is innocent.
| What you observe | What it clears | What it leaves |
|---|---|---|
| Any single sensor streams on its own socket | That sensor, its lens, its socket, its cable | Shared resources only |
| Open fails the moment two or more sensors arm | — | Sync init, pooled bandwidth, group power |
| The log shows a sync-controller error at open | Bandwidth and power | The sync initialization path |
| The failure lands at stream negotiation or mid-frame | The sync controller | Link bandwidth, host resources |
Commit to this order: sync initialization first, pooled bandwidth second, group power third. Sync leads because only a multi-sensor start programs it. Bandwidth follows because a pooled interface arms sensors one at a time and dies on the second. Power sits third because a dedicated supply clears it in minutes. The sequence below runs all three.
The isolation sequence, in order
- Start each sensor alone, one pipeline per socket, and record pass or fail. All passing clears the sensors and their individual paths.
- Arm the full group with frame sync disabled. This one test splits the fault space in half.
- Compute the payload per camera and the total on the shared link, then compare against the link rate.
- Run the group from a dedicated supply or a powered hub, with the host link kept for data only.
- Walk the trigger chain: one master source, every camera a listener, trigger input configured on each.
- Re-arm sync stepwise — a pair first, then the full group — and record the smallest group that fails.
- With bandwidth and power cleared and sync still failing, capture the debug evidence and report it.
Test one: disable frame sync, start the same group
Rebuild the failing pipeline with one change: sync mode off, every sensor free-running. Before you start it, set the same frame rate and the same exposure on every sensor — a sync group cannot reconcile two different frame periods, and mixed settings are the most common self-inflicted failure at this step.
Two outcomes, each decisive. If the group streams unsynced, the sensors, the link and the power are proven good, and the sync initialization path is guilty. Go to the report section, but first re-arm sync stepwise: many stacks arm a pair cleanly and fail only the three-sensor group, and that detail tells the maker exactly where the fault lives. If the group still fails with sync off, the sync controller is innocent — work the bandwidth arithmetic next.
Triggering cameras that already open together is a different job — see hardware sync for two USB cameras and multi camera exposure synchronization with a shared trigger. This sequence is for the rig that will not open at all.
Test two: the bandwidth arithmetic
Pooled interfaces allocate bandwidth when a sensor arms. The second arm request that exceeds the pool fails at open, wearing a sync costume. Arithmetic separates the two in under a minute.
The 1.2 factor covers packet and protocol overhead at 20%. Now a worked example with real numbers. The LS-CMR-0166 is a 12 MP USB3 area scan camera, and its data prints 4000 × 3000 resolution at 30 fps.
- Sensor format
- 1/1.7"
- Interface
- USB3
- Resolution
- 12 MP
- Shutter
- Rolling
Use exactly those numbers: 4000 × 3000 pixels × 1 byte × 30 fps = 360 MB/s, or 2.88 Gbit/s per camera. Two cameras: 2 × 2.88 Gbit/s = 5.76 Gbit/s, and with the 20% allowance, 6.9 Gbit/s on the shared link.
The decisions follow straight from the arithmetic. A 1 Gbit/s GigE link carries roughly 100-120 MB/s of image payload, so one such camera does not fit and two never will. A 5 Gbit/s USB 3.0 controller carries one camera with margin, and two only if their combined payload plus overhead stays under about 4 Gbit/s, the practical ceiling of that link. Two 12 MP cameras at 30 fps need a 10 Gbit/s path, or two separate links with one camera each. 5GBASE-T camera interface: bandwidth, cables and distance covers the middle option, and acquiring from multiple USB cameras covers splitting cameras across host controllers — industrial mini PCs with a controller per port keep the pools separate by design.
Test three: the power budget
Imagers draw their peak at start, which is why a power fault lands at open rather than mid-stream. Budget the group at full frame rate and keep 30% headroom; commit to that margin, because it absorbs multi-sensor inrush and cable loss together.
The numbers to work from: a USB 3.0 port supplies 900 mA at 5 V, which is 4.5 W; a USB 2.0 port supplies 500 mA at 5 V, which is 2.5 W; USB Power Delivery scales to 100 W at 20 V and 5 A. On PoE, 802.3af delivers 12.95 W at the device and 802.3at delivers 25.5 W. Sum your sensors against the port that feeds them, not the port's brochure claim.
The test is blunt: run the failing group from a dedicated supply or a powered hub with its own rating, keeping the host link for data only. If the group opens, the rail was sagging under multi-sensor start — fix the supply, not the firmware.
Test four: the trigger chain
Once the group opens unsynced, put synchronization back one piece at a time, starting with topology: one master trigger source, every camera a listener. Two sources driving one group is the classic way to recreate the original fault. Configure the trigger input on each camera — on GenICam-based cameras that is the trigger source setting on the input line — because a camera waiting for an edge that never arrives sits at open exactly like a sync failure. Hardware trigger source not detected: check the GenICam line settings walks those settings line by line.
Keep the wiring simple and locked: shielded camera cables, such as a 3 m USB3.0 camera cable built for drag-chain movement, or a 15 m RJ45 camera data cable with locking studs for a GigE run.
- Type
- Camera data cables
- Length
- 15 m
Now the acceptance numbers. At 30 fps the frame period is 33.3 ms; set the same 5 ms exposure on both sensors and a shared edge starts both exposures together. Hold the stamped start-time difference under 100 µs — a part moving at 0.5 m/s shifts 0.05 mm between the two views in that time. The wire is not the limit: a trigger edge crosses 2 m of copper in about 10 ns, near 5 ns per metre, so measured deltas far above 100 µs mean software timestamping or two free-running clocks. Verify hardware sync between two cameras actually works gives the measurement routine.
Free-running is not a substitute for that shared clock. Two crystals at ±50 ppm drift apart by up to 100 ppm, which is 3.3 µs per 33.3 ms frame and a full 1 ms after 300 frames — ten seconds of running. Stereo on free-running cameras fails as a slow calibration drift, which is far harder to diagnose than a trigger that will not arm.
Match the shutter to the job. A global shutter exposes the whole frame at once, so one edge aligns the pair truly; the MV-CH120-11UC is a 12 MP USB3 area scan camera with a global shutter. Frame-start sync on a rolling shutter still staggers the rows: take a 15 ms readout on a 3000-row sensor and each row lands 15 ms ÷ 3000 = 5 µs after the one before it. A rolling pair is row-coincident only if the stack locks readout timing, not just frame start.
- Sensor format
- 1.1"
- Lens mount
- C-mount
- Interface
- USB3
- Resolution
- 12 MP
If the fault sits inside a multi-sensor 3D device rather than your own rig, the fastest fix is hardware that solved it at the factory: a unit from 3D sensors such as the MV-DLS300P-04 synchronizes its sensor pair inside the housing and hands you one calibrated stream.
If the sync layer is guilty: report it right
Disabling sync made the group stream, the arithmetic cleared the link, the dedicated supply cleared the rail — and the sync arm still throws an input/output control error at open. That is a firmware or driver fault in the sync path, and the fastest route is a report the maker can reproduce in one run:
- Firmware version, SDK version and OS version, exactly as the device reports them.
- One full debug-level log of a single failing run, captured with the SDK's log-level setting raised — not scattered snippets.
- The minimal script: one sensor passes, then the smallest group that fails.
- The system log lines around the failure timestamp.
- A plain statement of the pattern: every single-sensor pipeline passes, every multi-sensor pipeline fails at open, sync disabled passes.
Retest on the last firmware and SDK combination you qualified before the upgrade. If that combination passes, say so in the report: a versioned regression goes straight to the team that changed the sync code, an unversioned complaint does not.
When the usual answer is wrong
Four look-alikes fool the single-pass, multi-fail pattern. Pooled bandwidth: the second arm exceeds the link pool and the failure lands at open, exactly like a sync fault — test two is the arithmetic that separates them. Group power: rail sag at multi-sensor start, cleared by the dedicated-supply test. Host limits: two identical cameras enumerate with the same name and the open grabs the wrong node — open by port, not by name, as two identical USB cameras shows. And a group that opens cleanly but corrupts frames later has a shared-hardware fault, not a sync fault: multi-camera image corruption: isolate shared hardware faults covers that branch.
Checklist before you add another camera
- Payload arithmetic per camera and per shared link, with the 20% overhead allowance — this decides the interface before anything is bought.
- Power budget for the whole group at full frame rate, with 30% headroom — this decides the supply.
- One trigger master, every camera a listener, trigger input configured on each — this decides the wiring.
- Identical frame rate and identical exposure across the group before sync is armed.
- Global-shutter cameras whenever the pair must be truly coincident.
- One camera per host controller when a single payload passes half the controller's line rate.
- Firmware and SDK versions recorded at commissioning, so a regression is provable later.
Ready to size the whole rig? The camera finder filters area scan cameras by interface and shutter, the system configurator walks camera, lens, light and controller in order, and the systems topic page collects the synchronization guides. If the fault is inside a device bought here, the contact page reaches the applications team — attach the debug log and the version list from the section above.
Questions
Why does every sensor report open failure when only the group start fails?
Because the open call arms the group as one unit: sync mode, pooled bandwidth and the group power state are programmed together, and one rejection fails the whole call. The error names the first camera in the group, but that camera is healthy. Disable frame sync and start the same sensors unsynced — if they stream, the sensors and their paths are good, and the failure lives in the group setup, not in any single camera.
How much timestamp difference should two synced cameras show?
Hold it under 100 µs between exposure starts. Scale the tolerance to your line speed: the shift between views equals speed times the delta, so at 1 m/s a 100 µs error is 0.1 mm of disagreement and a 1 ms error is a full millimetre. The wire contributes only nanoseconds of skew, so the budget is spent in firmware stamping and clock tolerance — which is why both cameras must timestamp from the same clock domain.
Can I skip frame sync and run the sensors free-running?
Only when the part is stationary and each frame is judged on its own. For stereo or moving parts, no: unmatched crystals wander, and the error grows with run time rather than staying put. Frames that are nominally simultaneous then disagree, and the failure masquerades as a bad calibration rather than a timing problem — far harder to diagnose than a trigger that will not arm.
What goes into a sync fault report a maker can act on?
Five items: the firmware version, the SDK version and the OS version exactly as the device reports them; one complete debug-level log from a single failing run; the minimal script that passes with one sensor and fails with two; the system log lines around the failure; and the last version combination that worked, if you have one. A versioned regression goes straight to the team that changed the sync code; anything less sits in a queue.
Does one camera need its own USB controller?
Yes, whenever a single camera's payload passes half the controller's 5 Gbit/s line rate. A 12 MP camera at 30 fps and 8-bit mono produces 2.88 Gbit/s, so it gets its own controller. Two 1.2 Gbit/s cameras share one comfortably: 2.4 Gbit/s of payload plus the 20% overhead allowance is 2.88 Gbit/s, under the roughly 4 Gbit/s practical ceiling of the link. Do that arithmetic before blaming the sync firmware.