24x conversion...
Yup, they did a bunch of work, that requires the end user to do a bunch of work. I know you have a zr1, but if you have ever had to yank off an opti, its no fun chore. To add insult to injury, they require the user to remove the timing cover... AND pay a chunk of change. I think differently than most, and the way I look at their method is "you want me to pay $2000 for something that doesnt work on my car, and you want me to spend 8-16 hours installing it?" You would almost have to pay me to get me to remove the crank hub on a LTX C4 with the engine in the car.
When I see what they have done, I think "I can do it better, for cheaper, and make everything work"
The LT5 has a unique designed system. But, I have designed a coil on plug system that would work just fine for the stock LT5 ICM. In fact its nothing more than removing the existing coils, using spade connectors and wiring in the individual coils from say a Chrysler 3.5l. The ICM does all the work already, and you just "distribute" the signals to individual coils. Working examples are on my brothers 3800 SC3 Fiero and a buddies 500hp Eagle Talon.
Yet I see you want the whole functionality of a new PCM, much like myself. A separate idea would have to be designed for the crank trigger on an LT5. Regardless, the position of the crank trigger is not critical to RPM, as many crank trigger fired engines easily exceed 7000rpm and the triggers have been located everywhere you can imagine. One particular example is a unit I made for a 7x reluctor on a GM 3500 v6, the reluctor was on the crankshaft snout. It was infront of the balancer, and not pressed on, only guided and bolted, like a washer. I spun to 7200 rpm with no errors.
The way these crank triggers work is with a hall effect sensor. They detect a change in magnetic field as it passes in front of the sensor. It is a transistor inside of the sensor. When the opposite pole from the transistors make (PNP or NPN) it forward biases the transistor allowing the voltage to flow through. The end result is a pattern that is cut into the metal reluctor. As each notch, grove or tooth passes, the status of the transistor changes, and you get a square wave dc signal.
The sensitivity of the sensor is not all that great, meaning the sensor needs to be pretty close to the moving metal to detect the change in magnetic field. I dont remember exactly but I think it was something like .20" is the maximum gap between the reluctor and sensor. Regardless of the distance to the reluctor, there is no requirement for position in the engine. To add, if you have a deflection of .20" on any part of the crank, you would have a grenade with a pulled pin.
The "noise" that gm refers to on their LSx is magnetic noise, or EMI. Since this sensor uses magnetic fields to detect the reluctor, any interference can be caused by another moving chunk of metal. This is the reason the reluctor is on the center of the cranks on some GM vehicles. It was the most neutral spot on the crank to cast in a gigantic chunk of metal and it saved cost, as this was done during crank casting. (probably not a cost concern on the LT5) Had GM decided to use a thin metal plate (like they did later on) they would have not chose to cast a gigantic weight into the middle of any part in the rotating assembly, like they did later on. The location of the reluctor in the center of the crank was for cost, ease of location, and partially misunderstanding/desgin requirements. (by misunderstanding or design requirements, I mean that there is no reason for the reluctor to be as wide or as stout as it was on the LT5, 60* V6, or Iron Duke, meaning they either didnt know that the sensor cant see very "wide" and there was no need to have something that large, or they had to make it that big due to casting in the middle of a crank)
Having said all of this, I respectfully argue the point of stability for the reluctor location on the LT5.
As an update to development, I have gotten some headway on the pinout conversion. I am making an excel program to match the pins from the old to the new, aligning them by circuit series, function of the circuit and wire color. The end result will be an excel spreadsheet that will show what wire needs to go where, what needs to be added, and what would happen if that wire was not connected.
As it stands, I think there is a way to simply make an adapter to plug the old harness into the new PCM, route a few new wires, and call it a day. No need to repin 160 wires, that stuff is for the birds.
Also, I have found that there is the possibility of using the newer style electronic cruise control modules. Updates coming soon.
-Jonathan
in the past all 800 series circuits were UART, as is here.
from http://www.atraonline.com/gears/2005...2005_05_26.pdf
The information is sent to
the PCM via a UART data line, hard
wired between the TAC module and the
PCM. The information sent is related to
the TP sensors, APP sensors, and other
relevant information. In addition, the
PCM sends the TAC module information regarding the vehicles operating
parameters such a MAF, MAP and
other information...
The low level logical format of GM's 8192 baud ALDL data stream is a simple async data stream with 8 data bits, no parity bit, and 1 stop bit. This is the type of data stream that most UARTs (Universal Async Receiver Transmitter) can handle. The PC (IBM clone) has a UART that can be set close to 8192 baud (actually 8226.6 baud, using a divisor of 14 with the 115,200 Hz UART clock - giving a 0.42% fast clock, a negligible difference).
8192 baud Frame Format
Commands to the ECU are organised into groups of bytes called command frames.....
Last edited by merlot566jka; Jan 9, 2013 at 10:33 AM. Reason: crappy internet connection
Given the C5 is using UART.
You need to simply change the throttle body for the cruise to a Throttle by Wire type which all C5's used. Me personally, I'd want mine stock setup. LS1 PCM can handle this F-body used a throttle cable in LS equipped ones 98-02?
Is the C5 multi-plexed like the C4 is to an extent?
I'm surprised the C5 isn't a Class 2 system. I have that listed in my notes for Car Computer communication.
FYI, you are off in the area where very few car folks go. I have a clue only because I'm trained/work on cars for a living.
Last edited by 93Rubie; Jan 9, 2013 at 06:58 PM.
The evolution of the data bus system is a bit involved...
the C5 had a few variations as time progressed, and to correlate it with the rest of gms stuff is kinda hard to do.
AFAIK:
C4- 92-96
UART serial data only.
CCM is master device.
ASR, ABS, A/C, DIC are all slaves.
DIC has limited access to CCM through trip/fuel/guages panel
97-98 ( i think)
Used UART for ALDL Data link. Still used 6800 processor
ALL VEHICLE MODULES USED CLASS II.
99-02
Class 2 for all communication
03-05
class 2 for major vehicle mounted computers (abs, tcs, tcm etc etc)
UART for TAC/APP system
06-08
CAN (what version of CAN, I dont know)
08-??
GMLAN
Using the drive by wire stuff is something I dont want to do. I dont like it. I have it on my Turbo Sonic,and have had it on several other cars... I just dont like it at all.
There are thousands of posts on multiple forums about ditching the drive by wire. It can be done with a few programming steps and a few other changes.
The C5 is multiplexed, the BCM is master. I think after the olds tornado, everything was multiplexed. Master device is usually the bcm/ccm
Some have multiple networks... not going to even look into that lol
The Best of Corvette for Corvette Enthusiasts
I can not find anyone who knows anything about this type of thing. Ive posted on multiple forums, emailed several companies and researched it to death.
Using the C4s PCM and piggybacking the 0411 pcm seems like the easiest idea. (this is what Balko above is saying) but this is not the best way to do it, in my opinion. its like a patch.
Swapping out the CCM for a matching set of PCM and BCM may be plausible. but at the same time, its like basically changing the whole cars electronics to a C5... why not just buy a c5 and call it a day. Haha.
So I am kind of going back to the drawing board.
I am going to post my thoughts here and see if anyone else can contribute...
The CCM receives information about the engine. This information is written and sent as UART. AFAIK, the CCM only checks to see if the PCM is still talking. (status word)
The specifics of this information seem to be what I posted above in that gigantic post that has coding in it.
Since all things are alike, the 0411 PCM also reports engine status and updates sensor readings to the BCM in its system. Except it uses a faster means of communication, Class 2. The coding and specific information is not known to me. But I am most certain it can be obtained.
So, what if....
We find out exactly what our CCM is looking for, by reading the code above, and see if we can find a match for the same information from above.
For example...
We know that engine coolant temp is displayed on the C4. The C4 PCM reports this information to the CCM. The CCM takes it and sends it to the cluster and DIC. It is then displayed.
We also know that the C5 PCM sends the engine coolant temp data to its BCM. Its BCM sends this to the cluster computer on the C5. It is then displayed.
So we know BOTH computers report the coolant temp sensor on their own respective style of serial data.
The next step, is to find out what sentence in the class 2 data stream is the coolant temp sensor information. Make a device, similar to the PIM, that understands the coolant temp sensor information. Have it read this information as class 2, and turn it into UART, and send it to the CCM. The CCM sees what it needs to, and does its job.
Now this is just one sentence of a very fast and fluid conversation. The example is in Barney style.
But this method would allow us to take class 2 data, decode it and make it into what we....
hold the phone.
A code reader communicates on class 2.... it can read a live data stream and display it. So this is nothing more than making a device similar to a code reader. Except we will have to make sure we arent sending a bunch of nonsense to the CCM.
The process would look like:
1. the 0411 spits out class 2 data stream
2. device reads and decodes information
3. device re-assembles information into UART word structure
4. device sends out word to CCM
5. CCM is happy.
6. CCM reports back
7. Device takes report, decodes it.
8. Device takes decode, translates information into Class 2
9. Device sends status report to 0411 PCM
10. 0411 PCM happy.
11. Rinse and repeat.
Okay. So there is a new path...
So What about the ASR signal for spark retard?
The SAE J1850.10.4 standard refers to the GM Class-2 communication protocol. This protocol has been used by General Motors since 1996.
With Class 2 data, each bit of information can have one of two lengths, long (128 us) or short (64 us). This is referred to as Variable Pulse Width (VPW). This allows the vehicle wiring to be reduced by the transmission and reception of the multiple signals over a single wire. The messages which are carried on Class 2 data streams are also prioritized. In other words, if two messages attempt to establish communications on the data line at the same time, only the message with the higher priority will continue. The device with the lower priority message must wait.
The data link connector (DLC) allows a scan tool to communicate with the class 2 serial data line. The serial data line is the means by which the microprocessor-controlled modules that are connected to it communicate with each other.
Once the scan tool is connected to the class 2 serial data line through the DLC at pin 2, the scan tool can be used to monitor each module for diagnostic purposes and to check for diagnostic trouble codes (DTCs).
Class 2 serial data is transmitted on a single wire at an average of 10.4 Kbps or higher depending upon the vehicle manufacturer's design.
The Class 2 bus is active at 7.0 volts nominal, however, it will measure at about 3.9 volts on a digital multimeter.
The Class 2 bus is inactive at ground potential (close to zero volts).
Last edited by merlot566jka; Jan 11, 2013 at 03:56 AM. Reason: you dont even know the half of it....
http://www.avt-hq.com/products.htm
OBD to UART interpreter
https://www.sparkfun.com/products/9555
making headway...
http://www.avt-hq.com/products.htm
OBD to UART interpreter
https://www.sparkfun.com/products/9555
making headway...
http://www.obdsol.com/obd-interfaces...bd-interfaces/
8192 Baud Asynchronous Communications With a P6 Processor
General Description.
The 8192 Baud data stream used by more advanced GM ECM's, (Type P4, P6 and P66) up to OBD II. The OBD II system is a CAN network, the communications protocol defined by statute.
The 8192 GM data format is asynchronous serial data the same as your PC is capable of processing, The 8192 baud rate is non-standard, but you can set the PC to a close enough so that the PC will accommodate the error.
The GM system is a master/slave system. Thus feature allows the vehicle to have multiple computers on line and avoids collisions between talker..
The user must initiate a short message to inform the receiving device that information is being requested. This message must conform to a specific format, describing the requested information as a block.
To Establish diagnostic communications between a P6 or P66 ECM or PCM and an outside computer do the following:
Mode 0 request, this clears any other communications such as the body computer, (dash board) , ABS brakes Etc.
Mode 1 request, This is a request for the diagnostic data stream, generally 60+ bytes of parametric data.
MODE 0, ALDL REQUEST:
MESSAGE ID = $F4
MESSAGE LENGTH = $56
MODE = $00
SUM CHECK
The ECM/PCM Will Reply:
MESSAGE ID = $F4
MESSAGE LENGTH = $56
MODE = $00
SUM CHECK
MODE 1, Data REQUEST:
MESSAGE ID = $F4
MESSAGE LENGTH = $57
MODE = $01
MESSAGE = $00
SUM CHECK
or
F45701B3
Note:
1. The sum check is the complement of the message. When the incoming message is added it
will always have a LSB of $FF
2. The message length is always $56 + the actual count of data bytes, in this case 1 byte.
The ECM/PCM Will Reply:
MESSAGE ID = $F4
MESSAGE LENGTH = $95
MODE = $01
data byte 1
x
x
data byte 63
SUM CHECK
To get another update the user must send another Mode 1 Request.
Possible data Reading Schemes:
The commercial scan tools generally use a 6800 series Motorola processor to decode and display the data. These commercial systems also convert the output to a standard serial data rate that is readable by a PC. The problem with all of this is it becomes a "kluge" of cables to set all of this up and the data format may not be what you want.
A more attractive method would be to eliminate the real time display part and have a small Microprocessor, (PIC Chip) translate the data and store it in a flash memory chip. I have found it very difficult to read and interpret data while driving, particularly if I'm using the data to do a tune up. I prefer looking at the results on my desk top and in some cases graphing them in order to calculate new values.
Other Communications Features:
The serial communications has several modes Typically:
Mode 2, Dump 60 bytes of memory starting with a user defined address.
Mode 3, dump of any 8 user defined address's
Mode 4, Controller mode, User may change AFR, Spark, TCC etc.
Mode 10, Clear diagnostic errors, (clear codes)
An example of Mode 2:
To Execute a Mode 2, Transmit the following message:
MESSAGE ID = $F4
MESSAGE LENGTH = $58
MODE = $02
Address MSB
Address LSB
CHECKSUM
The ECM/PCM Will Reply:
MESSAGE ID = $F4
MESSAGE LENGTH = $96
MODE = $02
data 1
x
x
data 64
SUM CHECK
.
An example of Mode 3,
To Execute a Mode 3, Transmit the following message:
MESSAGE ID = $F4
MESSAGE LENGTH = $65
MODE = $03
Address 1 MSB
Address 1 LSB
x
x
Address 8, MSB
Address 8, LSB
CHECKSUM
The ECM/PCM Will Reply:
MESSAGE ID = $F4
MESSAGE LENGTH = $63
MODE = $03
data 1
x
x
data 8
SUM CHECK
An example of Mode 10, "Clear Error Mode":
To Execute a Mode 10, Transmit the following message:
MESSAGE ID = $F4
MESSAGE LENGTH = $56
MODE = $0A
CHECKSUM
The ECM/PCM Will Reply:
MESSAGE ID = $F4
MESSAGE LENGTH = $56
MODE = $0A
SUM CHECK

