Ultrasonic Range Finder

[adjit]

You can't get distance, even with pulsing transmitter.

Honestly, I'm not understanding why I wouldn't be able to use the pulseIn() function in the loop() to get the duration in between every pulse.

If I set up a transmitter to emit a pulse every 29 microseconds (to account for the 'dead zone') I can use the time in between pulses to calculate the distance from that receiver.

Then I will have a few variables that I would need to account for - for example the speed of sound through a given medium at a given temperature. I would easily be able to figure out the speed of sound in my current settings because of my fixed starting position. Since I know that my transmitter is starting at n centimeters from the receiver I can use this to figure out how many microseconds it takes for the sound to travel n cm and now use that to determine the distance based on the duration in between emitted pings.

reply #4 never said that it wouldn't be possible to get the distance. As reply#4 had stated you will have to find the intersection of the hyperbolic planes. Because you will get a distance calculation of d in any direction. In my case I will have 4 hyperbolic planes

[Magician]

I would easily be able to figure out the speed of sound in my current settings because of my fixed starting position. Since I know that my transmitter is starting at n centimeters from the receiver I can use this to figure out how many microseconds it takes for the sound to travel n cm and now use that to determine the distance based on the duration in between emitted pings.

Is it my limited vocabulary or paragraph above in "android - java/40" language? Sorry, I don't understand a single word out of it.

[johnwasser]

You can't tell how long the sound has been traveling if you don't know when it was sent. If you rely on pulses being sent on a certain schedule you still need to synchronize the schedules at the sender and the receiver and use clocks that are accurate enough that drift doesn't become a problem. 

[AWOL]

If I set up a transmitter to emit a pulse every 29 microseconds

And the period of one 40kHz cycle is. . . ?

[RogerRowland]

Honestly, I'm not understanding why I wouldn't be able to use the pulseIn() function in the loop() to get the duration in between every pulse.

If I set up a transmitter to emit a pulse every 29 microseconds (to account for the 'dead zone') I can use the time in between pulses to calculate the distance from that receiver.

I think you're not quite understanding what people have been saying. If your transmitter emits a pulse every 29us, then your receivers will receive a pulse every 29us, whether they are 10cm away or a mile away. So, that tells you nothing. What you need to know is the time taken from when a pulse is transmitted by the transmitter to the time that the same pulse is received by each receiver, and that needs synchronisation between transmitter and receivers.

[adjit]

If your transmitter emits a pulse every 29us, then your receivers will receive a pulse every 29us, whether they are 10cm away or a mile away.

Ahh, yes that makes sense. I was thinking that an initial sync would fix that - just hadn't figured out yet how I could achieve this without knowing anything from the transmitter except that it is emitting a 40Khz wave at 29us. What if I set something up a sync so that when the transmitter begins its movement I have a counter to see how many pulses were detected and a timer so that I know how many pulses should have been emitted.

ie. if the timer has been running for 1000us I know that there should have been 34 pulses, but if my pulse counter is only at 32 pulses that means the last pulse was sent at 928us. So that tells us this pulse took 72us to travel to the receiver.

The way that I would synchronize the running timer using the millis() function. Tell my arduino, wait for the first pulse, once you have that first pulse get millis() and store the value as the millis() offset. Now every pulse after that I get use millis() subtract out the offset value and I have my run time since the first pulse.

Again, in theory this sounds doable.

And the period of one 40kHz cycle is. . . ?

Would the period matter if I am just checking for a pulse?  It would seem like a better idea to use a period of 1 40Khz cycle. I don't know how to do that, but I suspect I will most likely try to achieve this with a 555 timer.

[RogerRowland]

Scroll back up to reply #4 by @johnwasser and read it again, you have all the advice you need there. 

And, as @AWOL said, you should be able to figure out that you couldn't send a 40kHz pulse every 29us. A 40kHz pulse has a period of 25us.

You need to slow down and think this through, taking into account the answers you've been given and ignore (for the moment) your own preferred solution. You'll soon realise where you're going astray.

[AWOL]

Also, the common Murata-style piezo devices ring badly - you may try to send a train of eight cycles, bit they'll ring for another four or five.

[adjit]

So I had been thinking about a number of different options:

• Radio transmitter to synchronize the transmitter/receiver. Obviously this seems like the easiest option, however, I would like to try and achieve this without requiring extra hardware to accompany the transmitter.
• Go by the time difference between each received signal. This could work for my purpose because I just need to know the general direction
• Try and figure out someway to sync up the transmitter and receiver

So option 2 could work for my process. I have one of those Syma $20 helicopters that I can send commands to using the Arduino - my idea being get the helicopter to land on it's own using the ultrasonic transmitter and receivers to zero in on the 'landing zone'. If I go with option 2 - at least at the start I could send interval commands to the helicopter and then re-asses the position / direction.

A couple of issues with this option:

• How would I be able to determine the orientation of the helicopter?
• What about measuring the altitude of the helicopter?

Possible solutions:

• At the initiation of landing protocol run a quick test to move the helicopter in a certain direction and see how that effects the receivers. This way if I go forward I can use the new time differential in order to figure out which way the helicopter moved (further, closer, left, right) and orient it properly - then retest
• Not going to worry too much about altitude for now, however, if all the receivers are receiving a pulse at the same time then you know the helicopter is directly over the receivers and can tell it to slowly descend.

I already see the issues that will arise from this because sound is not exactly the best range finder - in fact I would be shocked if I could get it to land on the right spot. I just haven't been able to find any 'easy' 3d motion tracking ideas.

[AWOL]

I just haven't been able to find any 'easy' 3d motion tracking ideas.

Maybe that's because there aren't any.

[adjit]

Maybe that's because there aren't any.

Hence the quotes. Just trying to figure out what would be the best method of achieving this. Or at least measuring distance of one object to another.

If I am going to be putting a radio control on the transmitter than I might as well use 2 gps units. I think it would be much more accurate at a distance, and it gets rid of a lot of complications and drift errors that could occur with using sound waves.

Could you point me in the right direction of doing something like that so I can research it a bit?