The i2c address collisions that actually bite
We recently added a batch of boards to the dataset and ran every address through the table. The clashes that fell out weren't the theoretical kind — they're the ones sitting in a drawer of parts you probably already own.
Why it happens
112 addresses, and everyone wants the same twelve
An i2c address is seven bits. That's 128 slots, and the spec reserves both ends — 0x00–0x07 and 0x78–0x7F — leaving 112 usable addresses from 0x08 to 0x77. That would be plenty if chip vendors spread out. They don't. Conventions calcified decades ago: power monitors cluster at 0x40, anything with a clock or a gyroscope lands on 0x68, displays sit at 0x3C, multiplexers own 0x70. So the real space isn't 112 wide — it's a dozen popular addresses with a queue of parts behind each one.
What makes this worse than a normal hardware conflict is the failure mode. Two devices on one address don't produce an error. Both ACK the address byte — and an ACK is just someone pulling SDA low, so two devices pulling it low looks identical to one. Then both drive data. The bus is open-drain, so a low always beats a high: what your host reads is the bitwise AND of two devices' answers. Not a crash. Just a number that's plausible and wrong.
The real ones
0x68 — the worst address on the bus
If one address deserves a warning label, it's this one. Every DS3231 real-time clock is at 0x68. So is every MPU-6050. So is the AMG8833 thermal camera on its alternate strap. These are three of the most common hobby parts in existence, and a clock plus a motion sensor is an extremely normal thing to want together — a datalogger, near enough by definition.
The MPU-6050 escapes: pull AD0 high and it moves to 0x69. But that's the AMG8833's default, so a Grid-EYE and an MPU can collide at either address. The DS3231 can't move at all. The practical order: strap the MPU to 0x69 if the AMG8833 isn't present, otherwise put the thermal camera behind a multiplexer and leave the clock and the gyro on the main bus. Both parts have their own walkthrough — the DS3231 tutorial and the MPU-6050 tutorial each cover this from their own side.
0x5A — three unrelated chips, one slot
This one surprised us during the audit. The DRV2605L haptic driver is fixed at 0x5A — no strap, no jumper, no software escape. The MLX90614 infrared thermometer is also at 0x5A. So is the MPR121 touch controller, and so is the CCS811 air sensor. Four chips with nothing in common except an address, and three of them are the kind of thing that ends up in the same project: a touch panel that buzzes when you press it, with a temperature readout.
Because the DRV2605L can't move, it wins by default — everything else has to go behind a mux or onto a second bus. Worth knowing before you design the PCB, not after.
0x3C — and the e-paper nobody expects
Every SSD1306 OLED is at 0x3C or 0x3D. So is every SH1106, which matters mostly because half the SH1106s are sold as SSD1306s. Fine — you rarely want two displays.
Except the Waveshare 1.9inch segment e-paper uses both 0x3C and 0x3D at once: one for commands, one for data. A low-power e-paper readout with a little OLED for debug output is a natural pairing, and it cannot work as-is. The e-paper has an alternate pair at 0x3E/0x3F — use it, or mux the OLED.
0x10 — a lidar and a light sensor
The TFmini Plus lidar answers 0x10. So does the VEML7700 ambient light sensor. Neither can be moved. A robot that measures distance and adjusts for ambient light is a completely ordinary build, and those two parts refuse to share a wire.
The sneaky one
0x70: the multiplexer's own address is contested
The fix for an address conflict is a TCA9546A or TCA9548A multiplexer, which lives somewhere in 0x70–0x77. That block is busier than it looks: HT16K33 LED backpacks are there, and DFRobot's SEN0322 oxygen sensor defaults to 0x70 exactly.
The one that catches people out is the PCA9685. Its own address is somewhere in 0x40–0x4F, so it looks unrelated — but NXP's datasheet is explicit that the LED All Call address (register ALLCALLADR) resets to 0xE0, which is 0x70 in 7-bit terms, and is enabled at power-up. Every PCA9685 on your bus answers 0x70 from the moment you power it, whether you asked or not. Put a servo driver and a multiplexer on the same bus with default settings and they fight, at an address neither one appears to use.
The fix is a one-liner: clear the ALLCALL bit in MODE1, or move the mux to 0x71–0x77. But you have to know it's happening, and a scan showing "0x70" gives you no clue which of the two answered.
Finding them
A scan won't tell you — here's what will
An i2c scan lists addresses that ACK. It cannot distinguish one device from two answering together, because the ACKs are electrically identical. So a bus with a hidden collision often scans perfectly.
Three things that do work. First, read a chip-ID register — most sensors have one, and a WHO_AM_I that matches neither datasheet is two devices ANDing their answers together. Second, unplug one and rescan: if an address survives, something else is on it. Third, if devices are behind a mux, remember they're invisible until their channel is open — a scan of an eight-sensor rig shows an empty bus, which people routinely misdiagnose as broken wiring.
The i2c tool covers all three: i <addr> does the chip-ID probe against nineteen fingerprints, and mux walks every multiplexer channel and reports what's behind each — listing the main bus separately, so you can see which device is actually where.
From the dataset
Who's on the contested addresses
Straight from our board data — every entry we hold that answers one of the addresses above.
| Address | Boards that answer it |
|---|---|
| 0x68 | MPU-6050, DS3231, AMG8833 |
| 0x5A | MLX90614, DRV2605L |
| 0x3C | SSD1306 OLED, SH1106 OLED, 1.9inch Segment e-Paper |
| 0x10 | VEML7700, TFmini Plus |
| 0x70 | TCA9546A, SEN0322 |
The full picture, every address and every board: the i2c address list. Already stuck with two chips that won't budge? The address-conflict guide ranks the four fixes by cost.
Questions
Address collision FAQ
Why do so many i2c chips share the same address?
Because the usable space is tiny and vendors pick from the same corner of it. Seven bits gives 128 slots, the spec reserves both ends, and you're left with 112 — from 0x08 to 0x77. Chip designers then cluster around habits: 0x40 for power monitors, 0x68 for anything with a clock or a gyro, 0x70 for multiplexers. The result is that a handful of addresses carry a dozen popular parts each.
What happens if two i2c devices have the same address?
Both answer the same address byte at once. Their ACKs overlap, then both try to drive data onto SDA — the low bits win because the bus is open-drain, so you get a bitwise AND of two readings rather than an error. That's the nasty part: it usually looks like one device returning plausible-but-wrong numbers, not a clean failure.
How do I find out which of my boards will clash before I buy?
Check each part's address before it arrives, not after. Our address list groups every board in the dataset by 7-bit address, so you can see at a glance that an AMG8833 and a DS3231 both want 0x68. If two parts you need collide, look for one with address-select pins — or plan on a TCA9548A multiplexer.
Can a scan find a device that's colliding?
Only partly. A scan shows which addresses ACK — it can't tell one device from two answering together, because both ACKs look identical on the wire. If a scan shows the right number of addresses but a sensor returns nonsense, suspect a collision. The tool's identify command helps: a chip-ID register read that returns a value matching neither datasheet is a strong hint two devices are talking over each other.
Does a multiplexer fix every address conflict?
Nearly. A TCA9548A gives each identical device its own isolated channel, so eight parts can keep one address. The catch is the mux itself lives at 0x70–0x77, which is a busy block — HT16K33 displays, DFRobot's O2 sensor and the PCA9685's all-call address are all up there. You can trade one conflict for another if you don't check first.