Code: EGR and CTS conversions [Archive]

EagleMark

03-16-2013, 09:29 PM

Thought I'd take advantage of this thread for learning purposes. Can't seem to track what issue is.

Here's the problem, EGR Temp enable is not working right in $42 mask/XDF.

LD1B3 FCB 120 ; ..c COOL FOR EGR ENABLE (1K PU) TBL 3
Can't find a table 3 and not sure what 1K PU is. There is a table for Coolant temp AD counts to C which I am used to using.

XDF parameter title.
EGR - Coolant Temp for EGR On!
Here's the conversion from XDF.
0.750000 * X + -40.000000

Stock ASDU is 59c/84 hex Is this sane? Does EGR wait till 59C to operate?

Raising it to max 151.xx C does not turn it off?
Lowering it to -40C does turn it off?

What's wrong? Should it be a Disable and not enable?

EDIT: Looking at some other CTS to Enable conversions are:
0.750000 * X -40.000000 NOTICE NOT + -40.000000
0.572900 * X + 0.000000
0.546875 * X

RobertISaar

03-16-2013, 09:43 PM

1K PU is referring to the A/D circuit using a 1K resistor to "pull up" the circuit to 5 volts. usually coolant temp is done through either a 348 or 4K(combined) resistor set, increases resolution. it looks like in the C3 era, GM only used a single 1K resistor to compromise between the two(check sheet3 of the Ludis schematics for the 7747).

i'm looking at the code that involves it(starting at EB59), that value is compared to 00E3, it branches to EBA5 if the calibration value is lower, where EGR DC% is set to 0. i'm seeing 00E3 being referred to as startup coolant temp in some locations as well. it only ever gets stored to at FDBA.

jim_in_dorris

03-16-2013, 09:52 PM

RobertISaar

03-16-2013, 09:58 PM

EDIT: Looking at some other CTS to Enable conversions are:
0.750000 * X -40.000000 NOTICE NOT + -40.000000
0.572900 * X + 0.000000
0.546875 * X

the first one is fine since the order of operations will do the multiply, then subtract.

the other two.... looks like someone was guessing at the correct conversion, they shouldn't look like that. when dealing with delta, you'll have X*.75(for *C, if *F, X*1.35), but for all others, it should be the X*.75-40 you're used to.

EagleMark

03-16-2013, 11:32 PM

Mark, that is a puzzler. I only looked at it for a minute, will spend some time tonight but that address is not referenced anywhere else in the code. It appears to not be used. also my ASDU has 132 at that location. It must be in the second chip. I was posting at the same time as robert, looks like he found something. I will try tonight to puzzle out what egr is doing.

Well unless my stock ASDU is compromised? I have 84h at that location which is 132d...

Truthfully I don't even know if it's EGR? I've always used another way to turn off EGR and worked well. This time I used it and set to max. engine would idle but not rev up? Turn it down and engine would rev up and run fine.

EagleMark

03-16-2013, 11:43 PM

the first one is fine since the order of operations will do the multiply, then subtract.

the other two.... looks like someone was guessing at the correct conversion, they shouldn't look like that. when dealing with delta, you'll have X*.75(for *C, if *F, X*1.35), but for all others, it should be the X*.75-40 you're used to.

As to not confuse Jim, I am know using the ASDX3 ASM and ASDX BCC to work on my $42 XDF...

Robert: Well back to your guess of guessing... may be it. What would be correct way to convert hex to decimal that represents temp in C without AD lookup?

I've found several variations of
0.572900 * X + 0.000000
0.546875 * X
0.588235 * X + 0.000000
all over the place. None of which come out to temps in Jims ASM. Some are close?

Like
LD299 FCB 48 ; 25c COOL Min for CLS LP Enable
0.546875 * X + 0.000000 Comes out to 26.26C

Hex shows 30 which is 48d

EDIT: Did find another old xdf that had conversion for above at
0.625000 * X + -5.000000 which comes out to 25c in Jims ASDX3.asm file...

RobertISaar

03-17-2013, 01:32 AM

EagleMark

03-17-2013, 02:12 AM

So everywhere I find these...?

0.572900 * X + 0.000000
0.546875 * X
0.588235 * X + 0.000000
0.546875 * X + 0.000000

Should be... ?
0.750000 * X -40.000000

Then just use whatever came stock value and wing it up or down?

Besides AD counts I Also found some reference to Inverse AD counts, no wonder there's so many conversions? No wonder this has always confused me...

EagleMark

03-17-2013, 02:17 AM

trying to calibrate using raw A/D counts is a horrible idea... you wouldn't be able to give it an equation or even convert it accurately at all since tunerpro doesn't support lookup tables in the XDF.Wondering how the ASM comes up with the value? Seems to be there and everyone just shot for a conversion that came close?

LD299 FCB 48 ; 25c COOL Min for CLS LP Enable

gregs78cam

03-17-2013, 02:37 AM

RobertISaar

03-17-2013, 04:24 AM

EagleMark

03-17-2013, 05:23 AM

I have wonderd about this before. But, according to a hac that I just looked at, the coolant temp calc (if indeed linear) should be a range of 192*C that is proportional to 256 A/D counts. Which would be the "0.750000 * X -40.000000" equation. Any parameter that references Coolant temp in *C should also be converted as such.Hmmm... well I wonder? Since the A/D counts to Degrees C I have goes from
255 = -40
and
0 = 200

If that should not be 0.781250 * X -40.00000 ?

gregs78cam

03-17-2013, 05:28 AM

all coolant tables I saw were from -40 to 152C = 192*C range

EagleMark

03-17-2013, 05:58 AM

I guess it's splitting hairs at this point? But your the one who got me started on math, math is cool, it's everwhere! Yeah well how come it's not exact? :mad1:

Found this in a $0D dis.asm

;>Coolant counts conversion table for raw A/D value
;
; A/D degrees A/D
; counts C Inv
; ------- ------- ---
; 255 -40 0
; 251 -30 4
; 250 -25 5
; 247 -20 8
; 245 -15 10
; 241 -10 14
; 237 - 5 18
; 231 0 24
; 225 5 30
; 218 10 37
; 209 15 46
; 199 20 56
; 189 25 66
; 177 30 78
; 165 35 90
; 152 40 103
; 139 45 116
; 126 50 129
; 114 55 141
; 102 60 153
; 92 65 163
; 81 70 174
; 72 75 183
; 64 80 191
; 56 85 199
; 50 90 205
; 44 95 211
; 39 100 216
; 34 105 221
; 30 110 225
; 26 115 229
; 23 120 232
; 21 125 234
; 18 130 237
; 16 135 239
; 14 140 241
; 13 145 242
; 12 150 243
; 0 200 255
;
;>Temp conversion for stored linear counts
; -Deg C = .746 x counts - 40

SO if it were needing inverse would it be 0.750000 * X +200.000000

EagleMark

03-17-2013, 06:06 AM

And this in a ASDX1.asm

; INV COOL BP'S
; 17 lns
; BIN Deg c
; ----------------
; 0 -5
; 16 5
; 32 15
; 48 25
; 64 35
; 80 45
; 96 55
; 112 65
; 128 75
; 144 85
; 160 95
; 176 100
; 192 105
; 208 110
; 224 115
; 240 200
; 256 201

gregs78cam

03-17-2013, 06:30 AM

jim_in_dorris

03-17-2013, 06:35 AM

Mark, I'm not sure where we are trying to go here, but if you look at ASDU LD1B3 as A/D counts, then 132 = 59 C. which is EGR enable temp right? That is using the .750000*X-40.00000 formula. Not sure if 59 C. makes sense as EGR enable, but if that's what's used, then at least I understand how it got from 132 to 59 C. I should problably edit some of these comments as we figure out what is going on to clear up confusion down the road. Let me know what you want changed in the comments and I will make those changes in all copies.

I made this change in my ASDU1.asm file. Does it make sense to you?

LD1B3 FCB 132 ; A/D counts (.750000 * X - 40.0000) 59c COOL FOR EGR ENABLE (1K PU) TBL 3

looking at the original 42 hack it has 48C, not sure which one is correct.

jim_in_dorris

03-17-2013, 06:45 AM

Ok, I think I have figured out the TBL3 reference. It should read "Real Time Service Routine 3" which is where the egr parameters are referenced.

EagleMark

03-17-2013, 08:07 AM

I don't know, I didn't write the comments in the hacs, I was just going off of what I saw. different PCMs with different PU resistors, may have a different scale from VDC(Analog) to counts(digital).

?I understand your going off what you saw, then it was a little different then what I saw, then almost close to the math! Then I found a completely different Inverse table?

The explanation of different PU resistors and scales seems most logical. I can't believe how many different conversions I found in the $42 XDF? All because of a EFG enable temp that seems to work backwards? Which is still an issue, big issue, but not part of the temps we have been discussing.

Mark, I'm not sure where we are trying to go here, but if you look at ASDU LD1B3 as A/D counts, then 132 = 59 C. which is EGR enable temp right? That is using the .750000*X-40.00000 formula. Not sure if 59 C. makes sense as EGR enable, but if that's what's used, then at least I understand how it got from 132 to 59 C. I should problably edit some of these comments as we figure out what is going on to clear up confusion down the road. Let me know what you want changed in the comments and I will make those changes in all copies.

I made this change in my ASDU1.asm file. Does it make sense to you?

LD1B3 FCB 132 ; A/D counts (.750000 * X - 40.0000) 59c COOL FOR EGR ENABLE (1K PU) TBL 3

looking at the original 42 hack it has 48C, not sure which one is correct. I wasn't trying to go anywhere except find out why raising the temp at LD1B3 made my engine quit running if I revved it up? Raising it should have turned EGR off, but instead it turned off fuel or something when I revved engine? Lowering it made everything OK. BTW this engine did not even have an EGR on it??? So trying to find out what it really does is more important, there are other ways to turn off EGR, if we can't figure it out I'm going to remove this parameter from the XDF. Who knows how many guys have problems now because they turned off EGR by raising this temp?

Ok, I think I have figured out the TBL3 reference. It should read "Real Time Service Routine 3" which is where the egr parameters are referenced. I looked but haven't found it yet, still learning and appreciate your assistance in helping me tune cars and learn this assembly stuff! :thumbsup:

For right now I'd like to figure out what AD count to digital is for 1227747? Supposed to be a 1kPU IIRC from Robert. Looking at the tables in hacs it's not linear. Nor do I know if they are correct or how to get correct info?

But take for instance ASDU3.asm
LD299 FCB 64 ; 18c COOL Min for CLS LP Enable
I think my ASDU is unmolested? It has 40h at that location. with 0.750000 * X -40.000000 it comes out to 8c?
If I change it to 64 as in ASM and use 0.750000 * X -40.000000 I get 35c

Neither is 18C ? SO I guess my question is? Is 18C correct? If so the conversion is wrong? How does 64h ever make 18c

I may have found it? Stock bin 40h, would line up to about 18c in this table I found in ASDU3.asm?

