After the substitution of the tone function with the toneWorkaround one and the change of the power supply of the PING))) (attached to A4) to getting it's power from the Arduino everything is working juuuust fine!!!
I am now using the ping_median for the pings just in case there is some interference.
Thanks again for the great library.
basile
basile-laderchi:
After the substitution of the tone function with the toneWorkaround one and the change of the power supply of the PING))) (attached to A4) to getting it's power from the Arduino everything is working juuuust fine!!!
I am now using the ping_median for the pings just in case there is some interference.Thanks again for the great library.
basile
Another solution would be to comment out line 214, 216, and 217 in NewPing.cpp if you're not using the interrupt method of NewPing. You can then use the tone library without conflict. In my development version, I've created a switch to do this if you're not using the timer interrupt method of NewPing.
Tim
I'm getting close to releasing a new version of the NewPing library. Is anyone having any problems with it or want to suggest something new to add? It's getting quite mature now so the updates probably won't happen as frequently.
I'm going to test it with the new 32-bit ARM Teensy 3.0 that I got last week. If someone has the Arduino Due and would like to test NewPing with it, that would be appreciated. Note, that the timer interrupt methods probably won't work with the new crop of 32-bit Arduinos. So, all I really care about testing and supporting at this time is the standard ping() method.
Tim
I've downloaded the v1.5 and tried it in arduino 1.0 but it wont compile. im using a cloned arduino board with atmega8. does it support older boards?
http://www.elab.ph/forum/index.php?topic=6698.0
this is the board im using.
jackryan:
I've downloaded the v1.5 and tried it in arduino 1.0 but it wont compile. im using a cloned arduino board with atmega8. does it support older boards?http://www.elab.ph/forum/index.php?topic=6698.0
this is the board im using.
I know the timer interrupt methods won't work correctly with the ATmega8 due to the clock rate. Never had anyone try a ATmega8 to know if it worked or not. Be sure to start with the basics and try the sample sketch (using the standard ping() method). If you're still getting compile errors, including them with your reply would be helpful to detect if it's a simple thing or something more complex. As it stands, without the errors I can't even guess as v1.5 works just fine with Arduino 0023, 1.0, 1.0.1, and 1.0.2.
Tim
First, thanks for the lib! I love it.
Second I will apologize in advance if this has already been asked, but I can't seem to search just this topic so I may have missed it, if it was.
Has any one else experienced an error when attempting to use tone() along with this lib? When I attempt to include tone [e.g. tone(11,1000,20)] I get an error:
core.a(Tone.cpp.o): In function __vector_7':* *C:\Users\Dave\arduino-1.0.1-windows\arduino-1.0.1\hardware\arduino\cores\arduino/Tone.cpp:523: multiple definition of __vector_7'
NewPing\NewPing.cpp.o:C:\Users\Dave\arduino-1.0.1-windows\arduino-1.0.1\libraries\NewPing/NewPing.cpp:214: first defined here
Dear amatbrewer,
amatbrewer:
First, thanks for the lib! I love it.
It is a great lib indeed!
amatbrewer:
Second I will apologize in advance if this has already been asked, but I can't seem to search just this topic so I may have missed it, if it was.
you did miss it indeed! It's just on the previous page: NewPing Library: HC-SR04, SRF05, SRF06, DYP-ME007, Parallax PING))) - v1.7 - #250 by basile-laderchi - Sensors - Arduino Forum
amatbrewer:
Has any one else experienced an error when attempting to use tone() along with this lib?
I had stumbled upon this error just a while ago, and after searching around I found the toneWorkaround function in a book (Arduino Cookbook, page 307). You can find the function I used here: NewPing Library: HC-SR04, SRF05, SRF06, DYP-ME007, Parallax PING))) - v1.7 - #252 by basile-laderchi - Sensors - Arduino Forum
basile
I have a HC-SR04 sensor, a 3.3v capable bluetooth module, and an Arduino Uno r3 (that is it besides spares of all three). I am using 10" jumper wires from the Arduino for power and pins 12 and 13. I am running newping with median(5). I have the HC-SR04 in a fixed position holder aiming at a 3 square inch surface that only moves in one direction directly away from the sensor (from 1" to 78"). This smooth/flat surface is accurately controlled to be square to the sensor for good signal return. With one sensor holder (this one is steel, fairly open air, and lightly holds the sensor around the two barrels) the readings are either perfect or up to 3% bad values (even after median(5) and the stationary object not very far away 15"). The other sensor holder (which is machined plastic, holds the barrels tightly, and encloses the sensor board) might work just as well or might give far more bad values. The erroneous distance values don't seem to be random. They are very similar numbers on a given day (a lot of 9" ±.3 one day, it might be around 3" another day). The "test bed" is very controlled so I don't have items causing pings one day and not the next. I bored out the tight fitting holder and hung the sensor in it with spacers to the sensor board 2 mounting holes and I didn't notice any change. I want to use this sensor and I know that this type of distance sensing isn't perfect, but I can't live with the "bad" days of the output. I can't enlarge the surface of the object being measured. I have tried changing all of the hardware with no change. I have tried USB 5v, 9vdc wall warts, and 4 x AA battery packs. I have slowed the ping rate some. I have been trying to think through the possible problems (I will list some below):
Power pulsing (put a 1uF capacitor across the HC-SR04 Vcc and ground, and possibly across on the Arduino as well?).
Different sensor mounting (I don't know how much direct mechanical vibration problems there are at the receive barrel from the trigger).
Don't use pin13 due to the led.
The Arduino and bluetooth module need to be farther away from the sensor.
Use shielded cable instead of jumper wires.
Interference from something in the room.
Somehow pull the sensor farther back so I am not measuring the first 7" or so.
Maybe change to the HY SRF05 (I kind of doubt this will help).
Do you have any suggestions or do you think these sensors are just "flaky"?
Thank you.
amatbrewer:
Has any one else experienced an error when attempting to use tone() along with this lib? When I attempt to include tone [e.g. tone(11,1000,20)] I get an error:
core.a(Tone.cpp.o): In function__vector_7':* *C:\Users\Dave\arduino-1.0.1-windows\arduino-1.0.1\hardware\arduino\cores\arduino/Tone.cpp:523: multiple definition of__vector_7'
NewPing\NewPing.cpp.o:C:\Users\Dave\arduino-1.0.1-windows\arduino-1.0.1\libraries\NewPing/NewPing.cpp:214: first defined here
If you're using the ping_timer() method with NewPing, you won't be able to use both the Tone library and NewPing as they both use Timer2. If, however, you're using just the ping() method in NewPing, you'll be able to use the Tone library. You'll just need to comment out a few lines in NewPing.cpp to avoid the conflict. See this message for more details:
Tim
CyklKent:
I have a HC-SR04 sensor, a 3.3v capable bluetooth module, and an Arduino Uno r3 (that is it besides spares of all three). I am using 10" jumper wires from the Arduino for power and pins 12 and 13. I am running newping with median(5). I have the HC-SR04 in a fixed position holder aiming at a 3 square inch surface that only moves in one direction directly away from the sensor (from 1" to 78"). This smooth/flat surface is accurately controlled to be square to the sensor for good signal return. With one sensor holder (this one is steel, fairly open air, and lightly holds the sensor around the two barrels) the readings are either perfect or up to 3% bad values (even after median(5) and the stationary object not very far away 15"). The other sensor holder (which is machined plastic, holds the barrels tightly, and encloses the sensor board) might work just as well or might give far more bad values. The erroneous distance values don't seem to be random. They are very similar numbers on a given day (a lot of 9" ±.3 one day, it might be around 3" another day). The "test bed" is very controlled so I don't have items causing pings one day and not the next. I bored out the tight fitting holder and hung the sensor in it with spacers to the sensor board 2 mounting holes and I didn't notice any change. I want to use this sensor and I know that this type of distance sensing isn't perfect, but I can't live with the "bad" days of the output. I can't enlarge the surface of the object being measured. I have tried changing all of the hardware with no change. I have tried USB 5v, 9vdc wall warts, and 4 x AA battery packs. I have slowed the ping rate some. I have been trying to think through the possible problems (I will list some below):
Power pulsing (put a 1uF capacitor across the HC-SR04 Vcc and ground, and possibly across on the Arduino as well?).
Different sensor mounting (I don't know how much direct mechanical vibration problems there are at the receive barrel from the trigger).
Don't use pin13 due to the led.
The Arduino and bluetooth module need to be farther away from the sensor.
Use shielded cable instead of jumper wires.
Interference from something in the room.
Somehow pull the sensor farther back so I am not measuring the first 7" or so.
Maybe change to the HY SRF05 (I kind of doubt this will help).Do you have any suggestions or do you think these sensors are just "flaky"?
Thank you.
Your full sketch and picture of your test jig may shed some light on things. I have a bunch of sensors, and none have ever had a bad day. My guess is that there's either a problem in your sketch, you're getting some type of environment noise, or there's something causing an echo reading. The sketch and picture should lead us in the right direction.
Tim
Thank you for the reply. I will post the code this evening. Here is a picture of the hardware. I am sorry but I can't show the actual set up or the 3in2 object being measured. The red and black wires hanging out from one sensor was temporary to watch on a scope.
Here is the code that I normally use:
#include <NewPing.h>
#define TRIGGER_PIN 12
#define ECHO_PIN 13
#define MAX_DISTANCE 200 // In Centimeters (200cm = 78.7") It will not keep waiting for a return if past this value
NewPing sonar(TRIGGER_PIN, ECHO_PIN, MAX_DISTANCE);
void setup() {
Serial.begin(9600);
}
void loop() {
float uS = sonar.ping_median(5);
Serial.print(uS / US_ROUNDTRIP_IN);
Serial.print("a");
}
CyklKent:
Here is the code that I normally use:#include <NewPing.h>
#define TRIGGER_PIN 12
#define ECHO_PIN 13
#define MAX_DISTANCE 200 // In Centimeters (200cm = 78.7") It will not keep waiting for a return if past this value
NewPing sonar(TRIGGER_PIN, ECHO_PIN, MAX_DISTANCE);
void setup() {
Serial.begin(9600);
}
void loop() {
float uS = sonar.ping_median(5);
Serial.print(uS / US_ROUNDTRIP_IN);
Serial.print("a");
}
I was hoping to get the picture of your testing jig in the test environment to look for possible echo sources.
But, looking at just your sketch I can see a problem. Your sketch is sending a ping on top of an old ping, with no pause between. This won't give reliable results. What you'll get is possible echos. You MUST wait AT LEAST 29ms between pings. The reason you shouldn't go faster has to do with the sensor hardware and the speed of sound. The sensors can sense up to around 500cm away (1000cm round-trip). Speed of sound is around 29uS per cm. That works out to 29ms. If you don't wait AT LEAST 29ms, you could get an ping echo from a previous ping giving you all kinds of strange results.
While the ping_median() method adds a delay between each ping, it doesn't add a delay before or at the end. So, the first ping is basically on top of the last ping. It doesn't add a delay at the end of the ping_median() on purpose, so you can add whatever delay you want, or none at all if it's a one-time only ping.
So, after the sonar.ping_median(5), you need to add a line with something like "delay(29);"
Also, you shouldn't use pin 13 if you're using an Arduino as there's an LED on that pin. Change that to any other pin to avoid possible conflict. I stopped using pin 13 in my sample sketches due to a couple users having problems with an LED conflict. Best to avoid that.
If you still have a problem, I would lengthen the delay between pings to something much larger, say 100ms. You need to change the delay(29) to delay(100) as well as edit the NewPing.h file and change the PING_MEDIAN_DELAY from 29000 to 100000. While a ping delay of 29ms should be long enough, if the sensor is too sensitive (say it can sense up to 600cm away, it would need at least a 600229=34800uS [35ms] delay between pings).
Tim
I thank you for the reply and advice. I did not realize that there was no delay between the last median ping and the next first median ping. I will update like the below (actually, I will probably go with 35 delay in the library and below):
#include <NewPing.h>
#define TRIGGER_PIN 12
#define ECHO_PIN 11
#define MAX_DISTANCE 200 // In Centimeters (200cm = 78.7") It will not keep waiting for a return if past this value
NewPing sonar(TRIGGER_PIN, ECHO_PIN, MAX_DISTANCE);
void setup() {
Serial.begin(9600);
}
void loop() {
float uS = sonar.ping_median(5);
delay(29);
Serial.print(uS / US_ROUNDTRIP_IN);
Serial.print("a");
}
I did run with no median and a 200 delay, and I still got some stray distance returns (that are oddly similar in value for a certain test period or day or two). I can live with a certain amount of stray distance returns, but some times it gets real bad. I will run on pin 11. I have gone through fixes that seem to fix the problem, and then I find out days later that the problem is back. Your library gave perfect results for a good while (earlier sketches with and without libraries did give stray values). I found that 3 different 9vdc wall warts gave stray returns, and then laptop or wall plug 5v usb had perfect returns....a month later I couldn't tell the difference between the power inputs. I do see some 60 hz at the sensor with the 9vdc wall warts. I have been wondering if I need a separate power supply for the ultrasonic sensor ( I don't know if there is a ground problem doing that). I think I will solder a 10uF capacitor across the sensor Vcc and ground. There seems to be two 47uF caps on the Arduino for its regulation (the new Arduino Due only has one I just noticed). I am going to do more testing, but I have to admit that I may have to change to a different type of sensor set up. My setup possibly does have echo problems. I may try with single pings every 2 seconds just to try to rule out echos as problems (I have tried with 500 delay before). I also am going to try completely unplugging the bluetooth module and watching the serial printer on the laptop (I usually watch distance values on my tablet via bluetooth).
Thank you again.
Wow, I am full. I want to eat more though XD
The below is what I use when I am wanting to see every ping result for testing (yes, I know that delays are to be avoided (even though Tim just told me I needed to add a delay between medians)).
#include <NewPing.h>
#define TRIGGER_PIN 12
#define ECHO_PIN 13
#define MAX_DISTANCE 200
NewPing sonar(TRIGGER_PIN, ECHO_PIN, MAX_DISTANCE);
void setup() {
Serial.begin(9600);
}
void loop() {
float uS = sonar.ping();
Serial.print(uS / US_ROUNDTRIP_IN);
Serial.print("a");
delay(500);
}
Hello.
I have a project with 8 HC-SR04.
My problem is that when I trigger a sensor, the sensor closest are also triggered. I'm not yet used this new library. Can anyone give me an idea how can I do that with this new library?
The project summary is:
8 sensors HC-SR04 each sensor being fired one at a time.
The distance that the sensor is triggered should be between 5 and 15 cm.
Best regards.
murphy
[[|]]'s
murphy:
Hello.I have a project with 8 HC-SR04 sharp sensors.
My problem is that when I trigger a sensor, the sensor closest are also triggered. I'm not yet used this new library. Can anyone give me an idea how can I do that with this new library?
The project summary is:
8 sensors sharp HC-SR04 each sensor being fired one at a time.The distance that the sensor is triggered should be between 5 and 15 cm.
Best regards.
murphy
[[|]]'s
Sharp sensors? Those are completely different sensor to the HC-SR04.
Sorry, is only HC-SR04. I thought they were maded by sharp
is it ok to use this:
HC-SR04 -------> > > > > blank space < < < < < - ------HC-SR04 sensor 2
is it ok if i limit the max reading range of both sensors to like 50 cm (and i need to read 50 cm), and i place sensors like 200 cm away from each other..
Would this work if each sensor had an independent microcontroller ???
delay(STEP_TIME);
unsigned int uS1 = SONAR_L.ping();
per_l = uS1 / US_ROUNDTRIP_CM;
Is the blank space enough, or should i use a "sponge" to prevent interference between 2 of the sensors ?????
THX 
murphy:
I have a project with 8 HC-SR04.My problem is that when I trigger a sensor, the sensor closest are also triggered. I'm not yet used this new library. Can anyone give me an idea how can I do that with this new library?
The project summary is:
8 sensors HC-SR04 each sensor being fired one at a time.The distance that the sensor is triggered should be between 5 and 15 cm.
I have an example sketch that pings 15 sensors that's designed to be scaled to any number of sensors.
http://code.google.com/p/arduino-new-ping/wiki/15_Sensors_Example
Just set SONAR_NUM to 8 and modify the sonar object array to 8 sensors and to the pins tied to each. This sketch works using the timer method so there's no delays and it will therefore work in many complicated sketches (just do everything triggered from events with no delays). Also, as NewPing will work using the same pin for both trigger and echo, you only need to use 8 pins to work with all 8 sensors. So, it's possible that your project would fit on a Uno or Teensy 2.0. Which is a huge bonus for both price and size.
You shouldn't have any problem getting this example sketch working with your 8 sensors. And it shouldn't be much of a challenge getting it integrated with your overall project sketch.
I'm going to make another post with tips on using the 15 sensor example sketch as some are having problems understanding how to use an event-driven sketch like this.
Tim