When it comes to testing parking sensors we have probably all come across the method of testing where you put your ear to the sensor and listen for the clicking noise, however if a customer sees you crawling around on all fours with your ear to their bumper they are likely to think you should be wearing a tin hat to protect you from the alien mind rays. So what methods are there that make us look less like we are a set of spark plugs short of a service?
The first and most obvious would be to use our serial diagnostic tool, plugging in to the OBD port and hoping to get a code that points to a specific sensor. If we are really lucky we’ll get live data too, giving us the distance from each sensor to an object behind. If we stand in front of the sensor we should be able to make the data change. However, with limited resources, parking sensors are low on the priority list of aftermarket diagnosis system producers and is often seen as not worth the effort needed to reverse engineer an application, leaving us back wearing our tin hat.
Luckily, we have another universal diagnosis tool available to us, the oscilloscope. Pico Technology have recently introduced the TA329 Ultrasonic parking sensor detector, which enables us to visually see the sound bursts as they are transmitted from the transducer. The detector is quite affordable at around £20+VAT. The process for using it couldn’t be any simpler – connect the oscilloscope to your computer and plug in the sensor detector (Figure 1). I found the best settings for the scope were +/- 500 mV and 200 microseconds across the screen. Set a trigger to hold the image on the screen. If you now hold the detector a few centimetres in front of each sensor, you’ll see the sound burst magically appear before your eyes (Figure 2).
By comparing sensor signals, a faulty sensor should stand out as it will have no, or reduced, output. This method quickly tells us the parking sensor is receiving a command from the parking control unit to send an ultra-sonic sound burst and is transmitting a signal, but it does not tell us if the sensor is receiving the returned sound wave echo and transmitting that information back to the control unit. Most of the time, this would be enough information to detect and condemn a failed sensor.
The next method is a little more complicated but gives us more insight as to what is going on in the circuit. A couple of issues back I gave a brief overview of the Piezoelectric Effect and briefly mentioned parking sensors and the method they use to transmit and receive signals. Many of these sensors use either a bespoke single wire serial interface or LIN Bus to communicate and we can tap into the data stream to gain more information. The set up is more difficult as it may involve the removal of bumpers or access to the parking sensor control unit. The parking sensor itself will normally have three wires going to it – power, ground and signal. As with any sensor testing, we should always start with testing powers and ground. The earlier systems used a fairly simple communication where the control unit sends a pulse on the serial wire to request the sensor transmits a sound pulse, followed by a pulse from the sensor to say it has received the echo. The time between the two is related to the distance to any object behind. This can be seen quite effectively on a scope with the distance between the two pulses varying with the distance any object is from the sensor.
EXAMINING LIN BUS SIGNALS
Later sensors use LIN Bus to communicate between control unit and sensors. As with any LIN Bus signal, we should see a nice clean square wave data signal that is about 1V below battery voltage. Again, there will be a request by the control unit followed by a reply from the sensor, however, it is now more difficult to pick out this info from the waveform. PicoScope has a feature that decodes the serial data. It can be found under the tab ‘Tools > Serial decoding’. By selecting LIN and the appropriate Baud rate we can see the data being transmitted displayed in a table below the waveform. Figure 3 shows a LIN Bus signal and the information being decoded below. This data will change with the distance measured to any object. If we wanted to, we could analyse the data to give us the exact distance. The actual data transmitted will vary from make to make, even model to model, so unless you do a lot of the same model, it is probably not worth the effort to reverse engineer the data to say that it should give a particular reading at a set distance, but it is probably sufficient for our needs to simply note this is changing.
Hopefully, this gives you a few different options for testing. Obviously, the easiest method is fault codes, followed by the TA329 sensor, but it is worth learning about LIN BUS and getting used to testing with a scope, as it is now commonly used between many switches, sensors and control units.