Introduction: Hacking Automotive Ultrasonic Sensors

Picture of Hacking Automotive Ultrasonic Sensors

This instructable will show you how to hack / reuse a common Bosch automotive ultrasonic sensor(s).  The sensor in this instructable is a very common sensor that can be found in junkyards all over the world.  The hope is that this information will allow folks to reuse these sensors in wonderful new applications.

There are many advantages to using automotive ultrasonic sensors.
  • Easily detect objects within a two meter range.
  • Detect multiple objects within the sensor's field of view.  This particular sensor returns all echoes after a ping event.  In contrast, many hobbyist sensors only return the distance to the first detected object.
  • All Digital.  No analog signals are used between the control module and sensors.  In other words, the sensors are all digital.  Note, the first generation automotive sensors were analog and had many problems.  Many aftermarket systems are still analog!
  • Water proof.  Both the sensor and the connector are completely water proof.  Remember, these sensors live inside a vehicle fascia.  The inside surface of a fascia is a very tough environment!
  • Short circuit proof.  The IO pins can be shorted to battery, or ground, or in any combination without harm to the sensor.  This includes reverse battery and double (24 Volts) battery connections.  Believe it, or not, but modern vehicles are still designed to allow good old back country boys to connect two batteries in series so that their trucks can start really fast! Legacy automotive requirement, I'm guessing.
  • EMI (electromagnetic interference) resistant.  The sensor has been through a lot of testing to prove it's capable of both being resistant to EMI interference and resistant to generating EMI noise.  The EMI tests take weeks - being able to pass automotive EMI requirements is a really big deal!
  • Hardened.  The face of the sensor is electro primed and painted solid aluminum.  The rest of the sensor is plastic with the electronics rubber potted.
  • Shock proof.  Again, the sensor design had to prove it's self in a whole battery of tests.  Again, remember that fascia mounting location - bumpy place to live.
  • Zap Proof.  Each of the sensor pin is tested during EMC (electromagnetic compatibility) testing to verify it can survive a high voltage discharge.  I think the test requires surviving a 15kV zap on each pin!  Nothing worst than watching this test being performed on your product at the EMC lab.  I'm convinced, watching this took years off my lifespan!
  • Temperature proof.  Tested from -40 degrees C to +85 C.  There is also thermal shock tests that must be passed.  Living in a fascia is not easy.
  • Expandable.  Multiple sensors can easily be used to cover any portion of 360 degrees.  As an example, it would be easy to use eight sensors on a robot where the sensors were placed at 45 degree increments around a circle.  The robot could then have a complete 360 degree view with no moving parts!
  • Fast.  One ping out two meters and back takes just under 50ms (milliseconds).  The 50ms I quote actually includes two pings (to double verify) and guard-band time.  See below for more on this.
  • Smart.  A sensor can be commanded to generate a ping or, instead, to simply listen.  Using a pinging sensor and one, or more, listening sensors tricks can be done to detect additional (very close) objects.  More on this below too.
  • Elliptical Pattern.  The ultrasonic pattern generated is purposely not circular as you might expect.  Otherwise, the sensor would get echoes off the ground.  Turns out, the lip of a pot hole reflects a lot of ultrasonic energy.
  • Low Power. A sensor only draws about 20 to 25mA.  About the same amount of energy used to light a standard LED.
OK, these sensors are just about as bullet proof as possible.  Needless to say, if you find yourself in possession of one of these sensors, and it has not been smashed, it is most likely a good one.  In other words, if the sensor shows no sign of mechanical abuse it is probably good.

These sensors can be found in junkyards all over the world.  The sensor used in this instructable come from Bosch and are widely used in GM and Chrysler vehicles.  I believe, but don't know for sure, that the sensor are also used in many European vehicles too.  After all, this is Bosch (a German company) we're talking about.

A disclaimer is in order.  I worked for a small supplier who also produced ultrasonic sensors for GM.  However, that was three years ago.  I never had, nor ever learned of, any direct knowledge of how a Bosch ultrasonic sensor / system is designed or how it is used or operated.  The GM engineers were very careful not to divulge anything (other than warranty info) concerning competing suppliers. 