Especially at 11PM at night. I'll read thru your posting/links tomorrow some time.
I am interested in the pinout. I'm PM'ing you my e-mail.
I would not worry about the ASR spark retard. That is just a single signal to the ECM to reduce it.
The ASR would still work as long as it was hooked up just no spark retard. Its mostly throttle closing and brake pulsing anyway.
I am working 12am to 12pm offshore of Louisiana right now, and we have had a considerable amount of down time, which is really helping research and learning. Sorry to overload everyone at such late/early hours, in a month or so, Ill be back on land and the posts will be around normal human hours.
As for todays developments...
I have not heard a peep back from LTCC, I do not think they are interested.
I did get in contact with one of GMs software and data protocol engineers from the 1983-1996, Paul Bowen. We emailed about the conversion of the J1850 VPW protocol to the GM UART 8192 protocol. He isnt aware of anything that does this, and said it would be a very daunting task. More updates to come from him, I assume. It would be nice if I could hire him to design this, or at least throw in a bit of help.
I have found the break down of both languages. But that is only half of the story. The other half comes from the actual information that is being used by the computers. Its not like just translating from english to spanish... its like translating chinese and caveman! The words formed by the 0411 pcm have more 'letters', and it talks faster than our PCM. So we cant just match up letters, or even words. We have to dissect the 0411 words, take out the information, and turn it into our words. Then when our ccm wants to talk back, we have to take its words and send it over to get beefed up into the 0411 words. And to do this, we have to know all of the words and letters that both computers will ever speak.
Another thing to add, and discover, is that if our DIC and Cluster use the data stream, or if the CCM does all of it. Because what I see in the CCM data stream shows no information about the engine. It only knows if the PCM is there or not. This would imply that isolating the CCM from the data bus would only effect the happiness of the CCM, and not necessarily the data that goes to the DIC and Cluster.
So tonight, I will see if the www has pinouts for our cluster, DIC and ccm. These should let us know which data is being sent by process of elimination.
The final bit of interesting info, our cars have both class 2 data stream AND GM 8192 UART data stream.
What does this mean? This means that the car has two data buses. The bus system for the entire car is only UART as far as we know. But you can use the Class 2 data to access the PCM and all of its information. This was known as OBD 1.5. We are a gray area.
But what it leads me to believe is that our PCM already does what I am trying to do. It already translates everything to Class 2. Well at least everything that is pertinent to the PCM. I dont know what to make of this information just yet.
ccm green
it has serial data... and it controls the cluster lcd.
more to come...
The Serial Data Circuit is a master (CCM)/slave (ECM) configuration.
The CCM polls the ECM. If the ECM fails to respond after 3 consecutive polls (3x200ms/600 miliseconds) a Code 41 sets.
The Serial Data Circuit links Serial Data 1 to Serial Data 2, which includes the electronic HVAC controler, ECM, ALDL teminal, and anti-lock braking controller.
-----
The CCM is part of the VATS system (and other stuff too). When the key is inserted and turned, the resistance of the pellet is checked. If it checks out, the CCM sends a byte string to the PCM saying all is good. Programming this out of the PCM is easy with tuning software. That will remove the CCM from the VATS equation (but there is more to removing VATS completely).
F-body PCM's are the same hardware, but programmed differently. F-bodies have a BCM instead (body control module). When the key is turned, a 50 hz square wave is sent to the PCM to signal everything is good and the PCM can allow the car to run. Note that the signal is different. While the CCM actually 'talks' to the PCM, the BCM only sends a square wave signal.
-----
DIC/Trip computer info...
tuning the trip computer in the ecm
----
cluster to ccm
it appears the cluster is only fed information for the LCD and this is not serial data we are concerned with.
to boot, the DIC is not a part of the whole game...
entire data bus
Last edited by merlot566jka; Jan 12, 2013 at 10:36 AM. Reason: oh you know
I'll have to dig into my FSM to take a look at this more.