; INV COOL BP'S
; 17 lns
; BIN Deg c
; ----------------
; 0 -5
; 16 5
; 32 15
; 48 25
; 64 35
; 80 45
; 96 55
; 112 65
; 128 75
; 144 85
; 160 95
; 176 100
; 192 105
; 208 110
; 224 115
; 240 200
; 256 201

jim_in_dorris

03-17-2013, 09:28 AM

if that is a temperature refered to in counts. I think 35c would make sense if you are talking close loop enable at 95 F. Close loop enable at 64 F sounds a little low. However if 64 is degrees farenheit then it is indeed 18 C. That one is really puzzling. I would think that you have to look at what it is being compared to to figure out exactly how it is used. I really think after looking at the comments above it that it is in degrees farenheit.

1project2many

03-18-2013, 04:57 AM

LD1B3 FCB 120 ; ..c COOL FOR EGR ENABLE (1K PU) TBL 3
Can't find a table 3 and not sure what 1K PU is. There is a table for Coolant temp AD counts to C which I am used to using.
Looks like this has been straightened out. Careful about mixing disassemblies and strategies from different generation ecm/pcm's. You can get into trouble.

Here's the problem, EGR Temp enable is not working right in $42 mask/XDF.
EB5A: LDX #$D1B3 ; EGR PARAM'S ;
So we get the address for the enable value, D1B3.

EB5D: LDAB L0006 ; STATUS ;
We load up a status flag
EB5F: LDAA 0,X ; 48c COOL FOR EGR ENABLE (1K PU) TBL 3
Now we do a funny trick, we use the address loaded in X at $EB5A to load the a value into A. What value? The value found at the location in X. IOW, load the EGR enable temp into A.

EB61: CMPA L00E3 ; COOL, 1k pu
Compare A(enable temp) with L00E3 (coolant temp)
It helps me to remember this is actually a subtraction. It means "A - L00E3"

EB63: BLS LEBA5 ; BR IF COOL VAL LT THRESH[/code]
Branch if Lower or Same. If what is lower or same? If A is lower than or same as L00E3.
So this skips most of the EGR code if the enable temp is higher than actual. Not much more going on there.

I wasn't trying to go anywhere except find out why raising the temp at LD1B3 made my engine quit running if I revved it up?
Well, some bit set / reset arguments were occurring during the skipped code but I don't remember having any problems raising enable temps in the past.

The inverse coolant table exists because the ideal gas law, used for VE calculations, has temperature as a divisor. In the world of the HC09 and HC11, dividing takes more steps and more time than multiplying so the engineers simply did the division ahead of time and put it into a table for speedy lookup for multiplication.

Here's a neat page that might help with code:
http://www.slideboom.com/presentations/618212/68HC11-MICROCONTROLLER

EagleMark

03-18-2013, 05:25 AM

Well guys... I went through Jims new hacks and some old hacks and found 99% of all temps listed to hex number all calculated to
0.750000 * X -40.000000

What was done years ago? I don't know but we see all the examples above, as time moves on we learn and improve.

So that is what I am going to do with $42 I've been working on for years now... If you remember when I started (before this forum) I found several $42 masks, put them all together, then learned how to use the DSM/ASM, added stuff, practiced and learned. So all I can figure is all the ones I put together form different people all got it close? Then just recently found all the different conversions! It's been a great project, I've learned so much. But at this point it's probably overdone and I'm glad I found this last (hopefully) glitch.

Thanks for all the help! Was great sanity check because I was starting to loose it! :laugh:

But now I'm back to what started all this.
LD1B3 FCB 132 ; ..c COOL FOR EGR ENABLE (1K PU) TBL 3
Have to figure out why I raised this temp to disable EGR and when I rev motor it shut off? Well just like fuel was turned off?
I'm going to do some more testing on my stock 1990 Suburban that has EGR.

1project2many

03-18-2013, 02:32 PM

Ward had been around for a long time. I believe he was involved with original design of HEI ignition. I know he worked with Steve Cole and Tunercat to make TTS tuning software. And at the end, he was fighting cancer while trying to remain active on the efi lists. I think the comments were more of a casual thing, to be used by people familiar with GM code. As others tried to make disassemblies they used some of Ward's work verbatim. 'Tis the nature of the internet. But many of GM's formulas don't change over the years with OBDI so you can bet that coolant temp in one mask is calculated the same as coolant temp in another. A good sanity check is to calculate the upper and lower limits and see if they fit within the range of the sensor or data field. If not, the forumla is probably wrong.

EagleMark

03-18-2013, 06:14 PM

I missed your post #43 while typing...

That has been the issue, I can't find any of that or Service routine 3? Took your exact address commands and not a? So I started looking through all SRC, ASM files I have in $42 folder and Voila! One is three times the size! ARJU_HAC.src and sure enough it is there.

Not sure why I had an issue with raising EGR temp by looks of that?

What is the difference of a temp noted with 1k PU and one not?

For example:
LD1B3 FCB 132 ; 48c COOL FOR EGR ENABLE (1K PU) Matches Coolant temp table
LD296 FCB 102 ; 60 Deg c, (140f) CLS LP Timer WARM THRESH, (1K PU) Matches Coolant Temp Table
LD299 FCB 64 ; 35c COOL, Min for CLS LP Enable Does not match Coolant Temp Table

The ones that match coolant temp table still are not accurate with conversion for coolant temp table? 0.75000 * X -40

Or should I just give up and go back to life?

1project2many

03-18-2013, 07:05 PM

Are you talking about a raw a/d count to temp table?
I'll have to look through disassembly tonight.

EagleMark

03-18-2013, 07:10 PM

Yes...

jim_in_dorris

03-18-2013, 08:56 PM

Mark, when this is figured out, I will go through and change the comments in asdu and asdx. I looked at code last night, and when you raise the temp to max at that qualifier, it skips the rest of the egr code following, but then does some vacuum qualifier stuff and goes to a routine I don't fully understand yet. I will have to spend time with the pink book to try to understand what is going on.

EagleMark

03-18-2013, 09:42 PM

Well if I have you confused I feel much better! :innocent2:

1project2many

03-19-2013, 12:32 AM

it skips the rest of the egr code following, but then does some vacuum qualifier stuff and goes to a routine I don't fully understand yet.
I glanced through quickly last night and saw two jumps that ended with a save desired EGR%. Is the vacuum stuff after that?

Years ago I was warned not to set any temp enables to max or min values or strange things may happen. I've followed that warning so often that I didn't even think about it until just now.

EagleMark

03-19-2013, 01:20 AM

Years ago I was warned not to set any temp enables to max or min values or strange things may happen. I've followed that warning so often that I didn't even think about it until just now.I remember some earlier masks that had instructions for hex to disable. It did not max...

Wondering if max is beyond what hex it can handle and causing issues?

1project2many

03-19-2013, 01:31 AM

I would have more faith in the programmers to handle min and max. Yes, someone could have made a mistake but most of the time they handle the limits correctly.

jim_in_dorris

03-19-2013, 09:24 AM

I glanced through quickly last night and saw two jumps that ended with a save desired EGR%. Is the vacuum stuff after that?

Okay, I will take a stab at this...

at EB63, if the coolant value is below (LT) the threshold, it branches to LEBA5

EB63: BLS LEBA5 ; BR IF COOL VAL LT THRESH

then at EBA5 it clears the A register and does an uncoditional jump to LEC00

EBA5: LEBA5 CLRA ;
EBA6: JMP LEC00

At EC00, it stores pct EGR at L0080 from the A register which we just cleared, so %EGR is zero...

EC00: LEC00 STAA L0080 ; Pct EGR

It then checks if Heads up is on line

;
; CK IF HEADS UP ON LINE
; EGR MOD
;
EC02: LDAB L0000 ; STATUS MODE WD
EC04: BITB #$02 ; b1
EC06: BEQ LEC0B ; BR IF NOT b1
; ... else
EC08: JSR L5806 ; GOTO HEADS UP <-------<<
EC0B: LEC0B LDAB #160 ;
EC0D: MUL ;
EC0E: ADCA #$00 ;

not real sure what heads up code is all about, but it ends up at EC10 which is VACUUM Limiter code . Follow along here to see if I do this correctly

EC10: LDAB L0031 ; VACUUM
EC12: CMPB #192 ; VAC LIMIT aprox 20 Kpa
EC14: BCC LEC2D ; BR IF VAL VAL ...

the code gets vacuum (I assume from the MAP sensor) at L0031, compares it to 20 Kpa, and branches to LEC2D if it is less.

if it is more or equal, it compare the MAP sensor to 70 Kpa. If it is greater than 70 Kpa, it limits it to 70 Kpa. Here again, regardless of what happens, it will end up at EC20 where it will branch always to LEC2F

C16: CMPB #64 ; VAC LIMIT aprox 70 Kpa
EC18: BHI LEC1C ;
; ... else
EC1A: LDAB #64 ; VAC LIMIT aprox 70 Kpa
;
EC1C: LEC1C NEGB ;
EC1D: LSRB ;
EC1E: ADDB #96 ; 60 kpa
EC20: BRA LEC2F

so we can end up at EC2D or EC2F from this routine. This is the EGR Correction VS VACUUM Vs EGR duty cycle lookup. It exits at EC53 with an uncoditional jump to LE548

EC2D: LEC2D NEGB
EC2E: ASLB
***********************************************
*
* EGR CORRECTION Vs. VACUUM Vs. EGR D.C.
*
* ASDZ BP EGR
*
* TBL = Factor * 256
**********************************************
EC2F: LEC2F LDX #$D21D ; EGR CORRECTION Vs. VACUUM Vs. EGR D.C.
EC32: JSR LFB67 ; 3d LK UP
EC35: STAA L007F
EC37: LDAB L0006 ; STATUS
EC39: ANDB #$7F ; CLR b7
EC3B: LDAA L0080 ; Pct EGR
EC3D: CMPA LD1BD ; 19.9% D.C. THRESH FOR EGR ON
EC40: BLS LEC51
;... else
EC42: LDAA L0031 ; VACUUM
EC44: CMPA LD1BE ; 1 Kpa VAC THRESH FOR EGR ON, (100 Kpa)
EC47: BHI LEC51 ; BR IF VAC GT THRESH
; ... else
EC49: LDAA L000A
EC4B: BITA #$01
EC4D: BNE LEC51
; ... else
EC4F: ORAB #$80 ; SET b7
EC51: LEC51 STAB L0006 ; STATUS
EC53: JMP LE548

This is where I am not sure what is happening.. it sets some bits, but the comments are none existent. I do know that at the end of this routine, it goes into a loop where it clears interupts, then branches back to itself to clear interupt again.

E548: LE548 LDAA L0001 ;
E54A: BITA #$04 ;
E54C: BNE LE55B ;
; ... else
E54E: ORAA #$04 ; SET b2
E550: STAA L0001 ;
E552: LDAB L0070 ;
E554: STAB L00DD ;
E556: CLI ;
E557: ANDA #$FB ; CLEAR b2
E559: STAA L0001 ;
E55B: LE55B CLI ;
E55C: BRA LE55B ;

It appears to sit here waiting for the next interupt to occur if I read the pink book correctly.

1project2many

03-19-2013, 02:06 PM

