"Heads-Up Display" and Scantool for 1995 Camaro Z28


Date: 1/14/2001:
Inital, ugly site. Stay tuned for beauty.



Standard Disclaimer

WARNING: Trying to recreate this device, use these designs or code, or generally even think about attempting this yourself means that you can't blame me if you blow something up, render something inpoerable, cause property values to fall, cause marital or employer strife, or cause you to lose belief in the Easter Bunny. I did this for me, I like it, and if you think it's groovy, terrific. If not, move along. ;-)

Putting a computerized display on or in your dash to put information in your line of sight could be distracting and you might have an accident. This may seem like a silly warning, but so does the "This coffee is served extremely HOT" warnings on fast food coffee cups.

Most importantly, I have no real idea if driving around constantly interrogating the computer for data will have a long term impact on the drivability of the car. Only time will tell.  I can't be held responsible or liable for things that you do with this design - and attempts to use this information to build something HUD-like means you accept this.
 
 

Big Thanks!

Many people have helped on this project, and hopefully will continue. Some of the notables:

Introduction / History

My name is Dan, and I own a Camaro. I also am hopelessly addicted to Linux, gadgetry, and other things that just are just cool.

I decided about 9 months ago to try and create a "Heads-Up Display" for my Camaro. HUDs aren't a factory option for the 1995 model year Camaro, or any other model year.

I've reached the "I want to tell the world about it" stage, so you get this web page to look at.

After a test-drive of a new 2000 Corvette in March of last year, I decided that Heads-Up Displays were just the coolest things since sliced bread, and that I had to make one for my Camaro (since I damn sure couldn't afford the 'Vette).

My first attempts at getting HUD-like functionality were centered around getting a display unit from a Corvette, Grand Prix, or other GM car - thinking that something might be compatible.  There was one gentleman who said he'd payed some ungodly amount of money to have a 'Vette HUD adapted to his Camaro, and only wanted a  really large sum of money for it , but negotiations failed.   After considerable digging, I discovered that local auto salvage yards (read: Junkyards) didn't have the HUD units, and frequently didn't even know what a HUD was. Turns out that most HUDs are sent back to some sort of HUD Heaven to be repaired or refurbed, and no one was willing to sell me one.

More digging and bugging parts counter guys to look at wiring diagrams for Grand Prix vehicles showed me that the HUDs didn't use computer communication to get their data, but they used input from the VSS (Vehicle Speed Sensor) at 4000 pulses per mile to get an idea of how fast the car was going. "Ok," I thought, "4000 pulses per mile seems to be a common thread in GM vehicles. I could be lucky."

My next idea was to use a   Basic Stamp II   for the brains of the thing.  The BSII is a small, BASIC programmable microcontroller.  Ideally, it could read the pulses, count them, and send data to the display in serial fashion.  To put it bluntly, it didn't work out as well as I'd hope.   I then tried to get the BSII to talk to the car's computer via serial, and then send the data out.  No go - the BSII just isn't fast enough.

I found a company called  Defi-Shop  that sells a heads up display: It connects to your vehicle's speed sensor and decodes data to send to a little dash-top unit, which bouces light off of a little sticky-film on the windshield.  Unfortunately, this device is really more suited for import vehicles, and the types of speed sensors it wants to talk to isn't really in line with what the GM  product line puts out.  It might have been possible to make some kind of converter circuitry (perhaps even with the BSII), but ultimately I decided that it was a bad idea.

I searched a lot for the right kind of display to use, and ultimately settled on a 256x64 Vacuum Flourescent Display (VFD).  It's got good daylight readability, and it's a pixel-by-pixel programmable display (if you want).  This gives the added advantage of being able to show characters backwards to reflect off of the windshield and look the way they should, instead of resorting to mirrors/lenses/smoke/freakin' magic to make it look right.  Also, you can use any font or graphic that you wish.  I got mine from  ControlAnything , and they've since started carrying some different sizes of displays as well.   In a later update to this page, I'll explain some of how it works.

The current configuration, using a laptop, and a VFD display, and ALDL-> Serial converter, seems to be the best choice.

Brief Overview

Okay, here's how the thing works.
 
  1.     A serial cable connects a laptop (or other computer capable of running Linux) to the ALDL port on the Camaro, using a converter widget.
  2.      The VFD display is connected to the laptop.
  3.     The "aldlrec" program is started on the laptop, which causes the following things to happen:
    1. An init sequence is sent to the display to switch screens a couple of times (looks neat, and shows that communcation is active)
    2.  A "shutup" ("Disable Normal Communications")command is sent to the car.  This tells the car to stop it's chatter on the ALDL bus.
    3.  A "Mode 1 Message 0" command is sent to the car. This asks for 64 bytes of somewhat important data (MPH, Tach, etc)
    4.  The data is interpreted and displayed on the VFD and the laptop screen (for logging).
    5.   The  laptop does 3 more "Mode 1 Message 0 Commands" and interprets the data, doing the display and logging stuff.
    6.   Another "shutup" is sent, and the loop continues until the program is stopped.
 And that, as they say, is that.  For more information on "Disable Normal Communications" and "Mode 1 Message 0", see  Andrew Mattei's page.   In a future update, I'll get in to more detail here.

