Hi, I am trying using two HC-SR04 at the same time to measure in m3 (volume) with two decimal points, but the US_ROUNDTRIP_CM convert to int. When I change to float, measures were strange.
Is there one best way to do this ?
Tks.
Why not simply convert to mm?
cayazigi:
Hi, I am trying using two HC-SR04 at the same time to measure in m3 (volume) with two decimal points, but the US_ROUNDTRIP_CM convert to int. When I change to float, measures were strange.
Is there one best way to do this ?
Tks.
"strange"? Meaning what exactly? Like they were all over the place? That's because the sensor is only accurate to about a cm. Basically, you're trying to get more precision than is possible.
But, if you'd like to convert to mm or see results to the precision of two decimal points, simply use the standard ping() method which gives you a ping time. Then, using your thermometer sensor, convert that time to distance using the speed of sound at the measured temp. If you want the most accurate measurements you can get from an ultrasonic sensor, that's the way to do it. And NewPing is perfect for those situations (you just need other sensors and use your own math).
Tim
Apologies if this question has already been answered but I couldn't find it: Are there any unresolved issues NewPing might have with the Arduino Yun board? I have cabled a ranger to an Uno board, uploaded a simple NewPing program and it works perfectly (thanks very much for that!). When I upload exactly the same program (Serial is replaced with Bridge/Console so I can see the numbers in a window) and connect exactly the same pins to exactly the same ranger all I get is zeros.
"Unresolved" as in no one has ever tried NewPing with Yun or reported a problem. I've never tested NewPing on a Yun board nor do I know anyone who has tried.
NewPing should be on the AVR side of the Yun and not use any pins that the WiFi or Ethernet are using. So, I would verify any pin conflicts and/or try different ports to use with your sensor. Also, start with something easy, just the example ping sketch with the NewPing library that uses the ping() method. Don't get fancy with using the same pin for trigger and echo (use two pins) and don't use any of the NewPing timer methods. Just your standard ping() only.
Basically, walk before you run. If you're still having a problem, post your sketch.
Oh, and I'm going the route of using the Particle Photon for WiFi development. Far cheaper, far smaller, easier to use, and easy to embed in a commercial project. Therefore, there's no chance I'll be getting a Yun for testing with NewPing.
Tim
Thanks, Tim, for the quick reply. I'm not sure what "the AVR side of the YUN" means. There are 6 analog IN pins and 14 digital I/O pins on both the YUN and the Uno, all of which are up for grabs and none of which seem to have anything to do with the wifi/ethernet/Linux or SD card. I have piggy backed SD shields and LCD displays onto Uno boards so I understand that data pins can be off limits under those circumstances. The SD card, the wifi/ethernet, and the linux connections appear to be all under the hood on the Yun board, leaving the I/O pins wide open.
Trying different pins is still a good idea, so I did that. I had originally used pins 12 and 13 for TRIG and ECHO (already separate, as you suggested) and I reconfigured to pins 10 and 11 but still get zeros. The NewPing call that I'm using (listing below) is sonar.ping() which is, I'm assuming, what you mean by "standard ping() only."
Again, this program works flawlessly with an Uno board (using the standard Serial command instead of Console).
/* This little ping program is about as simple as I can make it. I've set it to write to the Serial window to make it easy to monitor, but in other versions I've set the program to write to the SD card instead and the pinged range is always zero in that case as well */
#include <NewPing.h>
#include <Console.h>
#define TRIGGER_PIN 10
#define ECHO_PIN 11
#define MAX_DISTANCE 200
#define HOT_PIN 9
NewPing sonar(TRIGGER_PIN,ECHO_PIN,MAX_DISTANCE);
void setup(){
// Serial.begin(9600);
Bridge.begin();
Console.begin();
pinMode(HOT_PIN,OUTPUT);
digitalWrite(HOT_PIN,HIGH);
}
void loop(){
delay(2000);
int uS = sonar.ping();
Console.print("Ping: ");
Console.print(uS/US_ROUNDTRIP_CM);
Console.println(" cm:");
}
output in serial window no matter how the ranger is aimed.
Ping: 0 cm:
Ping: 0 cm:
Ping: 0 cm:
Ping: 0 cm:
Ping: 0 cm:
Ping: 0 cm:
goldstream_solar:
Thanks, Tim, for the quick reply. I'm not sure what "the AVR side of the YUN" means. There are 6 analog IN pins and 14 digital I/O pins on both the YUN and the Uno, all of which are up for grabs and none of which seem to have anything to do with the wifi/ethernet/Linux or SD card. I have piggy backed SD shields and LCD displays onto Uno boards so I understand that data pins can be off limits under those circumstances. The SD card, the wifi/ethernet, and the linux connections appear to be all under the hood on the Yun board, leaving the I/O pins wide open.Trying different pins is still a good idea, so I did that. I had originally used pins 12 and 13 for TRIG and ECHO (already separate, as you suggested) and I reconfigured to pins 10 and 11 but still get zeros. The NewPing call that I'm using (listing below) is sonar.ping() which is, I'm assuming, what you mean by "standard ping() only."
Again, this program works flawlessly with an Uno board (using the standard Serial command instead of Console).
The Yun has a AVR CPU as well as another CPU running Linux. I don't know how the Yun works, but it should be using the ATmega AVR microcontroller with NewPing and not the other CPU. Maybe you can't do this on the Yun, but on other multi-microcontroller boards you can program on either.
In any case... There must be some way that the AVR microcontroller communicates with the Linux CPU. That communication must happen on certain pins. Just looking at the Yun page on Arduino.cc it appears it only uses serial communications between the two microcontrollers so maybe just pins 0 and 1 are off-limits. Not 100% sure, just a guess based on 30 seconds of browsing...
It appears that something is very different with the Yun if it's not working. It will probably be impossible for me to diagnose without a Yun. Typically, you can hear the ultrasonic sensor "click" when a ping is triggered. So, you should hear a slight click every two seconds with the above sketch. If not, it's not even talking to the sensor.
My best guess is that there's something not right or different with the port registers on the Yun. For speed and compile size, I use direct port register calls for AVR microcontrollers. But, just a guess.
Tim
Hi Tim,
The ranger definitely clicks so sonar.ping() is apparently driving the TRIG pin like it's supposed to. The Arduino chip is also in charge of monitoring the ECHO pin and extracting the delay, which it then converts to distance and writes to the serial window.
I have wondered if the problem is related to the timing of the return pulse. The Uno uses the ATmega328 chip running at 16 MHz and 5V, and the Yun uses the ATmega32u4 chip, also at 16 MHz and 5V. Perhaps the Yun chip returns the delay in millisec instead of microseconds ....
The Arduino gui on my Mac writes to the Arduino chip, which handles all the I/O pins. I only use the linux chip to access the data that the Arduino chip writes to the SD card (i.e. shell scripts parse the raw data into a more compact form and then email it to me). Until cron tells a script to execute the linux chip is never used. It looks like there's a newer version of openWRT for the linux chip but I don't see how that would make any difference.
goldstream_solar:
Hi Tim,
The ranger definitely clicks so sonar.ping() is apparently driving the TRIG pin like it's supposed to. The Arduino chip is also in charge of monitoring the ECHO pin and extracting the delay, which it then converts to distance and writes to the serial window.I have wondered if the problem is related to the timing of the return pulse. The Uno uses the ATmega328 chip running at 16 MHz and 5V, and the Yun uses the ATmega32u4 chip, also at 16 MHz and 5V. Perhaps the Yun chip returns the delay in millisec instead of microseconds ....
The Arduino gui on my Mac writes to the Arduino chip, which handles all the I/O pins. I only use the linux chip to access the data that the Arduino chip writes to the SD card (i.e. shell scripts parse the raw data into a more compact form and then email it to me). Until cron tells a script to execute the linux chip is never used. It looks like there's a newer version of openWRT for the linux chip but I don't see how that would make any difference.
Try setting the pin you're using for echo to INPUT. I believe that would be the following:
pinMode(ECHO_PIN,INPUT);
It's worth a shot. The other things you could do would be to change some of the settings in the library. Specifically, I would try setting ONE_PIN_ENABLED and TIMER_ENABLED to false. If that doesn't work, I'm out of ideas.
Tim
Hi Tim-
I think I might have figured it out. I got out an oscope and compared the TRIG and ECHO pins for this ranger on the Uno board (which works) and on the YUN board (which doesn't work). The ECHO pulse goes from 0V to 5V (as expected) when I use the Uno board but the ECHO pulse only runs to about 1 V when I use the YUN (the pulse width doesn't change). Weird. The TRIG signals are identical in shape but the YUN board signal is lower by a few tenths of a volt.
Anyhoo, my latest theory is that the ranger I'm using (the only one I could find that's waterproof) puts out a weak pulse on the ECHO pin unless it gets a full 5 V on the power supply pin. The 1 amp USB port on my Mac tower will only give 4.6 V to the Yun board, and I have a 1.2 A USB wall plug charger that is just oomphy enough to bring the Yun board voltage up to 4.8 V. I honestly can't believe anyone would make a ranger that is so picky about the supply voltage, but I've ordered a 3 amp USB wall plug power supply to settle the issue. Another strategy would be to regame the NewPing code to accept a lower threshold for measuring the ECHO pulse width.
goldstream_solar:
Hi Tim-
I think I might have figured it out. I got out an oscope and compared the TRIG and ECHO pins for this ranger on the Uno board (which works) and on the YUN board (which doesn't work). The ECHO pulse goes from 0V to 5V (as expected) when I use the Uno board but the ECHO pulse only runs to about 1 V when I use the YUN (the pulse width doesn't change). Weird. The TRIG signals are identical in shape but the YUN board signal is lower by a few tenths of a volt.Anyhoo, my latest theory is that the ranger I'm using (the only one I could find that's waterproof) puts out a weak pulse on the ECHO pin unless it gets a full 5 V on the power supply pin. The 1 amp USB port on my Mac tower will only give 4.6 V to the Yun board, and I have a 1.2 A USB wall plug charger that is just oomphy enough to bring the Yun board voltage up to 4.8 V. I honestly can't believe anyone would make a ranger that is so picky about the supply voltage, but I've ordered a 3 amp USB wall plug power supply to settle the issue. Another strategy would be to regame the NewPing code to accept a lower threshold for measuring the ECHO pulse width.
NewPing is not looking at the echo voltage to change the threshold. It's a digital input and it's either on or off. It must not be enough voltage to trigger the Arduino microcontroller to a high state.
Supplying more amperage sounds like the logical move.
Tim
Hi,
Very nice job. I would like you to include the following modifications (if possible) so they are included in future versions.
I have included one additional function to your code "ping_fake_timer" so that it does not generate a ping, but initializes necessary variables for the timer.
The point is that if one uses a more limited pin arduino (such as nano v3.0), it might be interesting to share the trigger pin (assuming no cross-talking) between sonars so more pins are available for other purposes.
NewPing.zip (13.6 KB)
larmesto:
Hi,Very nice job. I would like you to include the following modifications (if possible) so they are included in future versions.
I have included one additional function to your code "ping_fake_timer" so that it does not generate a ping, but initializes necessary variables for the timer.
The point is that if one uses a more limited pin arduino (such as nano v3.0), it might be interesting to share the trigger pin (assuming no cross-talking) between sonars so more pins are available for other purposes.
Sample sketch would also be helpful.
I do see a problem with this. The frequency of echo polling is 24uS. But, if you have 3 sensors, it's taking up 3 times the processing from the ATmega. The 24uS polling frequency is already pushing it to give good accuracy. But, with 3 sensors it's like making the polling frequency every 8uS. That doesn't give the poor little ATmega much time to do anything else.
Instead of using your modification and using up most of your CPU resources, there's two other solutions.
First, my code supports a one pin method where you use the same pin for trigger and echo for each sensor. This way you would actually use one fewer pins that you're using now (3 instead of 4).
Secondly, wire everything exactly as you have it, and set all three sensors to the same trigger pin. All sensors will fire but only one will be listening for the echo.
Also keep in mind that the sensors are not just listening for anything. They're listening for a particular pattern. It's not just a simple echo but other slight echos can cause inaccurate results. So, using your method or the two listed above, you defiantly risk causing a problem.
Anyway, I think your logic is sound, but I have a problem with the execution. The ping frequency really should be reduced. This can be done with ECHO_TIMER_FREQ, but making it say 72uS instead of 24uS will reduce the ping accuracy to more than a cm. This would also get worse the more sensors you had.
A better way to implement this would be to have new methods designed for 2, 3, or 4 sensors that would ping all of them, then poll the status every 24uS to insure accuracy but not take over the CPU. But even then, I believe with the one pin capability and specifying the same trigger pin for multiple sensors, NewPing already accomplishes this in just another way. Besides, it's really not a good idea to trigger multiple sensors at the same time due to echo issues.
Tim
i was hoping this JSN-SR04T waterprrof US sensor would be plug compatible with the HC-SR04 but that seems not to be the case. haven't dragged out the scope yet, i thought i would find an answer on the web, but nothing concerning NewPing and this JSN transceiver.
any thoughts?
thanks so much for Newping,
mike
abraxas1:
i was hoping this JSN-SR04T waterprrof US sensor would be plug compatible with the HC-SR04 but that seems not to be the case. haven't dragged out the scope yet, i thought i would find an answer on the web, but nothing concerning NewPing and this JSN transceiver.
any thoughts?
thanks so much for Newping,mike
According to what I can find about this controller, it should be compatible with NewPing. It requires the same 10uS trigger and the echo pin goes high when an echo is received. That's exactly how the HC-SR04 works.
If it's not working connecting it to a scope and sharing your results may help. As waterproof sensors are a common request, a sensor like this that works with NewPing would be really nice.
Tim
found these online for $10. i'm really surprised at the lack of info out there. haven't found any docs.
what i've read does sound very much the same, the model number is similar, and the pinout is exactly the same.
but no joy on either of the two i have.
i'm anxious to get it on the scope too.
Abraxas - I am working with exactly the same waterproof acoustic sensor. I got it to work with an Arduino Uno board without a problem but had the devil's own time getting it to work with an Arduino Yun board. It is working just fine as of 20 minutes ago and there were 2 hurdles:
-
The Sample Newping Sketch (Arduino Playground - NewPing Library) does not declare the ECHO_PIN as input
pinMode(ECHO_PIN,INPUT);
For some reason the Uno board works without this line but the Yun board does not. -
The Yun board doesn't have a built-in voltage regulator like the Uno. There is another thread (Arduino Yun 5v pin doesnt give me 5v. - Arduino Yún - Arduino Forum) which discusses the result of this, which is that the Yun board voltage is noticeably lower than the 5V power supply that you use to drive the board. When I power the Yun board with the USB port on my computer (1 amp) or with a 1.2 amp power supply the acoustic sensor doesn't work. When I power the Yun board with a 3 amp power supply (which arrived in the mail yesterday) the acoustic sensor works fine.
seems to be working fine now. looks normal on the scope. i'm using your latest library 1.6beta with the ping.median call. my initial problem might have been related to my PS. i have a 5v Boost PS enabled through a MOSFET.
for the HC-S04 a Voltage Settle time of 5ms seemed fine. before trying this new sensor i upped it to 50ms and no joy, hence my last post.
since then i upped it to 150mS and it started working. i'll measure power draw sometime, 5V rise time. i use the 5v to power my temp sensors too.
still can't find any docs on this part except the description.
this thing looks very much like an automotive sensor. the beam shoots out and a slight angle, just like car sensors.
unlike a car sensor the long cable coming out of it is 75 Ohm coax with a 2pin molex type connector on it that mates to the PCB.
more tweaking and verification to do still before deployment but mounts nicely in a 7/8" hole. except the beam is not coming out perpendicular to the housing.
goldstream_solar:
Abraxas - I am working with exactly the same waterproof acoustic sensor. I got it to work with an Arduino Uno board without a problem but had the devil's own time getting it to work with an Arduino Yun board. It is working just fine as of 20 minutes ago and there were 2 hurdles:
- The Sample Newping Sketch (http://playground.arduino.cc/Code/NewPing) does not declare the ECHO_PIN as input
pinMode(ECHO_PIN,INPUT);
For some reason the Uno board works without this line but the Yun board does not.
That's interesting... Arduino ATmega pins should default to input state. I know the Teensy 3.0/3.1/LC default to a disabled state. So, you need do a pinMode to wake the pin up. But, I wasn't aware of any Arduino or ATmega microcontroller which required a pin to be set to input mode.
Also, there's lots of pinMode (or port register call versions) setting in the library itself. So, just because the example sketches don't set a pinMode doesn't mean they're not being set. I do set the trigger pinMode (to both in and out depending how you have ONE_PIN_ENABLED set. Also, for the Teensy ARM devices I do set the pinMode for the echo pin.
In any case, if the Yun requires you to set the pins to input, that would go against Arduino documentation and is probably a bug. I can add special code for the Yun to set the echo pin to input. But, we should clarify if this is a bug or designed behavior.
Tim
Gidday, I am pretty new to this, well, actually, truth be told I am a tadpole swimming in the Pacific Ocean. A microscopic plankton tadpole at that....... Just so everyone is aware of my utter newbie status.
Thing is right, I have spend the last few days scouring the internets in order to find what I had thought (my first mistake, an assumption) would be something rather simple. I have found, much to my utter dismay, that I am really rather very unable to procure any answers whatsoever.
I run a forum myself and have in the past become a bit jaded with newbie questions, and, I hope that I am not simply recreating these unfortunate set of circumstance here but I feel I most probably am.
So enough of the preamble, let's get to the question yes?
I have in my possession a SRF05, hooked up to an UNO. Works fine, no problems getting it sorted, reads out measurements good as gold. So far so good, right 
Problem is right, this. When I bought the wee unit the bloke who sold it to me says it could give me measurements incrementally of .2cm, yup 2mm, which is what I was after. I think, after reading quite a bit on this I should give some clarification of what I am attempting to do.
I am only wanting to read values within a range of 100mm (10cm), this can be done from any midpoint, say 10cm away from the target area, or any other number for that mater, but the thing I am needing is the specific accuracy within this range thereafter.
I thought, I should ask the experts as I came up with nada. It would seem that I might be pushing the poo uphill with a sharp pencil at this stage, it seems the blokes that know what these things can do will most probably say it can't be done, but the blokes that sell them say it can, but won't tell me how.
Rock/Hard place.
Any input, even if it is to tell me indeed that I am a bit green and got a little bit excited by a sales pitch is fine
Although, if it can be done........ then I am all ears, well, eyes, as the case may be