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

[teckel]

I wanted to add that I have a HC-SR04 that doesn't work with NewPing 1.2, 1.3, or the 1.4 pre-release, using either the Simple NewPing Example Sketch or the 15-sensor example, modified for 1 HC-SR04.  It works fine with the example code at http://goo.gl/kJ8Gl though.

How can I help debug the library for the HC-SR04?

EDIT: Forgot to add that I'm using an Arduino Uno r3 with the v1.0 Arduino IDE.

EDIT2: I get 0cm like everyone else with an HC-SR04 reported. I even tried getting the raw timing data instead, in case it was an obscure bug in the distance conversion. Everything I get is 0.

EDIT3: In case it's helpful, I note that I can hear the HC-SR04 sending out its sonar pings when I try NewPing. So I would guess that the bug doesn't involve actually sending out the pings.

I have (4) HC-SR04 sensors and they all work just fine with the Arduino Uno R3 using every library version of NewPing as well as every example sketch.  I've also run with Arduino 0023, v1.0 and have just switched to v1.0.1 all of which work.  So, I believe it's unfair to say "I get 0cm like everyone else with an HC-SR04 reported".  There's only a couple people that have reported a problem, it's running just fine for me with 4 different sensors, so not everyone is having a problem.

There's differences between my example sketches and the sketch at the link you provided.  For example, it's only doing 2 pings a second while my examples are typically doing 20 pings a second.  So, maybe your sensor can't ping that frequently.  To diagnose this, I've modified my example sketch to duplicate what that other example is doing.

Code: [Select]



#include <NewPing.h>

#define trigPin 12
#define echoPin 11

NewPing sonar(trigPin, echoPin);

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

void loop() {
 int distance = sonar.ping_cm();
 Serial.print(distance);
 Serial.println("cm");
 delay(500);
}

If this still doesn't work, it could be the VERY long trigger delay in the example you provided.  It's waiting 1000 microseconds when the sensor specs state it should only require 10 microseconds.  If your sensor is way out of spec, maybe it needs longer than 10 microseconds.  To change this in the NewPing library, look for the "delayMicroseconds(10)" in the NewPing.cpp file (line 48 in the 1.4 pre-release) and change it from 10 microseconds to 1000 microseconds.

If it still doesn't work, try changing the MAX_SENSOR_DELAY in the NewPing.h file from 18000 to 180000 (add a zero at the end).  This will give your sensor more time to finish the ping before waiting for the echo.  The longest I've ever measured is around a 17000 microsecond delay, but maybe your sensor requires longer.

If it's still not working for you, you could send me your sensor.  If I had the sensor, I could hopefully duplicate it and see what exactly is happening.  Of course, I'd send it back when I was done with the diagnosis.

Let me know what you find or if you want to send me the sensor for diagnosis.

Tim

[wrek]

HC-SR04 not working for me with the latest sketch.

[xerof]

Wow, I love the V1.4 with just the one pin required! - I started a project at the weekend, and solderd a long length of cable together, and at certain points only left 3 pins (+5,GND,Signal) - And it didn't work well. I was about to start chopping away at my cable to make room for another cable at each set interval untill I started reading this post again and noticed that about the v1.4 only needing one I/O pin, so you have saved me lots of work

I am using HR-S04 btw, and they seem to be working perfectly with the 1 pin v1.4

Cheers!

[teckel]

HC-SR04 not working for me with the latest sketch.

The HC-SR04 seem to be a real hit or miss in the quality department.  Or, there's several manufactures with different specs.  I have 4 of them, and they all work.

Try this, set MAX_SENSOR_DELAY in NewPing.h from 18000 to 180000 and in NewPing.cpp change "delayMicroseconds(10)" (line 48 in the 1.4 pre-release) to "delayMicroseconds(1000)".  And let me know if that changes anything.

Also, what Arduino hardware are you using and what sketches have you tried?

Tim

[Human]

Hi!  Thanks for your reply.

I have (4) HC-SR04 sensors and they all work just fine with the Arduino Uno R3 using every library version of NewPing as well as every example sketch.  I've also run with Arduino 0023, v1.0 and have just switched to v1.0.1 all of which work.  So, I believe it's unfair to say "I get 0cm like everyone else with an HC-SR04 reported".  There's only a couple people that have reported a problem, it's running just fine for me with 4 different sensors, so not everyone is having a problem.

You're right - it was a poor choice of wording. I didn't mean to imply that every HC-SR04 owner had the "0cm" bug. I was trying to say that I had the same "0cm" bug that was reported here by other HC-SR04 owners. And it's certainly hard to diagnose problems like this if your HC-SR04s aren't showing the problem. Did you get them all from the same vendor?