All information in this instructable came by way of reverse engineering my wife's 2008 GM Tahoe which had a reverse backup system factory installed.  For sure, these sensor operates completely different than the system I was involved with.  Although I really like these sensors, I have no love loss for Bosch as a company.  They put it to us every chance they got.

It just kills me that these sensors are going unused by the hacker community.  After all, over 100 million Bosch ultrasonic sensors have been produced since being introduced in 1993.  This factoid can directly off their web site.  Let me say it again because it is astounding, there have been 100,000,000 ultrasonic sensors produced by Bosch since 1993.  However, Valeo's web site claims they are the world's largest ultrasonic automotive supplier.  So, Valeo (who introduced the sensor in 1991) has produced even more!  Wow, so there are a lot of sensors out there.  Note, Valeo (a French company) supplies ultrasonic sensors to Ford, as well as to European manufactures.

OK, head out to your local junkyard and look for any GM or Chrysler vehicle that was manufactured since 2006.  This particular sensor design might even go back even farther - I just don't know.  Still, there are plenty of 2006 through 2011 GM and Chrysler vehicles around to plunder.  Go get 'em boys and girls.  Oh, don't forget to snag the wire harness in the fascia too.  Those water proof sensor connectors are very precious.  You'll need those connectors later on.

When looking for sensors make sure they match the first picture below.  Bosch laser etches their name right into the sensor plastic housing.  Never mind GM does not allow suppliers to mark their name on their own product.  Bosch seems to get away with ignoring this GM rule.  Look for the Bosch name and logo, and also that the sensor shape matches the picture in this instructable.  With a matching logo and shape you have the right sensor.  You should not have any problem finding these sensors.  My local junkyard quoted me $30 bucks for a set of four sensors (harness included).

There is also a bunch more information on my web site which shows "procuring" sensors from my wife's Tahoe.  I've also got a bunch of info on my site about reverse engineering the ultrasonic park assist (UPA) module.  The info is mostly about getting the UPA module tricked into operating on my bench once removed from the vehicle. Below is a link to the site.

Step 1: Hardware

Picture of Hardware

Each sensor has three pins. The pins are +8.5 volt supply, single wire half duplex comm, and ground.  In a vehicle, the UPA module provides the 8.5 volt regulated supply to the sensors.  The UPA is able to switch this supply on, and off, at will.  As an example, while traveling down the highway the sensors are switched off.  When the vehicle slows below some magic speed threshold the sensors are switched back on.

The single wire comm between the UPA module and sensor seems a bit strange to me.  When inactive the bus is idle at eight volts.  In an open collector kinda fashion, the UPA module and sensor communicate using pulses which pull the bus low for short pulses.  The strange part is that the UPA sends digital commands to the sensor and the sensor responds with either a digital waveform that looks like the actual echo, or normal digital bits.  It depends on the command.  For the echo response it's like they just took the analog right off the piezo element, ran it through a op-amp comparator, and sent the op-amp output out into the comm wire.  It's strange and slick at the same time.  Downside is, the micro has to use a fast timer to measure all those echo pulses.  No simple UART action to receive an echo response.

After power-up, the UPA sends a bunch of data to the sensor.  I'm guessing the first set of pulses initialize the sensor with a certain gain level.  I'm guessing each different type of vehicle has a different initialization string of data pulses.  Looks like the UPA then sends a couple of reset commands to the sensor.  Of course, there is an acknowledgment from the sensor.  Finally, a sensor scan sequence starts on the UPA where one sensors is commanded to ping while one or two other sensors are simultaneously commanded to listen only.  Using one sensor to ping and one / two sensors to listen allows very close objects to be detected.  All the results from the sensors are sucked up by the micro in the UPA.  Note, the Star12 micro in the UPA can capture timer values based on pulses come in.  There are eight pins on the Star12 that have this ability.  So, a pulse triggers the Start12 to capture the timer automatically, at the same time an interrupt flag is set for that pin.  In the interrupt routine the micro buffers off the captured value, clears the interrupt flag, and returns.  The cool part is that captured timer value is done in hardware right when the trigger happens.  So, even if there is jitter in the interrupt response, it doesn't matter because the timer had already been captured.  Motorola really knows how to design automotive micros.  OK, I admit it, as an X Motorola employee I still have a soft spot for old Moto.  Note, Motorola sold the micro division to Freescale some 6 / 8 years ago.  Motorola has also sold my old automotive division. 