not real sure what heads up code is all about
GM engineering had these huge "dashboards" that plugged into the internal edge card connector to display more data than ALDL at a faster rate. There was direct memory access, ability to toggle functions on and off, and whatever other toys an engineer might want for tuning. The setup looked like it might have been a prop for the pilot episode of Star Trek. Anytime you see "check to see if heads up online" you can safely assume it's not.

For the curious, this edge card connection is (or at least was) the basis for Dynamic EFI's "lockers" system.

E55B: LE55B CLI ;
E55C: BRA LE55B ;

It appears to sit here waiting for the next interupt to occur if I read the pink book correctly.
Interesting. But there's no room in this system for idle time so sitting and waiting for interrupts is not a good thing. I probably won't be able to look at this tonight thanks to incoming snow but maybe tomorrow.

EagleMark

03-20-2013, 07:21 AM

I've been looking through other old ECM masks and there's even a bigger questions as to CTS conversions?

But thinking of what 1project2many said about weird things happening when using MAX? Looked at conversions in calculated values, then hex! Min is 00 and max is FF, which would be right, right? But doesn't 00 and FF also mean nothing? Like when you burn a chip sometimes stock hex filler space is 00 then when burned it's FF...

I looked through some very old XDF/ECU files written by rBob, some enable temps were clearly noted to use a hex string below FF!

jim_in_dorris

03-20-2013, 09:26 AM

Okay try this again. I just finished grading 2 classes worth of finals, so the brain is a little fried right now.

Mark. 00 to FF hex is 0 to 255 decimal for a total count of 256.

if you are looking at an A/D converter which is measuring 0 to 5 V, then you have 5/256 or .02 volts per count.

if you look at temp range of -40 to 152 degrees for a total of 192 degrees (I assume that this is IAT) then you have 192/256 or .75 degrees per count

This works out as .75 degrees for every .02 volts.

Different ranges will have different results but will be similiar. HTH.

If you don't raise the EGR Qual temp to something that the coolant doesn't reach, then it exits differently. That may be why your truck runs poorly when you raise that value.

EagleMark

03-20-2013, 11:13 PM

Thanks Jim, most of that I knew.

Just had to question 00 and FF as it would always be the top and bottom. 3 reasons why were what 1project2many said about never going Max, but going above temp that would disable, second is old XDF files clearly state to use a hex to disable that was not max FF, third is looking at stock chips filler space is 00 and burned chips are FF.

EagleMark

03-20-2013, 11:40 PM

Well I did some testing today, had to find why this happened but was more interested in hex numbers that actually worked instead of the conversion to decimal. With correct hex it should be possible to create correct conversion.

Findings EGR Enable Temp:
1. Tests were done on fresh ADSU chip read from my factory ECM, in a factory ADSU vehicle while emulating with AutoProm.
2. Tests were all done warmed up and data showed 88c as Coolant temp. Varied up/down by 1c throughout tests.
3. EGR temperature to disable had drastic effects when "EGR - VE Comp Table" was zeroed out.
4. EGR CTS to enable 36h would die when revved up.
5. EGR CTS to enable 35h would run fine when revved up.
Conclusion: EGR is enabled/disabled at 35h/36h.

Findings Closed Loop Enable Temp:
1. Tests were done on fresh ADSU chip read from my factory ECM, in a factory ADSU vehicle while emulating with AutoProm.
2. Tests were all done warmed up and data showed 88c as Coolant temp. Varied up/down by 1c throughout tests.
3. Closed loop was entered at 91h
4. Closed Loop was exited at 94h
Conclusion: Conversion could be figured out that 91 to 94h = 88c.

Findings Closed loop entry at cold start:
1. Tests were done on fresh ADSU chip read from my factory ECM, in a factory ADSU vehicle while emulating with AutoProm.
2. Closed loop was entered at 69c when warming up.
3. Closed loop Enable Temp is 40h. Conversion in mask to enable Closed Loop is 8c
4. All timers for Closed Loop had long expired so I believe 69c is accurate.
Conclusion: Conversion is way off!

Both tests were done multiple times to insure accuracy.

Intresting note. I have tweaked my ASDU file for many things including entering CL sooner and my hex is 26 compared to stock 40

EagleMark

03-20-2013, 11:54 PM

I am going to test CTS when Closed Loop is entered again when vehicle cools off completely. 69c seems high?

But! if the conversion is removed and left at X the temp is 64c

40 hex is decimal 64. Is it possible these don't need a conversion?

jim_in_dorris

03-21-2013, 12:09 AM

Mark, that is correct. you are not looking at an A/D conversion for enable, but what temp is enable. (That is an awkward sentence) In that particular case, no conversion should be applied.

Mark. on your first test, were you changing location LD1B3 to 35 and 36 Hex? Stock is 132 decimal, hex 84 at that location. I am trying to use your values to walk through the code and see what is different. 88c would be 171 A/D counts or AB hex.

EagleMark

03-21-2013, 12:20 AM

:mad1: :mad1: :mad1:

So why do all these masks have a conversion?

And in which case does it need a AD conversion?

This is strange, some look completely sane with no conversion and some are completely wrong without a conversion?

Closed Loop Enable looks sane with no conversion at 64c and close to what I found at 69c

HiWay Min Coolant looks InSane at 133c

jim_in_dorris

03-21-2013, 12:26 AM

I think that we need to look at each individual case and determine how it is used. If we are comparing directly to A/D counts it's one way, and if we are comparing to already converted values its the other way.

EagleMark

03-21-2013, 03:34 AM

I agree and appreciate the help! I'd never been able to get this far without you and 1PTM help.

Looking through all these old masks they are all off.

Since a lot of these things don't need to be messed with we should look at important ones and maybe find a pattern of how they apply? Certain things like CL Enable, EGR Enable, DFCO Enable, PE enable etc.. are all important!

Back to Closed Loop Enable Temp, the 69c is accurate, may be a little less and closer to the 64C in bin because of the way 2 timers are involved could be an additional minute +. So 64c is what bin says, plus timers, I think this one is accurate, not sure if timers are accurate, next time I will check them for accuracy on seconds. Also this CL Enable is an important one. Why takes so long I don't know, my own personal tune is much lower and now I think I can get it even lower, there was a noticeable jump in MPG when doing all cold starts and around town driving in winter when I lowered this and other CL qualifiers. Never a drivability issue. My 98 Vortec 0411 goes closed loop within a minute... I've found so many similar errors in readings from EFI Live!

Is this how you actually get the comments for a hack? Dissembled, assembled, patterns, then find what does what? I've been using the 2d and 3d viewer in known hex to also understand how it is used in the process...

It's amazing this 1227747 $42 is what I started with for conversions, then tuning, then hex, reading assembly. It has all crossed over well to all other tuning including OBDII. And I'm still here where I started learning more!

I know this all started with you guys wanting to teach me the DSM/ASM, but understanding how these work and getting correct comments could be just as important! Seems the DSM/ASM would be easy compared to getting comments, then getting accurate temps or whatever for the comment even harder? So far I've only done one, CL Enable Temp C and it's not correct in comment of any ASM I've found.

Wish I still had my bench setup to run this... maybe a step up and figure out how to run a 0411 on bench? I have a 1990 Suburban test bench that works well!

EagleMark

03-21-2013, 03:42 AM

Mark. on your first test, were you changing location LD1B3 to 35 and 36 Hex? Stock is 132 decimal, hex 84 at that location. I am trying to use your values to walk through the code and see what is different. 88c would be 171 A/D counts or AB hex.Missed your edit above...

Yes LD1B3, stock ASDU is 84h

The 88c was what my coolant temp was reading in ADX file at time of test.

Attached is a clean read of ASDU, FYI it is identical to the one we have listed in $42 info thread as ASDU-$42-5.7L-Auto.bin‎

jim_in_dorris

03-22-2013, 03:50 AM

Sorry I missed this yesterday, busy grading and prepping for next quarter. What I really need to know Mark is what were you changing to 35/36 hex to cause your problem? I really believe you are using a correct bin, just not sure what location in that bin you are changing. Also at this point, I need to verify that L00E3 is the output of the A/D converter for coolant temp. also mark what location are you using to read the coolant temp?

EDIT!!! I was hunting thru the $42hack.asm and saw something that made me think. I know I have seen a table that related coolant temperatures to voltage output of the sensor. I need to look at that table, can you find it please.

EagleMark

03-22-2013, 04:45 AM

Sorry, same location noted below in BOLD.

Don't sweat it Jim if your busy, I appreciate the help, I'm not in a spot, right now we are in experimental mode for accuracy! :thumbsup:

Findings EGR Enable Temp: EDIT: 0x1B3
1. Tests were done on fresh ADSU chip read from my factory ECM, in a factory ADSU vehicle while emulating with AutoProm.
2. Tests were all done warmed up and data showed 88c as Coolant temp. Varied up/down by 1c throughout tests.
3. EGR temperature to disable had drastic effects when "EGR - VE Comp Table" was zeroed out.
4. EGR CTS to enable 36h would die when revved up.
5. EGR CTS to enable 35h would run fine when revved up.
Conclusion: EGR is enabled/disabled at 35h/36h.

Coolant temp is from ALDL and TunerPro ADX, Coolant is at 0x04, is that what you needed?

jim_in_dorris

03-22-2013, 05:48 AM

what parameter name in tunerpro is coolant temp, I can't seem to find it. And if I minded, I wouldn't have worried about responding, this is like a timeout from work, it helps keep me sane. Oops, to late for that. LOL.

I am looking at the ALDL output stream, and it looks like the raw temp is at $0025. That is just what I think at the moment, may change as I work this out. The problem is that this is inverse. That is higher counts = cooler temps. I am not sure where the conversion takes place yet from counts to temp for the aldl stream.

LD4ED FDB $0025 ; 4. COOLANT
; see table 1

here is the ALDL table entry, it is the 4th data item.

FAFF DECB ; DECR DIAG MSG LINE COUNTER
FB00: ASLB
FB01: ABX ; ADJ ADDRESS INDEX
FB02: LDX 0,X ; GET ADDRESS FROM TABLE
FB04: LDAA 0,X ; GET VALUED FROM ADDRESS
FB06: LFB06 STAA L007C ; CURRENT DIAG OUTPUT VALUE

This is where it sticks the value in the ALDL stream. at FB02 when X =4, it will get $0025 from the ALDL table (LD4ED), then at FB04 it will get the value stored at $0025 which should be the coolant temp. However, I can't seem to find where the value in $0025 changes from counts to temp. It may already be in temp when it is stored. How $00E3 and $0025 relate is something I haven't figured out yet. Also trying to figure out exactly why 34/35 is the breaking point when you test.

EagleMark

03-22-2013, 07:40 AM

And if I minded, I wouldn't have worried about responding, this is like a timeout from work, it helps keep me sane. Oops, to late for that. LOL.
I to find this way more relaxing then life in general! :popcorn:

Yes, this is where Coolant temp goes to ALDL, I am reading it in Data through TunerPro ADX called Coolant Temp. It's not in XDF as data...

