MAF table dialed in!!! *Tune almost complete!

[pknowles]

I changed my RPM boundries and it seemed to help my trimming too. Seems like there is some kind of average trim it uses for the big cell defined by the boundry and small adjustments for each cell. I see a significant changes in the trimms between the boundries. I reset my boundries to isolate idle which dragged all surrounding cells negitive that where in the same LTFT boundry. Now without touching my VE table, just changing the boudries, some low load, medium RPM cells that where around -5 are now -1.

[MNR-0]

Knowles and Snakes I believe you. Have seen that myself. On a CAMMED car I probably would change the RPM boundaries. But I would log the MAP vs RPM and determine the RPM that lies at each MAP boundary. That to me seems the logical way to rescale as the engine is telling you how it wants to perform.

CAMMED cars will lose dynamic compression down low so it makes sense for the same MAP you have a higher RPM.

[redhardsupra]

where do you set the boundries? i can't find them :-[

[MNR-0]

Since fixing the pinhole leak in my MAF pipe my trims have stabilised again. However, I tried increasing the RPM boundary for kicks. It is found under "Fuel - Closed Loop Feulling - RPM boundaries".

Since I now have even resolution via the Airflow Tables I wanted even resolution for the RPM - I just fitted 3.73s. Well, you were right, the LTFTs evened out even more. I added 800RPM resolution for each cell. Initially my boundaries were:

900
1400
2200

now they are:

1200
2000
2800

[redhardsupra]

I created a spreadsheet that does the whole MAF calibration automagically, please take a look:

http://www.allmod.net/hpt

[cured5.7]

redhardsupra,

That link appears to be dead.

Regards Mark

[redhardsupra]

i just tried it from few different computers and it seems to work fine, try
http://www.allmod.net/hpt/automafver2.xls
for a direct download of the file, see if that works.
Marcin

[JimMueller]

I tried the spreadsheet and these are the bumps I encountered:

- If I highlight the result airflow values and paste them into the Editor, I don't get the same values.

- It assumes you are using imperial units, even though you can select metric units in the scanner as well. Just a bit more work to convert it again.

I used my older 18K log, and a brand new 27K log trying to see if my MAF table needed to be corrected. I used the Dynamic Cylinder Airflow PID and the MAF Frequency PID's. Above 3000HZ both curves seem to exactly fit my stock curve. It's hard to get any data below 2650Hz.

Sooo... if I've modified my intake tract (lid & filter), why is this not working for me? ???

Edit: Dang it, I need to be in SD mode before logging this, don't I? I forgot to load my SD tune.

[redhardsupra]

yes, car needs to be in SD mode, as per point 0 of instructions:
0. PUT THE CAR IN SPEED DENSITY MODE!

you are correct, it does assume imperial units.
simple way to get around this, is to divide your airflow by 7.55987283333333, or do the same thing to the results.

there can be multiple reasons why you don't get the same values after you paste them into HPT editor:
1. different number of decimals displayed
2. you don't wanna highlight the cells for which you don't have results for (all the ones with DIV/0 error in them), as that's not gonna paste into the editor. highlight and copy the range with real values in them, and paste it onto your preexising calibration, just make sure you paste them for corresponding frequency values

hope that helps

[cured5.7]

Redhardsupra,

That worked fine thanks

Mark

[redhardsupra]

I put up a new version, should be slighly more precise, and is able to handle up to 65k samples. check it out

cured, did it work well for you? care to share more details? i'd love to hear more user feedback.

[cured5.7]

Redhardsupra,

Downloaded the more new and improved version, thanks....

I have'nt had any time to play with it yet, too much work at the moment...

as soon as i do and get to put a maff modified tun eon my dyno i'll let you know how it went...

Regards Mark

[txhorns281]

I put up a new version, should be slighly more precise, and is able to handle up to 65k samples. check it out

haha... good good... I went for an hour cruise yesterday and I sampled about 35K. Tried to use it but was too much... Of course I have the original version. Was gonna let you know but you're already on top of it! 8)

[SideStep]

I put up a new version, should be slighly more precise, and is able to handle up to 65k samples. check it out

cured, did it work well for you? care to share more details? i'd love to hear more user feedback.

Another question....

from your spread-sheet...


[glow=red,2,300]"1. log for Dynamic Airflow and MAFHz"[/glow]

Do you mean log the "Dynamic Airflow" (lb/min,g/sec) PID???

OR the

"Dynamic Cylinder Air" (g/cyl) PID???


??? ??? ???

Thanks

[JimMueller]

I've been using Dynamic Airflow (lb/min). It matched my stock MAF table when I accidentally logged w/o being in SD mode.

[redhardsupra]

yes, Dynamic Airflow is the one you want to get. The better the calibration, the better MAF(SAE) should be closer to DynAir. right?

[JimMueller]

OK, something doesn't seem right. My SD tune is based upon SnakeEater's write-up. When I have the MAF disconnected, my AFR reads ~13.x. With it plugged in, it reads stoich.

If it was really in SD mode, wouldn't my AFR be reading low 13's (assuming I've been working on the VE for awhile) even with the MAF connected to log MAF Frequency?

Also, since I don't recall the steps, which part of his write-up do I change to use the MAF Fail=0 version of SD tuning? Do I need to zero the MAF table as well (as indicated in other threads)?

*goes off to validate my SD tuning tables are what SnakeEaters write-up says...*

[MNR-0]

If you want them to align with the MAF TRIMS then you shoudl tune the VE at stoich, not 13:1. The reason you tune at 13:1 is so if the MAF fails (rarely to never) you don't risk damaging your engine when failing over to SD mode.

[JimMueller]

Where's the version which supports more than 30K rows? The only link I still has references to the 30K row limit on the Calculations sheet.

Also, would it feasible to put some validation checking on the values? Say if I've got 10 rows of 34-35.x, and a single row of 29.x in the same range - it average ends up being too low to create a smooth curve.

How did you handle frequencies which are difficult to log (<2500, >9000, etc)?

I see what I was doing wrong on the pasting. The Airflow row was set to 5 places, and the table was set to less than that... so when it was pasted it looked like there wasn't a decimal as the field is apparently right-justified.

[redhardsupra]

Where's the version which supports more than 30K rows? The only link I still has references to the 30K row limit on the Calculations sheet.

Go back to the site, 2.0.1 awaits you

Also, would it feasible to put some validation checking on the values? Say if I've got 10 rows of 34-35.x, and a single row of 29.x in the same range - it average ends up being too low to create a smooth curve.

The idea is to let large samples speak for themselves. The only 'validation' I do is when I import the data from hpt->csv->excel, I sort by frequency, and I sometimes get few 0's, which get deleted. Given decent amount of proper data, the one bad one will effectively become 'numerically ignored.'

How did you handle frequencies which are difficult to log (<2500, >9000, etc)?

That's the one area of this whole process that really doesn't fit the Excel way of doing things. But on the other hand, my thinking is that if I never stumbled upon certain values when testing (aka pushing it in all directions) then I should never encounter it during normal operation.
But for these who absolutely _must_ have the complete calibration (I know I do ) here are the directions, which are identical to how I do it the 'old way', as described it in my writeup:
1. Plot a XY graph of freq vs dynair
2. Plot a 3rd degree polynomial best fit through it.
3. Display the equation for that best fit line, with maxium precision.
4. Use that to determine the points for which you have not been able to obtain calibration empirically.

This method have been tested twice already, seems to work fine, but don't go crazy believeing the machines

Hope that clears it up, I should probably put that in my writeup now. Ugh, more typing...