HUD One: RADAR Detector/HUD Integration Project

As you may have heard (e.g. by reading this thread), I designed an interface between the Valentine One and Passport 9500ci RADAR detectors (yes, I have both installed in my car!) and the Head-Up Display (HUD) in my Corvette. I call my interface the "HUD One."

Part I

I began working on this project way back in 2008. The first step was to determine how to communicate with the HUD and tell it what to display. By studying the service manuals for the car, I quickly determined that the HUD is connected to the rest of the car via what GM calls the "Class 2" bus. This bus is based on an SAE (Society of Automotive Engineers) standard called J1850, and there is a lot of information available regarding the standard. This is primarily due to the fact that the J1850 standard owes its existence to CARB (California Air Resources Board) legislation that required all cars sold in California to provide a standard interface for smog check equipment. GM, Ford, and Chrysler decided that, since they had to provide this interface anyway for diagnostic and test purposes, they might as well use it for other purposes. By installing small embedded microcontrollers that directly control various functions and connecting them together using the J1850 bus, carmakers were able to not only satisfy the regulatory requirements but also to replace miles of dedicated wiring, relays, and other circuitry. This increased reliability, saved weight, and (most importantly) cut manufacturing costs.

Thus, although the basic protocol and the messages relating to diagnostic and smog test functions are publicly documented (and available from the SAE web site for a fee), the other functions use proprietary messages which are not publicly documented. Naturally, the HUD communication falls into this latter category. In order to "talk" to the HUD, it would be necessary to reverse-engineer these undocumented messages. This part alone took several weeks.

I also needed to understand the display protocols used by the RADAR detectors. Fortunately, the
protocol for the Valentine One was hacked out long ago and has been floating around the net for years. No such luck for the 9500ci protocol; this required another few weeks of reverse-engineering effort to tease out.

Next I needed a small embedded system on which to run the HUD-One application. I'm a software guy, not a hardware guy, so for this first attempt, I decided to use as many off-the-shelf hardware components as possible. I settled on an LPC-P2103 development board from Olimex. The LPC2103 has 5V-tolerant I/O (important for interfacing with the V1), and the board has a small prototyping area which turned out to be extremely handy. I already had all the necessary development tools from a previous project, which was also a plus.

I then selected an LDV6S to serve as the interface to the in-car network. Unlike most OBD-II interfaces which use the clunky ELM command protocol, the LDV6S uses a unique binary protocol and had other features which seemed to make it well-suited to this application.

To power it all I used an M3-ATX power supply. Total overkill, but after spending several weeks screwing around with other power supplies that didn't work well in the challenging automobile environment, I decided to bite the bullet and use something that I knew would work.

There were other problems which had to be worked out. For example, when I first hooked the fledgling HUD One up to the Class 2 bus, I discovered that the LDV6S would jam the vehicle network while it was powering up, preventing the car from even starting(!!!) I had to isolate the bus connection with a relay before it would even work. On top of that, although the LDV6S has a "bus monitor" mode where it "sniffs" all traffic on the Class 2 bus and forwards that through its serial port, it has to exit this mode in order to transmit a message - which means that any messages that appear on the bus during the time when monitor mode is turned off will be missed. This could definitely cause me problems down the road.

This is version 1.0 of the HUD-One, neatly packaged in a plastic box with a see-through smoked lid.

http://i39.tinypic.com/2m4ygqo.jpg

The box was chosen specifically to fit into the cozy little spot underneath the passenger side floorboard, next to the fuse panel and the amp for the stereo:

http://i39.tinypic.com/2ez342e.jpg

The V1 itself is hardwired to the passenger side headliner using a VoZtech mount:

http://i39.tinypic.com/5xix3.jpg

I ran the wire from the HUD One mounting location through the inside of the A-pillar:

http://i39.tinypic.com/20js94g.jpg

Once it reaches the top, it runs inside the headliner until it reaches the sun visor bracket:

http://i42.tinypic.com/zja0if.jpg

It comes out through a small hole in the bracket which used to house a small yellow LED used for ambient lighting in the cockpit at night. I saved the LED in case I ever want to restore the car to factory condition. :)

http://i43.tinypic.com/30t49ht.jpg

Part II

Realizing that the commercial off-the-shelf OBD-II scan tool wasn't going to work out for this application, I started researching the ways that OEM nodes interface to the bus. I found that they employ interface chips such as the MC33390 which are specifically designed to interface with the bus in a fail-safe manner. In other words, no more jamming of the Class 2 bus while trying to start the engine. :)

I also found a better microcontroller, the TMS470, that has a built-in Class 2 interface called a C2SIB. This peripheral is much like the UART used for RS-232 serial communications: it takes care of all the physical layer bit-banging in hardware, and presents a byte-oriented interface to the microcontroller. I ordered a demo board based on the TMS470R1A256, and then cobbled together a small daughtercard which would plug into it and provide the physical interface to the Class 2 bus.

http://i55.tinypic.com/2q3t7k1.jpg

While this approach worked much better, the downside is that anything beyond the proof-of-concept would require custom hardware. As I said before, I'm a software guy, not a hardware guy; designing circuits and laying out PCBs is not my forte (as you can readily see from the pictures).

Enter creaseguard, the guy who basically gutted his Z06 and put in an entirely new sound system, CarPC, and other electronics; read his thread about it here. He saw my posts about the HUD One on another forum and offered to design a custom board. After many more months of work, including a several-month wait for some critical parts, this was the result:

http://i51.tinypic.com/e7mhol.jpg

I finally had a board with proper connectors for the RADAR detectors and the vehicle wiring harness to plug into, as well as a USB port for future upgrades. WooHoo!!!

Here's a video of the HUD One in action:

http://www.youtube.com/watch?v=NxX0BlZCzno

I want!

That is sweet. I want one

Nice work!!!

Cool job

I agree, awesome job!! I admire the work you must of put into this.
:)

Now my question is: do you think it's possible to run a HUD from a carPC with an after market HUD unit?


Sent from my iPod touch using Tapatalk

Great job on this. Any thoughts of uploading a guide with schematics and code? I've got a 2005 Corvette with the HUD and I would be interested in trying my hand at feeding other types of data into it. It would be incredible to have an interface between the HUD and a PC similar to those 5.25" programmable LCDs that they make for computer cases.

Quote:

---

Originally Posted by richbleak

I've got a 2005 Corvette with the HUD and I would be interested in trying my hand at feeding other types of data into it. It would be incredible to have an interface between the HUD and a PC similar to those 5.25" programmable LCDs that they make for computer cases.

---

It would be cool if it were a bitmapped display, but alas that's not the case. The data which can be displayed is "canned" for the most part. The icons and such are geared toward the vital parameters of the car (speed, oil pressure, etc.) and the navigation system; I know of no way to change them or program any sort of custom graphics.