I think so. In searching this site and TGO, I found another XDF created by a TGO member. Using what he refers to as a "HAC" from the DIY-EFI website, he created an alternative 6E "extended" XDF. Beyond his addition of several new definitions, it has one major difference......

His XDF uses a different formula to display/translate the stored values for the OPEN LOOP vs TEMP table. Using his formulas, I see these two tables for Open Loop fueling....

Open Loop vs LV8..............Open Loop vs Temperature


Using TunerPro's 6E mask, those same tables look like this....



The obvious difference is in the right-hand table where you see negative values.

At first I thought this had to be wrong since you wouldn't want to lean out AFR during warm-up. IOW, you wouldn't want AFRs leaner than 14.7:1 at ANY time.

Viewing logs, I see the car idles in the 48-64 LV8 during warm-up. When you combine those two cells with the -3.91 "temperature" values, the net effect is zero adjustment (to AFR). (Of course, it does get richer as you pass below 50-deg or as you rise in load, aka "LV8".)

By contrast, using the TunerPro 6E mask makes it look like extra fuel is being added during open loop operation for any temperature. In fact, that mask makes it look like 14% extra fuel is being added at any temperature. In my ignorance, I assumed this was necessary until the engine reached operating temps (or at least ran for the few seconds necessary to hit closed loop operation).

I think that assumption was WRONG. I believe the extended XDF must be the correct map and that no adjustment to AFR is being performed for temperatures above freezing. (The motor may go a hair lean in the lowest LV8's but it'll only hit an AFR in the 15.2ish range when returning to idle -- and dropping below the 48 LV8. But that is acceptable.) Similar observations can be made if you look at the ARAP bin using these two masks.

The important thing (from my perspective) is to realize what is happening -- especially for the hotter temps. For people who use the 6E map, they might conclude they could lower the open loop enrichment below 9.77%. After all, why add extra fuel when the car is already hot? WRONG! You're not.

I think this error could confuse self tuners. It could cause them to (mistakenly) lower AFR during warm-up. If you convert the 9.77% cells to zero for your warmer temps, I suspect you'll really be running in the 16:1 AFR range during open loop operation. If you also convert the 48 and 64 LV8 cells to zeros, your AFR could hit 16.5:1 during warm-up!

Am I looking at this wrong? (I don't think so.) I wonder if TunerPro should be advised of this issue.


BTW...the 6E mask uses this formula: 0.390625 * X + 0.000000. The Extended mask created by TGO uses this formula: x/2.56-b. These are the formulas used to extract/display the bin values stored for the OPEN LOOP vs Temp table.

 

The correct conversion uses the offset value of 35. Which comes from the bias value of 221 at LC419 (256-221 = 35).

So the conversion equation in the tunerpro xdf should read (x-35)/2.56.

If you want to get fancy, it should really reference the bias value directly to support correct conversion if the bias value were to be edited. Since this is unlikely, the constant of 35 should work fine in most cases.

The table showing negative values (-3.91 %) has the correct conversion in your examples.

A simple test of the correct conversion equation would be to zero both the coolant temp and lv8 tables and verify that the open loop target AFR is equal to the stoichiometric value (neglecting start up enrichment influences).

If zero values result in something other than stoich, then you have an incorrect conversion in one or both tables. Not really conclusive as to which conversion is erroneous, but easy enough to perform a sanity check.

 

........ The only real difference that I see between the two sets of tables is that one is based on temps in farenheight and the other based on temps in celcius .... this explains the difference in formulas ................. the values themselves are what YOU can adjust by virtue of Tuner Pro , etc . to suit your combo's requirements / needs .............

 

Though my initial AFR was enriched for cold startups, before open loop was finished, I was seeing the target rise above 14.7 (stoich). This is one of the reasons I really started digging hard. I had a feeling the TunerPro map was wrong. Thank you for confirming my suspicion. Maybe I should email them?


C409: Your answer ignores the issue I posted. I believe there is a problem. (TequilaBoy agrees.) If you enter "0" as the enrichment for any row of a TunerProRT-edited BIN, you will actually be telling the car to run 14% leaner than stoich until open loop is activated. By this I mean if you use their erroneous $6E.XDF file w/o realizing the error.

 

.............. Those tables are meant to be adjusted to YOUR car ... to whatever number helps you to achieve your fueling goals ...be it 9.77 or -3.91 these are tuning points for two different vehicles and have nothing to do with yours except to provide you with a starting place for fine tuning YOUR car ... I have the feeling that you are not tuning a stock L98 ... if zero works for your combo set it to zero ... if you are using the Tuner Pro mask and you are going lean at any given temperature than raise the number shown a few points til you get it to where it makes you comfortable ... i.e. if you are going above stoich at 133 degrees change the 9.77 to 11.97 and see what happens ... if your wide band has a lambda read-out you can treat it as a percentage based change ... but remember there are other factors involved so try half changes at first ....

 

I understand ALL that. Not everyone has a WB. So, it's nice to use a map that's actually correct (or at least close)! Would you like to tune a car, enter an AFR value of 14.7:1 and have it really give you 16:1 back? I don't think so.

Re-read my original post. I don't think you're following this issue. Imagine this scenario. You buy two computer programs for tuning your car. You try both programs. In both, you enter 36-deg advance at 4800 rpms for the main spark table (maximum LV8). Program#1 actually runs with 36-deg advance @ 4800 rpms.

In the other program, you also enter 36-deg advance for 4800s. But, it really sends 58-deg advance to your engine. Which would you use? The one that correctly stores the value you want it to? Or would you rather have to remember to subtract 22-deg from EVERY value in your spark table -- because it had a 22-deg error?

I think you'll pick the one that doesn't have unexpected offsets. That's what I'm saying here. The $6E mask (on TunerPro's website) has an error that makes your open loop AFR about 15% less than the value YOU enter! IOW, For every row, the actual enrichment will be ~15% less than the number you put in.

Get it?

Course of action: Users can correct the formula so the mask works correctly. Or, you can go to TGO to get a corrected 6E definition file. Of course, using equipment to measure the results is always good advice.

 

I used your equation to change my copy of the $6E.XDF mask. It works correctly. Thanks!

Out of curiousity, what does the bias represent? Functionally, what is it the difference between?

 

........... Craig Moates is a regular on TGO at DIY/EFI ... I believe Mark Mansur wrote Tuner Pro ... have you taken this issue up with either of them ?

 

The value of just X in these tables is the Decimal value (0-255), which is what the ecm works in (actually binary but Tuner pro converts to decimal).

The conversion formula in the XDF file only converts this binary/decimal number to "engineering units" AFR, Fahrenheit, Celsius, or any other man readable amount. This is so the programmer can think in convenient terms. You as the programmer/tuner could convert these numbers to your own widget values that only mean something to you.

In my XDF files I include both the raw dec and the converted values.
Any changes that are made in the raw dec are converted in real time. Also it allows you to know what the next step is because at the Dec level you only have 255 choices. this is why small changes to a converted value only step up when you are at the next dec value, there is no in between the dec numbers that the programmer can adjust to.


Any comments?

 

Here is that section in my XDF. this XDF is a modified version of a "Mark Mansur" XDF file.

We build on the knowledge of others and I am most greatful on all who share.

Want a copy of this XDF (complete long version) contact me, it is free and at your own risk (work in progress).

Each conversion in the XDF file is in bold

%%TABLE%%
000002 UniqueID =0xB6
040005 Title ="Open Loop AFR % Chg Vs LV8"
040011 DescSize =0x1E
040010 Desc ="Open Loop AFR % Change Vs LV8"
040100 Address =0x3DC
040200 ZEq =0.390625 * X + 0.000000,TH|0|0|0|0|
040203 XOutType =0x4
040304 YOutType =0x4
040230 RangeLow =0.0000
040240 RangeHigh =255.0000
040300 Rows =0x11
040305 Cols =0x1
040320 XUnits ="% Change to AFR"
040325 YUnits ="LV8"
040330 ZUnits =""
040350 XLabels =%
040352 XLabelType =0x4
040354 XEq =X,TH|0|0|0|0|
040360 YLabels = 0, 16, 32, 48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208, 224, 240, 256
040362 YLabelType =0x4
040364 YEq =X,TH|0|0|0|0|
040660 XAxisMin =1000.000000
040670 XAxisMax =1000.000000
040760 YAxisMin =1000.000000
040770 YAxisMax =1000.000000
%%END%%

%%TABLE%%
000002 UniqueID =0x1D12
040005 Title ="Copy of Open Loop AFR % Chg Vs LV8"
040011 DescSize =0x1E
040010 Desc ="Open Loop AFR % Change Vs LV8"
040100 Address =0x3DC
040200 ZEq =x/2.56-b,TH|0|0|0|0|,TH|0|0|0|0|
040203 XOutType =0x4
040304 YOutType =0x4
040230 RangeLow =0.0000
040240 RangeHigh =255.0000
040300 Rows =0x11
040305 Cols =0x1
040320 XUnits ="% Change to AFR"
040325 YUnits ="LV8"
040330 ZUnits =""
040350 XLabels =%
040352 XLabelType =0x4
040354 XEq =X,TH|0|0|0|0|
040360 YLabels = 0, 16, 32, 48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208, 224, 240, 256
040362 YLabelType =0x4
040364 YEq =X,TH|0|0|0|0|
040660 XAxisMin =1000.000000
040670 XAxisMax =1000.000000
040760 YAxisMin =1000.000000
040770 YAxisMax =1000.000000
%%END%%

%%TABLE%%
000002 UniqueID =0x1B07
040005 Title ="Copy of Copy of Open Loop AFR % Chg Vs LV8"
040011 DescSize =0x1E
040010 Desc ="Open Loop AFR % Change Vs LV8"
040100 Address =0x3DC
040200 ZEq =(x-35)/2.56,TH|0|0|0|0|
040203 XOutType =0x4
040304 YOutType =0x4
040230 RangeLow =0.0000
040240 RangeHigh =255.0000
040300 Rows =0x11
040305 Cols =0x1
040320 XUnits ="% Change to AFR"
040325 YUnits ="LV8"
040330 ZUnits =""
040350 XLabels =%
040352 XLabelType =0x4
040354 XEq =X,TH|0|0|0|0|
040360 YLabels = 0, 16, 32, 48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208, 224, 240, 256
040362 YLabelType =0x4
040364 YEq =X,TH|0|0|0|0|
040660 XAxisMin =1000.000000
040670 XAxisMax =1000.000000
040760 YAxisMin =1000.000000
040770 YAxisMax =1000.000000
%%END%%

%%TABLE%%
000002 UniqueID =0x1ECE
040005 Title ="Open Loop AFR % Chg Vs LV8 Decimal"
040011 DescSize =0x26
040010 Desc ="Open Loop AFR % Change Vs LV8 Decimal"
040100 Address =0x3DC
040200 ZEq =X,TH|0|0|0|0|
040203 XOutType =0x4
040304 YOutType =0x4
040230 RangeLow =0.0000
040240 RangeHigh =255.0000
040300 Rows =0x11
040305 Cols =0x1
040320 XUnits ="% Change to AFR"
040325 YUnits ="LV8"
040330 ZUnits =""
040350 XLabels =%
040352 XLabelType =0x4
040354 XEq =X,TH|0|0|0|0|
040360 YLabels = 0, 16, 32, 48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208, 224, 240, 256
040362 YLabelType =0x4
040364 YEq =X,TH|0|0|0|0|
040660 XAxisMin =1000.000000
040670 XAxisMax =1000.000000
040760 YAxisMin =1000.000000
040770 YAxisMax =1000.000000
%%END%%

 

The bias value is used to set up the lean limit for the Target AFR. In this case the value of 221 decimal represents a lean limit of approx. 17:1.

14.7/17*256 = 221.

For a lean limit of 20:1, it would look like this:

14.7/20*256 = 189.

So if you wanted a lean limit of 20:1 for some strange reason or special fuel.

You would update the value to 189 in the bin at LC419, then adjust the equation offest to use 67 (256-189 = 67) instead of 35 for the offset for correct scaling in the xdf.

No reason to edit the bias value unless you want to target an AFR leaner than 17:1 in open loop

 

Thanks! That makes complete sense. The other thing I didn't figure out is how/where TunerPro defines variables. In the equation: (x-35)/2.56-b, I assume "x" is the current value retrieved. How did it "know" what "b" is?

My first attempt at transplanting the extended bin's x/2.56-b formula did not return the same results when entered in the TP $6E.XDF mask. However, your (x-35)/2.56-b formula did match up.

That means "b" must represent two different variables in each of the masks?

 

I understood the XDF file (aka masks) contain imbedded formulas/conversion so the stored hex values become considerably more readable. Since the field (column) I'm posting about here is labeled "% change to AFR", the units should be listed accordingly. (FWIW, I learned Assembler back in college.)

If no conversion was present, the column should say "Raw Hex value" or something similar. I also understand people can add/delete/alter the XDF for the own, personal needs.

My post here is to point out how, as a novice tuner, I was apparently misled.

 

A quick comment about "the Math" of the conversion formula.
X=25 (the decimal value) can either be converted with:
X/2.56 = 9.76562
X/256*100 = 9.76562
X*.390625 = 9.765625
X*39.0625/100 = 9.765925
All different ways to get the "correct" answer