NewPing Library: HC-SR04, SRF05, SRF06, DYP-ME007, Parallax PING))) - v1.7

karan2012singh:
hii,..i m using hc-sr04 ultrasonic sensor,..i m using the lastest version of ping,...all my connections are fine,,... and the code i m running is..
// ---------------------------------------------------------------------------
// Getting a reliable ping every 50 milliseconds isn't possible with other ping or ultrasonic libraries.
// These kinds of speeds work perfectly with the NewPing library. Even at the maximum sensor distance of
// 500cm, distance measurements can be done 20 times a second! If you set the maximum distance to 200cm
// as we have in this example sketch, even faster pings can be achieved. I suggest waiting at least 37
// milliseconds between pings to avoid previous ping echo issues, that translates to a maximum ping rate
// of around 27 times per second. Much better than the sometimes 1 ping a second with other libraries.
//

#include <NewPing.h>

#define TRIGGER_PIN 12 // Arduino pin tied to trigger pin on ping sensor.
#define ECHO_PIN 13// Arduino pin tied to echo pin on ping sensor.
#define MAX_DISTANCE 200
// Maximum distance we want to ping for (in centimeters). Maximum sensor distance is rated at 400-500cm.

NewPing sonar(TRIGGER_PIN, ECHO_PIN, MAX_DISTANCE); // NewPing setup of pins and maximum distance.

unsigned int pingSpeed = 50; // How frequently are we going to send out a ping (in milliseconds). 50ms would be 20 times a second.
unsigned long pingTimer = 75; // Holds the next ping time, start at 75ms to give time for the Arduino pins to stabilize.

void setup() {
Serial.begin(115200); // Open serial monitor at 115200 baud to see ping results.
}

void loop() {
// Notice how there's no delays in this sketch to allow you to do other processing in-line while doing distance pings.
if (millis() >= pingTimer) { // pingSpeed milliseconds since last ping, do another ping.
pingTimer += pingSpeed; // Set the next ping time.
Serial.print("Ping: ");
int cm = sonar.ping_cm(); // Send out the ping, get the results in centimeters.
Serial.print(cm); // Print the result (0 = outside the set distance range, no ping echo)
Serial.println("cm");
}
}
and the output coming is..
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
and continue....
i dont know why,..the sensor is just giving this output
plzz help

Try connecting it to pins 5 and 6 instead of 12 and 13. Also, is there a clear shot in front of your sensors? No wires or stuff in the way? Sensor at the edge of your breadboard? A user sent me a sensor that experienced the same problem on his Arduino, but on mine it works just fine. So, I'm starting to think it's how it's being wired or what the environment is.

Tim

Human:
I'm still amazed you're volunteering to do this :slight_smile: That's dedication!

Can't get your sensor to fail. Works perfect no matter what I try (works better than my 3 semi-working sensors). See my private message to start from the begining as we must be missing something basic here.

Tim

I don't mind posting this in public, since it may benefit others, but I was accidentally using a Duemilenove (2009) board instead of an Uno R3 :blush:

With the 2009 board, the sensor will send a ping, and status output goes to the serial port, but the distance reported is always 0cm. Swapping out the board for an Uno R3 makes it all work with NewPing, and the 2009 board works fine with the code I linked to. I assume that it's something about how NewPing compiles for the 2009's architecture.

I don't know why the 2009 board would have this issue, but at least this explains why my HC-SR04 appeared to be acting strangely.

To sum up:

2009 + NewPing + HC-SR04 = 0cm always
2009 + NewPing + HY-SRF05 = 0cm always
2009 + primitive code + HC-SR04 = works
2009 + primitive code + HY-SRF05 = works
UnoR3 + NewPing + HC-SR04 = works
UnoR3 + NewPing + HY-SRF05 = works
UnoR3 + primitive code + HC-SR04 = works
UnoR3 + primitive code + HY-SRF05 = works

Human:
I don't mind posting this in public, since it may benefit others, but I was accidentally using a Duemilenove (2009) board instead of an Uno R3 :blush:

With the 2009 board, the sensor will send a ping, and status output goes to the serial port, but the distance reported is always 0cm. Swapping out the board for an Uno R3 makes it all work with NewPing, and the 2009 board works fine with the code I linked to. I assume that it's something about how NewPing compiles for the 2009's architecture.