Do you how Motorola got it's name?  Well, a 100 years ago a Victrola played records.  So, Motorola got it's name by putting a Victrola (not an actual Victrola but just the idea playing a record) in a Motor vehicle. Motor Car + Victrola = Motorola Car Radio.  Motorola got its start by manufacturing automotive radios.  Now, Motorola is totally out of the automotive business.  Makes me sad. Anyway, a bit of trivia. 

Back to the hardware setup.  The development board shown below that I built interfaces four sensors to an MBed development micro.  Each sensor must have a buffer circuit to convert the bus voltages down to the 3.3V TTL values used by the MBed micro.  You can think of the sensor bus as a half duplex communications bus.  It appears the communications on the bus is 9600 baud serial.  At lease my LSA (logic state analyzer) can decode the pulses if set to 9600 baud.

I simply used pins P21 through P28 on the MBed to interface to the four sensors on my development board.  The MBed looks to be even better at processing pulse trains than the Star12.  It has all the bells and whistles that the Star12 does, plus a lot more.

Step 2: Software

Picture of Software

Now for some software.

Below are a couple of LSA (logic state analyzer) plots that show communications between the UPA module and the sensors.

The plan is understand these plots to a point where I can have the MBed reproduce them.  If the MBed could create the pulse trains then maybe the sensor could be convinced to operate normally.

Have a look at the oscilloscope plot below.  It's a good thing I got off my duffs and hooked up my scope.  The scope makes it possible to distinguish between the micro and sensor in terms of who is actively talking on the bus.  The scope plot shows a ping command being sent and the sensor's immediate response.  The distinction can be made based on the voltage level during a low level on the bus.  The UPA pulls the bus to a lower voltage level than the sensor does.  Well, that discovery sure came in handy!

Developing the MBed source code became a mater of slowly reproducing the pulse train that I captured with the LSA.

Right after power-up, it appears that the UPA sends a bunch of data to the sensors.  The two sensors mounted in the middle of the fascia get one set of data and the two outside sensors get a different set.  I'm guessing the two center sensors are setup with a higher gain value than the outside two sensors.  It's also likely these values are different between different vehicle platforms.  Doesn't really matter, I've captured both sets and can reproduce either one with the MBed.

After the initialization pulses there are another pair of pulses.  Maybe a couple of reset commands?  Not sure.  Again, I've got source code for the MBed which can reproduce them.

Finally, the UPA module goes into active sensor scan mode.  This scan mode consists of pinging and listening to the sensors in a round robin fashion.  Note, a sensor can be commanded to ping, or, only listen.  So, another trick.  At the same instant in time, the UPA commands one sensor to ping while commanding another sensor (or two) to listen.  If an object is right in front of the sensor that generated the ping then that sensor probably won't hear the return echo.  This is know as the ring-down problem.  When a sensor generates a ping there is a time delay before it can receive any echoes back.  A close object's return echo is likely lost in this dwell time.  A listen only sensor does not have a ring-down dead time.  Therefore, the ultrasonic energy is produced on one sensor (the pinging sensor), the energy bounces off a nearby object and returns to a different sensor. Cool uh?

Let me restate the ring-down problem because my description above was probably confusing.  A sensor can act as a ultrasonic loudspeaker, or, as a ultrasonic microphone.  Switching between loudspeaker mode to microphone mode takes a bit of time because the face of the sensor still vibrates for a short time after the piezo element stops.  The dwell time between mode is called ring-down and all single element sensors have this problem.  Ring-down dictates how close an object can be detected.  For these sensors that is about 16cm.

