BLM Update Rate – AUJP $8d

[toliphint]

Have been doing some tracing through the AUJP $8d and ANHT hacks and find an inconsistency in the BLM Update rate (0x851B) conversion factors mentioned there and TPro xdf files. I believe the TPro conversion is correct, but I’m clueless as to how the conversion values are actually determined. Here are the differences:

X = Decimal Value in Bin at 0x851B = 28 ($1C)

In TPro: (conversion = 2.4 seconds)
Seconds = [0.05 * X] + 1

In AUJP & ANHT: (per the comments in both, seconds are 1.35)
Comments state: X = (Seconds * 20) + 1
Seconds = [X – 1] / 20

With 28d in the Bin:
TPro: Seconds = [0.05 * 28] + 1 = 1.4 + 1 = 2.40
AUJP: Seconds = [X – 1] / 20 = [28 – 1] / 20 = 27 / 20 = 1.35

I realize that the comments in AUJP and ANHT are only comments, but someone believed that the formula documented was correct to yield 1.35 seconds .vs. TPro = 2.40 seconds.

So 2 questions:
- What is proper conversion?
- How are conversion factors determined for variables?

Any clarification would be greatly appreciated. Thanks!

[dex]

You would have to look at the code to see how often the BLM update timer is incremented. From what you've posted it would appear to be every 1/20 second. Therefore the minimum time that must elapse before an update is permitted is either X/20 or (X-1)/20 depending on the branch instruction used.

[Mangus]

I haven't studied the code, so I can't answer your first question (which is the more important question in the immediate sense). The limits of values may be determined a few different ways:

1) Empirically, on a test bench (or in the vehicle, though risky and less common). Values are set to their extremes and the results are measured (i.e. setting the value to 0 and measuring the update rate with a stopwatch, then 255 and doing the same).

2) With knowledge of the hardware (e.g. CPU frequency) and studying how the values are referenced in the code, it's possible to determine what the extents are.

3) By inferring the conversion from other calibration values that have been determed by methods 1 and/or 2. For example, temperature conversions are generally the same throughout the calibration.

[toliphint]

Thanks guys for the prompt replies. I understand both, but one more question and I believe the correct formula can be determined. In the code the BLM timer is updated every 50 msec, or 20 times per second. So both formulas are correct in multiplying by 20 or dividing by 0.05.

But the real key is the “+1” which both formulas employ. Is it 1 second time added for code overhead, or is 1 additional execution added?

Thanks!

[Mangus]

My guess is that the +1 is because 0 isn't a valid update interval, so the byte range of 0-255 is being adjusted to 1-256. Just a guess.

[dex]

To determine the minimum time that must elapse before an update is permitted it is down to what branch instruction the code uses, the order of the values and what the code executed next does. For example:

Code: Select all

if BLMTMR <= KBLMCNT then 'clear learn control enable flag'

the equation would be X/20

yet for

Code: Select all

if BLMTMR < KBLMCNT then 'clear learn control enable flag'

the equation would be (X-1)/20

[robertisaar]

from John Pell's 8D disassembly:

Code: Select all

;---------------------
; UPDATE BLM
;---------------------
LCCE9:        ldd     *L0046             ; Air Fuel Ratio MODE WORD                                           ; CRef: 0xCCE4
              bitb    #0x02              ; B1 1 = DECEL FUEL C/O ENABLED
              beq     LCD5A              ; BR IF NOT DECEL FUEL C/O ENABLED  (Goes to LCD52 in ANHT)
                                         ; ... else
              bita    #0x08              ; b3 1 = DELAY BLM UPDATE
              bne     LCD5A              ; BR IF DELAY BLM UPDATE   (Goes to LCD52 in ANHT)
                                         ; .... else
              ldaa    *L00EB             ; Get Closed loop integrator 
              cmpa    #0x80              ; VAL = 128,
              beq     LCD5A              ; IF E.Q. 128, NO CORRECTION  (Goes to LCD52 in ANHT)
                                         ; ... else
              ldab    *L00ED             ; BLM UPDATE TIMER
              incb                       ; INCREMENT TMR VALUE UP
              bne     LCCFF              ; BR IF NON ZERO  (Goes to LCCF7 in ANHT)
                                         ; ... else
              decb                       ; DECREMENT TMR VALUE DOWN
LCCFF:        stab    *L00ED             ; Save BLM UPDATE TIMER                                              ; CRef: 0xCCFC
              cmpb    L851B              ; 1.35 sec BLM update rate, (SEC*20)+1
              bcs     LCD5D              ; BR IF Carry Set, LESS THAN 1.35 sec (Goes to LCD55 in ANHT)

EDIT: in this instance, BCS = BLO (branch if lower)

starting at the LDAB 00ED:

timer is loaded, then always incremented by one. tested to see if value rolled over from 255 to 0, if it rolled over, decrement to bring it back to 255. store. compare to calibration scalar, branch if value is too low to update BLM.

