Notes about GCAR (or, rather, NEWGCAR) - hashed from the old page...

Disclaimer: I did not write the software; some very talented others did. I am merely assimilating and dispersing information. I do not state to be an expert; most of what is displayed here was learned from someone else. I will keep these sources private unless they request otherwise. So, please don't ask me HOW it works; I don't know. I only fiddle with part of it - where the getchar() section is [you'll see......] Remember - this information could be worth what you paid me for it! (Nothing!)

What will this program provide to me?

It's a Hex Dump. Hex dump is almost what it sounds like - it's hexadecimal numbers dumping across your screen. To my wife, it's jibberish. To people like me, it's beautiful! The "hex dump" is real time. What I do in my own experimentation is to drop it in to an array and then pull out parts of that array, and then scroll it up the screen.

If you're not in to cheezy little DOS programs that dump hex across your screen, this may not be the ticket for you. It's a hardcore hack. ;) It has provided me with hours of amusement, though...

The command documents may or may not work for your car. From my working with others, I've learned that the '94 hex stream is entirely different in construction than, say, the '97 hex stream (which is an OBDII car anyhoo). The stuff I have here is what I have started with. I have not included my software, as it is a direct variant of the linked software. I use Borland C++ v 4.52.

This download provides the source code, executable, and header files for accessing the serial port.

Here's how the car operates: a small continuous stream of data is always pouring out. There's not much important in there at all. You have to send request commands to get the real important stuff. You need to send a "shut up" (pause traffic) command first, and then send your information request packet. GCAR will allow you to log everything to disk.

It sure would be nice to have a Visual Basic version of this software, wouldn't it? Well, Micro$oft won't allow anything around 8192 baud to be entered in their comm control setting. Oh well. It's not a standard PC baud rate - but it is a standard baud rate for the Motorola 68HC11 microprocessor...

Now, for some of the technical details on the GM Computer interface: (remember, this is for MY LT1 motor GM interface - they vary!!! It's not the same on all GM cars!)

*Operates at 8192 Baud
* 5V TTL Level Logic
* ALWAYS traffic on it (RPM, IAT, couple other parameters; I call it "The Chatter")
* Pause "The Chatter" Traffic for 2 Seconds Command (in Hex): F4 56 08 AE
* Last value in packet is always 2's complement checksum. Easy way to calculate Win 95 Calculator, set to Hex and Byte mode. Add all digits, hit NOT, add 1. There's the checksum.
* VIN Info Request Packet: F4 57 01 04 B0
* There's more in the request format F4 57 01 XX CS, where XX is 00 thru 06, and CS is checksum.

My Constant Chatter Data Packet looks like (actually 4 packets - start columns 1, 5, 13, and 18 - then repeats):

I plotted a data capture in Excel (columns). According to my Excel spreadsheet:
* Columns 1,2,3,5,6,13,14,18,19 are always those values and fixed.
* Columns 4,12,17,25 are 2's complement checksums
* Column 7 is (approx RPM) / 25 (=575) (colums 15 and 16 are also RPM; 0x23E = 574). Same as column 20.
* Columns 8 and 21 always contain the same parameter - which I don't know yet. Doesn't vary a whole lot.
* Columns 9 and 22 always contain the same parameter - (IAT + 65C) (right now, that's my formula)
* Columns 10 and 23 always contain the same parameter (again unknown). Varies with throttle application pretty good.
* Columns 11 and 24 always contain the same parameter (again unknown). Don't recall looking at this one right now.