Two image sensors with the same I2C address: bus options that work

You have one image sensor running on a custom board and a second, identical sensor to bring up — and both answer at the same I2C slave address, so the second device node collides with the first the moment it loads. Every dual-sensor design hits this wall, and it is electrical, not syntactic: a devicetree can describe buses, but it cannot make a chip deaf. Here you get the decision — a multiplexer or a second controller — the devicetree pattern for each, the arithmetic that says how far one bus scales, and the checks worth doing before the schematic freezes.

Why no devicetree edit can separate the sensors

An I2C controller reaches a device by its 7-bit slave address, so a device's full identity is the pair of bus plus address. Two identical sensors wired to the same SDA and SCL are, to the controller, one device: every register write lands in both chips, and on a read both chips drive the data line, so the controller clocks out a wired-AND mix of two answers.

The devicetree cannot change that, because the collision happens before software runs. What it can do — and this is the whole trick — is parent each sensor under a different bus node. Both hardware fixes below exist to give the devicetree two buses to point at.

Before either fix, one schematic check: some sensor data sheets expose an address-select pin that offers a second slave address. If yours has one, strap the two parts to opposite levels and you are finished — no mux, no second bus.

The decision in one table

Both fixes are standard, and the choice follows your pin budget rather than preference:

The mux is the general answer; the second bus is the cleaner one when the pins exist. Boards with a serializer/deserializer link have a third path of their own, further down.

Fix one: an I2C multiplexer and its devicetree

A TCA9548A is itself an I2C peripheral: it sits on your existing bus at its own slave address and switches eight downstream buses behind it. A working multi-level design runs a TCA9546A at 0x77 on i2c2, with further switches hanging on its channels. The kernel's mux driver registers every channel as its own I2C adapter, so the system sees eight buses where the schematic has one.

In the devicetree, the mux node goes under the parent bus with its compatible string — ti,tca9548a — and a reg holding the mux's own slave address. Beneath it, one child bus node per channel in use: channels 0 and 1 for two sensors. Each sensor node then sits under its channel node with its reg unchanged. You never edit the sensor's address — only its parent.

Match the channel nodes to the mux family. One team declared ti,tca9546 channel bindings under a ti,tca9548a mux, and their devices attached to the wrong channels — a lost bring-up day over one string. The e3333 (ov5693) reference camera board is the devicetree template teams copy for exactly this pattern. And if a mux misbehaves once duplicate-address parts hang off it, troubleshooting I2C multiplexer conflicts with duplicate-address sensors walks the failure tree.

Fix two: a second I2C controller

If the processor has a second I2C controller with free pins, wire sensor two's SDA and SCL to it — i2c6, say, while sensor one keeps i2c2. The devicetree is then two ordinary sensor nodes under two bus nodes, reg unchanged in both. Because a device is keyed by bus plus address, the same address on two buses is two distinct devices, and both driver instances bind cleanly.

This route buys what a mux cannot: both sensors take register traffic at the same time, a hung sensor drags down only its own bus, and no channel-select transaction sits in the path. It costs controller pins and a second set of pull-ups. With exactly two sensors and a spare controller, choose it first.

How far one bus scales

The counting is simple, and it sets your ceiling before you stack switches:

Worked example, two identical sensors both fixed at — call it — 0x1A on one controller:

• One TCA9548A turns the bus into 8 buses; sensors on channels 0 and 1 occupy 2 positions, and 6 channels stay free for other peripherals.
• Identical sensors cap at one per channel, since every channel reuses the same address. With n distinct addresses in the design, one mux carries n × 8 devices.
• Two mux levels — a root TCA9548A plus one on each of its 8 channels — give 8 × 8 = 64 channels for 9 addresses on the parent bus. A 7-bit bus offers 112 usable addresses (128 total minus 16 reserved), so channels run out long before addresses do.

Timing is not a constraint at these counts. I2C fast mode runs at 400 kHz; selecting a channel costs one control byte with start and stop — about 10 bits, roughly 25 µs — and you switch once per register burst, not per register. A 300-write mode change at four bytes a write (device address, two register bytes, one data byte, about 95 µs each) takes near 30 ms with or without the mux.

SERDES links: break the collision at the deserializer

When the sensors sit behind a serializer/deserializer link, register traffic rides the same cable as the video, and the natural place to split addresses is the deserializer's control side. SERDES chip sets commonly translate a remote device's I2C address to a unique local one before the host sees it; if yours covers both sensors, enable that translation and the mux is unnecessary. Where translation does not cover both, hang the mux on the deserializer's control bus, so the host addresses one remote sensor at a time.

When the answer is a module, not a mux

If the two sensors are the product rather than a means to it, the address problem has already been solved on someone else's board. A binocular module such as LS-BCM-0043 — 1.3 MP, USB3, 1280 x 1024 resolution — is two sensor channels behind one interface. A split-sensor board camera such as LS-BCM-0059, 1.0 MP mono over GigE, integrates both halves on one module. You trade sensor choice for bring-up time, which at low volumes is the right trade.

The opposite case is the custom board you are already laying out around one sensor each. There, board-level cameras put the sensor in your BOM without an enclosure: the MV-CB060-10UM-B is a 6 MP USB3 bare board on the IMX178, and the LS-BCM-0003 is a 3.1 MP USB3 board camera, IMX252, 120 fps, C-mount. Sensor choice by itself is covered in board level camera selection for embedded vision machines, and the bench bring-up sequence in the board camera evaluation checklist.

Two fixtured prototypes also want stands rather than tape: camera stands and slide stages hold two modules at matched working distances, and each USB3 or GigE module needs its own camera data cable rated for the length and flex class of the bench.

With control solved, the pixels are next. I2C carries registers only; the image data crosses on MIPI CSI-2 lanes or the module's USB3/GigE link, and two sensors streaming together hit host bandwidth before anything else. Multiple camera modules on one host: shared bus limits covers the host side, MIPI camera lane bandwidth: what limits frame rate the lane math, and CSI-2 multi-camera connection: compatibility checks the wiring checks.

Checks before the schematic freezes

• Both sensors' control pins on the same power rail, sequenced together — the warning above is why.
• Mux footprint beside the camera connector, with two spare channels routed to test pads for a third sensor later.
• Pull-ups: one pair on the parent bus and one pair on each populated downstream channel; downstream pull-ups are never shared across channels.
• Total bus capacitance inside the fast-mode 400 pF budget — short channel stubs, one or two devices each.
• Second-controller route: confirm the pins in the processor ball-out before layout starts, not after.
• Plan a per-channel bus scan at bring-up; the shared address should appear once per adapter, on its own channel.

The decision, case by case

• One controller, two or more identical sensors: TCA9548A mux, sensors on channels 0 and 1, sensor reg unchanged under its channel parent.
• Spare I2C controller with free pins: second bus — simplest devicetree, best fault isolation.
• Sensor data sheet offers an address strap: strap the parts apart; no extra silicon.
• Sensors behind a SERDES link: enable deserializer address translation first; add the mux only if translation does not cover both.
• The pair is the product: buy the binocular or split-sensor module.

When the sensors are chosen and only the wiring remains, the camera finder filters by sensor and interface, and free expert support comes with every order through the contact page.