Long I²C lines: slowing down before adding hardware

I²C is convenient on a bench and much less convincing when a sensor is a few metres away. One plant-shelf sensor produced occasional read errors after I replaced a short cable with a 2.7 m run. The first instinct was to add active interface hardware. Before doing that I measured what changed when the bus was simply made slower and less electrically sloppy.

Original wiring

The ESP32 used GPIO 21 for SDA and GPIO 22 for SCL. The remote board was an SHT31 module. Four conductors carried 3.3 V, ground, SDA, and SCL in a flat cable. Both signal lines had 10 kΩ pull-ups at the controller. At 400 kHz, a ten-minute test with one read per second produced between 12 and 40 failed transactions depending on how the cable was routed near the 24 V lighting wires.

I changed one variable at a time. First I reduced the bus clock. Then I replaced the flat cable with a pair arrangement: SDA next to ground, SCL next to ground, with power on a separate pair. Finally I changed the pull-ups.

The firmware change was trivial. The important part was making the selected clock explicit instead of trusting a library default:

Wire.begin(21, 22);
Wire.setClock(50000);

bool readSensor() {
  for (int attempt = 0; attempt < 3; ++attempt) {
    if (sht31.read()) {
      return true;
    }
    delay(20);
  }
  return false;
}

I did not add stronger pull-ups than 4.7 kΩ because the waveform was already clean enough at 50 kHz and I wanted to avoid unnecessary sink current. I also kept the retry logic even after the errors disappeared. A retry is cheap; pretending a long single-ended bus is permanently perfect is not.

The 2.7 m run has since completed several multi-day logs without a recorded read failure. That does not make long I²C universally safe. It only shows that this particular bus, cable, voltage, and environment became reliable enough after reducing edge-rate demands and giving each signal a better return path.