Here's an example of what the logged output looks like:

Bytes did not match shutup command trigger.
Writing Shutup Request.
Writing data packet request.
+                                   at 32.
Packet Recieved.  Start->
00000000  F4 92 01 00 00 00 00 00   00 00 00 3C 2F 0C 00 06   ........ ...</...
00000010  40 00 40 38 0D B3 14 44   22 7E 04 41 57 1F 3F 20   @.@8...D "~.AW.?
00000020  00 85 F7 3B C1 00 00 10   80 80 80 80 00 FA 00 F7   ...;.... ........
00000030  04 DC 00 47 20 11 00 66   60 01 00 00 00 01 6D 6C   ...G ..f '.....ml
Packet Recieved.  End->
Writing data packet request.
+                                   at 83.
Packet Recieved.  Start->
00000000  F4 92 01 00 00 00 00 00   00 00 00 3C 2E 0C 00 06   ........ ...<....
00000010  40 00 40 4C 0D A0 14 44   22 7E 04 41 57 1F 42 20   @.@L...D "~.AW.B
00000020  00 86 F7 0C B7 00 00 10   80 80 80 80 00 FD 00 FB   ........ ........
00000030  04 CE 00 47 20 11 00 66   60 01 00 00 00 01 6E A7   ...G ..f '.....n.
Packet Recieved.  End->
Writing data packet request.
+                                   at 134.
Packet Recieved.  Start->
00000000  F4 92 01 00 00 00 00 00   00 00 00 3C 2E 0C 00 06   ........ ...<....
00000010  40 00 40 56 0D D9 14 44   22 7E 04 41 57 1F 44 20   @.@V...D "~.AW.D
00000020  00 86 F7 0C 8A 00 00 10   80 80 80 80 01 05 01 01   ........ ........
00000030  04 D0 00 48 20 12 00 66   60 01 00 00 00 01 6E 7B   ...H ..f '.....n{
Packet Recieved.  End->
Writing data packet request.
+                                   at 185.
Packet Recieved.  Start->
00000000  F4 92 01 00 00 00 00 00   00 00 00 7C 2E 0C 00 06   ........ ...|....
00000010  40 00 40 42 0D 8A 10 3C   22 7E 04 41 57 1F 42 1F   @.@B...< "~.AW.B.
00000020  00 85 F7 0A B0 00 00 12   80 80 80 80 00 FC 00 FC   ........ ........
00000030  04 C0 00 48 20 0B 00 66   60 01 00 00 00 01 6F AE   ...H ..f '.....o.
Packet Recieved.  End->

From the top:
    "Bytes did not match shutup command trigger" - After the serial connection is opened, we're looking for 4 specific bytes of "chatter" to signal that the car's in Chatter mode, not doing much.  Then we send the "Shutup Request" - which tells the car to stop chattering for 2 seconds.  Then we send the Mode 1 Message 0 request, and get a Packet of data.  The "F4 92 01 00" at the start of each packet identifies it as a Mode 1 Message 0 packet, and the meaning of each of the following bytes is spelled out in the "A274.txt" document.
 

And, below, is an example of what the "aldlplay" progam shows on the screen when you're playing back a log file.
 

     MPH 0################################...................  120
     RPM 0################...................................  6000
     THR 0##############.....................................  100%

               ###   ####   1900   RPM
              #          #   4th   GEAR
              ####     ###   192   WATER TMP
              #   #      #   028   THROTTLE %
               ###   ####    12.7  VOLTS
                             035   SPARK
                             000   KNOCK
 
 

     FAN1 RELAY        CAT OVRTMP          INJECTOR FAULT
     FAN2 RELAY        ENG MALF LOGGED     FEDS ENABLED
     AIR PUMP          TRANS MALF LOGGED   RESET OCCURED
    *ENG CLOSE LOOP    POWER ENRICH       *TCC BRAKE
    *LEFT 02 READY     KICKDOWN PATTERN   *PERF/NORMAL SWITCH
    *RT   02 READY     MALF 43A ACTIVE    *TRANS MODE A
    *LEARN ENABLED     MALF 43C ACTIVE     TRANS MODE B
    *CLEAN CANISTER    MALF 43D ACTIVE     TRANS MODE C
     SPARK RET REQ     ASR ACTIVE         *HEAT WINDSHIELD
    *PWR STEERING SW   CRUISE ACTIVE      *PARK/NEUTRAL
 

