1994-97 LT1 high speed data logging

Printable View

11-24-2023
hexdummy

1994-97 LT1 high speed data logging

So I've been following the great work that Tom H and others have been doing on the OBD2 LT1 ecu however I have not seen any discussion on this particular topic. Regarding datalogging, I realize there is a generic OBD2 communication layer which is very limited in data rate and selections of PID's, pretty much useless for tuning. A second layer that is GM specific that has all the "enhanced PID's" that is faster than the OBD2 but these are common addresses between different code bases, model years and possibly model types. Also, the data rate, while faster than generic OBD2 is still fairly limited at least based on what I've seen using my EFI Live interface. I know on the later LS1 411 ecu's commercial tools are able to communicate and a considerably faster data rate than the early LS1 computers, even so, still not that fast.

All that said, when GM was developing these engines and calibrations they must of had a much faster way to communicate with the ecu's as well as edit the calibration on the fly and have the ability to address any DMA not just the common parameters that are available on the TECH2. In the Bosch world they had what they called ETK which would typically sandwich between the processor/eprom and the ecu pcb, at least on older 1990's-early 2000's ecus. That setup had some sort of dual port ram arrangement and would also redirect the rom addressing to battery backed or EEPROM memory on the ETK board. With that setup you could log a very large number of ram addresses at very high data rates and edit any calibratable parameters on the fly using software called INCA. They also had communication protocols that although not as fast as the ETK, provided much higher data rates than the standard dealership level diagnostic tool as well as being able to log any direct memory address through the standard communication port (OBD1 or 2).

So:

1. Does anyone have an idea of how GM did it, i.e. did they have a development ecu like the ETK setup or was data access all done through the ALDL ?

2. Is there already a solution for DMA logging on these LT1 or even the LS1 generation of ecu's ?

3. What is the fastest data rate you can expect with either the 94-95 or 96-97 LT ecu with existing tools / software ?

Thank you in advance for any thoughts or comments on this topic.
11-24-2023
steveo

i can only answer question 3 for the 1994-1995 ecms
you have 9 (i think) bytes of overhead per message plus your data at 8192 baud so you can estimate your log rate from that
which isn't actually too bad although in modern terms i wouldn't call it high speed
you can statically configure the messages in the bin, when i made eehack i made a leaner message that only had tuning relavent data
i guess dma logging would be possible but for tuning these old ecms its a lot of effort for little gain
11-24-2023
Tom H

Quote:

Originally Posted by hexdummy

1. Does anyone have an idea of how GM did it, i.e. did they have a development ecu like the ETK setup or was data access all done through the ALDL ?

2. Is there already a solution for DMA logging on these LT1 or even the LS1 generation of ecu's ?

3. What is the fastest data rate you can expect with either the 94-95 or 96-97 LT ecu with existing tools / software ?

Thank you in advance for any thoughts or comments on this topic.