With the hardware and software in place the sensors can now be controlled without much problem.  The attached MBed code initializes the sensors and then starts actively pinging them. 

The MBed code can be modified easily to sue other applications.  The goal was to simply provide a foundation of code that can be adapted to other uses.

Update: After a bit of testing, I discovered the sensor will respond to ping commands even if the initialization data is not sent to the sensor at power-up.  The sensor must store the calibration data in flash, or EEPROM.  The production UPA module resends the data on each power cycle just for good measure. 

Step 3: Decoding the Results

Picture of Decoding the Results

I made some notes off the Wikipedia site that had to do with the speed of sound. The notable fact is that sound takes about 900us (microseconds) to travel one foot.  This is in dry air at standard temperature (25 degrees C) and standard pressure (sea level).  As temperature goes down the speed of sound goes down too.  This means time to travel that one foot goes up.  If the temperature is reduced to -25 degrees C it will take an extra 72 microseconds for the sound to cover that same foot!  Shocking, I know.

OK, lets sort out some expected timing.  Even though the sensors are only designed to reach out two meters lets plan on three just to be safe.  Who knows, maybe there will be some big monster object that can bounce ultrasonic energy back from three meters.

If we plan to measure out to a maximum of three meters then the sound will actually be traveling three meters out, bounce off some big object, and then travel three meters back.  Round trip is six meters.  Well, sound travels at 2939 microseconds / meter.  Therefore, we can expect 6 meters to take 17.634 milliseconds.  Lets round that up to a nice whole number of 18ms.

Now, since we're pounding the environment with ultrasonic energy strange things can happen.  Our ping could actually travel even further out and hit some super reflector (garbage dumpers are an awesome reflector) and bounce back.  If we immediately start another ping we might get a false mixing of the current ping with the previous ping which took the long way home.  Not good.  To prevent this, better to add a dwell time, or guard-band time, between each ping.  Lets add another 18ms for the surrounding environment to go ultrasonic sound quit after our ping.

Because of spurious noise in the environment it's best to double verify objects instead of relying on a single ping.  There is lots of junk in the environment the generates ultrasonic energy.  Therefore, ping the object a second time to verify it's location.  The odds that a noise source being seen at the exact same distance are slim.

Therefore, object detection goes like this: ping, guard-band, second ping, second guard-band.

Grand total, then, to declare an object as "real" is two pings with two guard-bands (18ms * 4) equals 72ms. This is worst case (most robust) timing. Note, we can also simultaneously collect echoes from listening sensor without any time penalty.  However, the geometry between pinging sensor and listening sensor must be accounted for to determine actual distance to the object.

Since we have total control over the sensors we could program them to any other timing we wish. I've never tried this, but, how about pinging all the sensors at the same time! Bang! Talk about pounding the environment with ultrasonic energy.


Well, that's about it.  I have a bunch more info on my web site concerning the UPA module and reverse engineering the system.  If your interested have a look at:



aantolin (author)2018-01-04

Hi Jim,

I'm currently working on a project where I was given 4 sensors and a UPA already taken out of the vehicle. I am planning on sending communicating with the UPA with a raspberry Pi. Any chance you can share the CAN messages required to trick the UPA into thinking that its in a running vehicle?

DanielR587 (author)2017-05-03

Could these be used to make an ultrasonic parts cleaner?

SteveR217 (author)2016-11-04

Any idea if the control box on a car can be faked out into thinking one of these is still connected ( I have a bashed in one that causes the system to fail)

maybe a cap or resistor acros common and ground?

abdelhakM4 (author)2016-06-13

hi can i use this ultrasonic sensor with the arduino

t0x0pg (author)2015-07-18

Hi Jim

I'm getting 404s on your website when I try to pull up the posts related to this article. Any chance you can fix it, or repost them if you still have the archive?

Thanks a bunch, this is really nice work.

jimk3038 (author)t0x0pg2016-05-08

Sorry for the crazy long time to respond. However, I recently discovered the Way Back Machine has an archive of my old web site. Here is a link.

