Multiple camera modules on one host: shared bus limits

Multi-camera carrier boards save space and wiring by putting two camera sockets on one shared I2C bus, and that choice has a consequence many teams meet late: identical camera modules with the same fixed address collide, and the host detects fewer cameras than you physically fitted. This article explains how shared control buses work, why two same-address modules cannot coexist on one bus, and how to plan addressing, multiplexing and host-side enumeration so every module comes up. It is for engineers building embedded vision machines from board-level camera modules who want a setup that survives a reboot, not just a bench test.

What the shared bus actually carries

A camera module needs two kinds of connection. The first is the image path: MIPI CSI lanes, or a USB3 or GigE link, which carries pixel data and is point-to-point. The second is the control path, and on board-level modules that path is almost always I2C: a two-wire bus with a clock line and a data line, on which the host addresses each device by a 7-bit address.

I2C is a shared bus by design. Every device on the same two wires hears every transaction, and only the device whose address matches responds. That is why a carrier can run one bus to two sockets: the wiring is cheaper, the connector is smaller, and the host needs fewer bus controllers. The trade-off is that the bus can hold only one device per address.

In practice you get far fewer usable slots, because common sensor modules ship with one fixed address each.

Why identical modules collide

Two modules with the same fixed 7-bit address on one bus produce a well-defined failure. When the host sends the address, both modules try to drive the data line. If their answers differ even by one bit, one drives the line high while the other drives it low, and the bus reads low. The controller may report an unexpected acknowledge, a bus timeout, or a device that answers with a corrupted register value.

The visible symptom at the application level is exactly what a bus conflict looks like: some sockets come up and others do not, and which ones work follows the bus pairing rather than the module. Swap modules between sockets and the working sockets stay the working sockets. That is the diagnostic signature. If moving a module changes nothing and moving nothing changes everything, suspect the bus map, not the hardware.

For a worked example of the failure mode at the electrical level, this article on resolving I2C acknowledge failures on a shared bus walks through how a controller reports the conflict.

Map your sockets before you order modules

Treat the carrier board as a small network you must survey. The procedure takes an hour and prevents weeks of swapping.

1. Fit one module to one socket. Scan its bus from the host and record the address it reports.
2. Move the module to each other socket in turn, rescanning each time, and note which sockets share an address space.
3. Fit a second module to each candidate partner socket and check for collisions: garbled scans, timeouts, or the first module vanishing.
4. Write down the bus map as pairs, for example sockets A and B on bus 1, C and D on bus 2, E and F on bus 3.
5. Only then decide the module set: unique addresses per bus, or a multiplexer, or a different interface.

Many sensor modules offer a way out of a collision. Some expose an address-select pin or strap on the module PCB, some hold the address in a configuration register the host can rewrite once, and some have two fixed addresses selected by a connector key. Check the module documentation before concluding that a pair cannot coexist. The live article on image sensor detection and camera module connections covers the related single-module case where a module answers nothing at all.

Three ways to run more modules than addresses

Once you know the bus map, you have three standard designs.

Unique addresses per bus. The cleanest option when modules support it. Each bus carries two modules at different addresses, the host enumerates everything in one pass, and no sequencing logic is needed. The cost is that your module set may no longer be uniform: one module per socket position rather than one catalogue number everywhere.

An I2C multiplexer. A one-byte register device that connects one of its downstream buses to the host at a time. Two same-address modules can sit behind different channels, because only one channel is live during any transaction. The multiplexer itself takes one address on the upstream bus, and its downstream buses are fully isolated from each other. The cost is software: every access to a module must first select its channel, and startup code must walk the channels in order. Sequencing bugs look like random detection failures, so log the channel state alongside the scan results.

Separate host-side controllers or interfaces. If the host has several independent I2C controllers, assign one per socket pair and the collision question disappears. And if the control bus is the recurring headache, step up to cameras whose interface carries control and data together: each USB3 or GigE link is its own world, addressed by the port rather than by a 7-bit code.

What this means for interface choice

The collision problem is specific to bus-addressed control, which is why it rarely comes up with industrial interfaces. A GigE board camera or a USB3 module negotiates its own link, and the host addresses it by network identity or bus port, so a six-camera build is a port-count and bandwidth exercise rather than an addressing one.

If your design is compact and close to the host, a board-level module with GigE still gives you per-camera links inside a small form factor. A GigE board camera with an M12 mount suits tight multi-camera clusters where each socket needs its own identity.

Board-level cameras in the shop can be filtered by interface, shutter type and lens mount, which is the quickest way to see what a per-camera-link design costs in space and power.

For modules that genuinely must share a bus, address selection is the deciding spec, and it is worth confirming with the module supplier before a multi-unit order. The live article on board-level camera selection for embedded vision machines covers the wider choice of sensor, mount and interface for built-in cameras.

Where the modules feed a standalone vision controller rather than your own carrier, the host-side enumeration problem moves into the controller, and the design question becomes port count instead of bus map.

Vision controllers typically provide several independent LAN ports, so each camera keeps its own link and its own identity.

Enumeration: make the host see everything, every boot

Detection is not a one-time event; it happens at every power-up, and a design that works on the bench can fail in the enclosure if timing or order changes. Three habits make enumeration deterministic.

First, bring buses up in a fixed order and log the scan result per bus. If bus 2 always enumerates before bus 1 has finished, a shared supply rail or reset line may be sagging, and the log will show it as a pattern rather than a fluke. Second, after any multiplexer operation, verify the channel switch took effect before addressing the module: read back the mux register, then scan. Third, treat a partial enumeration as a fault condition, not a warning. If the design expects six modules, software should refuse to run production on three and report which sockets are missing; the diagnosis you did in the socket survey makes that report precise.

The same discipline applies to higher-level image faults: when several cameras misbehave at once, the shared infrastructure is the first suspect, as the article on multi-camera image corruption from shared hardware faults explains for the image path.

Checks before you commit to a multi-module design

• Bus map surveyed per socket, written down as pairs.
• Address plan that gives every module on a bus a unique 7-bit address, or a documented mux design.
• Multiplexer sequencing in code: select, verify, then address.
• Enumeration self-check that counts modules and names missing sockets.
• Reset and power sequencing verified with all modules fitted, not one.
• A defined fallback: which interface you move to if the module set cannot take unique addresses.

If the survey shows more collision pairs than your addressing options can absorb, the usual answer is wrong: rather than fighting the bus, move those sockets to cameras with independent links and solve a simpler problem. The camera finder filters board-level and enclosed cameras by interface and mount, and the system configurator steps through camera, lens, light and controller choices in order; if the parts do not line up, the contact page puts the question to the applications team.