# Two ultrasonic sensors read wrong together: crosstalk between them

> Fix ultrasonic sensors that disturb each other: fire them one after another with a short gap and avoid pointing them across each other.

Canonical: https://roboticsengineering.in/fix/ultrasonic-sensor-two-robots-interfere-crosstalk/ | Published: 2026-11-03 | Updated: 2026-11-04

**Trigger the sensors one at a time, with a short gap between them.**

## What the message means

Each sensor listens for any echo. If two fire together, one hears the other burst and reports a wrong distance.

## Fix it in this order

1. Trigger sensor one, read it, wait about 30 ms, then trigger sensor two.
2. Do not fire all of them in the same instant.
3. Aim the sensors so the beams do not cross at close range.
4. Take the median of a few readings.
5. Use a different sensor type, such as time-of-flight, if you need fast readings from many.

## Why it happens

Two ultrasonic sensors that work at the same frequency hear each other, so a sensor may read the echo or the ping of another one and report a false distance.

Fire sensors one after another with a pause between them, point them in different directions, discard readings that jump, and use a median filter. Using another sensing method on one robot also avoids the clash.

## If you see this, do this

| You see | Do this |
| --- | --- |
| Readings jump only when both run | Crosstalk. Fire in turns. |
| Jumps with one sensor | See the HC-SR04 page. |

## Related

[HC-SR04 reads 0 or random](https://roboticsengineering.in/fix/hc-sr04-reads-zero-or-random-values/), [echo voltage](https://roboticsengineering.in/fix/hc-sr04-echo-5v-to-esp32-voltage-divider/).

Last reviewed: November 2026. These are the usual causes and the order that finds them fastest. Test on your own board; clones and cables differ.

## Why this happens

A typical HC-SR04 sends a short burst at 40 kHz and then waits for an echo. It cannot tell whose burst it hears. If two sensors fire at the same moment, or the second fires while the first’s echo is still travelling, each can pick up the other’s sound and report a distance that does not match any real object.

The wait is easy to work out. Sound travels at about 343 m/s in air at 20 degrees C. For a 4 m maximum range the round trip is 8 m, which takes 8 / 343, or about 23 ms. A gap of 30 ms between sensors is therefore enough for the first echo to fade.

## How to confirm the cause

- Read each sensor alone for a minute and record the values. If each is stable alone, the hardware is good.
- Run both together and compare. Jumping values only in this case point to crosstalk.
- Cover one sensor with cloth. If the other becomes stable, the two interfere.
- Check the angles. Sensors that face each other, or a corner that reflects one beam into another, interfere even with timing separation.

## Worked example

This takes turns between two sensors with a pause. Pins 2 to 5 are an example. The divide by 58 converts microseconds to centimetres.

```
long readCm(int trig, int echo) {
  digitalWrite(trig, LOW);  delayMicroseconds(2);
  digitalWrite(trig, HIGH); delayMicroseconds(10);
  digitalWrite(trig, LOW);
  long t = pulseIn(echo, HIGH, 25000);  // 25 ms timeout
  return t == 0 ? -1 : t / 58;
}

void loop() {
  long a = readCm(2, 3);  delay(30);
  long b = readCm(4, 5);  delay(30);
  Serial.print(a); Serial.print(' '); Serial.println(b);
}
```

## Common mistakes

- Triggering both sensors in the same instant, to save time.
- Calling pulseIn with no timeout, so a missing echo blocks for a full second.
- Setting the gap shorter than the echo time of your maximum range.
- Mounting two sensors close together at the same angle, so each hears the other.

## If this did not fix it

- Check the median of three readings to remove single outliers.
- Check the echo level if you use a 3.3 V board; a 5 V echo needs a divider.
- Check for another robot nearby using the same kind of sensor.
- Check soft or angled objects, which reflect the sound away.