Hope this helps,


ssuther1 (author)2016-05-08

Hi Jim,

I'm having the same problem - would very much enjoy looking at your full docs!


jimk3038 (author)ssuther12016-05-08

My poor little web site is long dead. However, looks like the good folks at the Way Back Machine made an archive. Here is a link to their archive of my old web site:

Hope this helps,

PaulMakesThings (author)2015-05-07

Glad you wrote this. I just pulled some of these sensors from a discarded bumper cover and when I was searching for info on how to use them google brought me to your Instructable. I'm going to see if I can implement this with a PIC or a PSoC.

gregordraksic (author)2015-04-07

Hello. I would also like to read more about this article, but your webpage is down. Best wishes.

allenpan (author)2015-04-02

Hello can you let me know if your webpage is restored? i am interested in reading more

allenpan (author)2015-04-02

hello, your website is down....i would like to access it for more info

michael.pail (author)2014-10-31

I'm looking at your step 1 schematic and I believe your top PNP BJT is in "upside-down". You have the emitter at the bottom when I think it needs to be at the top. Correct?

jimk3038 (author)michael.pail2014-11-03

It's been a really long time since I looked at any of this stuff.

However, I recently posted an update on my website that corrected some hardware issues. Have a look at the following and see if it looks correct to you:



fabcira (author)jimk30382015-03-20

Hi Jim,

great article. The site seems to be down, unfortunately. Any way to bring it back on? Thanks Fabio

michael.pail (author)jimk30382014-11-04

Yes, looks right now! Thanks for taking the time to contact me. Great
article, BTW.

manu1975 (author)2014-12-23


This instructable open a world of great sensors at low-no cost!

BruceW2 (author)2014-11-05

Hi. I wonder if you could take a few moments to give me some advice please

I have a 2007 vintage Audi on which I am changing the front bumper and grille to a later facelifted design

The old design had 4 identical park sensors (Valeo) all in the bumper. The new design has 2 in the bumper (outer corners) and 2 mounted in the grille; still Valeo and superficially the same.

Problem is the old sensors will not fit in the 2 new grille mounting positions. They need to have the connector plugs coming straight out the back, instead of at right angles as shown in your pics of the Bosch items

I also have 4 original sensors still in the rear bumper, and the controller is also original. Not really viable to change the controller and all 8 sensors to the correct latest part numbers, especially as the system interfaces with the rear camera and the whole "MMI" system in the Audi

My question, in a nutshell: What is the chance the sensors from 2010 which will fit my grille (plugs straight out the back of the sensor) are electrically compatible with the rest of the system from the same model car in 2007?

Audi give their Valeo sensors a huge range of different part numbers. Most people selling aftermarket replacement sensors seem to think that if they look much the same, then they work the same, but having read your piece on how they work and the exchange of digital data, etc, I am skeptical

Any advice much appreciated :)

sn2dlwith (author)2014-02-25


I was reading your link over on and was wondering if there would be a way to simply test a bunch of these for proper operation? I might be able to get a large quantity of these and want to test them before selling them, to make sure they work. Any idea how to set that up on a bench, rather than just plugging them into a vehicle?

jimk3038 (author)sn2dlwith2014-02-28

Did you see this page over on my site:

This page shows how an mbed, which is a little development board, can "talk" to a sensor. This page is kinda lost several layers deep so you might have missed it. Anyway, I think this is what your looking for.

Good Luck,


mosseltje (author)2013-12-30

I would love to use these sensors in a domestic water tank.
Any Idea if they could be used with a 1-wire or rs323 interface (home automation) ?

jimk3038 (author)mosseltje2013-12-30

I'm assuming your trying to measure the water level in some kinda tank in your home? Maybe for growing plants? Because, a hot water tank runs full all the time.

Anyway, to answer your question, the sensors need some kinda micro to command them to measure the distance. Once the distance is measured, the micro could report the results back using RS-232. The micro could probably fake its way onto the 1-wire bus too. But I'm not sure about that.