I don't know why the 2009 board would have this issue, but at least this explains why my HC-SR04 appeared to be acting strangely.

To sum up:

2009 + NewPing + HC-SR04 = 0cm always
2009 + NewPing + HY-SRF05 = 0cm always
2009 + primitive code + HC-SR04 = works
2009 + primitive code + HY-SRF05 = works
UnoR3 + NewPing + HC-SR04 = works
UnoR3 + NewPing + HY-SRF05 = works
UnoR3 + primitive code + HC-SR04 = works
UnoR3 + primitive code + HY-SRF05 = works

I guess this is good news, as before it was quite a mystery. My guess is that the Duemilanove 2009 board is somehow different with port registers. Since NewPing uses all port register access and the primitive code uses all built-in high-level pin access commands the two are quite different. Did the Duemilanove 2009 come in both ATmega168 and ATmega328? Which do you have?

Tim

teckel:
I guess this is good news, as before it was quite a mystery. My guess is that the Duemilanove 2009 board is somehow different with port registers. Since NewPing uses all port register access and the primitive code uses all built-in high-level pin access commands the two are quite different. Did the Duemilanove 2009 come in both ATmega168 and ATmega328? Which do you have?

Reading the chip silkscreening itself indicates that it's an ATmega328, which is consistent with the behavior in the IDE.

Human:

teckel:
I guess this is good news, as before it was quite a mystery. My guess is that the Duemilanove 2009 board is somehow different with port registers. Since NewPing uses all port register access and the primitive code uses all built-in high-level pin access commands the two are quite different. Did the Duemilanove 2009 come in both ATmega168 and ATmega328? Which do you have?

Reading the chip silkscreening itself indicates that it's an ATmega328, which is consistent with the behavior in the IDE.

So, the exact same processor as the Uno, darn... I'm thinking that I'll create a couple different test libraries if you're willing to try each. Probably one that replaces the ping echo detection with pulseIn to isolate the problem, then a few variations that do it a little differently.

Let me know if you're willing to do this, should be really quick and simple.

Tim

teckel:
So, the exact same processor as the Uno, darn... I'm thinking that I'll create a couple different test libraries if you're willing to try each. Probably one that replaces the ping echo detection with pulseIn to isolate the problem, then a few variations that do it a little differently.

Let me know if you're willing to do this, should be really quick and simple.

Even if it's not quick and simple, I'd be happy to help.

Hello Teckel.

First of all thanks a mil for your library I think is a lot of job and you are really kind sharing it with us.

I'm new to arduino and I have recently acquired a HC-SR04 sensor and I have donwloaded and installed your library for a test that I'm doing.

This is the little sketch that I'm running and I don't know if it's because I did something wrong but from time to time the sensor returns a 0 value.

#include <NewPing.h>

#define TRIGGER_PIN  7  
#define ECHO_PIN     6  
#define MAX_DISTANCE 200 

NewPing sonar(TRIGGER_PIN, ECHO_PIN, MAX_DISTANCE); 
int Range=200;
boolean Alarm=false; 
int Counter = 1;
void setup() {
  Serial.begin(9600); 
}

void loop() {
  
  Range = sonar.ping_cm();
 
delay(20);
  
  if (Range < 10) { 

    Alarm = true;   
    Counter = 1;    
  }
  else if (Counter == 11) { 
    Alarm = false;          
    Counter = 1;
  }
  
  if (Alarm)
    AlarmOn();
  
}

void AlarmOn(){
Serial.print("Intruso en:");  
Serial.println(Range); 
Serial.print("Valor del contador:");  
Serial.println(Counter);  
  Counter++;
  
}

looking at the serial output I see that from time to time the sensor gets a 0 value and I don't know if it's a problem with my sketch or with the sensor itself...

Valor del contador:8
Intruso en:40
Valor del contador:9
Intruso en:40
Valor del contador:10
Intruso en loop:0
Intruso en:0
Valor del contador:1
Intruso en:39
Valor del contador:2
Intruso en:39
Valor del contador:3

I hope you can help thanks :wink:

piratadelestrecho:
from time to time the sensor gets a 0 value

