Synchronize multiple IMX219 cameras on one MIPI bus with I2C

Eight camera modules that all answer on one shared I2C address, a host with a fixed number of MIPI lanes, and no trigger pin brought out of the module: that combination stalls more multi-camera carrier boards than any bandwidth limit. This guide gives you the scheme that works — one shared clock, a multiplexer for per-camera register access, a sequential I2C start with a known and fixed skew — together with the lane arithmetic that decides whether eight cameras fit your receiver at all. The worked example assumes 1920×1080 at 30 fps in RAW10 over two lanes per camera; substitute your own resolution, bit depth and frame rate, and the same arithmetic holds. By the end you can commit to a scheme and size it with numbers you can defend.

The scheme that works, in one paragraph

Feed every sensor the same external clock from one oscillator through a fan-out buffer. Put each sensor on its own multiplexer channel, so the shared 0x10 address answers for one camera at a time. Program all eight with the same register set, then write the release-from-standby bit to each camera in turn. Accept the resulting start skew — about 1 ms across eight cameras on a 400 kHz bus — because the shared clock keeps that offset fixed, and remove it on the host by aligning frame timestamps. That is the whole design. The sections below justify each number in it, show where it breaks, and mark the point at which you should change architecture instead.

Why eight sensors at one I2C address cannot share a bus

Most IMX219 modules expose the sensor at I2C address 0x10; some variants answer at 0x1A. You do not get a per-camera address choice, so two identical modules on one bus collide by construction: both acknowledge the same address, and every read returns two devices fighting over SDA. Writes are no better — a partially decoded write can leave both sensors in a mode you cannot debug, because you cannot read back through the collision.

The I2C specification reserves a general call address for broadcasts, but register writes to this sensor through general call are not a documented feature, so design as if every write is per-device. That leaves two workable topologies: a hardware multiplexer that connects one sensor at a time to the controller — the device tree side is covered in the TCA9548 I2C multiplexer guide for multiple MIPI cameras — or the isolation patterns in the guide to two sensors with the same I2C address. When the modules carry their own controllers instead of raw sensors, the shared-bus limits for multiple camera modules on one host apply instead.

One clock for all eight sensors

The mainline Linux driver for this sensor states the constraint plainly: the external clock must be between 6 MHz and 27 MHz. Pick one frequency for the whole board — 24 MHz is the common choice inside that window — and generate it once. One oscillator, one fan-out buffer, eight clock traces to eight sensor clock inputs.

Do not let each module free-run on its own crystal. Crystals differ by tens of parts per million; at a 50 ppm spread, two 30 fps cameras drift apart by 33.3 ms × 0.00005 = 1.7 µs per frame. That wraps a full frame period in 33.3 ms ÷ 1.7 µs ≈ 20,000 frames — about 11 minutes — after which simultaneous frames are a full frame apart and no software filter closes the gap cleanly.

The distinction that keeps the layout simple is clock skew versus frame drift. At 24 MHz one clock period is 41.7 ns, so even 10 ns of trace mismatch between boards is 0.00003% of a 33.3 ms frame period. You do not need length-matched clock traces to the millimetre; you need one source. And yes, one clock output from the host can feed all eight sensors, provided the output buffer is rated for the load — past two or three loads, add the dedicated fan-out buffer.

The start sequence: what I2C can and cannot do

Frame start is a register write, because the modules bring no start-of-frame pin out. The reliable sequence: switch the mux to a camera, write the full mode register set, move to the next; and only after all cameras are programmed, write the release bit to each in turn. If you release camera one before programming camera two, camera one is already exposing frames, and your skew absorbs the entire programming pass.

Each three-byte write is 29 bit slots on the wire — start, address byte, register byte, data byte, three acknowledgements, stop — which at 400 kHz costs 29 × 2.5 µs ≈ 73 µs. A mux channel change adds a two-byte write, about 50 µs. Eight cameras in sequence therefore span roughly 8 × 125 µs ≈ 1 ms from first write to last.

That skew is a fixed offset, not a drift. Once released, every sensor counts the same clock, so the 1 ms offset repeats identically frame after frame. At 30 fps — a 33.3 ms period — it is 3% of a frame. At a 200 fps mode — 5 ms — it is 20%, and it shows up as position disagreement between cameras on anything that moves. Below 30 fps with static or slow parts, ship it. Faster than that, correct the offset from frame timestamps on the host, or move to the trigger schemes at the end of this guide.

Worked example: eight 1080p cameras through a four-lane receiver

Start from the wire, because lanes decide feasibility before I2C does.