But yes, the sensors being water proof would work well in a wet environment. You just need a micro (like an Arduino) to control them.

Good Luck,

nmsr1196 (author)2013-12-11

Very Cool Project.
Would yo happen to have code for a picaxe or basic stamp?

jimk3038 (author)nmsr11962013-12-11

Sorry, just the MBed is all I have code for.

Good Luck,

Pole Cat (author)2011-12-20

Is there any way to tell what cone angle the Bosch sensors are and how many feet they detect? I 'm replacing an OEM bumper with an aftermarket and what to make sure befor I drill holes in an expensive bumper.
GM 15797507
BOSCH 0 263 003 548 864
2257B 080128/Q5
BOSCH assembled in Mexico

jimk3038 (author)Pole Cat2011-12-21

Pole Cat,

The GM specification is that these sensors must detect out to a distance of 2.0 meters. It's a stretch for these sensors to reach that distance.

The standard GM spec also specifies a FOV (Field-Of-View) study to be done. We had a 2.5 meter square mat that we laided out behind a test vehicle. The mat had a printed 10cm grid on its surface. The spec then called for a 10cm pole be placed around the mat while testing when the system reported an object. This is easy to do with a GM car. Just turn the key to "on" with the engine off. Drop the PRNDL (GM speak for Park-Reverse-Neutral-Drive-Low ie the gear shifter) into reverse. A car with an existing backup system will then go active and you can play with it.

Living in the US we didn't have a "10cm pole" so we simply used a standard 3" PVC pipe which was about 3 1/2 feet long. The pole was cut well so it would stand up on its end.

We would mark the mat where the pole was detected by placing a post-it note on the mat where the pole was first reported. After the entire FOV was mapped out I would stand on the top of 10' ladder and take a picture. One of our secretaries would then convert the image into a Inkscape drawing for presentation at GM. All in all, a major pain in the backside.

The FOV was basically a box shaped envelope that extended out 2 meters from the back of the car. The side of the FOV should not extend out more than a 1/2 meter, ideally.

A bigger problem than FOV is the sensor mounting angle. Have a look at the attached picture. We used this to measure the up angle of the sensor. Using the steel bar, press bar flat on the face of a sensor. Then, use the tilt gauge to measure the sensor mounting angle. The sensor should be mounted such that the angle is +5 to 15 degree positive. With anything less the sensor will start to "see" pot holes and cracks on the surface.

Mounting the sensors can be tricky. The sensors must be mounted high enough off the ground, have a 5 to 15 up angle, and not be mounted to far around the corner of the fascia so that they pickup side object.

Oh, and you gotta mount the sensors in a retainer clip with a silicon isolator ring. The retainer clip can also help with getting the sensor up angle.

There is a bunch more info on my web site about this subject too. Here is a direct link:

I hope I didn't scare you will all the detail. Most of this was just GM over kill. The sensors, and sensor mounting, is pretty forgiving. As you can imaging, if your going into production with a vehicle you want the mounting to be perfect.

Hope your install work well,

kdm06d (author)2011-12-02

This is a great instructable, Jim! Do you know anything about the circuitry inside the sensor? Is that a chip in there which communicates on the half-duplex comm wire? Wondering what kinda specs that chip has and if its EEPROM etc...

jimk3038 (author)kdm06d2011-12-02

The chip is a custom designed ASIC just for this application. So no, there is no public information about the chip specifically.

However, I put a bunch more info on my person web site. You can find it all here:

Thanks for the nice comments,

kdm06d (author)jimk30382011-12-02

Wow, designing an ASIC is time consuming. It's noted numerous times here (section 1:Hardware) that the sensor runs off of 8.5V.

On your page (See link below) under "Sorting Out the Pinouts" page, item 3 LM2941S, part a reads "a.Linear Regulator – Provides a regulated 5Vdc / 1Amp output for the sensors."

I don't see the difference in the 8.5V and the 5V. The delta V on your oscilloscope is < 1V, so I don't believe either of those are the signals which are used to talk?


kdm06d (author)kdm06d2011-12-02