;---------------------------------------------
; ALDL XMIT TABLE OR ADDRESSE'S
; 127747 ECM
;
; 5.7L TBI L05 C/K 87,91 TRUCKS
;
; DATA PIN: Read data on PIN "E" of ALDL Connector
;
; BAUD RATE: 160 Baud
; Open - 20 Bytes
; 10k - 20 Bytes
; Shorted - 20 Bytes
;
;---------------------------------------------
ORG $04E7 ;
LD4E7 FDB $D002 ; 1. EPROM ID LSB
LD4E9 FDB $D003 ; 2. EPROM ID MSB
;---------------------------------
LD4EB FDB $00FD ; 3. CURRENT IAC POSIT, (0-255)
; N = COUNTS
;---------------------------------
LD4ED FDB $0025 ; 4. COOLANT
; see table 1
;---------------------------------

Coolant table 1 is about line 2438 in ASDU3.asm

;=============================================
;
; 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
;
;=============================================

Have you ever looked at ARJU_Hac.src ? It has a lot of stuff after the Prom.

jim_in_dorris

03-22-2013, 08:07 AM

EagleMark

03-22-2013, 09:20 AM

I think it's just a start up coolant temp.

L00E3 EQU $00E ; START UP COOL

jim_in_dorris

03-22-2013, 09:30 AM

L00E3 EQU $00E3 ; START UP COOL

And the only place that I find $00E3 referenced says start up cool when it loads, but it only gets stored here

: LDAA LD51F ; 50c,Coolant default, ERR 14/15
FDBA: LFDBA STAA L00E3 ; COOL, 1k pu

; Error 14/15 param
; Coolant default
;---------------------------------------------
LD51F FCB 126 ; 50c, 122f Coolant default

That would mean that it is comparing the EGR enable to 126 counts, 34/35 hex would not be close, as I explained above. and it would never change. It has nothing to with actual coolant temp.

here is what happens..

load accum with 132 (from D1B3) EGR parameters
compare 132 to 126 (from 00E3)
Branch if 132 less than 126. Nope won't branch.

Set D1B3 to 34 or 35 and it will branch. The part causing it to die is tied to actual coolant temp not here. I will venture to say that any value above 34 hex and below 7E will cause your truck to die and anything below 35 hex your truck will run. Now we need to find out why setting the EGR enable does that. How is it tied to actual coolant temp. I will keep exploring this.

gregs78cam

03-22-2013, 09:34 AM

Okay mark, it looks like $0025 is raw counts, does the ADX do the conversion to temp? I still don't see how $0025 and $00E3 connect.

edit. I looked in TPV5, it does a lookup, so $0025 is raw counts and is somewhere around 52 or 53 counts for 88 c. This is right at 34/35 hex.. now if I can just tie $00E3 to $0025 I will know what is happening with the data.

That seems to make sense. The PCM stores and sees everything as a digital 'count', the ADX converts that to a real world value, and we can see it in HexEdit as a hexadecimal number. Mark if you were to change you view in HexEdit to decimal it should show the counts, which the ADX converts to *C.

EagleMark

03-22-2013, 10:17 AM

I will venture to say that any value above 34 hex and below 7E will cause your truck to die and anything below 35 hex your truck will run. Seems you found something very close to my test...

4. EGR CTS to enable 36h would die when revved up.
5. EGR CTS to enable 35h would run fine when revved up.

Mark if you were to change you view in HexEdit to decimal it should show the counts, which the ADX converts to *C. That's what I started to do when I found this issue. Then found so many different conversions I had no idea what was going on? Half of which need no conversion! Some I have found to look sane and react exactly to hex, converted to decimal. Other's are way off and must go through the A/D counts and need the conversion.

EGR was another whole issue that started the temps conversion issue.

jim_in_dorris

03-22-2013, 10:21 AM

I found it!!!! Coolant from $0025 (actually result from A/D) stored at E3 here

FD91: LFD91 PULA
FD92: CMPA LD51E ; 35c, COOLANT LOW LIMIT
FD95: BLS LFDBA

The PULA is get saved accum A value. I followed it from the A/D converter to here.

FDBA: LFDBA STAA L00E3 ; COOL, 1k pu and save it here. I now know how this works. E3 and 25 are the same thing so it makes sense. When coolant temp is 88 C the counts are 34/35 hex. everything fits. now to figure out why your truck dies.

jim_in_dorris

03-22-2013, 10:30 AM

EagleMark

03-22-2013, 10:33 AM

I know why it dies! It's because I set the "EGR CTS to enable 36h would die when revved up."

I know when it runs! It's because I set "EGR CTS to enable 35h would run fine when revved up. "

You just verified it in code! Give or take 1h for coolant temp at 88c and did have 1c variable in tests.

:laugh:

OK Back to serious... why would turning on/off EGR Enable temp there even matter while parked and rev engine up? Would barley hit 1000 RPM and seemed to shut off fuel? Async flag came on at same time as it started to die... Dam, I should have watched what BPW was doing at the same time!

jim_in_dorris

03-22-2013, 10:33 AM

Also, this comment is WRONG

CMPA LD51E ; 35c, COOLANT LOW LIMIT

It should be -35c.

No Mark, we know that setting those values causes it to die, not why it dies. Thats what I intend to figure out next.

EagleMark

03-22-2013, 10:48 AM

I will start looking at EGR stuff tomorrow after I finish a little paid work. I really think I am getting a handle on this. Mark please start making a list of questions about Coolant temp comments and I will try to resolve them as I can.Well here's one we can consider accurate.

Edited Findings Closed loop entry at cold start LD299 :
1. Tests were done on fresh ADSU chip read from my factory ECM, in a factory ADSU vehicle while emulating with AutoProm.
2. Closed loop was entered at 69c when warming up.
3. Closed loop Enable Temp is 40h with no conversion is 64c
4. Add in 2 timers that add up to over a minute and I did have engine at 1200-1500 RPM for the warm up... so I believe 64c is accurate.

Change would be:
LD299 FCB 64 ; 64c COOL Min for CLS LP Enable
it is
LD299 FCB 64 ; 18c COOL Min for CLS LP Enable

Could double check with this?
2. Tests were all done warmed up and data showed 88c as Coolant temp. Varied up/down by 1c throughout tests.
3. Closed loop was entered at 91h
4. Closed Loop was exited at 94h
Conclusion: Conversion could be figured out that 91 to 94h = 88c.

1project2many

03-23-2013, 08:24 AM

Mark,

I wanted to double check this before replying just to make sure it's correct.

Within the ecm there are "pull up" resistors which are used to create a bias voltage on the temp sensor line. The temp sensor then pulls this voltage back to ground. The voltage is read by the A/D converter and associated with a temp reading. However, not all ecm's are the same in this regard. The 7747 uses a single fixed 1k pull up resistor to create a single bias voltage. You'll see the references "1k p/u" in some of the disassemblies. But other ecm's use a dual pullup resistor circuit and the ecm is able to choose which resistor to use. This apparently allows better resolution across the temperature range. The resistors used are 348 and 4k Ohms. For these ecm's you're likely to see a very different A/D --> Temp conversion chart. In addition to this, the IAT sensor may also have a fixed pull up resistor of 2.5k Ohms which would lead to another A/D conversion table.

In summary, be careful if hopping from one disassembly to another looking at temp conversion charts because different ecm's will probably have different charts.

jim_in_dorris

03-23-2013, 08:40 AM

1project, what ECMs are we talking about? I think mostly right now we are concentrating on the 7747 with $42 but if other ECM/Dissassemblys are used, it would help to know which ones.

EagleMark

03-23-2013, 10:01 AM

This whole thread is 1227747 $42 for now.

The others I looked at were $4E, $4F and I forget, but all the same C3 type ECM, none of which had IAT. All of them had similar conversions but again different, most were in this range:
0.572900 * X + 0.000000
0.546875 * X
0.588235 * X + 0.000000
0.625000 * X + -5.000000

When it looks like now they did not need a conversion at all? Well some, that is the porpose now to decifer which is which. Besides the EGR issue.

All good information though Shannen, it will help as I persue some of these others. As always I appreciate your expertise and time to help us! :thumbsup:

1project2many

03-23-2013, 03:25 PM

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

03-23-2013, 08:09 PM

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

03-23-2013, 08:39 PM

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

03-23-2013, 09:53 PM

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

03-24-2013, 03:07 PM

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

03-24-2013, 07:42 PM

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

03-24-2013, 08:24 PM

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

03-24-2013, 08:31 PM

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

03-24-2013, 08:34 PM

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! :mad1:

gregs78cam

03-24-2013, 08:39 PM

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

03-24-2013, 09:28 PM

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

03-24-2013, 11:04 PM

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

Hehehe, I am hoping never.

1project2many

03-25-2013, 12:06 AM

EagleMark

03-25-2013, 12:33 AM

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

03-25-2013, 01:34 AM

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.

EagleMark

03-25-2013, 02:46 AM

I have those notes as well. It seems someone figured out how to disable EGR with 3 values (on low vac, on high vac, and TPS%), when it should only take the Enable Temp which is where I found this issue!

Then the Coolant temp conversion issue...

jim_in_dorris

03-25-2013, 06:09 AM

Okay Mark, when you have time, look at the log just before your truck dies for fueling. I think that it may be part of the EGR correction VS Vacuum VS EGR D.C. I haven't completely figured out that table, but it looks like it gets to that table with the D.C. = 0, but is assuming a D.C. of 30% If that is the case, then it takes away fuel and your truck dies. Not positive that is it yet, but preliminary look at it indicates that may be happening. LMK

1project2many

03-26-2013, 04:07 AM

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?

It's as simple as using the lookup chart you posted from the ALDL DS file.
40 hex is 64 decimal. Lookup 64 decimal on the chart and it crosses to 80 deg C.

From AFBW:
LD1B3 FCB 199 ; 20c COOL FOR EGR ENABLE (1K PU) TBL 3

From AKMJ:
LD1B3 FCB 139 ; c COOL FOR EGR ENABLE (1K PU) TBL 3 <-- 45C

From ANMW:
LD1B3 FCB 131 ; 48c COOL FOR EGR ENABLE (1k pu) TBL 3

The values all match up.

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. ?

That table is the conversion. It could also be written as :

A/D
HEX
DEGREES

COUNTS
COUNTS
Deg C

-------
------
-------

255
FF
-40

251
FB
-30

250
FA
-25

247
F7
-20

245
F5
-15

241
F1
-10

237
ED
-5

231
E7
0

225
E1
5

218
DA
10

209
D1
15

199
C7
20

189
BD
25

177
B1
30

165
A5
35

152
98
40

139
8B
45

126
7E
50

114
72
55

102
66
60

92
5C
65

81
51
70

72
48
75

64
40
80

56
38
85

50
32
90

44
2C
95

39
27
100

34
22
105

30
1E
110

26
1A
115

23
17
120

21
15
125

18
12
130

16
10
135

14
0E
140

13
0D
145

12
0C
150

0
00
200

