AUJP $8d-BLM Update Rate Conversion Formula
Thread Starter
Senior Member
Joined: Jun 2010
Posts: 580
Likes: 32
From: Montgomery, AL
Car: 84 El Camino
Engine: 360 TPI
Transmission: 700R4
Axle/Gears: 3.42 + Truetrac, Moser 28 Spline
AUJP $8d-BLM Update Rate Conversion Formula
Question: Is the conversion formula for BLM Update Rate at 0x851B in AUJP XDF files correct? Have been looking at this because a recent review of the AUJP code revealed a conversion formula in the comments different than that in the AUJP XDF files. Apparently someone believed the commented formula was correct. Here are the 2 formulas, where:
In AUJP Comments one line below label LCCFF: X = (Seconds * 20) + 1
Solving for Seconds yields:
Seconds = (X – 1) / 20 = (X – 1) Execs * (.0.05 Sec / 1 Exec)
Clearly different formulas. So which one is correct? The XDF formula uses “1 Second” in the calculation and the comments formula uses “1 Execution”. From an assembly language perspective, the comments formula appears correct because it uses 1 execution apparently for overhead of the Assembly language instruction. On the other hand, the XDF formula uses 1 second added to the calculated value. Is this purposeful by GM to slow down the BLM update rate from that resulting from the true number of executions?
Why is this important? Because some using AUJP have reduced “BLM Update Rate” from 2.40 seconds (X=28, $1C) to something lower, like 2.0 seconds (X=20, $14) and this would be counter to what GM was trying to accomplish. But if that was not GM’s intent, then the AUJP comment formula with X=28, $1C yields 1.35 seconds (versus 2.40 seconds using the XDF formula). And using X=20, $14 yields 0.95 seconds which might be too quick for accurate BLM updates.
My vote is for the AUJP comment formula.
If you feel differently, let’s discuss it; or if you know which is correct, would appreciate your reasoning.
Thanks!
- ‘X’ = Decimal # of executions ([Exec] = passes through the code) to produce the desired update rate in Seconds
- Units of measure are included for clarity and to ensure cancellations equal “Seconds”
In AUJP Comments one line below label LCCFF: X = (Seconds * 20) + 1
Solving for Seconds yields:
Seconds = (X – 1) / 20 = (X – 1) Execs * (.0.05 Sec / 1 Exec)
Clearly different formulas. So which one is correct? The XDF formula uses “1 Second” in the calculation and the comments formula uses “1 Execution”. From an assembly language perspective, the comments formula appears correct because it uses 1 execution apparently for overhead of the Assembly language instruction. On the other hand, the XDF formula uses 1 second added to the calculated value. Is this purposeful by GM to slow down the BLM update rate from that resulting from the true number of executions?
Why is this important? Because some using AUJP have reduced “BLM Update Rate” from 2.40 seconds (X=28, $1C) to something lower, like 2.0 seconds (X=20, $14) and this would be counter to what GM was trying to accomplish. But if that was not GM’s intent, then the AUJP comment formula with X=28, $1C yields 1.35 seconds (versus 2.40 seconds using the XDF formula). And using X=20, $14 yields 0.95 seconds which might be too quick for accurate BLM updates.
My vote is for the AUJP comment formula.
If you feel differently, let’s discuss it; or if you know which is correct, would appreciate your reasoning.
Thanks!
Senior Member
Joined: May 2010
Posts: 848
Likes: 0
From: Alamogordo, NM
Car: '86 Grand National
Engine: LZ9????
Transmission: 2004R
Axle/Gears: 3.42
Re: AUJP $8d-BLM Update Rate Conversion Formula
i could try it to see if one would be drastically different from the other
Moderator
iTrader: (1)
Joined: Mar 2002
Posts: 18,432
Likes: 233
From: Chasing Electrons
Car: check
Engine: check
Transmission: check
Re: AUJP $8d-BLM Update Rate Conversion Formula
The conversion appears to be this:
Delay in milli-sec = 50.000000 * X + 50.000000
So a value of 28 would be 1.45 seconds, along with the update amount being 2
RBob.
Delay in milli-sec = 50.000000 * X + 50.000000
So a value of 28 would be 1.45 seconds, along with the update amount being 2
RBob.
Thread Starter
Senior Member
Joined: Jun 2010
Posts: 580
Likes: 32
From: Montgomery, AL
Car: 84 El Camino
Engine: 360 TPI
Transmission: 700R4
Axle/Gears: 3.42 + Truetrac, Moser 28 Spline
Re: AUJP $8d-BLM Update Rate Conversion Formula
.05 secs * X executions
-------------
1 execution
But how does one know to add the 50 msec (.05 sec)? Does this have to do with assembly instruction execution cycles, branches, etc, and if so how does one know to make this adjustment? Please elaborate if you can so I can understand the details.
Bottom line, I agree with your anaysis and that confirms that the formula is incorrect in the downloaded AUJP xdf files, and that reducing it is likely not a good idea for accurate reporting of BLMs.
Thread Starter
Senior Member
Joined: Jun 2010
Posts: 580
Likes: 32
From: Montgomery, AL
Car: 84 El Camino
Engine: 360 TPI
Transmission: 700R4
Axle/Gears: 3.42 + Truetrac, Moser 28 Spline
Re: AUJP $8d-BLM Update Rate Conversion Formula
Code:
ldab *L00ED ; BLM UPDATE TIMER
incb ; INCREMENT TMR VALUE
bne LCCFF ; BR IF NON ZERO
; ... else [= zero with Carry set]
decb ; DECREMENT TMR VALUE
LCCFF: stab *L00ED ; Save BLM UPDATE TIMER
cmpb L851B ; BLM update rate [$1C, 28d=1.40 sec]
bcs LCD5D ; BR IF Carry Set, LESS THAN 1.40 sec
|
| ; Do BLM Update
|
LCD5D: ; Not time for BLM to update Am I looking at this incorrectly?
Last edited by 84Elky; Feb 19, 2013 at 03:46 PM. Reason: Corrected code comments
Moderator
iTrader: (1)
Joined: Mar 2002
Posts: 18,432
Likes: 233
From: Chasing Electrons
Car: check
Engine: check
Transmission: check
Re: AUJP $8d-BLM Update Rate Conversion Formula
Sometimes it is best to put the RAM variables into the data log and run it on the bench. Higher speed data logging also helps. There have been times that I've beat my head on the wall trying to figure out timing loops and such as this one.
But when you can see the data, it becomes much more clear. And much less of a headache.
And honestly, does it really matter if the equation is one or the other? We are talking about a 50 milli-second difference over a 1.5 to 2.0 second interval.
RBob.
But when you can see the data, it becomes much more clear. And much less of a headache.
And honestly, does it really matter if the equation is one or the other? We are talking about a 50 milli-second difference over a 1.5 to 2.0 second interval.
RBob.
Thread Starter
Senior Member
Joined: Jun 2010
Posts: 580
Likes: 32
From: Montgomery, AL
Car: 84 El Camino
Engine: 360 TPI
Transmission: 700R4
Axle/Gears: 3.42 + Truetrac, Moser 28 Spline
Re: AUJP $8d-BLM Update Rate Conversion Formula
Sometimes it is best to put the RAM variables into the data log and run it on the bench. Higher speed data logging also helps. There have been times that I've beat my head on the wall trying to figure out timing loops and such as this one.
But when you can see the data, it becomes much more clear. And much less of a headache.
And honestly, does it really matter if the equation is one or the other? We are talking about a 50 milli-second difference over a 1.5 to 2.0 second interval.
RBob.
But when you can see the data, it becomes much more clear. And much less of a headache.
And honestly, does it really matter if the equation is one or the other? We are talking about a 50 milli-second difference over a 1.5 to 2.0 second interval.
RBob.
Thread
Thread Starter
Forum
Replies
Last Post
90formulaVortec
Interior
1
Sep 8, 2015 12:42 AM