Ping))) #28015 Troubles

uidzer0

Hey everyone,

I am attempting to get started with this Ping ultrasonic distance meter #28015. The datasheet specifies a 5us burst to SIG, then a 750us holdoff, then an output from SIG for 18.5us - 115us. For some reason I don't seem to be getting any signal from the SIG pin. The "ACT" light does come on and I can hear a slight pitch coming from the device. Is there anything else special that is needed?

Attached is the signal when hooked to a scope. You can see the 5us output to SIG but nothing from SIG. Any ideas?

Thanks!

Ben

Mike Green

How do you have it hooked up? What's your power source. There's nothing special needed other than a 5us trigger pulse and a bi-directional signal driver that can listen with a high impedance for the output pulse.

uidzer0

Exactly! I've got a 7805 supplying 5v and GND going to GND. I have an ATMega16 sending the 5us pulse as you can see in the scope photo. I'm stumped.

Phil Pilgrim (PhiPi)

You're not waiting long enough. The wait time for an echo can vary from 115uS to 18.5mS. Also, make sure the I/O pin is tri-stated during that time.

-Phil

uidzer0

Hey everyone, thanks for the replies -

I took another look this morning before work and managed to get a signal coming back from the device. My question is, at what points should the pin go from High to Low to Tri-State on the timeline? The reason I ask is because the signal coming back from the Ping))) appears to be accurate only to about 20cm after that it gets very unstable. I'm thinking I've just got the timing on the pin states a little off. Any help would be great.

Thanks again,

Ben

Mike Green

The Propeller code is a pretty good example. It uses the minimum pulse width (2us) and immediately tri-states the pin (within 1-2us). I'd still stick with the 5us pulse width and tri-state the I/O pin within another 5us, then wait for the low to high edge of the response. You time the width of the response, then wait for another 200us (per spec) before issuing another start pulse.

uidzer0

Thanks Mike, I'll try that out again. Is it possible that ambient noise could cause the sensor to malfunction?

Chris Savage

Hello,

Ambient noise (depending on frequency) could cause erratic readings, but not cause the sensor to malfunction. Once triggered you will get a return pulse, whose width is determined by how the sound takes to return up to the maximum width. The Propeller Object does the following…

Clear the I/O pin (make it low, in case it was previously set).
Make the pin an output.
Set the I/O pin (make it high).
Make the I/O pin an input (in SPIN, the effective time to do this is > 2 us).
Wait for the I/O pin to go high (this is the start of the pulse).
Store the current counter value.
Wait for the I/O pin to go low (end of pulse).
Store the current counter value.
Subtracting the old counter value from the new one gives you the number of clock ticks and you can then calculate the time and distance.

Note that after your trigger pulse you should immediately make your I/O pin an input. I’ve had several people contact me saying they were never seeing a return pulse. Most had never made the I/O pin an input and in two cases, they were using a signal generator to generate pulses with a scope connected to ‘see’ the return pulse. The problem is that the signal generator is asserting the line and the scope will never see the PING))) return pulse in that case. I hope this helps. Take care.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support

uidzer0

Hey everyone,

Thanks for the help getting this thing going - I managed to get a good signal coming from the sensor. I've got another issue now·but I don't think this is the right forum for that one =].

Thanks again!

Ben

Post Edited By Moderator (Chris Savage (Parallax)) : 1/9/2008 3:26:31 PM GMT