This seems to be an issue inherent to this family of sensors. I have worked with two HC-SR04s and one HY-SRF05, and each of them sometimes throws anomalous results. I have applied a "digital filter" to compensate for this behavior. Basically, wait for N similar results in a row before trusting the value. The sensors do lie occasionally, and your code should compensate for that.

Thanks for the reply @Human, I was thinking to use one of this as an alarm sensor for intruders but apparently these sensors doesnt seem very trustful :slight_smile:

Regards,

piratadelestrecho:
Thanks for the reply @Human, I was thinking to use one of this as an alarm sensor for intruders but apparently these sensors doesnt seem very trustful :slight_smile:

You may still be able to do this, depending on the distance to your target. Specs for these sensors claim a 400cm range, but it doesn't seem that anyone is getting that. 100cm seems to be the max usable range.

In my case, my digital filter works very reliably. You need to find the settings that work best for your specific sensor, but in my current build, I poll every 500ms and I believe in-range values if there are 2 in a row, and I believe out-of-range values if there are 7 in a row. If your application doesn't require immediate response, then you could go this route.

Also, try not to use 0cm as the trigger for anything, since that's also considered out of range. (If you look at the sensor and see the emitter and receiver, it makes sense why you can't actually measure 0cm with it, so 0cm is never going to be a real distance.)

piratadelestrecho:
Thanks for the reply @Human, I was thinking to use one of this as an alarm sensor for intruders but apparently these sensors doesnt seem very trustful :slight_smile:

Regards,

First, do you know that the NewPing library returns a value of "0" (all clear) when it doesn't detect anything? So, a zero means that there's nothing within the range you set (in your sketch that would be 200cm). It doesn't appear that your sketch is considering this. Therefore, maybe your alarm if statement should be:

if (Range > 0 && Range < 10) {

Secondly, a delay of only 20 milliseconds is too short, you could get an echo from a previous ping. Try changing your delay to 50 and see if that helps. You probably shouldn't ping faster than once every 29ms.

Tim

teckel:

piratadelestrecho:
Thanks for the reply @Human, I was thinking to use one of this as an alarm sensor for intruders but apparently these sensors doesnt seem very trustful :slight_smile:

Regards,

First, do you know that the NewPing library returns a value of "0" (all clear) when it doesn't detect anything? So, a zero means that there's nothing within the range you set (in your sketch that would be 200cm). It doesn't appear that your sketch is considering this. Therefore, maybe your alarm if statement should be:

if (Range > 0 && Range < 10) {

Secondly, a delay of only 20 milliseconds is too short, you could get an echo from a previous ping. Try changing your delay to 50 and see if that helps. You probably shouldn't ping faster than once every 29ms.

Tim

Thank you @teckel after ignoring the 0 values, it's working perfectly!

Human:

teckel:
So, the exact same processor as the Uno, darn... I'm thinking that I'll create a couple different test libraries if you're willing to try each. Probably one that replaces the ping echo detection with pulseIn to isolate the problem, then a few variations that do it a little differently.

Let me know if you're willing to do this, should be really quick and simple.

Even if it's not quick and simple, I'd be happy to help.

As I can't attach files to private messages, I'm going to post test libraries to this thread. Everyone keep in mind that the official release library is always downloaded from the Google Project Hosting site, not this forum. The attached library is not an enhanced version, it actually is removing features for testing purposes only.

First off, here's the short and sweet sketch we'll be using for the tests:

#include <NewPing.h>
#define trigPin 12
#define echoPin 11
NewPing sonar(trigPin, echoPin);

void setup() {
  Serial.begin(115200);
}

void loop() {
  Serial.print(sonar.ping());
  Serial.println(" uS");
  delay(100);
}

Find the attached "NewPingTestA.zip" library and replace the existing NewPing.* files in your libraries/NewPing folder. The only thing that Test A does is replace the echo measuring with the default pulseIn command. Because you stated you can hear the sensor firing, we're going to first assume that the trigger is happening correctly and the problem is with measuring the echo. This first test should isolate the problem where we can then focus in on one area.

Let me know what happens.

Tim

NewPingTestA.zip (5.76 KB)

teckel:
Find the attached "NewPingTestA.zip" library and replace the existing NewPing.* files in your libraries/NewPing folder. The only thing that Test A does is replace the echo measuring with the default pulseIn command. Because you stated you can hear the sensor firing, we're going to first assume that the trigger is happening correctly and the problem is with measuring the echo. This first test should isolate the problem where we can then focus in on one area.

Let me know what happens.

I still hear a bunch of ticks, and I mostly get "0 uS" output over and over again. Now and then, nonzero values appear:

7494 uS
...
41944 uS
...
8251 uS
...
26104 uS

I haven't found a pattern yet that can make it produce nonzero output.

piratadelestrecho:
Thank you @teckel after ignoring the 0 values, it's working perfectly!

This may not be sufficient. I've seen valid, in-range values (nonzero) reported by the HC-SR04 when nothing was in range. You could get false positives if all you do is ignore 0cm distances.

Human:

teckel:
Find the attached "NewPingTestA.zip" library and replace the existing NewPing.* files in your libraries/NewPing folder. The only thing that Test A does is replace the echo measuring with the default pulseIn command. Because you stated you can hear the sensor firing, we're going to first assume that the trigger is happening correctly and the problem is with measuring the echo. This first test should isolate the problem where we can then focus in on one area.

Let me know what happens.

I still hear a bunch of ticks, and I mostly get "0 uS" output over and over again. Now and then, nonzero values appear:

7494 uS

...
41944 uS
...
8251 uS
...
26104 uS




I haven't found a pattern yet that can make it produce nonzero output.

Interesting... Find the attached TestB - TestE libraries and test with the same sketch. Each of these make slight changes and all work with the Uno. Let me know if you start getting correct results (objects several inches from the sensor should give results in the hundreds). It's still possible that none of these work for you, and if so that REALLY limits what the issue is, and I have a TestF library already ready to go.

Tim

NewPingTestB.zip (5.82 KB)

NewPingTestC.zip (5.82 KB)

NewPingTestD.zip (5.83 KB)

NewPingTestE.zip (5.82 KB)

teckel:
Interesting... Find the attached TestB - TestE libraries and test with the same sketch. Each of these make slight changes and all work with the Uno. Let me know if you start getting correct results (objects several inches from the sensor should give results in the hundreds). It's still possible that none of these work for you, and if so that REALLY limits what the issue is, and I have a TestF library already ready to go.

A rebuild with each version (exit Arduino IDE; unzip a test version of NewPing inside ~/sketchbook/libraries/NewPing/; run IDE; load test sketch; upload to Duemilanove; open serial monitor) still outputs 0 uS, regardless of whether or not something is close to the sensor. I can run each version for more time to see if I get any nonzero times, but I thought I'd report these results sooner rather than later.

I'm pretty sure my steps will explicitly re-build the NewPing library each time, but maybe I need to touch the sources, too.

Human:

teckel:
Interesting... Find the attached TestB - TestE libraries and test with the same sketch. Each of these make slight changes and all work with the Uno. Let me know if you start getting correct results (objects several inches from the sensor should give results in the hundreds). It's still possible that none of these work for you, and if so that REALLY limits what the issue is, and I have a TestF library already ready to go.

A rebuild with each version (exit Arduino IDE; unzip a test version of NewPing inside ~/sketchbook/libraries/NewPing/; run IDE; load test sketch; upload to Duemilanove; open serial monitor) still outputs 0 uS, regardless of whether or not something is close to the sensor. I can run each version for more time to see if I get any nonzero times, but I thought I'd report these results sooner rather than later.

I'm pretty sure my steps will explicitly re-build the NewPing library each time, but maybe I need to touch the sources, too.

You should see the compiled size change slightly with each test library. That's a good indicator that it's using a different library.

See the attached TestF library also.

Tim

NewPingTestF.zip (5.82 KB)

The test run I did earlier today isn't valid because I didn't notice the pin changes between the last test sketch and this one. (echo pin changed from 13 to 11). After making that change, I am seeing distances being reported in the test library versions that I tried. I wonder if there's a problem using pin 13 because it's also for the built-in LED.

I have to stop for today, but I tried NewPing 1.3 with this configuration, and I'm seeing distances there, too. I need to make sure I can consistently get results, but in the meantime, I'll investigate and see if I can try to make it fail again.