The additional value above the maximum temp read by the CTS (152 deg) is "padding" to complete the lookup table. Without it, in case of an error caused by unexpected incorrect resistance (think Ebay $1.99 Power Mod!), the ecm could accidentally look up a value that's actually another variable.

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?
Neither end is wrong. The "extra" values just complete the table. And FWIW when I lived in MT I saw -40F and below regularly enough to know it shows as -43C on the scantool and it sets a CTS code since "it just can't be that cold out for that long!"

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...
Which is why my notes say to use Vac and TPS values to disable EGR. But setting that table to the same values as BPW and making sure EGR can't open means fueling won't change even if ecm is commanding EGR.

EagleMark

03-26-2013, 05:42 AM

It's as simple as using the lookup chart you posted from the ALDL DS file.
40 hex is 64 decimal. Lookup 64 decimal on the chart and it crosses to 80 deg C.
That explains a lot... except the numbers you used above were for Closed Loop Enable Temp.
LD299 FCB 64 ; xxC COOL, Min for CLS LP Enable
In the disassembly this is one that does not have "(1k pu) TBL 3" and the vehicle enters CL at 64C ? Not 80C as the lookup would suggest.

EagleMark

03-26-2013, 05:42 AM

Now more confusion in the conversion based of AD table.

The actual conversion from a GM paper is N = (E + 40) * 256 / 192.
Not sure what N and E are?
Newer masks use 0.75000 * X + -40.000 where 75 is 192 divided by the 256

So we are back to 192 and not what the AD table3 which has temps from -40 to 200 which is 240, not 192?

Ahhh! Now I re read your post it is just padding above 152C, this is why 192 is total, 152 + the -40 = 192 and not 240? Right?

1project2many

03-26-2013, 02:06 PM

the numbers you used above were for Closed Loop Enable Temp.
LD299 FCB 64 ; xxC COOL, Min for CLS LP Enable
Didn't catch that.

Not sure what N and E are?
The post says what N and E are. One is "Real world" number. Other is "engineering unit."

Now more confusion in the conversion based of AD table.The actual conversion from a GM paper is N = (E + 40) * 256 / 192.
For $42 the conversion is posted with the table. It's a lookup table and it's not linear which means this formula doesn't apply.

Newer masks use 0.75000 * X + -40.000 where 75 is 192 divided by the 256
Same thing. But as I warned, different ecm's handle CTS differently in hardware so hopping from mask to mask, ecm to ecm, maybe not such a good idea.

1project2many

03-28-2013, 06:18 PM

So I was curious to see how the pay for software handled this issue. Turns out it doesn't. The CTS values that use the lookup table are not available for modification. Well, so much for that.

Can TP load multiple files to edit as one calibration? Maybe we can use a lookup table and link the CTS values to that somehow. The lookup table can be saved as a separate "segment" of the calibration and it loads each time you load the .bin file...

EagleMark

03-28-2013, 08:35 PM

You can compare another bin file, use it to copy and paste, but nothing like your describing?

Can't build a lookup table because TP will only use space on bin...

Could add the AD Lookup table to Parameter comments of each parameter? Found another fool proof way is using a Patch, there's options to add XDF items in several forms, one is a Patch. I already built one for Spark Advance and BPW to be added to data stream in place of 02 cross counts and Prom ID, works sweet, no way to make a mistake (if built right) then just use it again to remove patch. This could be fool proof way to turn things on/off if we know exactly what temp/hex they turn on off.

Still does not help the actual Parameter from showing an accurate temperature, not sure it ever will? Maybe they should all be referred to look at comments to set as per AD lookup?

There is one other option that I have no idea what it's for or how to apply it, X Y function? If you right click in Parmeters you can add new XDF item and one is this x y function...

1project2many

03-28-2013, 11:34 PM

That X Y function is what I was looking at. That and maybe I could get creative with referencing values elsewhere in the calibration.

The only other thing I can think of is to display the value in decimal and make dang sure there's a note visible that says "use lookup table for correct value."

EagleMark

03-29-2013, 12:16 AM

The only other thing I can think of is to display the value in decimal and make dang sure there's a note visible that says "use lookup table for correct value."Since the lookup is not in the bin, this would be only option?

gregs78cam

03-29-2013, 11:28 AM

Well I just spent about 3 hours coming up with an equation, a function really, that comes pretty darn close to the lookup table you posted. First I plotted it in AutoCad, to see just what type of curve it looked like, then I started manipulating it on this page:

Function Grapher and Calculator (http://www.mathsisfun.com/data/function-grapher.php)

Try this:

(-.033x+5.1)^3-.00055x^2-.09x+65.

I will graph it on my TI-85 and trace it to see how close it really is, later when I am not so tired.

EagleMark

03-29-2013, 05:57 PM

Well I don't doubt your math skills, but TunerPRo does not like that at all! Once I use it, raw hex changes to 80 and calculated turns to 69c, doesn't matter what the hex was? Take it out and hex goes back to what it was, hex should never change because of a conversion, only the calculated view should.

So I added an X to (X-.033x+5.1)^3-.00055x^2-.09x+65 and it was exactly opposite correct on AD chart, before TunerPro freaked out again?

gregs78cam

03-29-2013, 06:16 PM

You say it's opposite, like if you inverted one column in the posted table? I'll have to work on it some more when I have time.

EagleMark

03-29-2013, 08:20 PM

Yes, I got it to work twice and looked at the AD table, compared to what hack said and it was inverted. Then TP went weird on me again? Don't know if it's my TP, or one of the math symbols? Your conversion keeps telling it to look up at prior post! ^ LOL!

AD count was 218 which should be 10c

But it spit out 159c which is about AD count 10

1project2many

03-30-2013, 08:50 AM

Greg, that's some pretty creative thinking. You can actually see the curve in TP in the .adx file. By choosing acquisition then edit definition then lookup tables and table graph. If the formula is entered into excel and plotted against the lookup table the center is close but at the ends it doesn't track as well. For a hex value of 12 the formula returns 167 and the actual temp should be 150. In fact all of the calculations are off by more than 10 degrees from 95 deg C to the top of the chart. I think the final value of 0 = 200 is throwing off the generated formula on that end. At the low end of temp 255 should equal -40 degrees and the formula returns -30. That's a fair amount of error. But, and this is a big "but," we're really close between the temps of -25 and +40 degrees so what you did put us on the right track.

Mark... Tunerpro doesn't appear to like exponential functions. It can handle the beginning of the formula ok, (-0.033 * X + 5.1) , but it chokes when I try to add ^ 3. So the solution seems easy, just make it happen manually. To replace ^3 you can do this: (-0.033 * X + 5.1)*(-0.033 * X + 5.1)*(-0.033 * X + 5.1). Same thing and it works just uses more characters to type. Looking at the rest of Greg's formula, it doesn't look like there's anything hard to duplicate like "^-.22" or "^1/2" so we can replace the next one, 0.00055*X^2, with (0.00055*X)*(0.00055*X). The rest of the math is fairly basic so the entire formula looks like this:

(-0.033 * X + 5.1)*(-0.033 * X + 5.1)*(-0.033 * X + 5.1)-(0.00055*X)*(0.00055*X)-0.09*X+65.00000

This seems to give the same values as Greg's original formula when I plotted it in Excel so at least we're on the right track.

Greg, the only request I have is can we maybe get a little closer? It might help to plot more data points and fill in some missing values in the table. I'd try but my student version of Matlab from 2002 timed out and I doubt I can get another at the same price. Here's the chart of actual temp vs calculated:

Dec. Temp Calculated Temp
255 -40 -30.14303088
251 -30 -24.48907949
250 -25 -23.130875
247 -20 -19.18549165
245 -15 -16.66077163
241 -10 -11.85685448
237 -5 -7.368801361
231 0 -1.198779667
225 5 4.338171875
218 10 10.05995342
209 15 16.36256143
199 20 22.15233544
189 25 26.87357165
177 30 31.43218098
165 35 35.13518638
152 40 38.6133927
139 45 41.9984557
126 50 45.76409689
114 55 49.98754647
102 60 55.3115149
92 65 60.85763814
81 70 68.39727848
72 75 75.88135942
64 80 83.66449427
56 85 92.62673901
50 90 100.188625
44 95 108.5224338
39 100 116.0905388
34 105 124.2539974
30 110 131.231531
26 115 138.6211405
23 120 144.4420738
21 125 148.4586571
18 130 154.6917862
16 135 158.9885572
14 140 163.4004221
13 145 165.6500537
12 150 167.9291057
0 200 197.651

gregs78cam

03-30-2013, 06:35 PM

Thanks 1P2M, I spent a couple more hours on it, but couldn't get it a lot closer, I got it a little closer, but I gave up. I didn't write down the closer one before I closed the page though. It's hard to get both ends and the middle close, It was almost one or the other, and that upper part of the curve from 80C on up a PITA. I will try again and write down the end product.

EDIT: I will get the center of the curve as accuate as I can and to worry too much about the extreme ends i.e. above 150C and below 0C.

OK, this one gets it within about 5C all the way from -30 to around 95C...I THINK! And it is the format TP 'should' recognize?

((-.055x+6.5)(-.026x+4.6)(-.024x+4.0))-((.049x+1)(.028x-2.3))+.04x+53

The upper half of the curve is just so steep it's very hard to get both ends correct.

I don't know if this page will come up with the graph and points in it already, but go here:

http://fooplot.com/#W3sidHlwZSI6MCwiZXEiOiIoKC0uMDU1eCs2LjUpKC0uMDI2e Cs0LjYpKC0uMDI0eCs0LjApKS0oKC4wNDl4KzEpKC4wMjh4LTI uMykpKy4wNHgrNTMiLCJjb2xvciI6IiMwMDAwMDAifSx7InR5c GUiOjMsImVxIjpbWyIgMjU1IiwiLTQwIl0sWyIyNTMiLCItMzU iXSxbIjI1MSIsIi0zMCJdLFsiMjUwIiwiLTI1Il0sWyIyNDciL CItMjAiXSxbIjI0NSIsIi0xNSJdLFsiMjQxIiwiLTEwIl0sWyI yMzciLCItNSJdLFsiMjMxIiwiMCJdLFsiMjI1IiwiNSJdLFsiM jE4IiwiMTAiXSxbIjIwOSIsIjE1Il0sWyIxOTkiLCIyMCJdLFs iMTg5IiwiMjUiXSxbIjE3NyIsIjMwIl0sWyIxNjUiLCIzNSJdL FsiMTUyIiwiNDAiXSxbIjEzOSIsIjQ1Il0sWyIxMjYiLCI1MCJ dLFsiMTE0IiwiNTUiXSxbIjEwMiIsIjYwIl0sWyI5MiIsIjY1I l0sWyI4MSIsIjcwIl0sWyI3MiIsIjc1Il0sWyI2NCIsIjgwIl0 sWyI1NiIsIjg1Il0sWyI1MCIsIjkwIl0sWyI0NCIsIjk1Il0sW yIzOSIsIjEwMCJdLFsiMzQiLCIxMDUiXSxbIjMwIiwiMTEwIl0 sWyIyNiIsIjExNSJdLFsiMjMiLCIxMjAiXSxbIjIxIiwiMTI1I l0sWyIxOCIsIjEzMCJdLFsiMTYiLCIzNTAiXSxbIjE0IiwiMTQ wIl0sWyIxMyIsIjE0NSJdLFsiMTIiLCIxNTAiXSxbIjAiLCIyM DAiXV0sImNvbG9yIjoiIzAwMDAwMCJ9LHsidHlwZSI6MTAwMCw id2luZG93IjpbIi0xMCIsIjI3MCIsIi01MCIsIjIxMCJdfV0

It is nowhere near close above 100C, but I think if you ever get above 120C coolant temp (250F), you will have bigger problems than the dash display wrong.

gregs78cam

03-31-2013, 01:47 AM

OK, this is it, I give up. This is +/-5 across the whole curve except 150C and up, with an average error of 2.72. I think the sensor itself has more accuracy issues than that.

(-.0315x+4.5)^3+(-.00045x^2)-.135x+73.

I don't know how to put it in TPv5 to make it work, that is up to you guys..?

http://fooplot.com/#W3sidHlwZSI6MCwiZXEiOiIoLS4wMzE1eCs0LjUpXjMrKC0uM DAwNDV4XjIpLS4xMzV4KzczLiIsImNvbG9yIjoiIzAwMDAwMCJ 9LHsidHlwZSI6MywiZXEiOltbIjI1NSIsIi00MCJdLFsiMjUzI iwiLTM1Il0sWyIyNTEiLCItMzAiXSxbIjI1MCIsIi0yNSJdLFs iMjQ3IiwiLTIwIl0sWyIyNDUiLCItMTUiXSxbIjI0MSIsIi0xM CJdLFsiMjM3IiwiLTUiXSxbIjIzMSIsIjAiXSxbIjIyNSIsIjU iXSxbIjIxOCIsIjEwIl0sWyIyMDkiLCIxNSJdLFsiMTk5IiwiM jAiXSxbIjE4OSIsIjI1Il0sWyIxNzciLCIzMCJdLFsiMTY1Iiw iMzUiXSxbIjE1MiIsIjQwIl0sWyIxMzkiLCI0NSJdLFsiMTI2I iwiNTAiXSxbIjExNCIsIjU1Il0sWyIxMDIiLCI2MCJdLFsiOTI iLCI2NSJdLFsiODEiLCI3MCJdLFsiNzIiLCI3NSJdLFsiNjQiL CI4MCJdLFsiNTYiLCI4NSJdLFsiNTAiLCI5MCJdLFsiNDQiLCI 5NSJdLFsiMzkiLCIxMDAiXSxbIjM0IiwiMTA1Il0sWyIzMCIsI jExMCJdLFsiMjYiLCIxMTUiXSxbIjIzIiwiMTIwIl0sWyIyMSI sIjEyNSJdLFsiMTgiLCIxMzAiXSxbIjE2IiwiMzUwIl0sWyIxN CIsIjE0MCJdLFsiMTMiLCIxNDUiXSxbIjEyIiwiMTUwIl0sWyI wIiwiMjAwIl1dLCJjb2xvciI6IiMwMDAwMDAifSx7InR5cGUiO jEwMDAsIndpbmRvdyI6WyItMTAiLCIyNzAiLCItNTAiLCIyMTA iXX1d

Moving on......

EagleMark

03-31-2013, 02:21 AM

Thanks for putting you excellent math skills to good work! :thumbsup:

gregs78cam

03-31-2013, 08:35 AM

I think excellent is a bit of a stretch, buy you're very welcome,...... if it works that is.

1project2many

04-01-2013, 01:40 PM

I had to fight with TP to make the formula work but I got it going. Then I remembered that I had the original installation CD for Matlab and re-installed that software and promptly realized I forgot how to use it. Then the Easter events started so that was that for the day.

I'll post the TP version of Greg's latest formula here tonight. It's closer than the original and it will probably work well enough for most. If it's not close enough the user will simply have to consult the lookup table. I probably won't get a chance to see if Matlab can generate anything closer for a while.

Again, thanks, Greg.

EagleMark

04-01-2013, 06:34 PM

I have to thank all you guys for this! :thumbsup:

Would be another advanced math class for me, while still learning the reading end of disassembly let alone the disassembly itself which has not worked out so far.

My time has been spent learning this forum software, my cgi, php and js courses of 12 years ago are really lacking in making changes needed for search functions.

Then some good weather made me go outside and get some sunshine, fix the lawn mower, cut the grass, wash my truck, do some work on my truck and if another day of good weather... polish my wheels because they started using salt on highways up here at 20f and below... my aluminum wheels have black spots! :yikes:

gregs78cam

04-01-2013, 06:45 PM

You know I was thinking about this issue the other day and realized that this is also why the E-Fan patch doesn't turn on/off the fan at the exact temp when viewed in the Dashboard. Because we see the temp converted by the simple (linear) equation, when the PCM is seeing the true temp generated from the non-linear look up table.

..... they started using salt on highways up here at 20f and below...

ERRRR! When did this start?

EagleMark

04-01-2013, 07:01 PM

..... they started using salt on highways up here at 20f and below...

ERRRR! When did this start?All this winter and half of last. State Highways only, no city streets.

1project2many

04-01-2013, 08:40 PM

Mark, everyone here plays a part in what gets done. You've done a helluva lot of organizing and cleaning up and imo that's worth a bunch. And you're not doing too badly with the code stuff so don't worry. I spent many years on it.

gregs78cam

04-02-2013, 04:26 AM

EagleMark

04-02-2013, 04:30 AM

Thanks guys! It's always been a great team here!

1project2many

04-04-2013, 02:01 PM

Just got back to this.

Here's a version for entry in TP:
(-.0315X + 4.5)(-.0315X + 4.5)(-.0315X + 4.5)+(X*X*-1*.00045)-.135*X+73.00000

You might have to type it in by hand. TP didn't like it when I copy / pasted it from another program.

FWIW (not to take anything away from Greg's work) I've found the *real* equation for resistance vs temperature. It's called the Steinhart - Hart equation and you can find plenty of information online starting with a Wikipedia entry sure to confuse anyone who doesn't think big equations are fun. Someone involved with Megasquirt worked out A, B, and C values (see online if curious) for the GM temperature sensors and with a slight correction it produces correct temperature values for a given sensor resistance value. I'm not sure it can be made to work in TP though. It uses logarithms which may not be supported by TP. The first step is to determine a relationship between A/D counts and resistance and modify the formula so I can produce correct results in Excel.

As an aside, this equation and the non-linear nature of the resistance vs temp chart is the reason why Megasquirt guys developed the small piece of software which can generate a lookup table for a temp sensor given three resistance values. They also chose to skip trying to force the ecm to do this somewhat tricky math and opted instead for simple lookup values. Very interesting.

Mark, you seem to have a way of finding the right question to start a long quest for answers. Keep it up.

1project2many

04-04-2013, 03:45 PM

Found interesting info related to the "two step" temperature measurement strategy mentioned earlier:
wps.prenhall.com/wps/media/objects/6568/6725731/ppts/Chapter14.ppt

Slide 9 shows a circuit using a 1K pullup resistor.

EagleMark

04-09-2013, 06:47 PM

Just got back to this.

Here's a version for entry in TP:
(-.0315X + 4.5)(-.0315X + 4.5)(-.0315X + 4.5)+(X*X*-1*.00045)-.135*X+73.00000

I gave this a shot today and choose this entry from disassembly.

LD2C8 FCB 218 ; 10c, Cool TEMP THRSH FOR COLD START
; (A/D 1K PU)

Verified hex at $DA and decimal 218 which is 10C on AD count chart. But temp in TunerPro was 35.59c ?

gregs78cam

04-09-2013, 07:11 PM

Nevermind, graph doesn't like it either.

The equation 1P2M came up with plots properly in the graph. Don't know what TP problem is.

(-.0315x + 4.5)(-.0315x + 4.5)(-.0315x + 4.5)+(x*x*-1*.00045)-.135x+73.00000

1project2many

04-09-2013, 08:29 PM

Who knows. I'll have to take a look and see what's going on. The PC was locked up the other night so I lost a bunch of work in the programs that were open.

EagleMark

04-09-2013, 09:05 PM

EagleMark

04-09-2013, 09:07 PM

EDIT: I will get the center of the curve as accuate as I can and to worry too much about the extreme ends i.e. above 150C and below 0C.

OK, this one gets it within about 5C all the way from -30 to around 95C...I THINK! And it is the format TP 'should' recognize?

((-.055x+6.5)(-.026x+4.6)(-.024x+4.0))-((.049x+1)(.028x-2.3))+.04x+53

Tried this one and got 56.36c ?

EagleMark

04-09-2013, 09:10 PM

1project2many

04-09-2013, 09:32 PM

So it's good now?

EagleMark

04-09-2013, 10:03 PM

No, I just tried Gregs and got a different number, but he said yours was correct. I didn't understand how I got a different number? But his was missing a *.

Still

Verified hex at $DA and decimal 218 which is 10C on AD count chart. But temp in TunerPro was 35.59c ?

1project2many

04-10-2013, 12:09 AM

Ok, then. See previous post. ;)

gregs78cam

04-10-2013, 01:48 AM

I think we are dealing with an 'order of operations', or something that TP doesn't like to handle. In the graph these all work out the same. If you follow this link and then click on the "trace" button on the graph you can click anywhere to see the (x,y).

(-.0315x+4.5)^3+(-.00045x^2)-.135x+73.

(-.0315x + 4.5)(-.0315x + 4.5)(-.0315x + 4.5)+(x*x*-1*.00045)-.135x+73.00000

(-.0315x+4.5)^3+(-.00045(x*x))-.135x+73.

http://fooplot.com/#W3sidHlwZSI6MCwiZXEiOiIoLS4wMzE1eCs0LjUpXjMrKC0uM DAwNDV4XjIpLS4xMzV4KzczLiIsImNvbG9yIjoiIzAwMDAwMCJ 9LHsidHlwZSI6MywiZXEiOltbIjI1NSIsIi00MCJdLFsiMjUzI iwiLTM1Il0sWyIyNTEiLCItMzAiXSxbIjI1MCIsIi0yNSJdLFs iMjQ3IiwiLTIwIl0sWyIyNDUiLCItMTUiXSxbIjI0MSIsIi0xM CJdLFsiMjM3IiwiLTUiXSxbIjIzMSIsIjAiXSxbIjIyNSIsIjU iXSxbIjIxOCIsIjEwIl0sWyIyMDkiLCIxNSJdLFsiMTk5IiwiM jAiXSxbIjE4OSIsIjI1Il0sWyIxNzciLCIzMCJdLFsiMTY1Iiw iMzUiXSxbIjE1MiIsIjQwIl0sWyIxMzkiLCI0NSJdLFsiMTI2I iwiNTAiXSxbIjExNCIsIjU1Il0sWyIxMDIiLCI2MCJdLFsiOTI iLCI2NSJdLFsiODEiLCI3MCJdLFsiNzIiLCI3NSJdLFsiNjQiL CI4MCJdLFsiNTYiLCI4NSJdLFsiNTAiLCI5MCJdLFsiNDQiLCI 5NSJdLFsiMzkiLCIxMDAiXSxbIjM0IiwiMTA1Il0sWyIzMCIsI jExMCJdLFsiMjYiLCIxMTUiXSxbIjIzIiwiMTIwIl0sWyIyMSI sIjEyNSJdLFsiMTgiLCIxMzAiXSxbIjE2IiwiMzUwIl0sWyIxN CIsIjE0MCJdLFsiMTMiLCIxNDUiXSxbIjEyIiwiMTUwIl0sWyI wIiwiMjAwIl1dLCJjb2xvciI6IiMwMDAwMDAifSx7InR5cGUiO jAsImVxIjoiKC0uMDMxNXgrNC41KV4zKygtLjAwMDQ1KHgqeCk pLS4xMzV4KzczLiIsImNvbG9yIjoiIzAwMDAwMCJ9LHsidHlwZ SI6MTAwMCwid2luZG93IjpbIi0xMCIsIjI3MCIsIi01MCIsIjI xMCJdfV0-

Mangus

04-11-2013, 07:45 AM

There are no implicit operators in TunerPro like there is in hand-written algebra. You're missing a few * operators. For instance, this:
(-.0315x + 4.5)(-.0315x + 4.5)(-.0315x + 4.5)+(x*x*-1*.00045)-.135x+73.00000

Needs to be

(-.0315 * x + 4.5) * (-.0315 * x + 4.5) * (-.0315 * x + 4.5)+(x*x*-1*.00045)-.135 * x+73.00000

EagleMark

04-11-2013, 10:28 AM

Mangus

04-12-2013, 03:11 AM

Thanks Mark.

I put the new conversion in the footplot link and it too worked.

But when inserted to TunerPRo Parameter Conversion it changed calculated to 0.00 and hex to 80h. Restart TunerPRo and hex was 66, change to calculated and went back to 0.00, change to hex and again it was 80h. Before it was off, not it just freaks out?...

Most likely a result of this being a multi-root equation. I haven't plotted it to see what it looks like, though. TunerPro converts from the calculated value back to the raw value stored in the bin by doing a binary search. If there are multiple points in the graph where that binary search results in a correct answer, it may land on a different one each time. It could also be an error in the equation still. Is that last ")-.135*x+73" correct? Should there be another * there, or do you mean to subtract 0.135 * X from the result of the previous results? Order of operations in TunerPro are respected. (Edit: just looked at the graph, and it should work. I'll have to take a closer look, but also, don't forget about the number of decimal places. This is a cubed function from a low-resolution binary input - you might try increasing to 3 or 4 decimal places in TunerPro.)

EagleMark

04-12-2013, 04:41 AM

Here's a link (http://fooplot.com/#W3sidHlwZSI6MCwiZXEiOiIoLS4wMzE1eCs0LjUpXjMrKC0uM DAwNDV4XjIpLS4xMzV4KzczLiIsImNvbG9yIjoiIzAwMDAwMCJ 9LHsidHlwZSI6MywiZXEiOltbIjI1NSIsIi00MCJdLFsiMjUzI iwiLTM1Il0sWyIyNTEiLCItMzAiXSxbIjI1MCIsIi0yNSJdLFs iMjQ3IiwiLTIwIl0sWyIyNDUiLCItMTUiXSxbIjI0MSIsIi0xM CJdLFsiMjM3IiwiLTUiXSxbIjIzMSIsIjAiXSxbIjIyNSIsIjU iXSxbIjIxOCIsIjEwIl0sWyIyMDkiLCIxNSJdLFsiMTk5IiwiM jAiXSxbIjE4OSIsIjI1Il0sWyIxNzciLCIzMCJdLFsiMTY1Iiw iMzUiXSxbIjE1MiIsIjQwIl0sWyIxMzkiLCI0NSJdLFsiMTI2I iwiNTAiXSxbIjExNCIsIjU1Il0sWyIxMDIiLCI2MCJdLFsiOTI iLCI2NSJdLFsiODEiLCI3MCJdLFsiNzIiLCI3NSJdLFsiNjQiL CI4MCJdLFsiNTYiLCI4NSJdLFsiNTAiLCI5MCJdLFsiNDQiLCI 5NSJdLFsiMzkiLCIxMDAiXSxbIjM0IiwiMTA1Il0sWyIzMCIsI jExMCJdLFsiMjYiLCIxMTUiXSxbIjIzIiwiMTIwIl0sWyIyMSI sIjEyNSJdLFsiMTgiLCIxMzAiXSxbIjE2IiwiMzUwIl0sWyIxN CIsIjE0MCJdLFsiMTMiLCIxNDUiXSxbIjEyIiwiMTUwIl0sWyI wIiwiMjAwIl1dLCJjb2xvciI6IiMwMDAwMDAifSx7InR5cGUiO jAsImVxIjoiKC0uMDMxNXgrNC41KV4zKygtLjAwMDQ1KHgqeCk pLS4xMzV4KzczLiIsImNvbG9yIjoiIzAwMDAwMCJ9LHsidHlwZ SI6MTAwMCwid2luZG93IjpbIi0xMCIsIjI3MCIsIi01MCIsIjI xMCJdfV0-) from above for the plot, it's a common AD count to celcius from many dissasemblies.

Tried increasing the decimal places in TP but same results, temp in calculated is 0.0000c and right click to show hex changes hex to 80h from 66h

Greg or Shannen will be around shortly to check the math you corrected for TP.

RobertISaar

04-12-2013, 04:45 AM

all of this work, just because GM chose to compare against an A/D count instead of a linearized variable....

1project2many

04-12-2013, 05:20 AM

TunerPro converts from the calculated value back to the raw value stored in the bin by doing a binary search. If there are multiple points in the graph where that binary search results in a correct answer, it may land on a different one each time.
Could you explain this? Does this refer to the mechanics of committing a value calculated in the "Edit parameter" window to the .bin?

all of this work, just because GM chose to compare against an A/D count instead of a linearized variable....
True, but... All this work is really about trying to make a linear equation for an "Aggressively non-linear" sensor. The actual equation to calculate temp from resistance uses the natural log e raised to a third order polynomial. I honestly don't even know how to code that for an HC11. I can see where a lookup table is an acceptable solution.

Tried increasing the decimal places in TP but same results, temp in calculated is 0.0000c and right click to show hex changes hex to 80h from 66h
I didn't check this thread before I worked out the formula. I noticed a couple of things that TP didn't like. Using a negative coefficient such as -.0315 caused problems. Breaking -1 out as a separate value caused TP to interpret coefficients less than one as zero. So .0315X became 0. TP didn't even recognize X as a variable in the "Variables" window. And as previously mentioned, the implied operators needed to be made explicit, .0315X needed to be .0315 * X. FWIW I did that with Greg's first formula but for some reason it seemed like it wasn't needed the second time. Silly me...

Anyway, this one's working on my pc. Lowest displayed temp should be -34.77 and highest should be 164.13 $DA = 8.92 deg C.

(-1*.0315*X + 4.5)*(-1*.0315*X + 4.5)*(-1*.0315*X + 4.5)+(X*X*-1*.00045)-(X*.135)+73.00000

If TP works with logarithms I might be able to get the actual Steinhart-Hart equation into play.

chevmasta

04-12-2013, 05:42 AM

I have zero idea what you guys are talking about.....

but this is why I love this forum. Keep it up! I'm sure I'll benefit in the end! :thumbsup:

EagleMark

04-12-2013, 05:54 AM

I dunno what happened. The version I posted was copied directly from TP after confirmed working but this time I couldn't make that one work. This one's working now, $DA = 8.92 deg C.

(-1*.0315*X + 4.5)*(-1*.0315*X + 4.5)*(-1*.0315*X + 4.5)+(X*X*-1*.00045)-(X*.135)+73.00000

Lowest displayed temp should be -34.77 and highest should be 164.13 We have a winner! Sort of... $DA is correct! Minimum and maximum are correct. But the scale is backwards, low is high and high is low...

1project2many

04-12-2013, 07:40 AM

That's correct. High temp = low resistance = low counts. Check the lookup table in the disassembly and see what's been staring at us all along. ;)

