Code: EGR and CTS conversions

[1project2many]

1project, what ECMs are we talking about?

I can tell you that the 7148 (A C3) and 7783 (also a C3) uses the dual pull up setup. If you go here:
http://www.aces.edu/~parmega/efi/inside7747.htm there are links to pictures of both types of circuits for visual confirmation.

This whole thread is 1227747 $42 for now.

Makes it easier, but still... who wrote some of those disassemblies? Where did they get the temp conversions? Can you say for sure someone didn't copy the wrong info because they had no idea it was wrong?? Maybe not now but after you're done with this I'll bet yes.

The others I looked at were $4E, $4F and I forget, but all the same C3 type ECM, none of which had IAT.

I wonder how hard it is to identify the code that handles the switch from one resistor to another. That would be a sure way to know what you're working with. Maybe it's as simple is identifying the shape or curve of the conversion table(s)?

When it looks like now they did not need a conversion at all?

You know, some of these guys had actual GM data in hand when they did this. For example, the commonly found GM P4 turbo document has this information:

2.4.1 Coolant Temperature
Due to the nature of the transducer interface configuration and the characteristics of the
temperature sensing thermistor, the A/D conversion is non-linear with coolant temperature.
ROM tables *FCLT348* and *FCLT4K* linearize coolant temperature to provide a coolant
range from -40 to +152 Deg C (3/4 of a degree per count).

So the raw A/D counts cannot be converted with a simple formula, but there is a math conversion for the eight bit value that represents coolant temp after the table lookup. And since most of the gmecm's I've worked on report CTS within roughly the same range, it's hard to imagine using any other formula for an eight bit value. The actual conversion from a GM paper is N = (E + 40) * 256 / 192.

Now you need to know if you're using values that represent raw a/d temp or linearized temp. The note "1K p/u" is the author's way of distinguishing the two. Three different datastream definitions for the L05 use the same chart of A/D to CTS values and based on the values it appears that inverted CTS is output on the ALDL. Is this how the conversion is set up for the scanner part of TP? If not, then the values you see when testing may not be correct. If you're monitoring events using ALDL data and you're unsure of the temp conversion, use the hex values. You'll be able to make a direct comparison between programmed and sensed temp and you can often tell if you're testing a linearized value vs a raw a/d count value.

I think I'm going to stop here for now. The kids are up and active and I don't get more than three minutes of clear thought before I have to go resolve one conflict or another.

HTH.

[EagleMark]

Three different datastream definitions for the L05 use the same chart of A/D to CTS values and based on the values it appears that inverted CTS is output on the ALDL. Is this how the conversion is set up for the scanner part of TP? If not, then the values you see when testing may not be correct. If you're monitoring events using ALDL data and you're unsure of the temp conversion, use the hex values.

The ALDL end is all documented in ALDL.ds charts, but I went to double check my work. Temps in ALDL datastream have always been correct from startup (ambient) to warmed up (T stat temp), data coming in is raw and goes to a lookup table.

 
5         COOLANT TEMPERATURE             SEE TABLE 1

Value of coolant X sent to lookup table, look up mode is Interpolate.
        
TABLE 1 --- COOLANT TEMPERATURE


         A/D            DEGREES
        COUNTS             C
        -------         -------
          255            -40
          251            -30
          250            -25
          247            -20
          245            -15
          241            -10
          237            - 5
          231              0
          225              5
          218             10
          209             15
          199             20
          189             25
          177             30
          165             35
          152             40
          139             45
          126             50
          114             55
          102             60
          92              65
          81              70
          72              75
          64              80
          56              85
          50              90
          44              95
          39             100
          34             105
          30             110
          26             115
          23             120
          21             125
          18             130
          16             135
          14             140
          13             145
          12             150
           0             200

So I believe ALDL temp data for comparing what is happening is accurate.

Since I see the same remarks in disassembly I'm wondering if this is where they got the info? And one parameter already has been proven to not need this, it was not marked 1KPUP, but had a conversion, take out conversion and it is accurate in hex compared to data stream Coolant temp.

But in TunerPro XDF looking at:
LD299 FCB 64 ; xxC COOL, Min for CLS LP Enable
Hex is 40h, TP shows in calculated view as 64d. Is it as simple as the decimal value shown for hex is Celcius?

Then I'll try and find a 1k pup one to test...

[1project2many]