There's differences between my example sketches and the sketch at the link you provided.  For example, it's only doing 2 pings a second while my examples are typically doing 20 pings a second.  So, maybe your sensor can't ping that frequently.  To diagnose this, I've modified my example sketch to duplicate what that other example is doing.
...
If this still doesn't work, it could be the VERY long trigger delay in the example you provided.  It's waiting 1000 microseconds when the sensor specs state it should only require 10 microseconds.  If your sensor is way out of spec, maybe it needs longer than 10 microseconds.  To change this in the NewPing library, look for the "delayMicroseconds(10)" in the NewPing.cpp file (line 48 in the 1.4 pre-release) and change it from 10 microseconds to 1000 microseconds.

If it still doesn't work, try changing the MAX_SENSOR_DELAY in the NewPing.h file from 18000 to 180000 (add a zero at the end).  This will give your sensor more time to finish the ping before waiting for the echo.  The longest I've ever measured is around a 17000 microsecond delay, but maybe your sensor requires longer.

I will look at that. I tried this investigation from the other direction, modifying that sketch I provided to do 20 pings per second with a 10 microsecond trigger delay. It still works in that sketch. Those two timings do not appear to explain the difference in behavior with NewPing. I will try changing MAX_SENSOR_DELAY in NewPing to see if that is a factor.

If it's still not working for you, you could send me your sensor.  If I had the sensor, I could hopefully duplicate it and see what exactly is happening.  Of course, I'd send it back when I was done with the diagnosis.

I may be able to do that, since I did buy a second sensor to try to compensate for the HC-SR04's occasional lie. (Sometimes reports out of range value when there is *definitely* something in range; sometimes reports in-range value when there is *definitely* nothing in range.) I'll also try my second sensor to see if it does or doesn't have the problem, but it appears to be the same exact build, and it's from the same reseller (so it may even be the same batch). I'll report back what I find.

[Human]

If it still doesn't work, try changing the MAX_SENSOR_DELAY in the NewPing.h file from 18000 to 180000 (add a zero at the end).  This will give your sensor more time to finish the ping before waiting for the echo.  The longest I've ever measured is around a 17000 microsecond delay, but maybe your sensor requires longer.

I tried in the 1.4 pre-release code base with 180000 microseconds MAX_SENSOR_DELAY and a 1000 microsecond delay between triggering HIGH and letting the HC-SR04 see this, and there was no change in behavior.

Are you using all 4 pins on your HC-SR04s, or are you using 3? You mentioned a recent optimization where you could do trigger and echo on the same pin. I'm using all 4 pins. Could that be the difference?

EDIT: I tried this with my second HC-SR04, but it's likely out of the same batch.

[xerof]

I used 2 sensors with the 15 Sensor example sketch, and found that what I needed to do, it was too slow at picking up changes.

I reverted back to adding 2 seperate sensors, and doing 2 seperate checks, See code below:

Code: [Select]


#include <NewPing.h>


#define SONAR_NUM     2 // Number or sensors.
#define MAX_DISTANCE 200 // Maximum distance we want to ping for (in centimeters). Maximum sensor distance is rated at 400-500cm.


NewPing sonar_START(6,6, MAX_DISTANCE);
NewPing sonar_END(7,7, MAX_DISTANCE);

unsigned int pingSpeed = 30;  // How frequently are we going to send out a ping (in milliseconds). 50ms would be 20 times a second.
unsigned long pingTimer[2];                // +1 for timer that displays results.


void setup()
{
  Serial.begin(9600);
  pingTimer[0] = millis() + 50;
  pingTimer[1] = millis() + 100;
/* Delays the start up per sensor, as I want to know the distance when it first starts up from the object - Running them at the same time causes issues. */
}

void loop()
{
  if (millis() >= pingTimer[0]) {
    pingTimer[0] += pingSpeed;
    startCheck();
  }
  if (millis() >= pingTimer[1]) {
    pingTimer[1] += pingSpeed;
    endCheck();
  }
}


void startCheck()
{
  int cm = sonar_START.ping_cm();
//Doing some code here
}

void endCheck()
{
  int cm = sonar_END.ping_cm();
//Doing some other code here
}



The above method, works quicker and more reliable than using the code from the 15 sketch example with changing NUM_SONOR to 2

[teckel]

I used 2 sensors with the 15 Sensor example sketch, and found that what I needed to do, it was too slow at picking up changes.

I reverted back to adding 2 seperate sensors, and doing 2 seperate checks, See code below:

Code: [Select]

#include <NewPing.h>

#define SONAR_NUM     2 // Number or sensors.
#define MAX_DISTANCE 200 // Maximum distance we want to ping for (in centimeters). Maximum sensor distance is rated at 400-500cm.

