Understand the Existing System
The first step in the process is to understand the existing system on a vehicle that is equipped with “Park Assists”. Just for background information, the term “Park Assist” was chosen for a reason. GM will tell you very quickly, this is NOT a safety device. This is for parking ONLY. Their fear is some bonehead will back over someone and claim the backup sensors never warned them. Not being considered a safety device made our lives much easier. That was good news since we had such a terrible time anyway. I could write a book about EMC testing!
Now, just so happens, Momma has a company car (2008 Tahoe) that is getting close to the end of its lease. Also, just so happens, Momma is out of town on a business trip in China. While the cat is a away the mice will play!
Back to step 1, in this step we’re going to activate the system and see how it works. Part of activating the system is putting the vehicle into reverse gear with the engine off. So, block the wheels so the vehicle won’t roll away while out of park gear. The system can be activated by keying up the ignition (again, leave the engine off) and pulling the gear shifter into reverse. With the vehicle stationary, you can get out of the vehicle and play with the system. There are three LED lights that light up based on range. There is also a chime when a new object is detected. Or, a continuous chime for very close objects. With the back hatch open the chime is easier to hear. Now is the time you can check the range of the system to verify to makes it out to 2.5 meters. We spent many months working on the FOV (field of view) for GM.I could never understand why GM wanted such a long range – they are the only ones shooting out to 2.5 meters. Everyone else is happy at 2 meters. Would a customer actualy care about that extra 1/2 meter? I know, I rant too much.
The two LSA Capture JPG links don’t seem to work. Any clue to get them working?
kmiles,
Thanks for pointing out the problem. Yeah, I moved from Drupal to WordPress and a few links got broken along the way. Both plots are now included and working. I even found another link that was broken too.
Thanks,
Jim
Thanks, Jim.
Oh and FYI, the mbed “home-grown” solution on page 6 is not viewable without an mbed plugged in. Any other way to view the code?
That brings me to another other question. I’m curious about the communication between the sensors and the UPA. The 9600 baud seems to indicate Serial transmission. If that is the case, does it follow normal serial message protocol?
I’m considering the USBee SX for this project:
http://www.usbee.com/sx.html
It should do fine with the LSA between the sensors and UPA. It also says it does CAN, what do you think about its capabilities to sniff the CAN bus and then replay the messages? Obviously the voltage levels need some type of buffer, but it’s CAN input has Tx/Rx, whereas this CAN is single wire…So I’m confused
Thanks for the project!
Yep, to follow the link and view the “home-grown” solution you must have a mbed account. However, the mbed account is free and only takes a few minutes to setup. If your going to use a mbed for anything you really should have a mbed account. They have lots of good stuff on their site.
No, the communications between the ECU and the sensors is not normal serial communications. It’s really more like half duplex – master / slave communications. The communications all happens on a single wire – hence the half duplex. A sensor won’t communicate unless command to do so by the master (the ECU in this case). For single wire / half duplex to work you need some kind of circuit attached to your micro since the comm wire is shared between the ECU and the four sensors.
For CAN communications there can be several different kinds of “flavors”. For low speed stuff, GM came up with what they call SWC (single wire CAN). The GM version is basically a low cost CAN method. Oh, and they use extend CAN identifiers on SWC for some weird reason. For high speed CAN everyone uses two wires. Even GM uses two wire high speed CAN on the same vehicle that also has SWC. Usually, the high speed CAN reserved for use between the engine and transmission. Then, they use the instrument panel as a bridge node between the high speed CAN and low speed CAN. In other words, the instrument panel has two CAN channels – one channel on low speed SWC and one channel on high speed. The instrument panel then listens for high speed messages and rebroadcasts to the low speed bus. Stuff like vehicle speed and PRNDL (park / reverse / neutral / drive / low – pronounced to kinda sound like pringles – a automotive term used a lot in Detroit).
So, to make a long story, the microprocessor has two TTL pins (Rx and Tx) for CAN communications. To connect to the CAN bus you must use a transceiver. The most famous is the Philips PCA82C250 which will get you on the two wire high speed bus. The GM SWC requires a different transceiver. From the microprocessor’s perspective it doesn’t matter which transceiver you use as long as it matches the CAN bus type your connecting to. Note, the “home-grown” link above shows how to connect a transceiver to an mbed and get it talking on the CAN bus.
For low speed CAN the USBee could probably keep up. However, the high speed CAN communicates at 500k buad and there is no way the USBee could handle that.
Hope this helps,
Jim
They probably used the extended identifiers to have more functionality with their naming system. Who knows, car manufacturers have exceptionallyyy tight control on the way things are done
What specs would I look at to know if it can keep up with the 500 kBaud on a product? Website says the SX can sample up to 24 Mega Symbols Per Sec, but maybe you’re saying it wouldn’t be fast enough to .replay. the messages to trick the brain into thinking it was inside the network?
http://www.usbee.com/products.htm
You have some great write-ups, by the way.
Thanks
Sorry, I misunderstood, I thought you were talking about an Xbee. I saw the “bee” and my thoughts went strait to the Xbee. The USBee is a little logic analyzer. I get it. Sorry.
All my experience with CAN comes from using the Vector CAN products. They are very very expensive.
The USBee should work to let you capture traffic on the bus. However, I don’t think you can play messages back onto the bus. I could be wrong – I just don’t have any experience with that device.
I would suggest the Mbed for CAN snooping. It would also allow for message playback. There are a couple downsides – you will have to program it in C or C++ and it will need a transceiver chip. Adding a CAN transceiver and all the source code are on the mbed site. Someone has already sorted it all out.
If your just trying to hack ultrasonic sensors then you don’t need CAN message. You can simple use the information I provided to talk directly to a sensor. Again, the Mbed is good for this too. I’ve even provided source code to get you started.
Guess it all depends on what your trying to accomplish.
Thanks for the kind words,
Jim
What I meant by the MBED website, is that you must HAVE an mBED plugged in, to be able to register with the site (which of course means you must own one). Not a problem, just an FYI.
On page 6, you hook up the UPA .only. at first. The last 8 bits, as noted, correlate to the ID which in this case for 0xBB would have been 1011 1011. 1) what does the (0x) in the 0xBB indicate?
The UPA then Tx a bunch of info (formalities according to SWCAN protocol), of which part is the actual data (0-8 bytes), which was extracted and shown:
Rx d 0 TE
Since I see a T, I’m assuming thats ASCII:
01100100 00100000 00110000 00100000 01010100 01000101
d (space) 0 (space) T E
Then, when you go back to the car and give the BIG list of codes, where the first one from the UPA is:
36.015570 1001e0bbx 34 14 01 7f 2b *
The data there is HEX.
2) Am I seeing this correct? The HEX makes sense, but I don’t see why there would be ASCII values?
Didn’t know that about the Mbed site – that’s kinda crappy.
The 0x is just my old bad habit of prefixing any hexadecimal number so that I can keep them strait.
The CANalyzer lets you filter messages so you can dump all the junk you don’t need to see. I had a filter that only let messages coming from the UPA to pass through. The CANalyzer output would look like:
0.0000 Start of measurement
0.0668 CAN 1 Status:chip status error active
3.4715 1 FFFE0BBx Rx d 0 TE
4.7002 1 FFFE0BBx Rx d 0 TE
5.9288 1 FFFE0BBx Rx d 0 TE
Looking at the third line, this says that a “State of Health” message came from the UPA module and occurred 3.4715 seconds after the CANalyzer was triggered. The message came in on channel one (there are two channels on a CANalyzer PCMCIA card). Next is the CAN Id, and in this example, is FFFE0BBx. The trailing “x” denotes an extended CAN Id message. The last byte in the CAN id, by GM definition of GMLAN, is the node number and has been reserved by GM to be BB (hexadecimal number of course) for the UPA module. So, any message on the extend CAN bus that ends in “BB” is a message from our UPA module.
The last thing on the line is “Rx d 0 TE”. The “Rx” means this was a received message (would be Tx if CANalyzer was generating the message). I don’t recall what “d” means – probably “Data”. The “0″ means this message has a data packet length of zero. And lastly is “TE” which simply means “Transmit Enabled”.
The “State of Health” is generated by every node and comes out about once per second. It’s a simple way for nodes to verify other nodes are active (and presumed OK) on the bus. For example, the UPA module depends on several other nodes. To generate a chime the UPA sends a request to the radio to play a chime on behave of the UPA. Therefore, the UPA will go inactive if the radio does not send a State-of-Health on a regular bases.
Sorry, I just grabbed the CANalyzer log file without thinking how confusing it might be. Then, in the BIG list of codes I guess I did purge the extra CANalyzer info. Yeah, kinda confusing.
To answer your question, yes, the following line from the UPA module is raw hex values:
36.015570 1001e0bbx 34 14 01 7f 2b *
I added the asterisk on the end just to mark the lines that came from the UPA module. And, to add more confusion.
With the vehicle keyed up (engine off) and the gear shifter in reverse the UPA module will go active. When active, the UPA will sound chimes (by asking the radio nicely) whenever an object is detected. The 100e0bbx message, from the UPA, is only sent when the module is in active mode. By filtering just for this message it’s easy to see the data bytes changing as an object moves past the sensors. It also possible to see the chime request going to the radio each time the UPA detects a new object.
Oh, one last thing about the BIG listing. You may notice the time-stamps at the beginning of the lines look funny. The message listing looks out of order from a time-stamp perspective. The jumbled time-stamps was a result of another CANalyzer feature. Instead of scrolling messages as they come in the CANalyzer can overwrite the line which has an identical CAN Id. The time-stamps, instead of display absolute time, are displayed as the delta time since the last identical message.
Maybe an example would help, say we have three repeating message on the bus. Message #1 repeats every 0.1 seconds. Message #2 repeats every 5 seconds. Lastly, message #3 repeats every 30 seconds. With a normal scrolling display all you would see are those pesky Message #1 because they are coming in every 100 milliseconds. It would be hard to see Message #2 and almost impossible to see Message #3. In the alternate CANalyzer display mode (I forget what CANalyzer called it) only three lines would be displayed for this example. Message #1 would be overwriting itself every 100 milliseconds and the time-stamp would say 0.100 since it repeats that often. The other two messages would be easy to spot and easy to see how often then repeat too.
Well, I hope this helps clear some confusion. I’m hoping I didn’t cause you too much grief,
Jim
Ahh. So what you’re saying is all four (4) sensors share the SAME wire, not an individual comm wire for each sensor. This is good stuff!
Are you familiar with LIN? Is it possible that the transmissions between sensors and brain are governed by LIN protocol? Obviously the brain interfaces through the GMLAN
I will have some more questions to follow up. In the mean time, I found that GM uses pin 1 of the OBD II plug for the SWCAN communication, which could simplify sniffing for people in the future.
Yes and no. Yes, all four sensor comm wires are multiplex to the same set of Rx/Tx pins inside the ECU microprocessor. The ECU has a circuit which allows it to “select” which sensor it wants to talk to. That’s why there is a dedicated comm wire from each sensor back to the ECU. Otherwise, it would have been cheaper to simply daisy-chain the wire along between sensors.
So why, you may ask, why the dedicated wire? Well, it allows the ECU to talk to multiple sensors at the same time.
Image three sensors lined up on a yardstick. The ECU tells the sensors on the ends of the yard stick get ready for listen only mode. Then, switching to only talk to the middle sensor, the middle sensor is told to get read to generate a ping. Finally, all three sensors are told GO. All four sensor have been told in advance what GO means. So, the middle sensor fires a ping and the two outside sensors start reporting echoes. Now image an object right in front of the middle sensor. The middle sensor couldn’t detect it because it’s too close and the return echo happens too quickly after the ping. This is the classic ring-down problem with ultrasonic sensors. The two outside sensors, however, have no ring-down problem since they didn’t generate the ping. Knowing the distance between the sensors and the exact time when the echo comes back the ECU can calculate the distance. After some know amount of time, the listen only sensors timeout and wait for the next command – free the comm bus.
No, the sensor to ECU communication protocol is a proprietary hybrid thing. It’s really strange. The ECU sends commands to the sensor(s) and the sensors can either respond with digital messages, OR, the sensor can respond with actual echoes – it depends on the command. So, if the ECU commands a sensor to listen, the sensor will respond with actual echoes. It’s like the sensor amplifies the signal strait from the actual piezo element, runs it through a logic gate, and sends it right out on the comm wire. The sensor has no brains to interrupt the raw echo signal. It good and bad at the same time. The ECU must be able to communicate on the comm wire but it must also be able to do fine-grain timing too. That’s why the ECU jumpers the Rx pin on the ECU micro over to a timing pin too. The timing pin (input only) can perform the pulse timing using hardware in the micro.
Yeah, the SWCAN communications run all around the vehicle. Inside the ultrasonic ECU you will find SWC on pins 6 and 12. Note, GM is the only one to use SWCAN that I know of. Everyone else just uses high speed two wire CAN. I guess GM expected everyone else to pickup on their great idea to save a few pennies and start using SWCAN too – but it never happened.
Jim
“The ECU sends commands to the sensor(s) and the sensors can either respond with digital messages, OR, the sensor can respond with actual echoes”
1) By “actual echoes” do you mean simply an instantaneous pulse where the sensor pulls the comm line low?
Also, you mention there is a different init string for the outside/inside pair of sensors where you theorize it is to establish a hotter gain on one versus the other.
2) Would the “higher gain” be a larger voltage across the transducer?
Jim,
Also, do you have any Logic Analyzers you would recommend?
Thanks!
I love my Logicport analyzer. Use it almost as much as my voltmeter.
http://www.pctestinstruments.com/
Only downside is that it does not run under directly under Ubuntu / Linux. However, it does just fine inside a VMWare virtual WinXP machine on top of Ubuntu.
So that’s my trick, old Windows hardware can be run (mostly) inside a virtual machine on top of Ubuntu. For sure, the Logicport seem very happy to run this way.
Jim
1)
Yes, whatever the sensor “hears” is directly applied to the comm. pin. This is both good and bad. Makes the response from the sensor harder to deal with since it’s not a direct encoded distance. The upside is, the sensor provides a whole lot more information. It’s possible to “see” multiple return echos with this setup. I always wondered if Bosch took advantage of the extra information returning from each sensor. Probably not is my guess.
2)
No. The sensors are pinged with a large 150 to 160 volt square wave. Any more voltage will damage the sensor. Have you felt the surface of the sensor as it’s pinging. Brush the surface lightly with your finger tip and you should be able to feel it. Or, with the sensor pointed upward, rest one end of a pencil on the surface while you lightly hold the other end. You should hear a clicking sound on each pinging event. You can hold a pinging sensor up to your ear and hear a distinctive click. However, I don’t recommend that considering how much sound energy is coming out of the sensor. So, to generate the sound waves, the sensor face is actually deforming much like a loud speaker. Crazy to think that the piezo element is actually flexing the aluminum surface of the sensor.
The return echo is a millivolt signal coming off the sensor that is run through an analog filter & gain. The result is then applied to an analog to digital converter in the micro. The micro then applies thresholds to the values coming out of the analog to digital converter based on time. Close objects have a high threshold than far away objects. This is all done to try and eliminate noise.
By hotter all I mean is that the thresholds are lowered to allow more detection. The downside is, of course, you get more detection of junk you don’t want like pot holes and curbs. It’s a balancing act between noise and detection.
The corner sensors are basically de-tuned and the bulk of the detection is done with the center two sensors. In fact, I’m now noticing Ford has some cars on the road that only have two sensors.
I ask GM if they were interested in us investigating a two-sensor solution as a cost reduction. Nope, too much work for the poor GM engineers to think about. I regress.
Anyway, hope that helps. Sounds like your making progress.
Good luck,
Jim
I’m trying to translate the Mbed code to Arduino (because that’s what I have). I understand most everything except “senRxRIrq.rise” and “senRxRIrq.fall”. Are these functions for setting interrupt registers?
Best I can tell the Mbed is only exciting the sensor modules, measuring the time interval of the echo return is not included. Correct?
RichD
RichD,
Very cool. You gotta send me your source code with finished. I’ll create another page dedicated to Arduino with your source attached.
The Mbed source code I posted pings four sensors. However, only the right sensor echos are measured. This is done by attaching an interrupt to the rising and falling edge on the Rx line coming from the right sensor. In the main loop, you can see the right sensor is pinged, then a 50ms loop runs to allow echos to come back. The interrupt routines senRxIrqRise and senRxIrqFall capture timestamps into an array. After 50ms in the main loop, any timestamps that have been captured are printed out.
The Mbed code above is not very good. Looks like there is a bug in senRxIrqFall one the line “tmrEchos[ indEchos++ ] = timer.read_us();”. This should have been (I think – it’s been a while) “tmrEchos[ indBuff ][ indEchos++ ] = timer.read_us();”
So, all four sensors are pinged but only the right sensor’s echos are captured and sent back to the PC through the serial port. The Mbed code was just an attempt to get the hardware up and running and to prove echos could be captured.
Good luck and send more feedback with questions and your successes. Would love to see pics of your Arduino talking to some sensors.
Hope this helps,
Jim
Thanks Jim!
Some questions about the initialization string: I believe you said the init string appeared to be 9600 Baud serial data. Could it be simulated with a standard serial port, (Tx channel only)? In looking at the Logic Analyzer waveform it looks like it might be negative logic (i.e. low voltage is logic 1). If your Logic Analyzer thinks the signal is standard serial port stuff, does it provide details like number of data bits, parity, stop bits, etc?
You define a table for senMidInit[], but I don’t see it used anywhere in the code. Apparently this table is for initializing the middle sensors? Why do you suppose there are only 2 unique init strings instead of 4?
Are the sensor modules in this demo made by Bosch? Somewhere I think you said GM uses Bosch sensor modules. If so, does Bosch provide application data for their modules? Knowing the purpose of the various bytes in the initialization string might be very useful.
RichD
RichD,
Yes and no. Yes, the transmitting of commands and data to the sensor could be done using a standard UART Tx. However, the return echo is not standard communications and would make no sense on a Rx pin of a UART. The echo return from the sensor is in raw pulses that must be timed by the master CPU.
When probing the Bosch ECU and sensors, while they were being tricked into thinking they we actually operating in a vehicle, I saw two different initialization sets. One set for the two outboard sensors and a different set for the middle two sensors. In my code, I simply initialized all four sensors with the same block of data. However, I included the unused senMidInit array for future use.
The two inboard sensors (or middle sensors) act very similar. Well, for that matter, the two outboard sensors act similar too. So, there is little reason to keep four sets of initialization patterns. As a retired supplier to GM, I know it’s hard enough to calibration two sets – four sets would just double the work.
Yes, the sensors in this demo are all from Bosch. Last I knew, there were three suppliers of ultrasonic systems to GM. In the old days (pre 2006) it was only Bosch. My company was second which got started back in 2006. Again, last I knew, all ultrasonic OEM supplies both the ECU and sensor as a calibrated set. Otherwise, there would be too much finger pointing when things go bad. Plus, each OEM holds their sensor intellectual property tight.
No, I have no way of knowing what the actual init bytes represent. And yes, it would be cool to know. My guess, the init bytes set gain values for different distances. So, the middle sensors probably have a hotter set of gain values compared to the corner sensors. All speculation on my part. But it would be easy to test out by trying different values and then testing the sensor’s ability to detect objects at different distances.
Good luck,
Jim
Hi Rich!
Did you have, by chance, any news about using an Arduino to controll these ultrasonic sensors?
Thanks
[...] his wife was out-of-town [James] jumped at the opportunity to do some snooping around with her Chevy Tahoe’s parking assist sensors. We can understand how pulling parts out of someone’s car would make them none too happy. But [...]
James are you selling that GMX222/272 Bench Simulator package still by any chance? I’ve been looking for something exactly like this to test and demo scan tools.
No, I’m not currently selling bench simulators. However, creating a bench simulator has never been easier. Have a look at the mbed platform. Creating and controlling CAN messages is really easy with this module. The only tricky part is interfacing the mbed to the CAN bus. You will still need to add some kind of transceiver. There are examples on the mbed web site to help with this too.
Good luck,
Jim
A similar hack of cheap 4-sensor unit is described here
I this case the protocol between the processing box and display is pretty simple, so connecting Arduino to it was no big deal.
Interesting.
One thing to note, the Amazon system uses analog sensors. So, a large 150V pulse hammers the piezo element in the sensor over those long sensor wires. Then, the small mV return echo signal, coming back from the piezo element, is transmitted on those same long wires. At the same time, another sensor might be getting hammer with a 150V signal. All this makes for a real challenge in terms of keeping noise off the wires. Analog systems are known for lots of false signals, as a result.
A digital sensor does the same thing – in terms of hammering the piezo element with a high voltage and then reading the mV signal back in. However, the piezo wires are all internal to the digital sensor. Plus, you can do tricks with digital sensors that I don’t think the analog system supports. One big trick is to command one sensor to ping while commanding other sensors to listen only. This allows for triangulation. Two sensors, working together, can also be used to measure small distances.
All boils down to your application and what your trying to achieve.
Good luck,
Jim