ECMGuy had access to datastream documents as well as GM calibration docs. I'd believe a mistake in labeling raw data as 1k or vice versa, but I'd be surprised at a large conversion error.

And here's a great place to introduce a little code teaching. When you look at disassemblies and you see something like "LD035 EQU D035" you're looking at a chance to make the disassembly better. The "LD035" part is a label. The disassembler and the assembler (if you get that far) can both replace the address D035 with a name that means something. When no name is assigned ahead of time many disassemblers will assign a name based on the location as the disassembly progresses. But it really helps to improve readability if we were to assign something like CTS1KPU EQU D035. The name CTS1KPU will replace the address D035 everywhere in the disassembly. Turns lines like STAA LD035 into STAA CTS1KPU. It can help to keep things clear during those late nights pouring over machine code.

[jim_in_dorris]

I actually teach using meaningful names for variables, so I completely agree with 1project. My editor lets me use find and replace, so that would be a simple job, and I probably should clean it up a little by doing something like that. Right now I would like to make certain that the comments are accurate. 1 thing at a time, or I get too sidetracked. I really think that if we can get 1 assembly correctly commented all the way through, then understanding what is going on and why will be easier.

[1project2many]

I was using GM variable names for a while or a slight modification of a GM name. Sometimes they are meaningful without any additional info, like krefangl or kmaxadv but other times they're almost as bad as the disassembler assigned name, i.e. k42rna. But at least they corresponded to other documentation and since they matched OE, they do form something of a standard.

I have posted requests for "caldocs" on a few forums and I have also done a fair amount of searching to see what can be found on the net. "Caldocs" are the the original documentation for a calibration which specifies variable location, name, value, and in many cases additional notes. With an honest effort going on to clear up these partial disassemblies I think it's time to get as much GM info as we can out into the open.

[EagleMark]

First those hex temps I found are accurate, but only produce the engine shut off if ERG compensation table is zeroed out. If left stock the problem does not happen. So I think the hex for coolant on/off is accurate.

But the EGR compensation table is percent, others are BPW, the hack spends a lot of time on EGR changes... so with 0 in EGR compensation table we were able to find exactly where EGR enable coolant temp was. The percent may be accurate but I believe it is BPW since that is starting point of fueling code.

Either way, guys have turned off EGR by coolant and it was wrong, EGR was still active and effecting fueling because of the EGR Compensation table... and never knew it!

There is no EGR bit on/off in ALDL stream...

[gregs78cam]

I posted yesterday while the forum was acting funny and I see it did not actually post. That table you listed seems a little off to go all the way to 200*C. That would be a significant difference in the conversion. ?

[EagleMark]

Yeah, I know and realized that from what you and others have said about the conversion going to 192c and others say 152c. But that one above is straight out of the ALDL.ds file from GM...

IIRC same as one found in hack, which may be copied in from ALDL.ds file...

On the ALDL data side it seems correct, next time I'll use my laser temp gun at CTS sender for a comparison.

[EagleMark]

I posted yesterday while the forum was acting funny

That was not funny, very stressful. So much for tech support telling me to use update patch when I needed a full newer version install!

[gregs78cam]

Everything I have seen says -40 to 152C, that's 192*C range for the sensor, if GM says -40 to 200, that is a 240*C range, then a lot of .ADXs are wrong.

[EagleMark]

I agree! Who's right?

Since it's also non linear which end is wrong? Or both ends? As long as the middle is accurate this is what matters. How many times do you see -40 or +200 Celsius?

[gregs78cam]

How many times do you see -40 or +200 Celsius?

Hehehe, I am hoping never.

[1project2many]

Mark, which EGR compensation table are you zeroing out? The BPW vs EGR table? That table determines how much fuel to deliver when EGR is displacing available oxygen. Don't zero it, set it the same as BPW.

[EagleMark]

Mark, which EGR compensation table are you zeroing out? The BPW vs EGR table? That table determines how much fuel to deliver when EGR is displacing available oxygen. Don't zero it, set it the same as BPW.

That's the problem, it's percent, not BPW? With it at 0 I could find the EGR enable temp, left at stock values I could not. So I believe it is still on in many cases where a guy turned EGR off by EGR enable temp. Wonder why you go lean? Opps, 70% of fuel because of EGR...

[1project2many]

Well, according to my $42 tuning notes, "Disable EGR: $1B8=FD, $1B9=FF, $1BF=00."

Nothing about the enable temperature.

But that still doesn't "Address" the issues at hand.