since the value is ALWAYS incremented before being checked, it can never be 0, so the "+1" method is correct.

[dex]

I disagree that the incrementing of the timer causes a "+1" to come into play, it's the choice of the branch instruction that determines the equation. The timer increment just means that the timer has a minimum value of 0.05 secs before it is compared against the KBLMCNT value.

[robertisaar]

well.... think of it this way:

if the RAM weren't incremented before checking against the scalar and the scalar was set to 0, then on the first pass:

RAM: 0
scalar: 0
branch(and skip update) only if RAM is lower, do not branch if equal

then on the first pass(and every pass actually), the BLM update code would be entered.... if a value of 1 were used in the scalar:

RAM: 0
scalar: 1
branch(and skip update) only if RAM is lower, do not branch if equal

then on the first pass, the BLM update code would be skipped and the RAM incremented, then it would update on the next pass.



that's my reasoning anyways, too tired to think too much more about it tonight.

[toliphint]

Sorry for not weighing in sooner on this, but am not getting emails when posts are made . But that’s another matter. Dex, I think you’re on to something. Just wish I understood Assembly better and the whole instruction execution thing you talked about.

Try this. Take a look at the formulas using units of measure (my math teachers would be so proud). A little tedious, but bear with me:

In the formulas:
- ‘# Exec’ = Number of Executions (decimal) needed to achieve desired time (Secs)
- ‘Seconds’ = Secs

TPro - In the TPro conversion formula, the ‘+1’ has to be “Secs” in order to keep the units of measure consistent:
Secs = ((0.05 Secs / 1 Exec) * # Execs) + 1 Sec

AUJP & ANHT - Here, the “+1” has to be ‘1 Exec’, again to keep units of measure consistent:

Formula per JP’s hack posted above (the subject of my original post):
# Execs = ((Secs * (20 Execs / 1 Secs)) + 1 Exec

And solving for Secs:
Secs = (# Exec – 1 Exec) / (20 Execs / 1 Secs)
Secs = (# Exec – 1 Exec) * (1 Secs / 20 Execs)

We now have 2 formulas for Secs that are different. Plugging in the variable from the Stock AUJP Calibration (28d, $1C) into the formulas yields:

TPro: Secs = ((0.05 Secs / 1 Exec) * 28 Execs) + 1 Secs = 1.4 + 1 = 2.4 Secs
AUJP: Secs = (28 Execs – 1 Exec) * (1 Secs / 20 Execs) = 27 /20 = 1.35 Secs

So which one is correct??? I tend to believe the AUJP formula is correct and that BLMs are being updated every 1.35 seconds with a Calibration value of 28(d). Why? Because it seems inconceivable that 1 second of overhead in the TPro formula would be added to compute something that is measured in milliseconds. One second is forever in computer terms.

What say you guys? I really want to fully understand this.
Thanks!

[robertisaar]

you're on the right track.... but the +1 isn't +1 seconds.... it's +1 executions.

[dex]

Looking at that snippet of $8D disassembly the minimum time that must elapse before an update is permitted is X/20. My reasoning being is that the BCS jump occurs when the update timer < 1.4 seconds and doesn't occur when the update timer is >= 1.4 seconds.

[toliphint]

you're on the right track.... but the +1 isn't +1 seconds.... it's +1 executions.

Looking at that snippet of $8D disassembly the minimum time that must elapse before an update is permitted is X/20. My reasoning being is that the BCS jump occurs when the update timer < 1.4 seconds and doesn't occur when the update timer is >= 1.4 seconds.

So that I fully understand, does this mean you are both in agreement that the AUJP commented formula is the correct one to arrive at 1.35 seconds with 28(d) executions in the calibration?

The reason this is important is because there are a gillion AUJP users who believe 2.4 seconds is the proper result and have even reduced it (as in AUJP v4), and thus may not be providing sufficient time for a true BLM update.

[dex]

I'm saying the equation is X/20. Assuming the value at 0x851B is 0x1C and the update timer is incremented every 0.05 seconds then looking at it simplistically:

If the timer is 1.35 secs (or less) then the carry is set and a jump occurs.

If the timer is 1.40 secs then the carry is clear and no jump occurs.

If the timer is 1.45 secs (or greater) then the carry is clear and no jump occurs.

This means the the BLM update code runs every 1.40 seconds.

[toliphint]

I'm saying the equation is X/20. Assuming the value at 0x851B is 0x1C and the update timer is incremented every 0.05 seconds then looking at it simplistically:

If the timer is 1.35 secs (or less) then the carry is set and a jump occurs.

If the timer is 1.40 secs then the carry is clear and no jump occurs.

If the timer is 1.45 secs (or greater) then the carry is clear and no jump occurs.

This means the the BLM update code runs every 1.40 seconds.

Bingo! That's what I believe as well but you stated it in the way the conversion formula should have been set in the AUJP xdf file. Thanks for your insight!