Or get your ECU reflashed. I had my FZ1 done, amazing. Or get a PIC mircontroller and program it yourself.
PIC microcontroller - Wikipedia, the free encyclopedia
You're gonna have to be pretty sharp on this if you build from scratch. Need the comms protocol, check sum, hex registers, hex values of those registers, then knowing the mapping of protected areas that should never be changed and then the things you need to change. . . list goes on and on. . .
Not to mention building the whole circuit to talk to the ECM. It's not impossible but it'd take some time and resources.
I run this on the auto put its for polling only and not flashing. AutoTap at
OBD-II - On-Board Diagnostic System
Here is some light reading to help you sleep. . . It'll give us a clue as to what we may encounter. . .
{paste} from
OBDII Information Page
Interested in rolling your own diagnostics software?
Multiplex-Engineering sells inexpensive ($70-80) OBDII interfaces for GM (VPW), Ford (PWM), and Chrysler (ISO). They will sell you the converter box, and provide you with the protocol document that allows you to talk to their box. The only thing you'll need to provide (heh heh) is the SAE paperwork that tells you what to request and how to decode it. They don't actually provide you with any OBDII docs, just how to talk to their box. As a side note, this is the same interface that the Palm based OBDII software that you see popping up everywhere (like at
AESwave.com, labscopes scan tools and accessories for diagnostic test equipment! ) is using. However, each M-E box has their own 'hardware address' that you must poll with the serial port message, and although I have not asked, I'd bet that they dedicate a hardware address to each Palm software vendor. For example, AESWave's software is looking for a M-E device at address 0x80. The M-E device I bought has address 0x55, so it doesn't reply to the AESwave software query (this was performed with software downloaded from their web site for free, a Palm IIIxe in its factory cradle, and some serial port sniffing software - no rocket science to figure this out). The M-E device sure is slick, though, and if I were wanting to write a diagnostics software package for my vehicle, I'd start with one of their interfaces. I met Paul Bowen (the owner of M-E) at SEMA this past year, he's a really nice guy, knows his OBDII!
NEW! Hey, check this out. These guys over at Scantool.net have an affordable OBDII reader! It's based on the Elm electronics chip (below), but looks like a rolled together and ready to go package. Looks nice. If you want to save a few bux to scan your computer, this looks like a much easier solution than trying to piece together parts. This looks to be the LEAST EXPENSIVE turnkey OBDII solution going these days. Check 'em out.
Want to build your own hardware interface and write your own software?
Well, here's a couple of links that are very interesting to anyone wanting to 'dig in deep' to OBDII. This is an OBDII interface chip, that's based on a Microchip PIC. It's pretty cheap (about $10), so with some support circuitry, you could climb in to this hardware for looks like about $25-$30. Then you need to write a scan tool (or use Hyperterminal). I've not obtained any of these chips. The PDF file is VERY interesting reading, though, and definitely worth a look if you're "in to that sort of thing".
Elm Electronics PIC based Interfaces
Elm GM VPW PIC .PDF Datasheet
Technically, WHY won't an AKM OBDI interface allow laptop to vehicle communications with an OBDII vehicle?
This is a pretty deep question, for those who don't have the stomach to get technical, you can probably just skip the rest of this page. However, here is the answer.
First, for an introduction to GM OBDII, read the Intel Whitepaper that describes the 10.4 kbps Variable Pulse Width (VPW). This shows how 1's, 0's, and the voltage level of the datastream are formed. Worthwhile reading, Adobe Acrobat .PDF format.
Intel J1850 Whitepaper
OBDI is *simple* compared to OBDII. An OBDI ALDL datastream operates at 8192 baud, with an RS232-like 8-none-1 encoding. All you need is a voltage to voltage converter (a la AKM interface cable) to translate the 5 volt ALDL bus wire to the RS232 compliant Transmit and Receive. That's it - voltage to voltage conversion. The rest is all software.
Now, for OBDII. GM OBDII has two modes - 1X - which is 10.4 kbps, and 4X - which is 41.6 kbps. OBDII Scan tools (AutoTap, Ease Diagnostics, M-E, etc) *only* operate at 10.4 kbps. That is GM's standard diagnostic bit data rate. Now, it sounds like being a kbps, that it might be RS232 compatible? Nope. GM uses Variable Pulse Width (see the Intel docs for more info). A logical low short pulse is a "zero", a logical low long pulse is a "one". A logical high short pulse is a "one", a logical high long pulse is a "zero". So, to send a byte of data, there is a voltage transition for every bit - high, low, high, low, high, low ad infinitum. The width of the pulse determines whether it's a 1 or a 0. Now, with RS232, you can have two 1's next to each other, and the voltage state of the two bits will not change between the two of them (I believe a 0 in RS232 is the range of +3 to +12 Volts, and a 1 in RS232 is -3 to -12 Volts) - so you can have (+V) (+V) (+V) (-V) (+V) (+V) being a valid sequence of 6 bits in RS232. Also, the OBDII data wire is transitioning between +12V and 0V (or thereabouts). So, due to the variable pulsewidth, you *must* have some sort of translator microprocessor between an OBDII data bus and an RS232 device.
The 41.6 kbps (4X) mode is used for reading from and writing to the flash memory. It's also known as programming / high speed mode. If a chip or cable can't do 4X mode, it can't be used to program a PCM. Period. My friends at Carputing designed their own cable to do this. It has to be capable of switching from 1X to 4X and back again. It took them a good deal of design time to hammer it out, but it works slick. To date, the guys at Carputing.com are the only ones who have a working, publicly available, <$1000 programming cable for OBDII, but it ONLY works with their software, and it ONLY works on LT1/LT4 and LS1 vehicles, and they are not giving away the keys to the castle. However, I know of another cable coming... Keep your eyes peeled this spring.
Now, for the exception to the rule. A member of the GMECM Mailing List wrote a quick and dirty DOS based utility to extract trouble codes from an OBDII vehicle - using the handshake lines of the RS232 port and 'bit banging'. Essentially, he samples the RS232 port to measure the time interval between pulses, and determines whether or not it's a 1 or a 0. And in sending messages to the OBDII bus, he does a similar timing procedure. However, he requires a rather quick computer to do the sampling (he uses a 500 MHz PIII - I could not get it to scan on a P1 133MHz machine). Although this is a novel approach, it's prone to errors and dropped bits, so I'd never use it for programming. But it supposedly works for getting trouble codes (I've never gotten it to work, even on my desktop Athlon 600).
Hopefully I've made it a little clearer why, technically, the AKM OBDI cable (voltage to voltage converter) can't be used to hook a laptop to a GM OBDII datastream - the variable pulse width aspect. That's the killer - a VPW OBDII datastream is completely, utterly, not RS232 compatible.
