ULTM8Z

I'm noticing in my datalogging that as time goes on, the commanded AFR during Power Enrich (as reported by TunerPro) starts to drift from what I've programmed in Tunercat. It's pretty accurate at first, but it starts deviating by about 0.2 to 0.3 after about 20-30 minutes of driving (i.e., programmed 13.25 in TC, I start noticing 13.08 in TP).

It appears to be independent of MAT (I plotted MAT vs time vs PE and there's no correlation).

Is there something else that's driving the PE commanded AFR besides coolant temp and RPM?

84Elky

Here's how PE AFR is calculated in $8d and reported the ALDL data stream. Maybe this will help:

• A Lambda W (Lw) value is obtained from the Table:
  • at 0x617 =Power Enrich Fuel/Air % Chg .vs. RPM, or
  • at 0xB3A =S_AUJP v4/v5 Extended PE Table if 0x99E b7=1 (use Extended Lw PE Table)
• Add 128 to Lw = (Lw + 128)
• (Lw + 128) is added to a Lambda C (Lc) value from the Table at 0x60D=Power Enrich Fuel/Air % Chg based on Coolant Temp
• The sum of the Lambdas, and Stoich AFR (0x41A) , are multiplied to yield PE AFR, which is stored in L00F1=AFR
• Looking at the Factory GM $8d table values, there is no effect on PE AFR once Coolant Temp reaches 133°F because the Lc values are all the same (0.227). So the real change in PE AFR comes from RPM-based Lw, unless the temp is < 133°F.

PEAFR can be approximated using decimal values from the Lw (0x617 or 0xB3A) and Lc (0x60D) Tables as:
PE AFR = Stoich AFR (0x41A) /(Lw + Lc)

But this is just a theoretical AFR that is reported and used in the calculation of a BPW which will ultimately determine the AFR measured by a WBo2 sensor. Just curious -- how are you "programming in TunerCat a commanded PE AFR", as that does not appear to be in the $8d Calibration. What's the hex address of the 13.25 AFR?

ULTM8Z

Thanks. I'm a hexidecimal ignoramus, so not sure how to answer your question.

But In Tunercat, I see the PE %Chg to AFR vs Coolant Temp table as well as a %Chg to AFR vs RPM. Each one of these tables has a numerical value for various coolant temps (which BTW do go higher than 133F) and RPM values.

There's a formula that TC gave me a long time ago which combines values for a given RPM and coolant temp, and then outputs a commanded AFR. I have an Excel tool that I generated that allows me to copy/paste the tables into the tool and then output the AFR values.


If I call the %chg vs coolant value "X" and the %chg vs RPM value "Y", then

basically it's => 14.7/[(1+X/100+Y/100)]

So at 80C, if I have a value of 15.6 and at 3200 rpm a value of 6, then it becomes

14.7/[1+15.6/100+6/100) = 12.08

Like I said in original post, the TC method matches the TP reporting initially, but then starts to diverge.

RBob

iTrader: (1)

This has been an issue with TC for quite some time. If interested here is a write up by TRAXION on calculating PE mode AFR:

https://www.thirdgen.org/forums/diy-...t-afr-how.html

RBob.

84Elky

Sorry about the hex, but have to use it because all XDF files do not use the same item descriptions. But the hex address is always the same. It’s the position of a calibration item from the top of the BIN when viewed in a hex editor. I only use TPro and can press F2 for any XDF item and get the hex address of the item (very handy). Don't know how to do that in TCat.

But, the titles you described appear to be the Lambda W and Lambda C tables in my post:
0x617 =your ‘%Chg to AFR vs RPM’ (Lw)
0x60D =your ‘PE %Chg to AFR vs Coolant Temp’ (Lc)
The values in those 2 tables are all that affect the calculation of the theoretical PE AFR.

But if you have changing values in the Lc Coolant based table past 56*C (133*F), your tables have been changed from Factory $8d. The only way it would appear the AFR could begin drifting if is coolant temp is rising causing new values to be used to compute AFR. Any way you could post your 2 tables?

BYW, the Traxion article RBob referenced is excellent, but is unfortunately now outdated in a few areas with the advent of S_AUJP. I’m in the process of putting together a document addressing those items plus how BPW gets computed in both OL & CL after AFR is computed.

JP86SS

iTrader: (1)

Across all of the different items defined there could be a scale difference between the TC reporting and TP reporting.
One calculated scale may have 255 value referenced vs. 256 in another or 10 Kpa column offset or not included, etc.

SbFormula

Your last recorded BLMs!

The ECM will use 128 if BLM is less than 128 or will use the actual BLM if BLM is greater or equal to 128. That's why your AFR number sometimes decreases (richer). In PE the ECM will enriched but never lean out. Just a precaution from GM since it is a blind calculation with no feed back. A way around it is to modify your BLM boundaries so CELL 13-14-15-16 are reserved for PE (MAP 91 and over) and setting Min MAP for PE at 91. That way in closed loop you'll never be in CELL 13-14-15-16 thus your BLM will stay at 128. That's how I tuned mine.

NOW THIS FOR A SPEED DENSITY SYSTEM with MAP and VE table. There are probably ways to do that with MAF system but I would not know the details.

Cheers

ULTM8Z

Hmmmm.... Now that is interesting. I'll go back and look at the data and take note of what the BLM was prior to entering into PE at the discrepant locations.

84Elky

Not wishing to be contrary, but the $8d code appears to do the following, slightly different than described above:

• Prior to S_AUJP v4: If not in PE & BLM >= 128, use BLM; if BLM < 128, BLM forced to 128. If in PE, always force BLM =128
• S_AUJP v4/v5: If not in PE, use BLM regardless of value. If in PE & 'V4 OPT 1, b6=1: Lock BLM to 128 in PE', force BLM =128. if b6=0 & BLM >= 128, use BLM; if BLM < 128, force BLM =128.

But, BLM does not affect the calculation of the theoretical PE AFR. That PE AFR calculation is as described in posts above. BLM <> 128 only affects the final BPW, of which the calculated PE AFR is one component. It's the calculated BPW that produces the AFR measured by a WBo2. If understanding the issue correctly, it's the calculated AFR that's varying and not the WBo2 measured AFR. Maybe need some clarification if otherwise.
Also ++ what JPSS86 said.

SbFormula

The more I read the more it makes sense!! I should know better. Commanded AFR should not vary since BLM is only correcting BPW!!!
My apology! That stuff gets confusing sometimes ;-). My conclusion on BLM use in PE was based on Data logging. That's why I did modify BLM boundaries to avoid any BLM modification that was happening in PE. I've never experienced a difference in PE commanded AFR between TC and DataMaster.