All of the data shown above is gleaned out of the "Mode 1 Message 0" request.   From the top, you see three bars that move dynamically based upon data - mash the throttle down and the "THR" bar zooms across the screen. The rest of what you see should be pretty self explanitory.  The playback speed is current fixed at about 3x real time, but I'll change that.  If, when you're running aldlplay, you have your VFD hooked up, it will display what it did while you were recording it.  Pretty simple.
 
 
 

System Diagram

        /-------------\                     /----------------------\           /--------\
        | VFD Display |---serial line-------| USB-Serial Converter |---USB-----| Laptop | (Or other computing device)
        \-------------/                     \----------------------/           \--------/
                                                                                    |
                                /------------------\                                |
                                | Camaro ALDL port |------serial line---------------|
                                \------------------/
 

Code

Yup, there is some C code involved. As I've hinted, it's actually two programs: aldlrec, and aldlplay.

In their current forms, the code is ->really<- ugly, but mostly functional. I'm not going to post it for your consumption just yet, as it's not yet feature complete... just... functional.

If you absolutely have to have it, and you have a 1995 Camaro Z28 with an automatic transmission, already have one of Andrew's converters, and you've got Linux on a laptop, and by some act of Divine Intervention you have a VFD display, send me a mail and I'll send you what I've got.

I'll post the C code when I feel that it can be released to the public. Do I know when that is? Some time between 1 day and 2 months. I'm a family man with 3 kids and a job - programming time is a luxury for me. That's why it took me 9 months to get this far!
 

Use

Problems / TODO

Yup, you guessed it, there are many things left to do.

Right now, the HUD is pretty much a nighttime only device. In bright light the display washes out. I'm experimenting with different polarizing filters and whatnot. NO ETA on a fix. It's winter now anyway, and when I drive to and from work I'm in darkness.

The code only asks for 1 of the 6 different messages that the computer can provide. This is to get speed and tach data. To make a 'scantool' all of the messages need to be asked for and logged. It's really a timing issue - the 'shutup' command lasts for two seconds. To get good refresh times on the display I need to keep the amount of data I'm asking for short. Alternatively, I could add an option which doesn't send data to the HUD but records more complete data. NO ETA.

Mounting of the beast is the next interesting problem. The VFD display that I'm using is expensive, and I've already blown one up. (OUCH!) The ugly plastic box that it sits in is functional, but non-optimal. Best solution is to cut a hole in the dash, but I haven't had the heart (or the time) to rip the dash apart yet. Suggestions, anyone?

"Ghosting": As I mentioned earlier, GM cars (and one might assume other makers) have special windshields with a layer of material called "butacite" in the middle that minimized unwanted image reflections and ghost images for the HUD. My Camaro has no such windshield. I'm hoping that the glare solution and the ghosting solution will be the same thing: circularly polarizing filters.
 

Future Directions

I like the idea of having computers in my vehicle. My fist attempt was an MP3 player - it worked, but it took a concious act of will to use it: You have to turn on the inverter, boot the machine, use it, then shut it down, turn off the inverter, etc. When you have a device in your car, you want it to be instant-on, instant-off, no fuss, no muss: If you had to go through a 30 second ritual every time you wanted to use your radio, you wouldn't use it often. This reasoning is why I de-installed my homemade MP3 player and bought an  Empeg MP3 Player.

The HUD controller needs to be a single-board computer, or a really beefy microcontroller. It needs to have a one/two/three button interface to turn it on and off, change display modes, etc. This is all doable, and I know the people who can help me do it. It's a question of time and money.

Also, I've got this really nifty Valentine One radar detector. It's cool in many ways, but the relevant one here is that is has a 'remote display', that the main unit talks to via a serial line. If that serial data can be decoded, the remote display now becomes the HUD - and you get radar warnings right next to your speed and tach. Handy. Add a GPS input, and you can create a "Radar Map" to help filter out those pesky falses from your local grocery store.
 

Links

 ControlAnything , makers of the  VFD Display.
 Andrew Mattei's  ALDL page.  Did I mention that he's a great guy?  You can find the ALDL spec for 1995 Camaro Z28's with Automatic Transmissions there.
 Keyspan , makers of the USB-Serial converter that I use with this project.
 Dupont Automotive , makers of the "Butacite" windshield used in cars with factory HUD's. Also has a picture of the Corvette HUD.

 E-Mail me  and let me know what you would like to see in this web page, and this software.

Site Counter: 142849 visits since 1/14/2001.

GuestBook

Name:
Email:
HomePage:
Where are
you from:
Comments: