I'll start with an example, albeit completely fictional.

Say the scanner is reading a MAF airflow rate of 20 gm/sec and a BLM of 140. 140 / 128 = 1.09, or 9% that the 20 gm/sec reading would need to be increased to get the BLM to read approximately 128. On a stock ARAP bin, the gm/sec is as follows:

MAF Table #1
1.46 V, 22.27 gm/sec
1.28 V, 17.69 gm/sec
1.10 V, 13.92 gm/sec
<--snip-->

"20 gm/sec" isn't indicated anywhere on that table. What entry would be adjusted, the one for 22.27 gm/sec or the one for 17.69 gm/sec? Now, here's a question regarding MAF voltage -- wouldn't it make more sense to have a scanner read the voltage, so you could just say "OK, at X MAF voltage it's reading Y, but it's *supposed* to read Z. Let's change that to compensate"?

I'm also assuming that the voltage specified in each table remains constant, but the MAF scalar number just changes the span of numbers? For example, could I have 1.46 V in the first table equal 25 gm/sec (with a scalar of 25 and an entry of 255), or 100 gm/sec (with a scalar of 100 and an entry of 255)? If so, is the reasoning behind changing a MAF table's resolution to tune for more exact measurements (as in my first example; no "20 gm/sec" on the table)?

MAF tables make my head hurt

 

The ECM will interpulate (sp) between cells in the MAF table, infact, the ECM interpulates between cells in all tables.

So, if you have 20gms/sec on your scanner, the ECM interpulated between the two cells which 20 lies between, very simple process.

Now you can attempt to adjust the flow values in the MAF tables in order to bring the BLMs in line, BUT, the problem that I had with this method is that there is a max value for each of the six MAF tables which you can not exceed,,, which totally destroys this method. For example, I believe that the max value for the top cell in MAF table #1 is 23.0 gms/sec (or something close to that). Just try entering 25.0 and see what happens.

You figure out how to enter 25.0 in the top cell (highest voltage cell) in MAF table #1 and get to save, and you will be my hero!!!!

 

Reset the boundaries in the code, to change the cell table.

If you really want to get into it find a hac of the 6E and read thru that, there is nothing you can't change.

 

Bruce is very correct. In fact, you MUST do through the hac and REALLY LEARN how the MAF tables are controlled before you start to mess with them. I haven't checked TunerCat's latest version of the $6E TDF, but there are a LOT of settings beyond the MAF tables that need to be changed in conjunction with the tables.

As for making a Table accept a value greater than the "max" in the top of MAF Table, as Bruce said, you can do it - but you MUST get into the code. If you are prepared to do that, they you can do virtually ANYTHING you want to the MAF Scalar Tables (and do it right).

Just changing the MAF Scalar Tables by themselves is a risky proposition and not for beginners. A few subtle changes in the middle of the individual tables won't cause too much problems but when you start hitting those boundaries, you better know what you are doing.

 

I'm definitely aware of the scalar value that needs to changed, and I have no problem modifying the code without the aid of a tuning program like TC. I'd like to get some answers to my original questions in the first post in this thread:

How do I know what part of the MAF table to change, even if I do know about the scalar value? I realize that some readings fall between two cells, but which cell needs changed? That's why I figured it would make more sense to know the MAF voltage, not the gm/sec, because it seems that the voltage remains constant whereas the gm/sec is the independent variable.

That previous question is predicated on the notion that the voltages in each table do not change when the scalar is changed. Is this true?

 

https://www.thirdgen.org/techbb2/sho...&highlight=MAF

RBob.

 

RBob, that thread is very enlightening. You've really made some things clear for me with the step-by-step explanation of how the ECM determines the gm/sec calculation. One thing that I wanted to know... on step 6 of that explanation, you say that because the table is interpolated, the value of 237 will be retrieved instead of 223 (because 223 isn't on the table). 237 is a greater difference from 223 than 217 is -- why doesn't it go for the closer entry?

You say that you've figured out how all this works just by reading the hack? What about the math involved? I have a complete printout of the $32 hack sitting in front of me and nowhere do I see any sort of logical explanations as to how this stuff works. I guess there are a lot of clues to put together based upon the commenting in the code.

I think I'm definitely going to monitor MAF sensor voltage. It seems like there's a lot less involved if I can get straight to the actual voltage instead of some theoretical calculation by the ECM.

 

i mentioned doing this to someone else a while back. if you know where your lean in terms of voltage and you have a grms/sec to vout chart all one needs is to adjust relevant table entrys. my advice however lead towards $32 $32b. just the way i do things. i listed the chart the thread title was


maf flow chart

the chart is there for the sensor.

 

Thank you, funstick. I found the chart in the thread -- are those values straight from the $32 hack?

I did a little reading on the $32 vs. $6E stuff, and for the most part it seems like the $32 is just easier to tune with the downside of less features than the $6E. I don't want to get off-topic, but is that true for the most part? I was seriously considering going to $32B for the ease of tuning.

 

that one upside.

the donwsides are no IAC learn function that ive seen. no highway fuel mode( which really doesnt seem to offer much )and the cold start injector issues ( which can be handled with the crank AFR and the cold start tables. so all in all there about the same. the $32b does have a highay spark mode. the biggest advanatge is that 3d fuel table. itll come in handy. especially if you have a odd VE curve,.

 

I've had great success. Generally I experience 20%+ increase in gas mileage on the cars I tuned when invoked properly. The key is to have the prom running 128/128. Proms that are not properly tuned will not get the full benefits and possibly decrease gas mileage.

 

Yes, and an automatic car with only idiots lights appeats easier to drive than a manual with full gauges. I like "full control and full knowledge" myself.

Ease of "setup/use" always involves sacrifices. Features and tuning ability being the most common. For a stock setup, this can be fine. Heck, doing nothing is even easier yet. But for modified engines, you will find yourself having to compromise.

I personally find "ease of use/lack of feature" more difficult to tune. I am wanting to "tweak something" and then realize "oh yeah, I can't do that with MAF". Most of the guys I've dealt with find SD easier once they learn it. None of my buddies I've converted will ever convert back to MAF once they realize the full potential SD offers. And I've never seen a SD user convert to MAF.

Just thnk about what you want to do. If you want to keep your car basically stock with minimum of modifications, stay stock. If you want to modify your engine, then I would do MORE research first. Make sure it will take you in the direction you want to go.

 

I agree. I'm planning some more radical things with my engine (heads, cam, possibly water injection) and it's best to have an entire palette of options available to tinker with. I see myself converting over to SD in the future but I'm not ready just yet. I still have a lot to learn about the way the ECM operates and I'd like to learn on what I have before I go making changes. The only thing about SD that I'm leery about is the two methods of conversion -- repin a 730 or use a 165 with 808 code. It seems the 808 way is easier but the 730 offers more flexibility.

 

Regarding the value of 223, that term (value) is used as the lookup argument. IOW it is used to properly locate where in the table the mass air flow value is retrieved from. The value 223 when used for the lookup puts the table position very close to the 8th row. So even with the interpolation the result ends up being the 237 from that row.

If the lookup arg had located the position to be between two rows, then the interpolation would return a value that was between the values of those two rows.

Yes, by reading the hac. Although I am reading the code not the comments.

RBob.

 

what if we change the term to correct for the upper boundry error that the interpolation cuases. i can imagine that they picked that so they would be a tad more rich tne lean ??. any thoughts on that one ?also the $6e idle Iac feature are worthless so are alot of the later idle feature. good fuel and spark timing at idle wont even require them once the iac tables and values are properly adjusted. theres also one thing in the $32b code that theres not in the $6e,room. room for addition etc that could make it better. only problem is that im not fluent enough in assm to make any changes.

 

I assume you've read the various posts on Assembly Language programming. The best I can suggest is to "work" with the code making your own documented version. If you get stumped as to the meaning, just post it and someone (most likely RBob) will be glad to help you.

 

well im still comming to grips with the actuall way the codes works and how the math work inside of it all. sonner or later ill get it all sorted out. but its alot to digest working fulltime and this is a hobby.

 

RBob, could you explain that lookup argument again? I still don't understand why it's going for a number that's farther away than closer. Or, does it just go for the next higher number?

 

Yes, it's a LOT of work. Especially when you have a family and other committments.

 

I'm not sure of your question. The lookup arg (223) is not used as the answer of the lookup. It is only used to locate the proper entry within the table. Here is an example of a 2D lookup being done on a completely different table. Here is the table:

Within the ECM RPM values are stored as the RPM divided by 25. So 4000 RPM is the value 160 (4000 / 25 = 160). On a 17 byte table (such as above) a 16 point interpolation is done. There are also 16 'counts' between rows.

OK, engine is at 4000 RPM (ECM value of 160), to locate the proper row(s) the ECM divides the lookup arg (160) by 16 and gets 10. The ECM will use rows 10 & 11 in the result. In turn the result will be 100 (the 4000 RPM row). Even though row 11 was also used.

Another lookup, now the RPM is 4200 (4200 / 25 = 168), to locate the proper row(s) the ECM divides the lookup arg (168) by 16 and gets 10.5. The ECM uses rows 10 & 11 again. However, when the ECM interpolates between rows 10 & 11 the result is 97. This is a value that is halfway between the row 10 & 11 values.

Another lookup, now the RPM is 4300 (4300 / 25 = 172), to locate the proper row(s) the ECM divides the lookup arg (172) by 16 and gets 10.75. The ECM uses rows 10 & 11 again. However, when the ECM interpolates between rows 10 & 11 the result is 95.5 (ECM will round to 96). This is a value that is 3/4's between the row 10 & 11 values.

RBob.

 

Excellent; I understand the lookup method now. So the table merely defines several "boundaries" and the ECM determines where it needs to be by either having the same value as a "boundary" (as in the 4000 RPM example), or by mathematically determining between "boundaries" (as in the 4200 RPM example). I guess they did this to save space so they could stuff more code into a chip, instead of accounting for every single RPM value (in this case)?