1. GM has an unpopulated connector on both the TSide and ESide boards that I have mentioned. This permits an auxiliary computer to be connected to the system. The way it works is very tightly coupled with the software and hardware used. The auxiliary computer puts ram in a memory space that is not used by other chips on the boards. When attached it initializes a tag that software looks at to establish if there is this added computer. There is then a bunch of handshaking between the two software (aux and PCM). Once complete the aux is given a time slice (I don't remember the time or rep rate at the moment). This allows the aux to get in, read whatever and return the address space to the PCM CPU.
To give an idea of how large this was, the PCM code that runs it resides above the calibration (TSide ends at $4326) and below the operational code (TSide starts at $4E8A). So that's about 3000 bytes. For the ESide the size is similar. It includes canned routines to access TPU registers. I have some of this documented but it is quite difficult without seeing an example of the hardware used.

While I believe this is what GM used, there are other possibilities... The DLC can run at 40Kbps. That's not fast but the PCM can be set to monitor with repetition thus eliminating the request/reply sort of protocol.

For ALDL you are stuck with 8.192 kbps if comms is to take place with the other modules.

2. The architecture used is not compatible with DMA. There needs to be some sort of handshake with the bus master (CPU) for DMA to take over the bus. I believe this was never part of the design.

3. In the '97 PCM I think the fastest you will get is through the class 2 interface. Using a mode $2A, up to six PIDs can be requested. There is an option to repeat at up to 25ms intervals. To keep this up as you would when logging, you must send keep alive/device present messages $3F such that the operation doesn't time out.

-Tom
11-24-2023
Tom H

One last thought... Assuming that you wanted to log info present in the SPI messages sent between the two boards, it would be simple to tap the link between the boards. Any micro with two SPI controllers would work. Problems, just a ton of them:
How to access the SPI without introducing ESD into the PCM and killing it.
Where to mount the added PCB.
How to keep all this water tight.

Works nice on my bench though.

-Tom
11-27-2023
1project2many

Tom H, your description matches what I know GM used with OBDI hardware. If you look through some of the OBDI hacs, there's an address called out as HUD. The GM Heads Up Display was a very cumbersome bit of hardware reminescent of the bridge controls in 1960's sci-fi movies. Engineers would have very fast and direct access to the data and in some cases could make changes to sensor readings to the ECM.
11-27-2023
hexdummy

Quote:

Originally Posted by Tom H

1. GM has an unpopulated connector on both the TSide and ESide boards that I have mentioned. This permits an auxiliary computer to be connected to the system. The way it works is very tightly coupled with the software and hardware used. The auxiliary computer puts ram in a memory space that is not used by other chips on the boards. When attached it initializes a tag that software looks at to establish if there is this added computer. There is then a bunch of handshaking between the two software (aux and PCM). Once complete the aux is given a time slice (I don't remember the time or rep rate at the moment). This allows the aux to get in, read whatever and return the address space to the PCM CPU.
To give an idea of how large this was, the PCM code that runs it resides above the calibration (TSide ends at $4326) and below the operational code (TSide starts at $4E8A). So that's about 3000 bytes. For the ESide the size is similar. It includes canned routines to access TPU registers. I have some of this documented but it is quite difficult without seeing an example of the hardware used.

While I believe this is what GM used, there are other possibilities... The DLC can run at 40Kbps. That's not fast but the PCM can be set to monitor with repetition thus eliminating the request/reply sort of protocol.

For ALDL you are stuck with 8.192 kbps if comms is to take place with the other modules.

2. The architecture used is not compatible with DMA. There needs to be some sort of handshake with the bus master (CPU) for DMA to take over the bus. I believe this was never part of the design.

3. In the '97 PCM I think the fastest you will get is through the class 2 interface. Using a mode $2A, up to six PIDs can be requested. There is an option to repeat at up to 25ms intervals. To keep this up as you would when logging, you must send keep alive/device present messages $3F such that the operation doesn't time out.

-Tom

I’m coming back with a few more questions :

1. I clearly missed some of your notes regarding this topic in your previous threads, but I understand your explanation, very interesting. Too bad there is not more GM calibration documentation floating around like you can find for the early EECIV Fords. Maybe one of these development ecus will show up on ebay one day...

Over the weekend I came across an add on board for the LS1 ecu called "Real Time LS1" from a company in Australia which sounds similar to the interface you are describing. I may ask these guys if they ever offered (or considered offering) their interface for the LT1 as it would appear that they have been around for a while.

If the DLC can run at 40Kbps that sounds reasonable fast. Is this that standard protocol i.e. TECH2 class 2 interface at 4x, or would this involve some code modification in the ecu ? Also would this mode allow for specific memory addresses or PID’s or just those available in the TECH2 ?

2. Let me clarify my question as my terminology may have not been correct. I meant to ask is there a way to log directly the RAM memory addresses as opposed to the receiving the preset message packets intended for the TECH2. Steveo mentioned in his post on this thread that he trimmed down the message on the $EE to improve the data rate using his software, I imaging you can also replace some of the standard parameters in that message on the ECU side ?

3. If I understand correctly the scanning side of the LT1 should work the same as it would with a LS1A or LS1B. I went back through your posts on the 1997 F-Body ECM thread pg. 29 which go over the 2A mode as well as some other addressing modes. Assuming this ecu should communicate with the LS1 logger in Universal Patcher, then I need to do a bit more homework to understand how that software works, i.e. are the PID’s common for all LS1 computers and if so are they also common for the LT1 i.e. LS1 PID’s same as LT1 PID’s ? If not, I need to figure out how to find them.

To your last post, do you actually have that working on your bench? If so that’s pretty cool. A cruder way I suppose it could be done is using a pair of emulators like the Moates Ostrich at least for editing the ROMs.
11-27-2023
hexdummy

unintended post
11-27-2023
hexdummy

Quote:

Originally Posted by 1project2many

Tom H, your description matches what I know GM used with OBDI hardware. If you look through some of the OBDI hacs, there's an address called out as HUD. The GM Heads Up Display was a very cumbersome bit of hardware reminescent of the bridge controls in 1960's sci-fi movies. Engineers would have very fast and direct access to the data and in some cases could make changes to sensor readings to the ECM.

Interesting, Chrysler had something similar called the Interrogator. It had a keypad on it and a vacuum florescent display, you could data log with it and I believe edit the rom on specially modified ecu's using the keypad.
11-27-2023
Tom H

Quote:

Originally Posted by hexdummy

IÂ’m coming back with a few more questions :

1. I clearly missed some of your notes regarding this topic in your previous threads, but I understand your explanation, very interesting. Too bad there is not more GM calibration documentation floating around like you can find for the early EECIV Fords. Maybe one of these development ecus will show up on ebay one day...

Not sure if I detailed much of the interface or s/w that drives it. Ask for what info you need... I have worked through some of the cal. Limited by my knowledge of auto trans and so on.

Over the weekend I came across an add on board for the LS1 ecu called "Real Time LS1" from a company in Australia which sounds similar to the interface you are describing. I may ask these guys if they ever offered (or considered offering) their interface for the LT1 as it would appear that they have been around for a while.

If you like I could put together a pinout of the interface for them to look at.

If the DLC can run at 40Kbps that sounds reasonable fast. Is this that standard protocol i.e. TECH2 class 2 interface at 4x, or would this involve some code modification in the ecu ? Also would this mode allow for specific memory addresses or PIDÂ’s or just those available in the TECH2 ?

The 40K (yup, class 2 at 4X) isn't always 40K *exactly*. To a small degree it depends on the distribution of ones and zeros because of the VPW pulse widths. If you want the automated repeat, that needs to be a PID. You could easily add a PID for whatever you need, but this would need a custom flash.

2. Let me clarify my question as my terminology may have not been correct. I meant to ask is there a way to log directly the RAM memory addresses as opposed to the receiving the preset message packets intended for the TECH2. Steveo mentioned in his post on this thread that he trimmed down the message on the $EE to improve the data rate using his software, I imaging you can also replace some of the standard parameters in that message on the ECU side ?

You can read/log ram. Looks like you can use Dynamically Define Diagnostic Data Packets (that's mode $2C). I have messed with this a bit, but not enough to give you details.

3. If I understand correctly the scanning side of the LT1 should work the same as it would with a LS1A or LS1B. I went back through your posts on the 1997 F-Body ECM thread pg. 29 which go over the 2A mode as well as some other addressing modes. Assuming this ecu should communicate with the LS1 logger in Universal Patcher, then I need to do a bit more homework to understand how that software works, i.e. are the PIDÂ’s common for all LS1 computers and if so are they also common for the LT1 i.e. LS1 PIDÂ’s same as LT1 PIDÂ’s ? If not, I need to figure out how to find them.

Can't help you here... I have not looked at LS1A/B, nor have I any experience with the Patcher. I do know that the '96/7 PCMs have complexity due to having two boards/cpus. There are two addresses used in class II. You can't directly converse with the ESide. All messages need to be processed by TSide.

To your last post, do you actually have that working on your bench? If so thatÂ’s pretty cool. A cruder way I suppose it could be done is using a pair of emulators like the Moates Ostrich at least for editing the ROMs.

I have not made hardware/written software to look at both E->T and T->E at the same time. The ideal would be to have a two line display. I have decoded the format, found the sequence info and looked at each direction separately.

-Tom