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.

http://ph-elec.com/content/hacking-gm-ultrasonic-park-assist-sensors

Step 1: 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

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

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:

ph-elec.com

Thanks,
Jim