|
|
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.
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.
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.
/-------------\ /----------------------\ /--------\ | VFD Display |---serial line-------| USB-Serial Converter |---USB-----| Laptop | (Or other computing device) \-------------/ \----------------------/ \--------/ | /------------------\ | | Camaro ALDL port |------serial line---------------| \------------------/
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!
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.
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.
E-Mail me and let me know what you would like to see in this web page, and this software.
Site Counter: 
visits since 1/14/2001.