EagleMark

04-12-2013, 08:38 AM

I just haven't had time to look... so it's accurate? Just the slider in TunerPro is backwards?

gregs78cam

04-12-2013, 09:48 AM

That's correct. High temp = low resistance = low counts. Check the lookup table in the disassembly and see what's been staring at us all along. ;)

You lost me, what exactly are we looking at?

1project2many

04-12-2013, 02:44 PM

Apparently the slider action is backward. Moving it left usually generates a minimum value but for the inverse coolant temp it's backward. But I never looked at the slider. lol... I don't use TP much and I was focused on the equation. Apparently the slider is tied to the hex value rather than the converted value? Unsure if that can be fixed. Uhmmmm.... time for input from the author.

And what this also means is that setting the value to "max" hex actually enabled EGR at the minimum possible temp! 'Splains why I had a vague recollection of having to set this to zero. Too bad I couldn't find anything in my notes to back it up waaay back whe4n this all started.

EagleMark

04-12-2013, 06:56 PM

Apparently the slider is tied to the hex value rather than the converted value?
Yes everything is the hex, converted to the value.

What this also means is every temp based on AD lookup in every mask is wrong! Just checked, the slider works right but temp is Max when at Min and Min when at Max!!!

RobertISaar

04-12-2013, 07:04 PM

What this also means is every temp based on AD lookup in every mask is wrong!

luckily, it doesn't happen that often.

unluckily, when it does happen, it's usually on the C3s, meaning you can't just change the algorithm in the PROM and have it use the linearized variables.

gregs78cam

04-12-2013, 07:04 PM

So, you are saying that the .xdf parameters are wrong in the way they are converting the hex value? Then this is a separate issue from the .adx displaying an inaccurate temp, right?

EagleMark

04-12-2013, 07:15 PM

EagleMark

04-12-2013, 07:29 PM

With this new found, or res-erected and explained info is making sure that temps in dissasembly are marked correctly. If it is 1k pu is it? If it's not marked? Should it be?

EagleMark

04-13-2013, 01:51 AM

What this also means is every temp based on AD lookup in every mask is wrong! Just checked, the slider works right but temp is Max when at Min and Min when at Max!!!I just realized something! This is the reason I had issues with turning off EGR by enable temp and what started this thread! :mad1:

jim_in_dorris

04-13-2013, 03:44 AM

gregs78cam

04-13-2013, 07:34 AM

ADX temps are accurate.

All XDF Parameters that use the AD count for temp are wrong until this conversion is installed. They are backwards!

Looks like all temps in dissasembly comments are also way off?

Although this conversion developed here makes the slider in TunerPro operate backwards, the numbers/temps are accurate. Within a few degrees for all the one's I've checked!

Just so I have this right, the ADX is fine, but the xdf parameters are backwards because the value that we are changing is the hex value in AD counts which is the inverse of the actual temp. Right?

EagleMark

04-13-2013, 07:03 PM

