HomeProjectsDownloadsLinks
 HUD One History

Projects > HUD One > History

Developing the HUD One

When I was shopping for a C6 Corvette back in 2005, I made sure the one I selected was equipped with a HUD. I have always thought that the HUD was not only extremely cool but exceptionally useful, allowing my to keep my eyes on the road most of the time. 2005 was the first year of production for the C6, and My Millennium Yellow dream car attracted lots of attention - not all of it desirable. After collecting a couple of speeding tickets, I decided to invest in a RADAR detector; after much research, I purchased and installed a Valentine One. The Valentine One supports an external "concealed" display, which can be mounted discreetly inside the car while the main V1 unit is left with a good view of the road. Since the C6 HUD is capable of displaying turn-by-turn directions from the car's navigation system, I began to wonder what it would take to display the output of the V1 on my HUD. So in early 2008 I set out to do precisely that.

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 communications bus is based on a SAE (Society of Automotive Engineers) standard called J1850, and there is a lot of information publicly available regarding that standard. J1850 owes its existence to the EPA (Environmental Protection Agency), CARB (California Air Resources Board), and legislation that required all cars to provide a standard interface for smog check equipment. The automakers realized that the J1850 bus could benefit them, as well: by installing small embedded microcontrollers into their cars and connecting them together using the J1850 bus, the automakers 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 cut manufacturing costs. It was a win for everybody involved.

Although the basic protocol and the messages relating to diagnostic and smog test functions are well documented and publicly available, the other functions use proprietary messages which are not publicly documented. Of course, 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 using an OBD-II scan tool with passive monitoring capability and custom software that I wrote to log and decode the traffic on the Class 2 bus. While Class 2 bus analyzers are commercially available, they are targeted at automobile manufacturers and their suppliers, not at hobbyists, and have price tags that hobbyists cannot afford. Thus, I had to develop my own software to capture and analyze the Class 2 bus traffic.

I also needed to understand the display protocols used by the RADAR detectors. The Valentine One external display protocol was published by Valentine Research long ago and is readily available on the net. The 9500ci also has an external display module, but to my knowledge its protocol has not been published. Decoding this required another few weeks of reverse-engineering effort.

Next I needed a small embedded system on which to run the HUD-One application. 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.

This is my original prototype for the HUD-One:




Of course, there were some 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 bus 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.

Realizing that the commercial off-the-shelf OBD-II scan tool wasn't going to work out for this application, I set out to learn how the OEM nodes interface to the bus. I found that they employ interface chips such as the AU5780 which are specifically designed to interface with the bus in a fail-safe manner. These devices are also full-duplex, and can transmit and receive messages at any time without cumbersome mode switching or lost packets.

I also found another microcontroller, the TMS470, that has a built-in Class 2 controller peripheral 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 provide the physical interface to the Class 2 bus.



While this approach worked much better than my first try, anything beyond the proof-of-concept would require custom hardware. As you can see from the pictures, designing circuits and laying out PCBs is not my strong suit.

Fortunately, another C6-owning hobbyist saw my message board threads about the HUD One and offered to design a circuit board to my specifications. After many more months of work, including a several-month wait for some critical parts, this was the result:



This new board has proper connectors for both the Valentine One and the 9500ci RADAR detectors, as well as a USB port for future upgrades.