Module works:
(1) using IO trigger distance, the high signal to at least 10us;
(2) module automatically sends eight 40khz square wave, automatically detects whether a signal return;
(3) a signal back, through the IO output a high electrical level, high electrical level duration is: the ultrasound time from launch to return. Test distance = (time of the high electrical level * speed of sound (340M / S)) / 2;
ok so i just got some of these and im tryin to figure out exactly how these work i would think there would be a pdf or something. are they exactly like a ping with a send and recive pin?
i just wanna know how to pulse the thing what pins need to be hi low etc, and how to read the feedback, not looking for any specific code really
There's code in post #32 to use these with a Propeller.
I realize I didn't update the schematic when I modified the Ping code to use with these sensors. Here's an updated schematic.
i got one of my batches in under 7 days thats just nuts most items take 3 weeks + if customens holds them.
i had read that description on ebay but i guess what im not understanding is does it have to be 10us or can u do 16 pulses in 20us, also using the formula with speed of sound returns time in what seconds? then how do u convert to distance?
i had read that description on ebay but i guess what im not understanding is does it have to be 10us or can u do 16 pulses in 20us, also using the formula with speed of sound returns time in what seconds? then how do u convert to distance?
i just wanna know how to pulse the thing what pins need to be hi low etc, and how to read the feedback, not looking for any specific code really
Send it a 10us pulse, that keys it to do its thing. In short order, prepare to receive a pulse back. The width of that reply pulse is proportional to the distance result (the emission and the echo.)
The speed of sound in air is 1,126 feet per second (13,512 inches per sec., 13.5 inches per millisecond, 0.0135in per usec, 343 mm per millisecond, 0.343mm per usec.)
So, given that, rig up an experiment.
PULSOUT that trigger pulse, get that PULSIN, DEBUG the result.
See what happens.
So, given that, rig up an experiment.
PULSOUT that trigger pulse, get that PULSIN, DEBUG the result.
See what happens.
Agreed, the 10us figure isn't magic, it's just a safe value that the sensor should be sure to be able to detect. Once the sensor sees a pulse on the trigger line, it sends out a ultrasound "ping". I think it waits until the trigger goes low before sending the "ping" since it raise the echo pin high while the sound is travelling (both ways). As soon as it detects the first echo back, it lowers the echo pin.
You can measure the echo pulse length with the PULSIN command with a BS (as PJ suggested) or with a Propeller use the waitpne and waitpeq and time the interval.
From the Ping object (also my modified version):
waitpne(0, |< echo, 0) ' Wait echo pin to go high
timer := -cnt ' Start timer
waitpeq(0, |< echo, 0) ' Wait echo pin to go low
timer += cnt ' Stop timer
(The "timer := -cnt" is a trick to time intervals with only one variable.)
Then you do the math PJ talked about.
If you use diodes and a pull-down resisitor you can have multiple sensors share the echo pin and just use a unique pin for each trigger line. Martin_H started a thread about using multiple sensors and I know I was able to use four sensors using five Prop I/O pins.
ok guys thanks, ill hook one up to a bs2 and mess around. i guess what i was saying about the 10us pulsout is that it says it sends 8 blasts of sound so if i pulse it at 20us will that send 16 sounds and give me more accuracy? in applications like a "tape measure" where speed isnt an issue this may be more favorable
It says the sensor's accuracy is 2mm (I think the wavelength of the 40KHz sound is an important limiting factor on the accuracy of the sensor). Sound traveling 340m/s will take about 12us to cover 2mm(two directions). So as long as your microcontroller can measure the pulses with at least 12us (6us would be even better) resolution you're probably okay.
I used the figure "340m/s" from the ebay site. Wikipedia has a good article about the speed of sound. Humidity, temperature and other factors effect the speed of sound (but not enough you need to worry about it much).
so most of the time u see these being used on pan/tilts to sweep areas. If u wanted to acually aim at something specific and use a laser to aim would sticking a laser in the center of the transducer be the best bet? also how wide should one imagine the sound beams, a pinpoint like a laser, a circle with an inch diameter... i guess im asking what the spread is
i got so many i figured making lil tape measure with a 7 segment would be a neat simple project, also usefull for work and household tasks. although im worried about slight hand movements messing up the accuracy and causing bounce
It's a pretty wide beam. My guess is somewhere between 50 and 80 degrees. It uses the first echo back not the strongest so you have to watch out when using it too close to the floor or it will measure the distance to the floor and not the distance to the wall. It may also not see soft objects like a couch. If the sound bounces off a hard flat surface at a glancing angle no sound may be returned as an echo.
I added an ultrasound to my Scribbler 2. The video of it moving around shows some of the short comings of using ultrasound. IR tends to be good at detecting object ultrasound has a hard time with so it's good to use both on a robot.
I believe the ultrasound I used on the S2 has a narrower beam than these ebay ultrasounds.
so maybe using ultrasound for a wider coverage of genral obstacle detection around the room is better and then using a laser/wiicam setup is going to be more presice?
it says theres an arduino library that has been updated and allows 1 pin com with the sr04! maybe someone could turn this into a prop object or at least give a run down on how there using 1 pin to talk to the sr04
You have to follow through, rwgast: hit the links, read the material, and look at the pictures.
The two pins (Trig and Echo) get jumpered together.
Once the device gets triggered then it's locked out from further triggering and during that time the echoes don't loop back as re-triggers. After emitting the trigger, the pin has to be re-configured as an Input. Some slower microcontrollers may not be able to get that done fast enough (sort of guessing.)
So, have you tried getting one of those things running yet or what?
ya i very quickly hooked one up to a hw board and just pulled the raw data. i read through that first page and it jusp kept saying that the object allowed the sr04 to com on one pin, not alot detail probably shoulda read farther
lol i dont get it I ordered 2 from different vendors and got them 7 and 8 days from order then ordered 6 more last week from the same vendor. I had a problem with a nokia 5110 from china once stuck in new yourk for a week called the pot office turns out customs isnt overly motivated looking through cheap rat chinese shipping sometimes so they had just sat there took a month and a half to get the screen. Like I said im surprised these arrived so quick I dont excpect anything from china before 3 and a half weeks
Yea, It is kind of surprising to me. I have never had an issue with anything I order from China. I actually had forgotten about them until last week when a post on this thread came up!!! I double checked and sure enough, I had ordered 4 of them and paid. If they are not here tomorrow I told seller I want a refund or for them tou reship and show proof they did so.
I tested a BS2 Homework board and verified that one-pin mode does work with both cheap sensors, the HC-SR04 and 05. Both sensors return occasional "zero" readings whether in one- or two-pin mode; I guess that's just par for the course using $2 sensors. I tweaked the code from above slightly, the duration of the PULSOUT slightly affects the number of zeroes returned, so you can play with that for your particular sensor. And the IF statement filters zeroes out of the DEBUG display.
' {$STAMP BS2}
' {$PBASIC 2.5}
' HC-SR04/SR05 ultrasonic sensor 1-pin usage
' P1 to trigger
' 1K8 resistor from trigger to echo
MAIN:
PULSOUT 1,10
PULSIN 1, 1, W0
IF W0=0 THEN MAIN
W0=W0/72
DEBUG DEC W0,CR
GOTO MAIN
The Picaxe gurus maintain that this is the preferred method to use with this one-pin setup, faking a PULSOUT by setting the pin HIGH then using PULSIN to quickly end the output pulse, change the pin to an input, and begin the PULSIN measurement. I added a PAUSE between samples to damp sensor ringing and reduce zeroes. Works fine with a BS2 too. You can try reducing the PAUSE 50 (thus increasing the sample rate) until zeroes start coming back in the DEBUG screen.
DO
HIGH 1 ' start output "pulse" on P1
PULSIN 1, 1, W0 ' make P1 an input and measure return echo
W0=W0/72 ' convert to inches
DEBUG DEC W0,CR ' display data
PAUSE 50 ' delay stops ringing, reduces zeroes
LOOP
I tried this with the Prop and got numbers all over the place. Occationally the numbers looked accurate but if could have just been chance.
I haven't looked at the traces with an o'scope yet. That's probably my next step.
I know these sensors don't like much of a resistor between the Prop and the "trigger" pin since the Prop is only pulsing with 3.3V. It still seems like this should work with the Prop. It will just have to wait until my hexapod is walking.
I'm completely new to this so please forgive any erroneous lingo or newbie questions.
Alright, with that disclaimer I'd like to ask a question and hopefully someone can help me out.
I need a solution to remotely monitor and report back to the office the level of fluids remaining in a container. I'm an IT guy but I'm not a electronics engineer and I've essentially been tasked with creating this solution. There are several on the market but they are all above the price point we're willing to pay. With that in mind I've been researching different ways of monitoring and these ultrasonic sensors appear to be a viable solution but I would need a way to get the reading back to the office. Several companies use cell service to get the data (and it seems like the best solution) but I will need to account for lack of a service range... so incorporating something like a cell booster into the mix (wilson electronics maybe, external antenna, other ideas?) would be something to take into account.
I have several hurdles to overcome on this project, one being how to get the data from the field to a processing center. The other is how to receive and interpret that data, and lastly how to report that data to the appropriate salesmen. The first stage is to get a solution working that accurately measures the contents.
Does anyone have any suggestions or would be willing to lend their expertise?
Comments
yes, exactly, just use one pin for output (trigger) and another for input (echo).
Looks like your answers are in the last ebay link provided.
http://www.ebay.com/itm/10-x-Ultrasonic-Module-HC-SR04-Distance-Measuring-Transducer-Sensor-for-Arduino-/130705106799?pt=LH_DefaultDomain_0&hash=item1e6ea1a76f
Module works:
(1) using IO trigger distance, the high signal to at least 10us;
(2) module automatically sends eight 40khz square wave, automatically detects whether a signal return;
(3) a signal back, through the IO output a high electrical level, high electrical level duration is: the ultrasound time from launch to return. Test distance = (time of the high electrical level * speed of sound (340M / S)) / 2;
There's code in post #32 to use these with a Propeller.
I realize I didn't update the schematic when I modified the Ping code to use with these sensors. Here's an updated schematic.
┌───────────────────┐ │┌───┐ ┌───┐│ Connection To Propeller ││ ‣ │ SR04 │ ‣ ││ Remember SR04 Requires │└───┘ └───┘│ +5V Power Supply │ Vcc Trig Echo Gnd │ └──┬────┬────┬───┬──┘ 5V │ │ │ │  │ 1K  10K │ └───┘ │ │ │ │ │ │ trigger ┘ │ │ echo ─────┘ │ You don't really need the 1K resistor on the trigger line but you need at least a 3K on the echo line to protect the Prop from the 5V.
i had read that description on ebay but i guess what im not understanding is does it have to be 10us or can u do 16 pulses in 20us, also using the formula with speed of sound returns time in what seconds? then how do u convert to distance?
Send it a 10us pulse, that keys it to do its thing. In short order, prepare to receive a pulse back. The width of that reply pulse is proportional to the distance result (the emission and the echo.)
The speed of sound in air is 1,126 feet per second (13,512 inches per sec., 13.5 inches per millisecond, 0.0135in per usec, 343 mm per millisecond, 0.343mm per usec.)
So, given that, rig up an experiment.
PULSOUT that trigger pulse, get that PULSIN, DEBUG the result.
See what happens.
Agreed, the 10us figure isn't magic, it's just a safe value that the sensor should be sure to be able to detect. Once the sensor sees a pulse on the trigger line, it sends out a ultrasound "ping". I think it waits until the trigger goes low before sending the "ping" since it raise the echo pin high while the sound is travelling (both ways). As soon as it detects the first echo back, it lowers the echo pin.
You can measure the echo pulse length with the PULSIN command with a BS (as PJ suggested) or with a Propeller use the waitpne and waitpeq and time the interval.
From the Ping object (also my modified version):
(The "timer := -cnt" is a trick to time intervals with only one variable.)
Then you do the math PJ talked about.
If you use diodes and a pull-down resisitor you can have multiple sensors share the echo pin and just use a unique pin for each trigger line. Martin_H started a thread about using multiple sensors and I know I was able to use four sensors using five Prop I/O pins.
I used the figure "340m/s" from the ebay site. Wikipedia has a good article about the speed of sound. Humidity, temperature and other factors effect the speed of sound (but not enough you need to worry about it much).
i got so many i figured making lil tape measure with a 7 segment would be a neat simple project, also usefull for work and household tasks. although im worried about slight hand movements messing up the accuracy and causing bounce
I added an ultrasound to my Scribbler 2. The video of it moving around shows some of the short comings of using ultrasound. IR tends to be good at detecting object ultrasound has a hard time with so it's good to use both on a robot.
I believe the ultrasound I used on the S2 has a narrower beam than these ebay ultrasounds.
http://arduino.cc/forum/index.php/topic,106043.0.html
it says theres an arduino library that has been updated and allows 1 pin com with the sr04! maybe someone could turn this into a prop object or at least give a run down on how there using 1 pin to talk to the sr04
The two pins (Trig and Echo) get jumpered together.
Once the device gets triggered then it's locked out from further triggering and during that time the echoes don't loop back as re-triggers. After emitting the trigger, the pin has to be re-configured as an Input. Some slower microcontrollers may not be able to get that done fast enough (sort of guessing.)
So, have you tried getting one of those things running yet or what?
' {$STAMP BS2} ' {$PBASIC 2.5} ' HC-SR04/SR05 ultrasonic sensor 1-pin usage ' P1 to trigger ' 1K8 resistor from trigger to echo MAIN: PULSOUT 1,10 PULSIN 1, 1, W0 IF W0=0 THEN MAIN W0=W0/72 DEBUG DEC W0,CR GOTO MAINDO
HIGH 1 ' start output "pulse" on P1
PULSIN 1, 1, W0 ' make P1 an input and measure return echo
W0=W0/72 ' convert to inches
DEBUG DEC W0,CR ' display data
PAUSE 50 ' delay stops ringing, reduces zeroes
LOOP
Are getting good measurements?
I tried this with the Prop and got numbers all over the place. Occationally the numbers looked accurate but if could have just been chance.
I haven't looked at the traces with an o'scope yet. That's probably my next step.
I know these sensors don't like much of a resistor between the Prop and the "trigger" pin since the Prop is only pulsing with 3.3V. It still seems like this should work with the Prop. It will just have to wait until my hexapod is walking.
That PING was also a pistol on the S2, wasn't it? Maybe Parallax needs to introduce the PINGpal for use with the Propeller.
Alright, with that disclaimer I'd like to ask a question and hopefully someone can help me out.
I need a solution to remotely monitor and report back to the office the level of fluids remaining in a container. I'm an IT guy but I'm not a electronics engineer and I've essentially been tasked with creating this solution. There are several on the market but they are all above the price point we're willing to pay. With that in mind I've been researching different ways of monitoring and these ultrasonic sensors appear to be a viable solution but I would need a way to get the reading back to the office. Several companies use cell service to get the data (and it seems like the best solution) but I will need to account for lack of a service range... so incorporating something like a cell booster into the mix (wilson electronics maybe, external antenna, other ideas?) would be something to take into account.
I have several hurdles to overcome on this project, one being how to get the data from the field to a processing center. The other is how to receive and interpret that data, and lastly how to report that data to the appropriate salesmen. The first stage is to get a solution working that accurately measures the contents.
Does anyone have any suggestions or would be willing to lend their expertise?
A 10-pack of ultrasonic sensors for $16.44, free ship! Gettin' ridiculous now.