NewPing sonar_START(6,6, MAX_DISTANCE);
NewPing sonar_END(7,7, MAX_DISTANCE);

...

The above method, works quicker and more reliable than using the code from the 15 sketch example with changing NUM_SONOR to 2

Well, it may be faster, but only at the expense of possible cross-sensor echo issues as you're sometimes pinging only 10ms apart. Your pings are at 50, 80, 100, 110, 130, 140ms (some of those are only 10ms apart).  You could make the 15 sensor sketch faster by simply changing the PING_INTERVAL value to 10ms, but unless the sensors are pointing in opposite directions, you very well could get cross-sensor echo issues.

Also, your sketch doesn't use the timer interrupt method, which will free up your sketch to run other tasks at the same time it's doing the ping.  Basically, the 15 sensor sketch is event-driven (multitasking) even during the ping process.  This is a far more preferred method of programming.  You could also simplify your sketch by keeping the two sensor objects in an array so you wouldn't need two different if statements and two different functions to process the results.

Below is a modified version of the 15 sensor sketch that just uses 2 sensors, is event-driven (uses the timer interrupt method), but still allows a user to easily change for more than 2 sensors.  It also displays each ping result individually as you wanted.  The ping times are 29ms apart, which shouldn't cause any cross-sensor echo issues.  If you want to make them every 10ms, just change PING_INTERVAL from 29 to 10.  But, I would not suggest it unless you're sensors are pointing in opposite directions.  Here's the sketch:

Code: [Select]

#include <NewPing.h>

#define SONAR_NUM      2 // Number or sensors.
#define MAX_DISTANCE 200 // Maximum distance (in cm) to ping.
#define PING_INTERVAL 29 // Milliseconds between sensor pings (29ms is about the min to avoid cross-sensor echo).

unsigned long pingTimer[SONAR_NUM]; // Timer array.
unsigned int cm[SONAR_NUM];         // Where the ping distances are stored.
uint8_t currentSensor = 255;        // Keeps track of which sensor is active (255 indicates starting position).

NewPing sonar[SONAR_NUM] = {   // Sensor object array.
 NewPing(6, 6, MAX_DISTANCE), // Each sensor's trigger pin, echo pin, and max distance to ping.
 NewPing(7, 7, MAX_DISTANCE)
};

void setup() {
 Serial.begin(115200);
 pingTimer[0] = millis() + 75;           // First ping starts at 75ms, gives time for the Arduino to chill before starting.
 for (uint8_t i = 1; i < SONAR_NUM; i++) // Set the starting time for each sensor.
   pingTimer[i] = pingTimer[i - 1] + PING_INTERVAL;
}

void loop() {
 for (uint8_t i = 0; i < SONAR_NUM; i++) { // Loop through the sensors.
   if (millis() >= pingTimer[i]) {         // Is it this sensor's time to ping?
     pingTimer[i] += PING_INTERVAL * SONAR_NUM;  // Set next time this sensor will be pinged.
     if (currentSensor < SONAR_NUM) {
       processResult(currentSensor);             // Previous sensor ping complete, do something with the results.
       sonar[currentSensor].timer_stop();        // Make sure previous timer is canceled before starting a new ping (insurance).
     }
     currentSensor = i;                          // Sensor being accessed.
     cm[currentSensor] = 0;                      // Make distance zero in case there's no ping echo for this sensor.
     sonar[currentSensor].ping_timer(echoCheck); // Do the ping (processing continues, interrupt will call echoCheck to look for echo).
   }
 }
 // The rest of your code would go here.
}

void echoCheck() { // If ping received, set the sensor distance to array.
 if (sonar[currentSensor].check_timer()) cm[currentSensor] = sonar[currentSensor].convert_cm(sonar[currentSensor].ping_result);
}

void processResult(uint8_t sensor) { // Do something with the results.
 Serial.print(sensor);
 Serial.print("=");
 Serial.print(cm[sensor]);
 Serial.println("cm ");
}

[teckel]

If it still doesn't work, try changing the MAX_SENSOR_DELAY in the NewPing.h file from 18000 to 180000 (add a zero at the end).  This will give your sensor more time to finish the ping before waiting for the echo.  The longest I've ever measured is around a 17000 microsecond delay, but maybe your sensor requires longer.

I tried in the 1.4 pre-release code base with 180000 microseconds MAX_SENSOR_DELAY and a 1000 microsecond delay between triggering HIGH and letting the HC-SR04 see this, and there was no change in behavior.

Are you using all 4 pins on your HC-SR04s, or are you using 3? You mentioned a recent optimization where you could do trigger and echo on the same pin. I'm using all 4 pins. Could that be the difference?

EDIT: I tried this with my second HC-SR04, but it's likely out of the same batch.

All of my HC-SR04 sensors work with both 2 pins and 1 pin, so it has nothing to do with the pins.  Who did you purchase your sensors from as I'd love to duplicate the problem.

Also see the attached file to this message.  This modified version of the library simulates the pulseIn function that's being used the example sketch you linked to (waits up to a second for a ping echo).  I would not suggest anyone else using this library, it's just meant for testing for those with a HC-SR04 that are giving 0cm results.  It's an inferior library just meant for testing.

Let me know how this works.

Tim

[Human]

All of my HC-SR04 sensors work with both 2 pins and 1 pin, so it has nothing to do with the pins.  Who did you purchase your sensors from as I'd love to duplicate the problem.

I got them from this vendor on Amazon http://www.amazon.com/gp/product/B0085MXZH0/ref=oh_details_o01_s00_i00

They're currently out of stock, so replacements you get may or may not be the same batch.

Also see the attached file to this message.  This modified version of the library simulates the pulseIn function that's being used the example sketch you linked to (waits up to a second for a ping echo).  I would not suggest anyone else using this library, it's just meant for testing for those with a HC-SR04 that are giving 0cm results.  It's an inferior library just meant for testing.

Let me know how this works.

I'll try that out tomorrow and report back. Thanks for your help!

[teckel]

I got them from this vendor on Amazon http://www.amazon.com/gp/product/B0085MXZH0/ref=oh_details_o01_s00_i00

They're currently out of stock, so replacements you get may or may not be the same batch.

I got one from this vendor on Amazon:
http://www.amazon.com/Ultrasonic-Module-HC-SR04-Distance-Arduino/dp/B004U8TOE6/ref=pd_cp_e_1

Two others I got direct from China on eBay.  I forgot where the 4th one came from.  All work, but 3 are only stable to around 50cm.  This is the case with any library I use or if I use a sketch without a library.  So they're defective for sure, and 3 out of 4 being defective makes me question the quality of the HC-SR04 sensors.

I'd say the SRF05 is the best sensor.  Works perfectly and works with only one pin.  It's also easy to identify as it's the only ultrasonic sensor I know of that has 5 pins (one is not used).

Tim

[AWOL]

It's also easy to identify as it's the only ultrasonic sensor I know of that has 5 pins

So does the SRF04.
SRF02 also has five pins, but it is I²C.

[Human]

I tried NewPingTest1, and I get one ping per second, returning 0cm each time. Is there a specific sketch you wanted me to use? I used the minimal sketch that does 20 pings per second in the loop() function.

This is with the sensor that works fine with that standalone code I linked to, even when I assign delays and timeouts that are consistent with the baseline NewPing.

If you're interested, I can mail it to you.  I have two of them, and I just ordered an HY-SRF05.

[teckel]

I tried NewPingTest1, and I get one ping per second, returning 0cm each time. Is there a specific sketch you wanted me to use? I used the minimal sketch that does 20 pings per second in the loop() function.

This is with the sensor that works fine with that standalone code I linked to, even when I assign delays and timeouts that are consistent with the baseline NewPing.

If you're interested, I can mail it to you.  I have two of them, and I just ordered an HY-SRF05.

That basic sketch is just fine.  The modified library basically waits up to 1 full second for the ping echo (which is what pulseIn does).  It's very interesting that it doesn't work for you yet we are running seemingly identical hardware.  The only variable is the sensor, so yes, it would be great if you could send it to me.  I'll message you my address.  I'm sure we can get to the bottom of this if I have a sensor with this issue in front of me to test.

Tim

[deverett]

Tim,
So far everything is working fine with the single pin version. I've only had time to wire up 2 of the sonars so far.

Dave

Basically, because the library is designed specifically to communicate with ultrasonic sensors instead of using stock commands like pulseIn, it waits for all the correct pin states between the trigger and echo stages.  So, it can both trigger and echo using the same Arduino pin because the output and input stages are clearly defined.

The idea came when I wired a sensors incorrectly (trigger and echo pins reversed) with no ill effect while looking at adding support for the Ping))) sensor which only uses 1 pin for both trigger and echo.  I knew it wouldn't break anything to try (from my incorrect wiring experience) and it also seemed logical that the sensor was only ever listening for a trigger during certain situations and only sending an echo output during other situations.  Sure enough, I believe 3 lines of code were modified and it worked perfectly.

On projects where you have multiple sensors (which many have) reducing the number of pins needed by half is huge.  Projects that at once needed a large Arduino Mega could be done with a thumbnail-sized Teensy 2.0.

Keep us updated!

Tim

Up to 6 sonars now, not a hitch. Also I think the reads are more stable as I get solid results even when the robot is moving. I currently have the update set at 80ms, but I'm about to take it back to 35ms as the number of sonars increases.

You do good work Tim.

Dave