On second read, the delta v is the difference in the two pulses (one from module, one from sensor), which then yields a 2V scale and hence, 8V. However, I still can't see what the 5V is for?

jimk3038 (author)kdm06d2011-12-02

The 5Vdc is for the ECU micro.

Probably wrong to say that it provides power to the sensors. There must be another regulator in the ECU which provides power to the sensors. I know, for sure, the ECU has the ability to switch off sensor power. So, when your trucking down the highway the sensors are off.

Sorry for the confusion,

jimk3038 (author)kdm06d2011-12-02

The ASIC is embedded in each sensor and are sold by the millions each year. I saw somewhere that more than 100 million sensors have been produced over the last 10 years. So yeah, a ASIC makes sense for them.

Have a look at this page:

Or even better, have a look at this image:

Note, the scope was set for zero volts at one division up from the bottom. So, with no communication the comm wire is sitting at 8Vdc.

The ECU pulls the comm wire down to 1Vdc when active. The sensor, on the other hand, only pulls the wire down to 2Vdc.

Hope this helps,

Oh, and have a look at my new instructible I put up just today:

sunruhai (author)2011-09-13

Can you tell us what this Mercedes-Benz Car Number: 0015425918 ultrasonic sensor detection data, which has an IC is Bosch's number: 30330 0806/06 PC054.1 function or feature, thank you.

jimk3038 (author)sunruhai2011-09-14

Sorry, I have zero experience with Mercedes-Benz and their part numbers.

abraxas1 (author)2011-02-28

Really love this info. going to stop by the local pick-and-pull soon.
can you elaborate on what it takes to cause it to ping? do you have to actually send it digital commands to initiate pinging, or does it do it upon power-up automatically? i'm wondering how much complexity i need to get it to do the most simple range sensing. i'll need to address it digitally and program with the codes i figure out from sniffing? or maybe just pull some signal down/up for a moment and it starts pinging? then i can sample the resulting echo signal for analysis.
thanks so much

jimk3038 (author)abraxas12011-02-28


Nope, the sensor is a total slave device. It won't do anything without being told. However, to get the sensor to generate a ping is quite easy. Just send the sensor a pair of "correctly" timed pulses (the pulses are understood by the sensor as a ping command) and your in business.

The hardest part is interfacing the sensor to a micro. The sensor has three wires - ground, power, and comm. The comm wire is half duplex which means both the micro and the sensor talk on the wire. That's the reason for the transistor interface circuit described above. Two micro pins (one for Rx and one for Tx) are needed.

When you send the ping command to the sensor it responds by pinging, of course, and then sending the echo pulses back to the micro on the same comm wire. Very cool.

Well, good luck at the junkyard,

MnVelocityPilot (author)2011-02-06

If the range could be extended this would make a most excellent landing gear warning system for experimental airplanes (like mine). Landing with the gear up (retracted) is ... well ... a bad thing.

You mention that the data exchange in the power up sequence seems to be about gain setting... any ideas how it works? Any other ideas re. getting the range out to say, 100 - 150 feet?

jimk3038 (author)MnVelocityPilot2011-02-06

I'm also a pilot and have had the same idea. I want to start flying amphibian aircraft and I understand landing on glass smooth water is difficult. It's hard to judge distance above the water when it's glassy. My people have flared too high and stalled while landing on smooth water.

I don't think the ultrasonic sensor is a good choice for this application. The automotive sensor is just not the right kinda beast. However, my wife's new leased Tahoe has a "blind spot detector" system. Oh boy! Now we're talking.

The blind spot detector system uses a 25GHz radar to detect vehicles coming up along side while driving down the highway. There is a little icon that appears in the outside review mirror when a vehicle is passing.

The blind spot detector is mounted in the fender on the inside surface of the fascia. In other words, the radar is punching through the fascia! There are two sensors, one for each side of the Tahoe.

The blind spot detector must have a range of at lease 20 to 30 meters. Perfect for our use as pilots.

Well, I guess it's back to the junk yard to look for some more parts.


