Everyone knows the argument in the fiero community that multecs cause problems when used in our little engines. I've seen people on other forums make fun and argue with whomever brings this tidbit info nugget to the debate.......
Being naturally investigative, I drove off the cool bridge and right into the nut hut.
Here's what I've found out so far.......
Multecs are a thorn in someone's side at gm. How do I know? Because they spent $$$ to code the problem away.
Here's a brief explanation from another forum when I asked the question of WHY?
"RobertISaar RobertISaar is offline
Super Moderator
Join Date
Mar 2011
Location
Camden, MI
Age
26
Posts
2,943
should have been some notes in the item(present in all MPFI 60V6 masks that I've made XDFs for)... if not:
WHEN DIVIDED BY ADMAPF+28, THIS FACTOR PRODUCES A SUBTRACTED CHANGE TO BPW IN MSEC. ITS UNITS ARE THEREFORE 'KPA*MSEC'. TO PRODUCE THE COMPUTER UNITS FOR THIS CALIBRATION FROM THE MAP AND DELTA BPW VALUES, USE THIS EQUATION: N = (65.536*DELTA BPW)*(2.711* MAP) WHERE DELTA BPW IS IN MSEC AND MAP IS IN KPA, OR, N = 2.711*(DELTA BPW)*(MAP) WHERE DELTA BPW IS IN COUNTS AND MAP IS IN KPA.
kind of(really) cryptic, I know, but that's the official word from one of the GM code engineers back in the day.
using A1(since I've spent FAR more time documenting and modifying it than 88) since they're going to be really similar for this stuff. I don't have this completely documented in my disassembly, so some of this is going to appear unnecessary.
the subroutine at C1DC deals with the offset stuff. if above the max value in the F94 table, all of this is skipped.
the F94(injector offset vs low BPW) table lookup is done, then added to the final BPW value(and then stored to the stack). MAP is then grabbed(filtered and has an offset added), B cleared and then all placed into X. A receives the KF94MAP calibration value(B stays clear) and an integer divide occurs(effectively, D/X with the quotient ending up in X and any remainder in D). so, we've just divided a MAP value by the KF94MAP value and I'm actually just going to write out an example to better understand this myself.
using a ported BCFA calibration, assuming a target pulsewidth of .73mSec, the low PW adder will add .17mSec for a total of .90mSec, stored to stack.
MAP(let's say a raw 48 a/d counts, should be 28.07kPa MAP) value used here isn't raw MAP, it's filtered and rounded up when necessary, so let's still say 48 counts. it has d28 added to it(so a total of 76 counts in the accumulator), then pushed into the stack with a cleared B and pulled into X.
B stays clear and A receives the calibration value(d50 for BCFA), then the integer divide occurs. should compute as 3200/4C00 (or 12,800/19,456 for humans, or since these are 8-bit values being used with a 16-bit instruction, 50/76), which is .658 real-world. the microcontroller should have 0 in X and 50 in D.
X is saved to the stack and pulled into D(ignoring the remainder of 50) and stored as byte FE. another value is pulled out of the stack into D, this would be the final BPW with the low BPW adder accounted for. now, byte FE(which has a value of 0) is subtracted from BPW, taking it from .90mSec to the same .90mSec....
and that's the end of the multec correction adder stuff. after this, the voltage offset is added to these values and the BPW is pretty much done being modified.
doesn't seem too significant to me, at least in that scenario. i'll do an abbreviated version of another calibration's values using the same scenario: ASHH(92 w-body 3.1/3 speed). at .73mSec, there is an adder of .12 for a total of .85mSec. has a KF94MAP value of d162. so, 162/76, which is 2.13. so, 2 counts of (1000/65536) are subtracted from the BPW, that's .03mSec, final PW of .82mSec....
still seems really insignificant. let's get nuts. going off of how the code works, increasing either the KF94MAP value or operating at lower MAP ranges will increase the amount of change caused by this code. running significantly larger injectors or a smaller cylinder volume should help decrease the total injection time as well.
let's max out the calibration value to 255 and assume that injectors that flow 50% more fuel per time-period are installed(but otherwise follow the 3.1 offset curve). now we're looking at .49mSec, which has an offset of .18mSec(.67mSec total). KF94MAP of 255. let's say around 15kPa in a strong overrun situation. 13 a/d counts would be 15.15kPa, offset that by 28 counts to end up with 41, so our critical math step ends up at 255/41, which is 6.22. that's .09mSec removed from .67 for a total of .58, making it 86.5% of what would have happened otherwise. that's kind of a significant change proportionally.
now let's operate this exact engine in a more common situation: 50kPa at 2.2mSec, which is probably reasonable for a 55MPH cruise. no offset at 2.2mSec. KF94MAP of 255, 108 a/d counts is 50.2kPa, offset by 28 is 136, math ends up at 255/136, which is 1.875, so only subtracting .015mSec from the pulsewidth....
so, much like the rather cryptic description given by GM, it appears to remove some measurable injector on-time when in low MAP situations...... and that's about it. setting up a "correct" KF94MAP value that isn't well within a margin of error using an O2 sensor is probably not going to happen. that's a lab-level measurement, I would just leave it as-is or lower it to a trivial level."
Got that?
Ron
