Solved-Knock Retard Reported When No Knock Count
12-28-2012, 11:53 AM
#1
Senior Member
Thread Starter
Solved-Knock Retard Reported When No Knock Count
CORRECTION TO CODE ADDRESS FOR KNOCK COUNT REPORTING IN DATA STREAM
Please see changes in red in last paragraph that corrects the above address.
Well shaazaaaaam… After hours of code review, flowcharting and code simulation, I think the mystery of why Knock Retard (KR) is reported in AUJP $8d when there are no reported Knock Counts (KC) may have been solved. Likely the following will apply to other masks as well. If you have a different view, please respond.
First some background. May get a bit code geeky, but necessary for understanding the logic. Also a long post but also necessary.
To begin, the KC logic is NOT “what you see is what you get”. (RBob alluded to this years ago and again recently in other posts. Thanks RBob!). Here’s what that means. There is a difference between ACTUAL KCs detected by the sensor and those REPORTED by ALDL monitoring software (TunerCat TunerPro, etc.). The reported KC value is equivalent to 1 KC after the sensor has actually sensed 255 KCs, 2 KCs are reported after 510 KCs are actually sensed, etc. What’s happening under the covers is that there is a separate place that actual, sensed KCs are accumulated before being reported. From an Assembly language perspective, the reported KCs are stored in 0x00C1 (this could be called ‘Slow KCs’) and the actual (sensed) KCs are accumulated in 0x00C2 (call this the ‘Fast’ KCs). In the code, 0x00C1 is a 2 byte word where C1 is the MSB and C2 is the LSB. Neither byte can be more than $FF (255d), so when C2 reaches $FF, it rolls over to 0, continues to count actual KCs and increments C1 by 1. Research indicates this is apparently how most OBD I devices handle KCs. Possibly GM felt that a couple of hundred or so actual knocks was not a big deal and they would not be reported, but then a steady accumulation of them was significant and would be.
With that background, here’s what occurs that causes KR to be reported without seeing any KCs being reported. Looking at JP’s AUJP hack, the key is the ‘mul’ (multiply) instruction found in the area of code labeled with the comment “LOOK UP KNOCK ATTACK RATE vs RPM”. The ‘mul’ instruction is commented as follows (see line 8 of Code Segment 2):
mul ; KNOCK CNT * ATTACK RATE = "D"
On the surface, one would take the comment at face value and assume that “KNOCK CNT” refers to the reported KCs (C1); and if zero, the result of the multiply would be zero, and thus all the logic that follows the multiply would cause KR to be stored and reported as zero.
Ah, but remember C2, the actual sensed KCs (‘Fast’ KC). That is the value used in the multiply instruction. This can be verified by tracing backward in the hack to where KCs are detected and the LSB of L3FCA (L3FCA = Knock Sensor Input to the ECM code, see first line of Code Segment 1) is pushed to the stack (see 4th line from the bottom of Code Segment 2 = pshb). There is no other code after that pshb that affects the stack. Thus, when the following instruction is executed, (line 6 of Code Segment 2):
pulb ; GET KNOCK CNT FM STX
it is the LSB (C2 = Fast KC) that is pulled from the stack for use (and NOT C1, the reported KC value). So there could be a couple of hundred KCs actually sensed and residing in C2, but C1 would not have reported anything because 255 KCs had not yet been accumulated in C2. Now with KCs in C2 being > 0, the code that follows may (note “may”) cause a value > 0 to be stored via the ‘staa’ instruction to L00C4=Knock Retard Degrees at the last line of Code Segment 1.
And that is how I believe it works. After KR is encountered, it’s decayed to zero in the LSEG_A loop of the code.
Given this, one could change C1 to C2 at Calibration address [original=incorrect=0x8992] [correct=0x8922] which will cause the actually sensed knock counts to be reported instead of the C1 counts (thanks again RBob). Location [original=incorrect=0x8992] [correct=0x8922] is where KC is reproted in the ALDL data stream. With this change, actual KCs can be compared to when KR occurs. Granted, there might be a lot of activity reported with C2, but at least it will be “what you see is what actually happened” and not what GM wanted us to see.
Code Segment 1 (In the bin, this code precedes Code Segment 2 below)
Code Segment 2
Please see changes in red in last paragraph that corrects the above address.
Well shaazaaaaam… After hours of code review, flowcharting and code simulation, I think the mystery of why Knock Retard (KR) is reported in AUJP $8d when there are no reported Knock Counts (KC) may have been solved. Likely the following will apply to other masks as well. If you have a different view, please respond.
First some background. May get a bit code geeky, but necessary for understanding the logic. Also a long post but also necessary.
To begin, the KC logic is NOT “what you see is what you get”. (RBob alluded to this years ago and again recently in other posts. Thanks RBob!). Here’s what that means. There is a difference between ACTUAL KCs detected by the sensor and those REPORTED by ALDL monitoring software (TunerCat TunerPro, etc.). The reported KC value is equivalent to 1 KC after the sensor has actually sensed 255 KCs, 2 KCs are reported after 510 KCs are actually sensed, etc. What’s happening under the covers is that there is a separate place that actual, sensed KCs are accumulated before being reported. From an Assembly language perspective, the reported KCs are stored in 0x00C1 (this could be called ‘Slow KCs’) and the actual (sensed) KCs are accumulated in 0x00C2 (call this the ‘Fast’ KCs). In the code, 0x00C1 is a 2 byte word where C1 is the MSB and C2 is the LSB. Neither byte can be more than $FF (255d), so when C2 reaches $FF, it rolls over to 0, continues to count actual KCs and increments C1 by 1. Research indicates this is apparently how most OBD I devices handle KCs. Possibly GM felt that a couple of hundred or so actual knocks was not a big deal and they would not be reported, but then a steady accumulation of them was significant and would be.
With that background, here’s what occurs that causes KR to be reported without seeing any KCs being reported. Looking at JP’s AUJP hack, the key is the ‘mul’ (multiply) instruction found in the area of code labeled with the comment “LOOK UP KNOCK ATTACK RATE vs RPM”. The ‘mul’ instruction is commented as follows (see line 8 of Code Segment 2):
mul ; KNOCK CNT * ATTACK RATE = "D"
On the surface, one would take the comment at face value and assume that “KNOCK CNT” refers to the reported KCs (C1); and if zero, the result of the multiply would be zero, and thus all the logic that follows the multiply would cause KR to be stored and reported as zero.
Ah, but remember C2, the actual sensed KCs (‘Fast’ KC). That is the value used in the multiply instruction. This can be verified by tracing backward in the hack to where KCs are detected and the LSB of L3FCA (L3FCA = Knock Sensor Input to the ECM code, see first line of Code Segment 1) is pushed to the stack (see 4th line from the bottom of Code Segment 2 = pshb). There is no other code after that pshb that affects the stack. Thus, when the following instruction is executed, (line 6 of Code Segment 2):
pulb ; GET KNOCK CNT FM STX
it is the LSB (C2 = Fast KC) that is pulled from the stack for use (and NOT C1, the reported KC value). So there could be a couple of hundred KCs actually sensed and residing in C2, but C1 would not have reported anything because 255 KCs had not yet been accumulated in C2. Now with KCs in C2 being > 0, the code that follows may (note “may”) cause a value > 0 to be stored via the ‘staa’ instruction to L00C4=Knock Retard Degrees at the last line of Code Segment 1.
And that is how I believe it works. After KR is encountered, it’s decayed to zero in the LSEG_A loop of the code.
Given this, one could change C1 to C2 at Calibration address [original=incorrect=0x8992] [correct=0x8922] which will cause the actually sensed knock counts to be reported instead of the C1 counts (thanks again RBob). Location [original=incorrect=0x8992] [correct=0x8922] is where KC is reproted in the ALDL data stream. With this change, actual KCs can be compared to when KR occurs. Granted, there might be a lot of activity reported with C2, but at least it will be “what you see is what actually happened” and not what GM wanted us to see.
Code Segment 1 (In the bin, this code precedes Code Segment 2 below)
Code:
; KNOCK MINOR LOOP LBB59: ldd L3FCA ; READ KNOCK SENSOR INPUT ; CRef: 0xBB53 pshb ; SAVE TO STX [Tom-This is Knock Count LSB] psha ; [Tom-This is Knock Count MSB] subd *L00C1 ; CALC CURRENT KNOCK CNT = (PA3 CNT'R LAST MNR LP) tsta ; Subtract 0x00 from A, set condition codes beq LBB65 ; BR IF EQUAL TO [Tom-Branch if Z=1 meaning ;...else, ldab #0xFF ; Val = 255, Max Value LBB65: pulx ; CRef: 0xBB61 pshb ; SAVE CURRENT KNOCK COUNT TO STX ; [Tom-This is LSB of Knock Sensor Input] stx *L00C1 ; CPU PA3 CNT'R LAST MNR LP clra brset *L0003,#0x80,LBB8A ; BR IF b7, KNOCK DISABLED, FUEL/AIR MODE WORD 1
Code:
;-------------------------------------------------- ; LOOK UP KNOCK ATTACK RATE vs RPM ; ; TBL = ATTACK RATE IN Deg/MSEC/0.0225, ; 400 - 4800 RPM ;------------------------------------------------- ldaa *L0057 ; GET Scaled RPM/25 lsra ; DIV BY 4 FOR LK UP, (DIVIDE BY 2 twice) lsra ; ldx #L820E ; KNOCK ATTACK RATE vs RPM TABLE Location jsr LE3D8 ; 2D LOOK UP, NO OFF SET (Is LE3D0 in ANHT) pulb ; GET KNOCK CNT FM STX pshb mul ; KNOCK CNT * ATTACK RATE = "D" lsld ; MULT * 2 adda *L00C4 ; SUM in L00C4 bcc LBBC0 ; Branch IF NO OVER FLOW, ; ... else ldaa #0xFF ; Val = 255, MAX LBBC0: psha ; CRef: 0xBB9D,0xBBA6,0xBBA8,0xBBBC brclr *L0046,#0x20,LBBD2 ; BR IF NOT b5, POWER ENRICHMENT ; ... else ;------------------------------------------------- ; LK UP MAX KNOCK RETARD WHILE IN PWR ENRICH .. ; vs RPM [Tom-2D Table varies from 13.54 - 16.52 Deg .vs. RPM] ;------------------------------------------------- ldx #L8218 ; MAX KNOCK RETARD WHILE IN PWR ENRICH vs RPM TABLE ldaa *L0058 ; RPM/25 (un-filt) ??? lsra ; DIVIDE BY 2, RPM/2 ldab #0x10 ; Val = 16, Offset for Look Up jsr LE3D4 ; 2D LOOK UP (Is LE3CC in ANHT) bra LBBDB ; BRANCH ALWAYS ;-------------------------------------------------- ; LK UP MAX KNOCK RETARD WHILE not IN PWR ENRICH .. ; vs MAP ;-------------------------------------------------- LBBD2: ldx #L8220 ; MAX KNOCK RETARD while NOT in PWR ENRICH vs MAP TABLE ; CRef: 0xBBC1 ldaa *L0071 ; NORMALIZED LOAD MAP VALUE lsra ; DIVIDE BY 2 jsr LE3D8 ; 2D LOOK UP, NO OFF SET (Is LE3D0 in ANHT) LBBDB: pulb ; CRef: 0xBBD0 cba ; COMP LOOKED UP RESULT to B reg bcs LBBE0 ; BR IF B is Greater Than LOOKED UP RESULT ; .... else tba ; Transfer from Accumulator B to A LBBE0: staa *L00C4 ; KNOCK RETARD ; CRef: 0xBB88,0xBB99,0xBBDD
Last edited by 84Elky; 11-22-2013 at 11:57 AM. Reason: Corrected Code Address of Knock Count Reporting in Data Stream
10-03-2022, 05:45 PM
#2
Supreme Member
Join Date: Jun 2012
Location: Canada
Posts: 1,225
Received 149 Likes
on
122 Posts
Car: '91 Firebird Formula
Engine: SP383 Deluxe FIRST® TPI Intake
Transmission: Tremec T56
Axle/Gears: Moser 9" Eaton Truetrac Motive 3.89
Re: Solved-Knock Retard Reported When No Knock Count
This is a 10 year old post that just answered my question. It's quite important for anyone trying to tune WOT-SA.
It does apply to mask $6E, APYS (Camaro IROC-Z, 1989, LB9, M5). On my data log, KR is reported and increasing without any increase in reported KC. That had me confused. So for tuning SA, I now refer to "KR increase" between frames to detect where knock is occurring. Also, to add to the confusion, Knock Recovery %/sec is not exact. If 100% is entered, you will not get full recovery within a sec. It takes up to double that time. That's based on data log observations. Not sure why but be aware.
10-25-2022, 03:32 PM
#3
Senior Member
Thread Starter
Re: Solved-Knock Retard Reported When No Knock Count
This is a 10 year old post that just answered my question. It's quite important for anyone trying to tune WOT-SA.
It does apply to mask $6E, APYS (Camaro IROC-Z, 1989, LB9, M5). On my data log, KR is reported and increasing without any increase in reported KC. That had me confused. So for tuning SA, I now refer to "KR increase" between frames to detect where knock is occurring. Also, to add to the confusion, Knock Recovery %/sec is not exact. If 100% is entered, you will not get full recovery within a sec. It takes up to double that time. That's based on data log observations. Not sure why but be aware.
1)
Where are you seeing "Knock Recovery %/sec"? Can't find this in any XDF. I believe you're referring to the Table at 0x213 "Knock Recovery Rate .vs. RPM" which has a Column Title of "% Retard Removed". See 2) below.
2)
Analyzing the details of the above table, it was discovered the XDF information is incorrect. Below are the particulars one should change until an updated XDF is released. Note that none of the changes below affect the underlying values in the Calibration:
Changes to make to XDF Table at 0x213
- Title to: Knock Retard Reduction Factor .vs. RPM
- Conversion: The value extracted represents the INITIAL percentage reduction of KR Degrees.
---- From: 1.953125 * X
---- To: (X / 256) * 100
- Decimal Places: From 1 to 2
- Column Description to: % Retard Reduction
- Description to:
The values in this Table represent the INITIAL Knock Retard Degrees percentage reduction at X RPM. For example, at 3200 RPM, 0x5E (94d) is returned. As a percentage, that’s a 36.7% (94/256) reduction in Retard Degrees in the INITIAL 200ms. Why in 200ms? It’s because this table is only accessed every 200ms. Until KR Degrees are reduced to 0, a factor from this table will be applied to the remaining KR degrees. Mathematically, this means that the percentage reduction after 200ms will not be exactly 36.7%. It could be higher or lower if RPM changes, or if RPM remains the same, the same factor will be applied to continually declining KR Degrees, which changes the percentage reduction.
The following users liked this post:
SbFormula (10-27-2022)
10-26-2022, 08:06 AM
#4
Supreme Member
Join Date: Jun 2012
Location: Canada
Posts: 1,225
Received 149 Likes
on
122 Posts
Car: '91 Firebird Formula
Engine: SP383 Deluxe FIRST® TPI Intake
Transmission: Tremec T56
Axle/Gears: Moser 9" Eaton Truetrac Motive 3.89
Re: Solved-Knock Retard Reported When No Knock Count
Took me a while to digest this, so consider this:
1)
Where are you seeing "Knock Recovery %/sec"? Can't find this in any XDF. I believe you're referring to the Table at 0x213 "Knock Recovery Rate .vs. RPM" which has a Column Title of "% Retard Removed". See 2) below.
2)
Analyzing the details of the above table, it was discovered the XDF information is incorrect. Below are the particulars one should change until an updated XDF is released. Note that none of the changes below affect the underlying values in the Calibration:
Changes to make to XDF Table at 0x213
- Title to: Knock Retard Reduction Factor .vs. RPM
- Conversion: The value extracted represents the INITIAL percentage reduction of KR Degrees.
---- From: 1.953125 * X
---- To: (X / 256) * 100
- Decimal Places: From 1 to 2
- Column Description to: % Retard Reduction
- Description to:
The values in this Table represent the INITIAL Knock Retard Degrees percentage reduction at X RPM. For example, at 3200 RPM, 0x5E (94d) is returned. As a percentage, that’s a 36.7% (94/256) reduction in Retard Degrees in the INITIAL 200ms. Why in 200ms? It’s because this table is only accessed every 200ms. Until KR Degrees are reduced to 0, a factor from this table will be applied to the remaining KR degrees. Mathematically, this means that the percentage reduction after 200ms will not be exactly 36.7%. It could be higher or lower if RPM changes, or if RPM remains the same, the same factor will be applied to continually declining KR Degrees, which changes the percentage reduction.
1)
Where are you seeing "Knock Recovery %/sec"? Can't find this in any XDF. I believe you're referring to the Table at 0x213 "Knock Recovery Rate .vs. RPM" which has a Column Title of "% Retard Removed". See 2) below.
2)
Analyzing the details of the above table, it was discovered the XDF information is incorrect. Below are the particulars one should change until an updated XDF is released. Note that none of the changes below affect the underlying values in the Calibration:
Changes to make to XDF Table at 0x213
- Title to: Knock Retard Reduction Factor .vs. RPM
- Conversion: The value extracted represents the INITIAL percentage reduction of KR Degrees.
---- From: 1.953125 * X
---- To: (X / 256) * 100
- Decimal Places: From 1 to 2
- Column Description to: % Retard Reduction
- Description to:
The values in this Table represent the INITIAL Knock Retard Degrees percentage reduction at X RPM. For example, at 3200 RPM, 0x5E (94d) is returned. As a percentage, that’s a 36.7% (94/256) reduction in Retard Degrees in the INITIAL 200ms. Why in 200ms? It’s because this table is only accessed every 200ms. Until KR Degrees are reduced to 0, a factor from this table will be applied to the remaining KR degrees. Mathematically, this means that the percentage reduction after 200ms will not be exactly 36.7%. It could be higher or lower if RPM changes, or if RPM remains the same, the same factor will be applied to continually declining KR Degrees, which changes the percentage reduction.
Yes it's table 0x213 and my XDF was not up to date for the $8D. So now it is!
I was refereeing to the $6E. So the table is 0x1C7. The XDF I had downloaded for $6E was modified and adapted for my use, so I might have copied some info from the $8D XDF, I don't remember. Nonetheless, it's now corrected. But here what the $6E hack shows:
;-----------------------------------------------
; KNOCK PCT. RECOVERY RATE vs RPM
;
; Table values attack rate in PCT.
;
; RECOVERY/SEC * 256/500
;-----------------------------------------------
ORG $01C7 ; PCT RPM
;-----------------------------------
LC1C7 FCB 20 ; 39.0 400
LC1C8 FCB 20 ; 39.0 1200
LC1C9 FCB 26 ; 50.8 2000
LC1CA FCB 31 ; 60.5 3200
LC1CB FCB 31 ; 60.5 4800
;-----------------------------------------------
The conversion appears to be different. It shows "RECOVERY/SEC". Could it be wrong?
10-26-2022, 08:43 AM
#5
Supreme Member
Re: Solved-Knock Retard Reported When No Knock Count
Think I’ll check my .xdf for the LT5 regarding this. However, I have not seen a case in my logs that would show KR when an increase in KC has not occurred.
Last edited by Dominic Sorresso; 10-26-2022 at 04:29 PM.
10-26-2022, 03:46 PM
#6
Moderator
iTrader: (1)
Join Date: Mar 2002
Location: Chasing Electrons
Posts: 18,401
Likes: 0
Received 215 Likes
on
201 Posts
Car: check
Engine: check
Transmission: check
Re: Solved-Knock Retard Reported When No Knock Count
Whereas the earlier code such as $42, $61, $32, $6E, $8D, $88, and so on only report the MSB.
RBob.
The following users liked this post:
SbFormula (11-02-2022)
10-26-2022, 04:28 PM
#7
Supreme Member
Re: Solved-Knock Retard Reported When No Knock Count
Thx RBob. Good to hear from u. 👍
Trending Topics
10-27-2022, 01:29 PM
#8
Senior Member
Thread Starter
Re: Solved-Knock Retard Reported When No Knock Count
Thanks for the info!!!!
Yes it's table 0x213 and my XDF was not up to date for the $8D. So now it is!
I was refereeing to the $6E. So the table is 0x1C7. The XDF I had downloaded for $6E was modified and adapted for my use, so I might have copied some info from the $8D XDF, I don't remember. Nonetheless, it's now corrected. But here what the $6E hack shows:
;-----------------------------------------------
; KNOCK PCT. RECOVERY RATE vs RPM
;
; Table values attack rate in PCT.
;
; RECOVERY/SEC * 256/500
;-----------------------------------------------
ORG $01C7 ; PCT RPM
;-----------------------------------
LC1C7 FCB 20 ; 39.0 400
LC1C8 FCB 20 ; 39.0 1200
LC1C9 FCB 26 ; 50.8 2000
LC1CA FCB 31 ; 60.5 3200
LC1CB FCB 31 ; 60.5 4800
;-----------------------------------------------
The conversion appears to be different. It shows "RECOVERY/SEC". Could it be wrong?
Yes it's table 0x213 and my XDF was not up to date for the $8D. So now it is!
I was refereeing to the $6E. So the table is 0x1C7. The XDF I had downloaded for $6E was modified and adapted for my use, so I might have copied some info from the $8D XDF, I don't remember. Nonetheless, it's now corrected. But here what the $6E hack shows:
;-----------------------------------------------
; KNOCK PCT. RECOVERY RATE vs RPM
;
; Table values attack rate in PCT.
;
; RECOVERY/SEC * 256/500
;-----------------------------------------------
ORG $01C7 ; PCT RPM
;-----------------------------------
LC1C7 FCB 20 ; 39.0 400
LC1C8 FCB 20 ; 39.0 1200
LC1C9 FCB 26 ; 50.8 2000
LC1CA FCB 31 ; 60.5 3200
LC1CB FCB 31 ; 60.5 4800
;-----------------------------------------------
The conversion appears to be different. It shows "RECOVERY/SEC". Could it be wrong?
Given retard is reduced every 200ms using the table's factor based on RPM at the time, the reduction does not occur every second. A long title for this table might be: Knock Retard INITIAL Percentage Reduction at RPM X every 200ms.
Sure hope I'm not looking at this incorrectly.
Elky
;***************************************************
;* MAJOR LOOP SUBROUTINE
;*
;* SEG A, Lk UP Man Air temp Var's
;*
;***************************************************
EC2D: LDAB L0000 ; MJR LOOP CNTR
EC2F: BITB #$10
EC31: BNE LEC4E ; BR IF b4
; ... else
;----------------------------------------
; LK UP KNOCK % Recovery rate vs RPM
;
; RECOVERY/SEC * 256/500
;----------------------------------------
EC33: LDAA L0058 ; RPM/25
EC35: LSRA ; DIV BY 2
EC36: LSRA
EC37: LDX #$C1C7 ; KNOCK PCT. RECOVERY RATE Tbl (Only place accessed)
EC3A: JSR LF3FF ; 2d Lk Up, (No Offset)
;
; CALC KNOCK RETARD AS PROD OF
; RATE AND KNOCK RETARD WITH MIN
; VAL HELD TO ONE
;
EC3D: LDAB L00A9 ; Retard for knock
EC3F: MUL ; RETARD * LK UP RESULT
EC40: ADCA #0 ; ROUND
EC42: NEGA
EC43: BNE LEC47 ; BR IF NZ
; .. else
EC45: LDAA #255 ; USE MAX VAL
EC47: LEC47 ADDA L00A9 ; Retard for knock
EC49: BCS LEC4C ;
; ... else
EC4B: CLRA ; CLR RETARD VALUE
EC4C: LEC4C STAA L00A9 ; Retard for knock
The following users liked this post:
SbFormula (10-27-2022)
10-27-2022, 10:14 PM
#10
Senior Member
Thread Starter
Re: Solved-Knock Retard Reported When No Knock Count
If the formula in the $6e code can be supported mathematically, then it's correct. if not, it's not. I know the XDF conversion "X / 256) * 100" is correct because I've simulated the SR-A code, and that's the percentage applied to reduce knock retard degrees.
The following users liked this post:
SbFormula (10-27-2022)
10-27-2022, 10:38 PM
#11
Supreme Member
Join Date: Jun 2012
Location: Canada
Posts: 1,225
Received 149 Likes
on
122 Posts
Car: '91 Firebird Formula
Engine: SP383 Deluxe FIRST® TPI Intake
Transmission: Tremec T56
Axle/Gears: Moser 9" Eaton Truetrac Motive 3.89
Re: Solved-Knock Retard Reported When No Knock Count
All I can say is that the code hacks and XDF files were created by humans. Humans are either correct or make mistakes. All one can do is logically go through the code and determine what actually happens. For me, measuring the reduction in retard degrees in deg/sec is improper because they are reduced by the factor in the table every 200ms. If you want degrees per second, multiply the result by 5 (= reduction in 1000ms).
If the formula in the $6e code can be supported mathematically, then it's correct. if not, it's not. I know the XDF conversion "X / 256) * 100" is correct because I've simulated the SR-A code, and that's the percentage applied to reduce knock retard degrees.
If the formula in the $6e code can be supported mathematically, then it's correct. if not, it's not. I know the XDF conversion "X / 256) * 100" is correct because I've simulated the SR-A code, and that's the percentage applied to reduce knock retard degrees.
Thread
Thread Starter
Forum
Replies
Last Post
