Ultrasonic sensor HC-SR04 behavior with different Arduinos

Hi, I have a puzzle with the well known HC-SR04 ultrasonic sensor:

it works well with Arduino Duemilanove and measures distances up to ~10 ft but the same program and same sensor transferred to the other board, namely, RBBB with Atmega328 chip http://shop.moderndevice.com/products/rbbb-kit provide reliable measurements only up to 2ft distance. All the distances larger than 2ft are returned as 2ft.

I don't have a scope at the moment to check the signals so I'm trying to nail the problem down using common logic and common sense. I would have suspected the power source if pure Vcc was used in the HC-SR04 comparator and if the Vcc on the second board was smaller compared to the "reference" one but it's not the case.

If pulseIn returns this number of microseconds then it's either the hardware of the Arduino board that reacts to the false signal from the sensor or from somewhere else or the sensor itself that produces this signal based on what it thinks. Both scenarios do not look real to me since I can't figure out what causes the difference but it's what I observe. Replacing the sensor doesn't change anything, either: it works with one board and it doesn't work at distances larger than 2ft with another one.

What else it can be? Thanks for the ideas.

I assume there is different code involved, so it can be the default int size (8,16, 32bit) or just complete different logic, or anything roundiing errors etc.

Can you post the code of both?

both chips are Atmega328 and I use long variable for reading the pulseIn()
just to be on a safe side.

The code is as simple as it can be:

pinMode(UltraSonicPinIn , INPUT);

digitalWrite(UltraSonicPinOut, HIGH);
delayMicroseconds(100); // just played with that. 10 or 100 makes no difference
digitalWrite(UltraSonicPinOut, LOW);

Serial.print(" ");


add-on: occasionally the second board returns larger distances but it happens once in 100 readings. The only reason I'm writing that is to prove that there's no software limit like "int" size or something like that.

So you say it's not in the software which is very probably true as it is the same code on the same processor

duration=pulseIn(UltraSonicPinIn,HIGH,100000L); // ADD THE L as 100000 is a long what type is duration? --> posting the whole code still works the best! and please use the # button for tags! what type is distance?

That leaves the hardware. The fact that there is once in a hundred times a higher reading makes me think of bad contacts.

Can also be a problem with voltages, different platform different power. Can you measure if the sensor gets enough juice?

thanks for the comments and recommendations. The "duration" is long, the "distance" may be long or double, it doesn't change the result: the first board returns real distance while the second one stops measurements at 2ft distance.

I also thought about the power or contact issues. However, it's very unlikely that the contacts stop/start working precisely 4 milliseconds after the synchronizing pulse. The power, indeed, might be under suspicion.

The second board is powered either through the programmator (4.9v measured on the sensor) or from the 3.7v lithium battery. In both cases the power goes directly to the sensor bypassing the board. I didn't see any voltage drop while the circuit was working. However, I do not believe in mysteries and there should be some explanation that might become obvious when the signals are traced.

There hasn't been a picture of your both setups yet!

My personal experience? Sonic rangers suck up lots of juice when their pulses are activated. You need a large capacitor (I used 1uF) between power and ground near the sonic ranger if you run UltraSonicPinIn and UltraSonicPinOut next to these pins.

that sounds reasonable, thanks.

Indeed, the second board is stripped down to chip+crystal and doesn't have caps in power line while the "working" board has a power stabilizer with all filters and caps.

At least it won't harm to add one to eliminate this reason.

adding the cap has helped, thanks. The sensor is really sensitive to the quality of power line: if additional sinks are switched, the problem returns but now it's clear how to avoid it.

The ultrasonic transducer is a big power sucker. It's turned on only momentarily and then turned off quickly, and then repeat for 7 to 8 times. the di/dt is big on the power lines and that could flicker the power voltage or couple to their neighbors via induction with dB/dt (magnetic field changes with time), AKA cross talk. When I was a grad student, I observed this strange but straightforward physics law first hand. I was trying to control a power supply. The power supply was connected to resistive heaters so was a thermistor. They went down the same cable, which was not shielded. The thermistor is used as input for a PID temperature controller. I got the strange jump of power every now and then and the temperature was not stable. Then I realized the problem and used the shield inside the cable to shield the signal from the power lines. It worked nicely. Turned out, the thermistor reading was strongly affected by the power supply suddenly turning on or off and that affected the temperature reading and knocked the PID off balance. My experience, either use a capacitor or use shield around your sensors. The shield needs to be grounded.

Thanks for replying with problem solved.

I've turned this post into a blog post :)