Just curious, what is Prior to S_AUJP v4? And what is p6? So only when S_AUJP v4/v5, p6=0 that "The ECM will use 128 if BLM is less than 128 or will use the actual BLM if BLM is greater or equal to 128

ULTM8Z

Yeah, in looking over the data, I didn't see a correlation between BLM's not equal to 128 prior to entering PE and a subsequant alteration of the commanded AFR.

84Elky

No problem. This stuff is not easy; and for me, looking at assembly code is like sticking my hand in a bag of fishhooks.

There are several version of AUJP: the original factory version, a version which incorporated an upper extend VE table I believe by RBob. Somewhere in there was AUJP v2 with some additional features. Then came Super AUJP with many changes. The first Super version was, I believe, S_AUJP v4 followed by the latest, S_AUJP v5, here: (https://www.thirdgen.org/forums/diy-...available.html. Many hacks here: http://gearhead-efi.com/gearhead-efi/moates/1%20Moates%20Fileman/5)%20Source%20Code%20and%20Hacks/)

b6 refers to bit #6 of a Flag in the S_AUJP v5 XDF file released with the BIN. The bit is labeled: "V4 OPT 1, b6, Lock BLM to 128 in PE". Usage is as described above:
S_AUJP v4/v5: If not in PE, use BLM regardless of value. If in PE & 'V4 OPT 1, b6=1: Lock BLM to 128 in PE', force BLM =128. if b6=0 & BLM >= 128, use BLM; if BLM < 128, force BLM =128.

No software to read a hack. Hacks are created by disassembling the factory code. That's relatively easy. The real work is commenting what the disassembly is really doing. Need to review an assembly code hack to see what it does (JPSS86 is primarily responsible for commenting the AUJP hack). S_AUJP v4 and v5 hacks are not available because they contain proprietary code the writers do not wish to be made public.
HTH.

SbFormula

Thanks a lot!
I figured out what a hack was after asking... Research before asking I should do
My calibration is ATNX (using $8D mask with 7730). I have modified it for my application. I could not find a hack for it but will research more!
So basically comparing ATNX to AUJP is a risky exercise, isn't it?