nerys (author)jimk30382011-02-06

I wonder of those cheap matchbox radar guns would be useful for landing distance? they output speed could they be adapted to output distance?

jimk3038 (author)nerys2011-02-06

The nice thing about automotive stuff is how bulletproof it is. The OEMs (GM, Chrysler, & Ford) beat the tar out of suppliers over this kinda stuff. Believe it, or not, but quality is the number one thing. Quality even beats out performance or functionality. It's gotta work for years and years or you, as a supplier, are dead.

I would worry a bit about using a "cheap matchbox" to help me fly.

Also, automotive parts are plentiful. It's just a mater of finding them.

Thanks for the interest,

nerys (author)jimk30382011-02-06

its not a match box its made by them AHH remember it now I think Matell ??

I am talking about these

jimk3038 (author)nerys2011-02-06

I'm sorry - I really did think you were talking about a cheesy little matchbox kinda thing. This is kinda cool. Plus, I bet your right, in that, there must be a way to get distance from this thing. How much does it cost? Where can I get one?

Thanks again,

GordieGii (author)jimk30382011-02-08

Actually it may not be that easy to get a distance out of it. Speed radars use Doppler shift, they don't measure the distance.

You might be able to tap into the circuit to send and receive single pulses but you'd need a pretty accurate timer, radar travels a LOT faster than sound.


nerys (author)GordieGii2011-02-08

Hmm good point it does not even need to know distance just change in distance over time.

but it could still be useful. the hard part with landing on water is knowing WHEN your going to hit the water this would allow you to control your descent rate which would also be hard to judge over water.

either way it would be fun to "play" with if your someone (not like me) who has the electronic skills to know what your doing. maybe even use the radar and timing circuits to run your own processes on your own circuitry.

either way its $30 for a RADAR emitter and receiver and thats just cool !! :-)

jimk3038 (author)nerys2011-02-09

I'm still hopeful about using the new automotive "blind spot" radar detectors. The sensor uses a 25GHz radar head that shoots through the fascia to detect vehicles passing by your own.

The blind spot detector measures distances. I know this because my wife's new leased Tahoe has the system. I was playing with it recently - as long as there is a vehicle next to me the warning lamp is on. In other words, while racing down the highway, if someone was acting like my wingman and just cruising next to me the system warning lamp stayed on. To be able to do that kind of a warning, the system must be able to measure distance so that it can detect a static object and not just measure relative speed.

Automotive electronics are so much more robust than consumer electronics. I'm sure the blind spot detector would have to meet all the automotive standards (water proof, shock proof, EMI proof, ect, ect).

My wife's lease is up in another year and there are two of these blind spot detectors on that vehicle! The anticipation is killing me.

Oh, have you seen the new "active cruise" control systems. These, too, use radar to actively manage your vehicle's cruise control speed. They "lock" onto the vehicle ahead of your own. These systems are good for several hundred meters! It's just too bad the Tahoe does not have one of these systems. Well, maybe her next one will.

nerys (author)jimk30382011-02-06

$10 to $30 on ebay. I got 2 in the store on clearance a few years back $10 a pop :-) they sold new for $20 if I remember right.

impressive little gizmos that really work !!

just search for:

hot wheels radar

dvboy (author)2011-02-04

100,000,000,000 is one hundred billion, not one hundred million.

GordieGii (author)dvboy2011-02-08

That depends where you're from. In Britain that would be one hundred thousand million. There a billion is a million million, not a thousand million like here in North America.

That is all moot since the 'ible said 100,000,000 which is one hundred million here or there.


jimk3038 (author)dvboy2011-02-04

Well, isn't that embarrassing.

I'll edit the number in the post.


d1wolf (author)2011-02-07

Could this 'sensor' be used to detect bats?

About This Instructable




Bio: Founder of Powerhouse Electronics. For more info goto:
More by jimk3038:Easy ESP8266 WiFi Debugging with PythonRaspberry Pi Internet Weather StationMake Your Own Laser Cut Standoffs for Electronic Projects
Add instructable to: