# Ultrasonic Range Finder

Want to avoid having to use some form of radio trigger for the transmitter and receivers. Is this really necessary? Because if I can get a baseline ping distance for each of the 4 sensors I should be able to determine which direction the transmitter is heading in.

You have to add a radio trigger to get the receiver and sender in sync these ultrasonic sensors are very time sensitive, ive done a project with them like yours but with only 2 receivers it works very well.

If you do not use a simultaneous trigger and you work out the shortest distance in cm to get your position just note your receivers need to be +- 30cm apart from each other to get a good differential reading between all the receivers .

M...........

Undermentioned: If you do not use a simultaneous trigger and you work out the shortest distance in cm to get your position just note your receivers need to be +- 30cm apart from each other to get a good differential reading between all the receivers .

That can work - I have a 15"x15" sheet of ABS plastic that I got from servo city. Would you be able to show me your design / how you did this without a radio trigger and what ultrasonic transmitter and receivers you used?

It's not necessarily to place transmitter on moving object, you can trace "passive" things. http://hackaday.com/2014/08/24/a-virtual-touchscreen-3d-ultrasonic-radar/

All depends on distance and resolution you need to achieve, you know wavelength and elementary school geometry (?) , do your math to see if you can get away w/o phase calculation, simply have 4 synchronous receivers.

That's an interesting concept, however that would not work for me, because I need a range of more than 3m. The transmitter is going to be moving far away - 10+m

I think I know what I need for now -

At least for proof of concept I am going to need to get 2 ultrasonic transducers - most likely 40Khz and then test to see if I can track distance and even create a transmitter to constantly send pings.

I have found a good independent ultrasonic transmitter and receiver that seems like it could fit my needs. If you look at some of the videos at the bottom of the page (primarily the one with the oscilloscope) you can see the 40Khz wave that is being received. Now I just need to figure out how to determine the distance if the transmitter is always on...

Does anyone have any ideas on how I can measure the distance of the transmitter to the receiver? - Transmitter will have a fixed starting position x cm away from the receiver. x will be known - The transmitter will be always on at 40Khz when it is moving, however thinking about it I may need to have it pulse - am I correct in thinking this? if so how should I go about achieving this?

Now I just need to figure out how to determine the distance if the transmitter is always on...

How long have you got?

AWOL: How long have you got?

Care to elaborate?

I am assuming that means it is impossible. Because if the transmitter is always on at 40Khz there is no way to figure that out.

Instead what I think I need to do is make a circuit that can pulse the transmitter on/off at a certain interval that I can control. Maybe I'll be better off getting an adruino micro and programming that to pulse at a certain interval. But I believe this can be done with a circuit. Do you have any ideas?

adjit: Instead what I think I need to do is make a circuit that can pulse the transmitter on/off at a certain interval that I can control. Maybe I'll be better off getting an adruino micro and programming that to pulse at a certain interval. But I believe this can be done with a circuit. Do you have any ideas?

A 555 timer is common and cheap. Easy to make a 40Khz transmitter with that. A second 555 can be used to turn the transmitter on/off with a certain duty cycle. You can also use one 556 that has two 555s in one IC. Plenty of diagrams online. Leo..

Does anyone have any ideas on how I can measure the distance of the transmitter to the receiver? - Transmitter will have a fixed starting position x cm away from the receiver. x will be known - The transmitter will be always on at 40Khz when it is moving, however thinking about it I may need to have it pulse - am I correct in thinking this? if so how should I go about achieving this?

You can't get distance, even with pulsing transmitter. Reference timing required, for example: - RF ping (reply #4 already advised this option); - IR ping, though it's not clear what distance you want to measure, IR can't traveled too far; - two parts ( transmitter & receiver ) synchronized to the same clock (GPS) - costly, you need 2 GPS ; - two parts have precise OCXO, and "preset" initially, not cheap again. So, reply #4 is the best option, with a radio set bundle 434 MHZ for 1-2\$

Magician: 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

adjit: 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.

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.

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

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

adjit: 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.

RogerRowland: 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.

AWOL: 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.

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.

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.

• 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.

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

Maybe that's because there aren't any.

AWOL: 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?