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

I put my HC-SR04 sensor in the mail to Tim today. Hopefully it'll tighten the test cycle and benefit others who have HC-SR04 sensors. :slight_smile:

My backup HC-SR04 is definitely less reliable than the one I shipped out, but it still "works" (for some value of "work"). I have digital filters in place to try to determine if a reading is true or not, so this mitigates the inherent issues with the sensor.

My code base can also create a virtual sensor from N actual sensors, and I was planning to do this to work around the unreliability, since it seemed unlikely that two sensors would be unreliable at the same moment in time (unless there are common environmental or power factors that cause this). If the HY-SRF05 is more reliable, then I can probably start trusting the data more and tune the digital filters to be more lenient.

Is there any demand for virtual sensors as I described? If so, I can work on turning what I have into a subclass of NewPing. It sounded like other people are using multiple sensors in non-redundant ways, and if the reliability solution really is "just buy an HR-SRF05" then maybe that effort would be wasted.

Human:
I put my HC-SR04 sensor in the mail to Tim today. Hopefully it'll tighten the test cycle and benefit others who have HC-SR04 sensors. :slight_smile:

My backup HC-SR04 is definitely less reliable than the one I shipped out, but it still "works" (for some value of "work"). I have digital filters in place to try to determine if a reading is true or not, so this mitigates the inherent issues with the sensor.

My code base can also create a virtual sensor from N actual sensors, and I was planning to do this to work around the unreliability, since it seemed unlikely that two sensors would be unreliable at the same moment in time (unless there are common environmental or power factors that cause this). If the HY-SRF05 is more reliable, then I can probably start trusting the data more and tune the digital filters to be more lenient.

Is there any demand for virtual sensors as I described? If so, I can work on turning what I have into a subclass of NewPing. It sounded like other people are using multiple sensors in non-redundant ways, and if the reliability solution really is "just buy an HR-SRF05" then maybe that effort would be wasted.

Can't wait to get the sensor and figure out what's going on. I hope to test and send back ASAP.

With properly working sensors, a virtual sensor from multiple sensors should not be required. Sensors that actually work are very reliable and give consistent and accurate readings all the time. I also have sensors that "work" but are clearly not 100% functional (this is with any library). Mine having a problem seem to work to around 50cm, then get all wonky.

While I find that my SRF05 and SRF06 are more reliable, online I've also found at least two totally different kinds of SRF05 sensors. Both have the same model number on them, but each are electronically different with different pinouts. So, I don't want to totally endorse the SRF05 as superior, as it appears they're made my multiple manufactures with different specs. Which is probably why there's some HC-SR04 sensors that "work" and probably why the HC-SR04 sensors you have don't work with my library, as they're made by a bunch of different manufactures, with different specs or quality control.

Tim

teckel:
Can't wait to get the sensor and figure out what's going on. I hope to test and send back ASAP.

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

If you find that the SR04 that I sent you behaves significantly differently than the ones you have, I would be happy for you to keep it for regression testing purposes. (I could potentially help write a regression test, too, although I've never tried making one for an Arduino library, and it couldn't be fully automated due to its nature.) I have a spare SR04 anyway, and they're cheap enough that I could just order more if I wanted more.

teckel:
With properly working sensors, a virtual sensor from multiple sensors should not be required. Sensors that actually work are very reliable and give consistent and accurate readings all the time. I also have sensors that "work" but are clearly not 100% functional (this is with any library). Mine having a problem seem to work to around 50cm, then get all wonky.

The sensor I'm sending you works up to 100cm (I didn't try longer distances), but it occasionally throws in an outlier of some kind, whether it's an in-range but wrong value while something is in the sensor's range, an out-of-range value while something is in range, or an in-range value while nothing is in range. I agree that if a sensor is working properly, it shouldn't do this. My original idea was to use virtual sensors to combat inherent unreliability issues with these cheap sensors (much like RAID was created to create reliability out of unreliable cheap parts), but if there are reliable sensors in the same family for the same price, I think I should just use those :slight_smile:

teckel:
While I find that my SRF05 and SRF06 are more reliable, online I've also found at least two totally different kinds of SRF05 sensors. Both have the same model number on them, but each are electronically different with different pinouts. So, I don't want to totally endorse the SRF05 as superior, as it appears they're made my multiple manufactures with different specs. Which is probably why there's some HC-SR04 sensors that "work" and probably why the HC-SR04 sensors you have don't work with my library, as they're made by a bunch of different manufactures, with different specs or quality control.

Hmm. Any such variations with the SRF06 sensors?

Human:
Hmm. Any such variations with the SRF06 sensors?

It doesn't appear there's different types of SRF06 sensors. But, I wouldn't be surprised if there were multiple manufactures. Also, the SRF06 won't work using one pin unless you put a cap across the trigger and echo pins, and, even that doesn't work with the Teensy. The ability to use only one pin is a huge advantage as in many projects multiple sensors are used and pins can be in short supply. For that reason, I'd lean towards the SRF05, which for at least one manufacture is actually designed to be used with only one pin.

Tim

Human:

teckel:
Can't wait to get the sensor and figure out what's going on. I hope to test and send back ASAP.

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

If you find that the SR04 that I sent you behaves significantly differently than the ones you have, I would be happy for you to keep it for regression testing purposes. (I could potentially help write a regression test, too, although I've never tried making one for an Arduino library, and it couldn't be fully automated due to its nature.) I have a spare SR04 anyway, and they're cheap enough that I could just order more if I wanted more.

Got your sensor today and had to plug it in to see what happens. Connected to the Teensy 2.0, it works perfectly with both 2 and 1 pins. Don't have a connector on this computer to connect to the Arduino R3, but I'll try it tomorrow on my primary system. Turning out to be quite a good puzzle this is.

Tim

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

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)