Just so I have this right, the ADX is fine, but the xdf parameters are backwards because the value that we are changing is the hex value in AD counts which is the inverse of the actual temp. Right?Yes! On ones that are through 1k pup.... but the more I look I think some are also 1k pup and not commented that way. This is all for $42, not sure what the implications are for $0D?

EagleMark

04-13-2013, 07:09 PM

Okay Mark, I guess this means that I can change the comments in the ASDU and ASDX asm files to correct them. I need to look at every place that temp is used and see if it is converted or raw A/D value and make the comment reflect correctly. I am still not convinced that it will solve your EGR problem, but since you apparently have a handle on it now, give it a try. If it still dies, look at fueling. I think you may find the fuel gets cut. Let me know.I'll be testing it on EGR soon. But it's obvious it was being adjusted the wrong way.

I spent a lot of time yesterday with XDF and hack, more questions then answers right now and so many temps have so many different conversions? Commented temps in hack are all over the place. I think most important for accurate temps would be PE enable, DFCO Enable, Hiway LC Enable, Closed Loop Enable. We have EGR enable now that was clearly marked 1k, so maybe that will help track down how other temps are handled? SOme temps should probably never be needed or touched.

EagleMark

04-13-2013, 07:22 PM

Which brings up? If not through AD then what is correct conversion?

RobertISaar

04-13-2013, 09:17 PM

with 0D, you won't necessarily have any problems, since you can change the value it's compared against in a patch, that's assuming any is compared against raw A/D counts.

jim_in_dorris

04-13-2013, 10:47 PM

I'll be testing it on EGR soon. But it's obvious it was being adjusted the wrong way.

I spent a lot of time yesterday with XDF and hack, more questions then answers right now and so many temps have so many different conversions? Commented temps in hack are all over the place. I think most important for accurate temps would be PE enable, DFCO Enable, Hiway LC Enable, Closed Loop Enable. We have EGR enable now that was clearly marked 1k, so maybe that will help track down how other temps are handled? SOme temps should probably never be needed or touched.

Then those are the areas that I will concentrate on correcting. If I have questions, I will post them. I assume that you would like the formula that was developed on here used for the conversions. Should I also put that formula in the comments?

EagleMark

04-13-2013, 11:29 PM

That's the big question Jim? Which ones use it as AD count 1k and what does not? The ones I mentioned are most important and with the EGR now found as commented 1k and correct maybe it will give you an idea what to look for. I'm just perplexed at why so many different conversions? Something is wrong?

I'll attach the ADSU3.asm marked as -V1. I made a couple changes marked after the comment with ***. Those have correct temps to this conversion, which is almost spot on in areas needed, worst I found was 3 degrees off. Bottom of scale and top of scale a little more so but does not matter, if you get to top or bottom you are forcing on or off. I'm not complaining, the work was incredible for something said that could not be done. Just giving you my results of conversion test, to hex and decimal shown in assembly. Since these will all work together I think what is shown in TP with this conversion is what should be shown in assembly? Or we would need to make a new 156 count to celcius chart for complete accuracy which I think is overkill at this point?

Then there's some marked *Question* or ***Question*. It is not all conclusive, just a few done, as I said I started having more questions then answers. If you can figure out what is AD 1k and what isn't and what is what, I'll test them?

Someday I'd like to get back to learning dissasembly, but what I'm learning now will go forward. It's great you guys are part of the team, I'm trying to do the other end, I'd never have got this far without you guys! With my computer issues (my best laptop dead, my spare mailed out to tune job, a rebuilder in mail, using a 12 year old XP desktop), learning the scripts of the site for search and other mods, I've just put off dissasembly and following the algortym till later so I can still have time to do what I like, tune cars and dial these files in!

jim_in_dorris

04-13-2013, 11:36 PM

Sorry to hear about all the computer problems, I would probably go nuts. I DL'd the v1 file, will start looking at it this weekend after I tape this weeks lectures for class and put in time in the online class I am taking. A couple of hours of work, then I get time to play. I would really like to get tuning my truck, but I think that as worn out as it is, nothing much will help. If I figure out it's occasional hicup, I will be happy until I finally get a new motor for it. (not much budget right now). Gotta go split this weeks wood first, the wife doesn't like it when we run out of wood LOL.

EagleMark

04-14-2013, 12:02 AM

the wife doesn't like it when we run out of wood LOL. :laugh:

You know I'd help find the hicup... but I'm guessing the ol gal is drunk from the ethanol? Didn't have that when these were built... :nono: Start a thread if you want.

Computers are not that big an issue, just bad timing and of course when I'm broke... I got a clean low hour Panasonic CF-74 for vehicles, would probably have saved my nice HP 17 inch desktop replacement laptop as it's been worked hard for 3+ years now. Has hit dashboard and ended on floor 3 times when I hit the brakes. I think the hard drive is just been overheated so many times from sitting on the seat, fan on bottom... The CF-74 needs no vents from bottom... semi rugged and a bonus still has a serial port. Plus it was cheap... $157... 2Mhz system up to 4GB ram. Dam SSD hard drive was almost as much...

jim_in_dorris

04-14-2013, 02:24 AM

I think it probably is a valve issue, but I need to log it to see. I can't find my inverter for my laptop right now, so no logging.

EagleMark

04-14-2013, 05:04 AM

Mechanical vacuum gauge is pretty good for seeing that if it's intake, gauge will shake.

jim_in_dorris

04-14-2013, 07:20 AM

Yeah, I just have to dig it out and plug it in. I think I loaned it to my son so he could use it at work. I have a "stumble" in drive when I stop at a light, it usually does it once hard, then it isn't as noticable after that. I will start a new post as soon as I can start to work on it.

1project2many

04-14-2013, 07:49 PM

Mark, for $42 I believe there are only two different conversions used for CTS. One uses the "standard" GM equation and the other uses the lookup table. The lookup table is contained in ROM space outside the eprom addresses so any variables which reference this space are table based values. L0025 and L00E3 are lookup based so anything comparing a temp to these variables will use the table conversion. Here's an example from ASDZ:

DB11: LDAA L00E3 ; COOL TEMP
DB13: CMPA LD2A7 ; -40c OPN LP DECEL THRESH
DB16: BHI LDB34 ;

Here's another:

DB93: LDB93 LDAB L00E3 ; START UP COOL
DB95: CMPB LD2C8 ; TEMP THRSH FOR COLD START
; 10 C, (50f) (A/D 1K PU)
DB98: BHI LDB9E ;

Start by searching for all the L00E3 references.

Now, no values in the disassembly should be based on the formula we're using here. The formula is a way to make a close guess as to the lookup table values for the tuning software. The lookup table produces the correct value, not the formula. The better answer is to include a note in TP saying the number given is a an estimate but the lookup table can be used if better accuracy is desired. Every degree C difference is 1.8 deg difference F so it might be important to be able to compute the right values. Also, by not changing the disassembly we can modify the XDF (and other software) if we happen to get the "correct" formula figured out without the need to redo all the disassemblies.

jim_in_dorris

04-14-2013, 08:31 PM

1P2M,
I wasn't going to change the disassembly, only comments. The idea is to clarify which way the code is getting the temp to make looking at the hack make sense. I have figured out the places where the table lookups are. I just want to make sure that the comments are accurate. I have found several that were incorrect, and when I modified the $42-Hac to make working ASDU and ASDX assemblys, I might have made some comments incorrect. I understand that the purpose of the equation that was derived here was to make calculations in the XDF match the data from the data stream, I want to make the comments better so that people creating the XDF files know what to expect.

EagleMark

04-14-2013, 10:03 PM

Mark, for $42 I believe there are only two different conversions used for CTS. One uses the "standard" GM equation and the other uses the lookup table. Well we have one now for the lookup. What is conversion for the other or how to figure it out? My last test showed decimal equivalent to hex of 64d ended up being 64C, that may have been just luck...

2 is good! I've found at least 7 different conversions in the XDF. None of them were the lookup. Looks like someone did some testing to find when it was switched from enabled to disabled temp in C and made one up to get close, problem is some are not close, then comment says enable at this temp, so you adjust to disable and all you did was turn it on sooner!

I understand the dissasembly should not be changed but comments are humans interpretations and need correction. That said most of this stuff is very accurate, these temps are horrible and after all this work I can see why. The accuracy can be noted in XDF, it would help understand when entering Closed Loop is not spot on as what you adjusted to... but dam if you get the wrong conversion and one is inverse like we have been dealing with here, your turning things on instead of off! Or later instead of sooner?

EagleMark

06-02-2013, 10:20 PM

Back to EGR!

Looks like what we accomplished here is spot on! :thumbsup:

Further testing is in order which brings up my need for knowledge. Now I know if I ask you guys would just tell me... but I'm at a point in assembly I'd like a lesson instead. It's EGR related so I kept it here.

How to trace bits or data on and off? So we have EGR fueling and spark compensation, there has to be a way to tell when it is on and off? Can this bit be added to data stream in place of something?

I see where some of this may be happening?

;---------------------------------------------
LDCE1 STAA L00A3 ; BLM, BIN
STAB L00A2 ; BLM
;
LDAA >$D2B4 ; BPW const for EGR off,
LDAB >$D2B6 ; EGR on filter coef
;
TST $0006 ;
BPL LDD07 ; BR IF EGR OFF
LDAA L00BE ; AIR FLOW, (gms/sec)
LDAB #197 ;
MUL ;
ASLD ;
CMPA #80 ; AIR FLOW LMT
BLS LDCFC ;
LDAA #80 ; LIMIT AIR FLOW
;---------------------------------------------
; Lk Up EGR COMP TABLE FOR AIR FLOW IN Gms/sec
;
; TBL IS GMS/SEC vs PCT EGR
; BL = N * 1461.5
;---------------------------------------------
LDCFC LDAB L007F ; AIR FLOW FOR EGR
LDX #$D324 ; EGR COMP TABLE FOR AIR FLOW IN
JSR $FB67 ; 3D LOOK UP ?
;---------------------------------------------
LDAB >$D2B5 ; EGR off filter coef
LDD07 LDX L00A7 ; EGR CORRECTION
JSR $FB12 ; LAG FILTER ROUTINE
;---------------------------------------------
STD L00A7 ; EGR CORRECTION
;
ASLB ;
ADCA #0 ;
PSHA ;
;---------------------------------------------

Useing EGR for an example. How to find where data could be? In this case just EGR on or off, but overall how to find data that could be used? Somewhere 1project2many had an address for VE, I did not have time to follow up but this is another example of data that could be very benifitial if it were in data stream.

RobertISaar

06-02-2013, 10:37 PM

in this instance, look at TST $0006 ;

what's happening here is that byte 0006(in RAM) is being checked for a couple of different statuses. in this case, BPL(branch if plus) comes up immediately afterwards. BPL causes a branch if the byte being tested against had caused the N bit in the status register to be clear. for the N bit to be set, 0006 would have had to have it's bit 7 be set.

so, it breaks down to:

check byte 6 for it's bit 7 status
if bit 7 was clear(meaning EGR is off), branch

now, TST followed by BPL would normally only be used for signed values(not bitmasks), but it worked here since bit 7 was being tested against. with a signed value, bit 7 determines if dealing with a positive or negative number.