HC-SR04 inconsistent readings above 55CM using NewPing and Ultrasonic libraries

Hi all,

I have a HC-SR04 which seems to give inconsistent readings when the distance goes over 55cm. It’s mounted on a robot but I see the issue when just running the ultrasonic pinging with the Arduino powered via USB as well. I’ve tried the “traditional” approach to pinging documented in the learning section of this site and the newping library as well.

The fluctuations happen just when the robot starts sensing distances > 55CM and I can see it go from a steady “54, 54 ,54 ,54” to “49, 0, 82, 57, 45”

Does anyone have any suggestions on how to compensate for or eliminate this issue? I’d be happy with a method to just return 55cm once it goes above this distance, however I have no idea if this is possible as it will sometimes return a lower number when the distance is higher.

I’ve tried with two different sensors, both have the same results. The setup is as shown in the sketch with +5v and GND being supplied by a rail I extended from the arduino 5v and ground pins

Sample sketch – (As I said I’ve tried several)

#include <NewPing.h>

int trigPin=52;
int echoPin=53;
int MAX_DISTANCE=100;
int running = 0;

NewPing sonar(trigPin, echoPin, MAX_DISTANCE);


void setup()                    // run once, when the sketch starts
{
  Serial.begin(115200);      
}


void loop() {
 
 delay(1000);
 unsigned int uS = sonar.ping();
 Serial.print("Ping: ");
 Serial.print(uS / US_ROUNDTRIP_CM);
 Serial.println("cm"); 
}

Sample output -

Ping: 57cm Ping: 56cm Ping: 58cm Ping: 58cm Ping: 93cm Ping: 56cm Ping: 55cm Ping: 56cm Ping: 57cm Ping: 0cm Ping: 52cm Ping: 56cm Ping: 55cm Ping: 57cm Ping: 9cm //put my hand in front of the sensor here Ping: 9cm Ping: 9cm Ping: 9cm Ping: 10cm Ping: 12cm Ping: 10cm Ping: 9cm Ping: 9cm Ping: 9cm Ping: 10cm Ping: 9cm Ping: 10cm Ping: 10cm Ping: 0cm //removed my hand

Can you tell something about the material used?
is it absorbing or not?
Does it occur with all materials tested?

Further investigation shows similiar issues with a sharp ir rangefinder being powered from the same rail. Is my issue the way in which I ran this 5v and gnd from the arduino? I connected a 5v pin to one line of pins and the gnd to another line of pins and I feed my sensors from this rail

robtillaart: Can you tell something about the material used? is it absorbing or not? Does it occur with all materials tested?

I'm using books or my hand for testing. It does occur with all materials tested and also seems to affect a sharp ir sensor. I'm thinking that I probably have an issue with my 5v rail ( described above). Any tips would be greatly appreciated

where you bought the sensor ?dx.com?

No it was from an ebay seller in hong kong

I had a similar problem with my hc-04. It was inconsistant when powered by USB but worked fine powered by a 9v battery to the power input on the board. I found that the hc-04 really needs 5v minimum. It was getting 4.8 v from USB.

liomry: Further investigation shows similiar issues with a sharp ir rangefinder being powered from the same rail. Is my issue the way in which I ran this 5v and gnd from the arduino? I connected a 5v pin to one line of pins and the gnd to another line of pins and I feed my sensors from this rail

Keep in mind that you set the max distance to 100cm. Any reading beyond 100cm will return a zero (0) result. For testing, you may want to set the max distance to 500cm (or leave blank and it defaults to 500cm). You should only set a max distance if you really need to set it. For example, you don't want to measure beyond a certain point, your sketch needs to do a bunch of other processing so you need it to timeout quickly, etc. For "hello world" and testing, you should always either set the max distance to 500 or not set it at all (defaulting to 500cm). Also, using a delay of at least 100ms (1000ms is even better as you have) while testing, especially if you're having a problem.

Many times, there isn't a problem, it's just that it's not returning what you would expect, because you've unknowingly set it up that way.

Tim