I've been tweaking the MAF tables looking for my 128s. Progress overall has been pretty good.
Every once in a while I'd open a prev modified table and find the top value had dropped down a significant amount. Thought maybe it has something to do with the values overlaping from table to table. Tonight I can't get the 3 top values in table #3 to stay where I put them. I'm not exceeding the lowest value in Table #4. I'll modify, save,re-open, and they are back to where they want to be. I'm using gmecmedit V2.0

When I tried using Winbin, for some reason MAf tables 1-5 seemed whacked. They all go up to 255 g/sec, even table #1.
Table #6 is the only one that looks like it may be OK.

Anyone seen this before?

 

At times I just take to editing things in hex.
Then recalc the checksum.

 

Hi.
Have you tried downloading the newest version of GMCEDIT? The one that you are using might have a bug in it.

 

yes, bug. get the latest version. (as even bruce can testify to - all good things take time to develop! over time, things get easier and better.)

 

Downloaded the newest version of GMECMedit.
Still having the same issue with the top value in MAF table #3, but now I'm even more confused.

If I select "calculated values" in the preferences window of GMECMedit, the top value in MAF table #3 is 82.8 g/sec.

If I select "raw hex" in the preferences window, the top number in MAF table #3 is FF.

Using a program called "Master Converter", the "FF" is equal to 255.
(Just like it shows in Winbin )

What's going on here??

 

Most likely the scalar for that table is set to 82.8 g/sec. That would make 255 82.8 (or there abouts) g/sec.

I think Grumpy's sticky post explains MAF scalars. There is another thread where I posted all of the MAF math. Search for MAF & KVU & RBOB.

RBob.

 

email me the bin and the ecu (mmansur at hotmail). i'd like to check this out.

 

Rbob>
Don't know a lot abt scalers. Guess it's time to learn. I was thinking the scalers only had to be modified if your eng's airflow exceeded 255 g/sec on table #6.
It would explain why I can't exceed 82.8 g/sec though.

I was trying to adjust the 82.8 to 93 g/sec to address high BLMs (140-142) during moderate acceleration (30% TPS from 40 to 80 MPH in OD).
I tried to adjust the "Power enrich VS temp" table and the "Accel enrichment factor VS change in LV8" tables but they seemed to have no effect.

Considering resetting the MAF tables back to stock and enabling the "BPW fuel VS Load" table, but that would mean starting all over again.

Mangus>> You have mail..

 

yeah, i'm taking a look. I can verify that the problem with MAF table 3 exists, and I'm looking into a solution. I have a feeling the problem is with the ECU you're using. I'll get back to you.

 

found your problem. Open up your ECU in notepad (or the text editor of your choice) and scroll down to table 10:

/* Table 10: Power Enrichment vs RPM
/*ylabel =RPM */
{
/*startAddr =622,
/*columns =1,
/*rows =17,
/*elementSize =1,
/*bitMask =0,
/*offset =-100.000000,
/*mulOrDivOrBit =0,
/*factor =0.781225,
/*map_name =Power Enrichment vs RPM
/*ylabel =RPM,
/*ylabel = 0 400 800 1200 Percent Enrichment Sub,
/*yaxis =Percent Enrichment Sub,
/*xlabel =,
/*xaxis =,,
};

This is all wrong. for one, you have two ylabel fields. You have another ylabel under the commented table title (which doesn't have a close comment ' */ ' itself).

You also have an invalid yalbel (the second one - "Percent Enrichment Sub" does not belong there).

This is causing major problems. Delete/Fix this object within the ECU itself and everything works fine.

I have no idea how this object got so corrupt, but it is very likely that it happened as a result of importing a poorly written ECU to begin with. I'm working on adding code verification as ECUs are imported.

Also, 255 is exactly correct for the raw hex at the top of MAF table 3. 255 converted comes out to the correct value (82.80).

Mark

 

WOW! With the PE VS RPM table fixed, it looks like I'm back in business!
Time to burn some more EPROMs

Thx Mark!! Awsome job!

 

If you want to change the 82.8 g/sec value higher and that value is the scalar value, you first need to increase the scalar. A side effect is that this will change every g/sec value in that table.

Every g/sec value will change because they are based on that tables scalar value. Changing the scalar is a global table change.

So, snap-shot the g/sec value of that table (for every row), increase the scalar, then re-scale each row to where they were. Now change the top entry of the table to were you want it.

RBob.

 

Doing some searches of old stuff and I ran across this and kept thinking about one thing. If you’re using something like Magnus’ software and change the scalar in the bin that you’re modifying and it changes the maf table values, what happens to the “compare” bins?

If they still use the scalar applied inside themselves, then you could very easily make a second copy of the bin you’re modifying, open one as the one that you’re editing and open the second as the compare file, change the scalar to whatever you want and then use the toolbox function to copy “value from compare” to put the values back to what they were before you changed the scalar, and then you can go and fix the tops of the tables rather harmlessly and quickly.

What would be really sweet is if this was all linked together, so in editing all you saw was one big table and graph showing all the tables and the scalar (essentially the limit) for each table got automatically adjusted to whatever was needed to allow the highest values in each table.