One 1920×1080 camera at 30 fps in RAW10: 1920 × 1080 = 2,073,600 pixels per frame; × 30 fps = 62.2 Mpx/s; × 10 bit = 622 Mbit/s. Over two lanes that is 311 Mbit/s per lane, so the D-PHY clock runs at 155.5 MHz — comfortably inside the 80–1000 MHz clock range that camera-side MIPI links are built around.

Eight such cameras into one 4-lane receiver through virtual channels: 8 × 622 Mbit/s ≈ 4.98 Gbit/s aggregate, so each lane carries 1.24 Gbit/s and its clock sits at 622 MHz. Legal on paper. Before committing layout time, check your receiver's documented per-lane maximum and hold back 5–10% for CSI-2 packet overhead. Most compute modules bring a fixed lane count to the connector — eight lanes is typical, arranged as two 4-lane or four 2-lane ports — so confirm the split before assuming this aggregation is even available.

Now the 200 fps case. Scaling the same mode to 200 fps raises one camera to 62.2 Mpx/s × 200/30 = 415 Mpx/s, which is 4.15 Gbit/s; eight cameras demand 33.2 Gbit/s. Four lanes at the 2 Gbit/s per-lane ceiling of a 1 GHz clock carry 8 Gbit/s — short by a factor of four. Splitting across two 4-lane ports still needs 4.15 Gbit/s per lane, twice the ceiling. No mux schedule or virtual channel trick fixes a lane-budget shortfall.

The fix is pixels, not topology. At 640 × 480 and 200 fps, each camera moves 307,200 × 200 × 10 = 614 Mbit/s — the same wire load as 1080p at 30 fps — and eight of them need 4.9 Gbit/s, the budget the 1080p30 set already fit. Frame rate is nearly free on the wire; pixels are what you pay for. Size your own modes with the lane-and-data-rate arithmetic in the MIPI CSI-2 frame rate estimation guide.

What each sync scheme buys you

Four schemes cover every build you are likely to draw. The first row is what you get by doing nothing; the last is what measurement-grade builds need.

The third row is the workhorse: the shared clock guarantees the offset never grows, and timestamp alignment trims what remains. The host-side alignment pattern is worked through in the guide to IMX219 and IMX477 on Jetson: built-in driver support and stereo sync; the same pattern applies on any host that timestamps frames as they arrive.

Checks before you route the carrier board

Five checks, in order, before you commit a board revision:

• Probe the bus with one sensor enabled: expect 0x10, accept a 0x1A variant, never assume.
• Measure the clock at each sensor pin, not just at the oscillator: the constraint is 6–27 MHz where the sensor sits.
• Read back a volatile status register after every write; a write that silently fails behind a mux is the standard multi-camera failure.
• Budget the lanes with the worked example above plus 5–10% packet overhead, before routing rather than after.
• Run all eight cameras for ten minutes and compare frame counters: with one shared clock they must advance in lockstep, and any divergence tells you the clock is not common yet.

When I2C sync is the wrong tool

Three cases should send you to a different architecture rather than a better mux schedule. Stereo depth and photogrammetry need agreement far below a millisecond, because disparity error scales directly with time offset. Width, gap and profile gauges on conveyors above roughly 100 mm/s turn 1 ms of skew into 0.1 mm of measurement smear. And any 200 fps build that fails the lane arithmetic above needs fewer pixels or a different transport regardless of sync method.

Cameras on GigE and USB3 transports take a hardware trigger line, so frame start moves from a register write to a wire. The input side is covered in the guide to wiring an opto-isolated camera trigger input, and the pattern of driving two cameras from one frame-grabber trigger carries over directly.

The MV-CB016-10GM-M-W pairs a 1/2.9" global-shutter sensor with GigE and an M12 mount; the LS-BCM-0003 runs a 3.1 MP global-shutter sensor at 120 fps over USB3. Either replaces a mux-plus-timestamp schedule with one wired pulse. A rig on moving carriers also needs drag-chain-rated cabling, which is what the camera cables category filters for:

The decision, per build

Commit by case. Static or slow parts at up to 30 fps: shared clock, mux, sequential release — ship it, the 1 ms skew is invisible at that pace. Moving parts between 30 and 200 fps: the same hardware plus mandatory host timestamp alignment, and if the lane budget fails, cut pixels per camera — the 640 × 480 example fits where 1080p does not. Stereo, photogrammetry, or tolerances near 0.1 mm: buy trigger-capable cameras and hand each one a wire; stop scheduling registers.

For hardware: browse the board-level cameras and area scan cameras categories, run the camera configurator when you want the system matched step by step, or filter the camera finder when you already know the spec. If a build sits between the two architectures, the contact page puts the applications team on it before you order boards. The camera guides topic page collects the rest of the integration material, including the frame-rate and pipeline guides.