kvu

Forget the last one,big misunderstanding.No more profanity,did'nt mean to... anyways.I have experienced alot adjusting the maf tables.My motor will be rebuilt in a year so the testing did'nt matter.I don't have no noticable problems,engine wise.So I think it payed off.I know by heart what count(s) is for the highway,idle and EVERYTHING.But I have taken Grumpy's advice.Started from scratch and not modded the maf tables. Now this is where I'm at.Ok,now what to do after all that for some rich spots (117-123blms) and one lean spot?The only positive response I've gotten was modding the maf tables VERY,VERY slightly.Another question,is having a steady 128 integrator better than a fluctuating int?I know the int is secondary to blm.My last question,could someone explain why my scan tool reads the same gr/sec @ x load regardless of what I do to the maf tables?There is 4 questions,my best shots for help.

goneracin

KVU, I have the same probs. I am slowly getting my idle to come away from lean, but my part throttle cruise goes rich. Trying to work with the inj size, and the batt voltage to get everything squared away. I think the only way I see to get it perfect, is to use the maf tables to bring idle more in line when the part throttle stuff is good, but Im trying not to. I also have another question. No matter what i put in for timing curve, i get alot of knock counts, and quite a bit of knock retard. Even at part throttle acceleration, i get retard. On the knock counts, mine will not return to 0. If they go to say 42, it will stay ther till it gets more counts, then it rises to say 65, etc. never comes to zero. is this normal?? Also, why do i get so much retard??? Im sure that with just the part throttle acceleration, its not detonating, esp with the very light timing curve in it at the moment. Can a knock sensor go bad, and give a knock too easy???

slowTA

iTrader: (1)

I have the same lean at idle and rich at many other places problem. Right now I have my injector constant very low and fuel pressure very high so it wont go too lean at idle, but BLMs still go to 160. So once I get the idle squared away I can fix the injetor stuff and maybe get a normal part throttle. But I can't get the idle right at all. After fixing a vacume leak it still goes to 160 at idle. I just don't get it. I have modified the MAF tables and still nothing. I used kvu's suggestion even though he doesn't use it himself anymore. I can't change the battery correction table because I don't have Tunercat, but I do have GMEPRO and WinBin. Any suggestions??

goneracin, I know this isn't what you want to hear, but I would check the exhaust. My y-pipe was hitting the oil pan and I would get an annoying amount of knock retard. You may also want to check where the exhaust comes close to the frame.

goneracin

slow ta, not a bad idea checking for rattles. maybe something is hitting. As far as the batt correction goes, winbin does have a table for it. Its called "injector pulse width vs battery voltage. Its in the 6ev009.ecu file a few down from the maf tables in the arrays section.

Grim Reaper

If you can get your BLM/INTs within +/- 5 of 128 (consistent 123-133 in part-throttle), consider it tuned and tune for WOT (with the aid of a WB).

Trying to obtain 128/128 perfection with 3rd Gen MAF is like trying to have "20 decimal point precision when you only have 2 decimal significant digits". You have precise imperfection. Too many variables will affect it to make it imperfect.

Has anyone noticed that you can tune it perfect for the summer, and then notice its "off" during winter? This is why Bruce, RBob and myself have been "harping" on getting into source code (lots of stickys to point you in the right direction). You would be far better off to create source code...trim the stuff you don't need (because the BINs for 165s are so tight) and then build some REAL MAT correction.

drive it

iTrader: (1)

OK, here goes my method....
I've gutted my maf so yes it's changed airflow....
I've changed my maf tables as needed to get 128 blm....
Now before anyone says how wrong I am-yes it's a big lie to the ecm-but GM lied too! And if you plug in a bigger inj. and inj. constant on an 8D that's a lie to the ecm also!
I change the inj. constant first to get the majority of the blms at 128-especially the upper gps/cell 15; then adjust the lower maf tables as needed to obtain 128 blms.
Now the difficult(?) part; you must have a wide band to do this! I then use the wide band to adjust the open loop F/A ratio. Then recheck the blms and adjust the maf as needed again.
The it's time for the lv8 related tables....since the 6E code calculates the lv8 and there is not a table in there that we can adjust.
For example-"pump shot" uses lv8-but if you use a wide band you can then adjust the lv8 accel enrich factor vs delta lv8 to obtain your ideal F/A ratio for that condition. Also the min delta lv8 for accel enrich-adjust as needed to get the best F/A ratio for your engine.
Using this method you end up with a "correct" end result-F/A ratios.
But yes it's not "correct" because I'm lying like a bad dog to the ecm!
I do make sure that my maf tables are the same where they overlap; end of table one is the same as beginning of table two; however I've tried it otherwise and didn't notice any difference in drivability or F/A ratios! I'm sure if you tested it on a bench you'd find "spikes" though.
Anyway this works for me-perfect-no; but "real world" it works just fine!
On a side note on my combo-after I adjusted open loop F/A ratio % change vs coolant temp and got that dialed in I then checked with my wide band for the open loop F/A ratio % change vs load-and I didn't need to touch anything in that table!
So this is my $0.02....Later

Grim Reaper

The difference is the EFFECTS of the big lie. That's the crux of the problem when you do the MAF tables - or so you will discover if you ever study the "hack". Altering Injector Constant has a heck of a lot less affects (other than the intended effect) than touching those MAF Tables. And that's whats being pointed out...touching those MAF tables affect a whole lot more that other changes - they have MANY indirect effects. The Injector Constant doesn't affect spark...but the MAF Scalar tables do.

Also NO ONE has ever pointed out the "MAF Scalar pointers" at C5B3, C5BE, C5C9, C5D4, C5DF and C5EA. I don't even believe TunerCat has defined those variables WHICH MUST BE CHANGED it you modify the top part of the MAF Scalar Tables.

People REALLY need to work with the actual code, and not just the tables. Right now, you are all "lit matches in dynamite shacks"...you are ALL dangerous enough to blow yourself to bits. You need to read the HACK because it's your Safety Manual.

Again, around and around we go...with NO ONE reading the actual Source Code to find out WHAT'S REALLY HAPPENING. That's why I've refrained and will continue to refrain from speaking on this subject anymore. It seems you're all waiting for a "popularity contest" to decide it. Bad way to tune IMO.

So, YES, change those tables all that you want; you have my blessings. Have a smoke while you're at it. But until someone starts reading the hack and figuring it all out, your all dangerous.

Grim Reaper

And the irony is...it's imperfect and if your temperature, elevation or humidity changes...all your tuning is for not. Your striving for perfect imperfection.

slowTA

iTrader: (1)

goneracin, thanks for the info. I was stil using the 89v3.ecu file in winbin. I downloaded it and found the right table.


Glenn91L98GTA, I'm sure you know what you are talking about... but I'm not on top of source code and from what I read I'm not the only one. I have seen some of it along with the hacks, but I'm lost when it comes time to figuring it out. So why don't you try to explain it to some of us instead of telling us not to touch anything because we don't know what we are doing? When people talk like that I can't help but think of the guy at the parts counter who says that everything you buy for your car has to go by the VIN, year, make, yada yada yada.

Better yet tell us where to read up on it. A link to THE page would be great. I hate it when people say to go search some of these websites that don't have a search feature, you have to sit there reading everything line by line. To top it off most of the stuff out there is for MAP computers, not MAF!! I doubt alot of us here has the time and more importantly the patients to read through piles of e-mail that aren't even labeled as to their contents.

I'm not saying that these sites are useless, I just can't deal with them. That's why I'm here! They have a search feature, it's the best thing since the wheel! Also, I'm going to school for mechanical engineering, not electrical! These chips are greek to me, that's why I need tables to modify not hacks or codes.

I really don't mean for this to be a flame but I'm getting frustrated with this MAF already. The last thing I need to read is someone telling me that I have to learn a computer language to add more fuel to my motor at idle.

So where is the link to the hack that you talk about so much?
Give me the source code to read in something resembling English, because I'm not diving in there alone.

goneracin

Slow ta, I think everyone is talking about the BUA hack for the 165 computer. I have found it on the web, and have been reading thru it, trying to make sense out of it. It is very confusing to me also. I have some mech engineering, and build pro-stock engines for a living, but do not understand alot of the computer "language" .
Glenn, Thanks for the info on not trying to get 128/128 all the time. I was wondering about that, as alot of variables will effect the maf.I would be seriously interested in the source code thing, but I am not that good with a computer to understand it, therefore am scared of it. I would kill to be able to add a fuel vs rpm vs load or some such thing. I have used the fp fuel injection, and that was sooooooo easy to do whatever you wanted (of course its a map, not maf) eg just add 3% fuel and it did it. MAn if only mine was this easy. If there is someone or somewhere it is more in "laymans" terms, I, and many others I'm sure, would be very interested in it. As far as the maf tables go, I am sure that is not the best way to do things, and I have read where you give certain addresses for changing the scaler pointers. Where do you find those to modify them??? Obviously winbin and tc dont have those points on their programs for easy access. I am definitly wanting to do this the "correct" way, and am willing to learn whatever it takes, as I am very much "****" about the right way to do things, I just would like to have something explained in a more "non-computer guy" way.

Frank88

Just my $.02 on this topic...

I've been able to get a satisfactory (for me) tune by changing injection constant which got most of my BLM's close to 128. I'm most concerned with cells 14,15 as that's where I tend to be when PE engages. My thinking is that the ECM will tune for 14.7 under part-throttle conditions, and that's what it's supposed to do, so it's not a big deal if your BLM's aren't perfect, as long as they're not way off. I haven't made PE changes as I don't have a wide-band O2 sensor. I don't understand the hack that well either but (so far) my changes have made sense for me with my stock engine.

FWIW, using the 32B mask, WINBIN shows a table called "BPW Fuel Vs. Load (msec)". This shows rpm from 0 -> 6400 and load from 0 -> 256 gm/sec. with fuel changing from 0 -> 11 msec. I haven't changed this at all and don't know if the other masks show the same table, but after I start modding my engine (and get a W/B), I'll probably play with this table if necessary.

kvu

First I'de like to say sorry glenn for the misunderstanding.

I'm not going for popularity,actually I just ask 4 questions here.Please slice through the fuzz and check those 4 questions out.I've done alot of research and need help interpreting bits of it.I would like to share it someday.

I'm not talking about big lies but minor changes.In fact I could post two bins one w the stock tables,one that got me 128 at idle and most other spots.I would like to share my maf tables for people compare the mods and tell me the effects on lv8/sa.I think you'll be suprised at the minor changes.

I understand that,and not trying for that.It's a valid point to put out there.

I have brought something about that up in a post.But I have never modded the last 2 tables.

I'm not worried about that.I can burn a chip for four seasons.I'm getting into the source code,a bit at a time.
deposited
I have studied the bua hak for hours and understand more than i though I would.I'm talking about very minor changes.


Here is the 4 3 questions so you'all don't have to scroll up.Also to keep this post focused.Like I said I can get 128/128 everywhere w/maf tables after all other tables are done.But that is not the point of the post.Keep in mind I am not biased towards maf.I will be switching to sd in a week or two.

drive it

iTrader: (1)

Ditto to slowta-how 'bout some answers then, instead of the I won't discuss it further??????
And sorry Glen-no dis' meant, but the comment about dangerous enough to blow yourself to bits! Give me a break!
The folk who try to tune wot with a narrow band do have the potential to melt a piston-but if you use a wide band.....come on!
Yes, you can have drivability problems till it's dialed in......but lit matches in dynamite shacks......
Yes I agree maf isn't perfect! But my buttometer sure can't tell the diff. in real world driving, and I doubt most butts could....
Tunercat has always been more than willing to add tables for us "hack/programming challenged folk"; so tell us what those critical maf scalar pointer tables are, what they do, and what happens if you don't change them to match the maf table changes?
Any usefull info greatly appreciated!
(And yes, in the future I'm looking at map, but for now it's maf!)

kvu

I guess if you a/f ratio is right then it's ok to change the maf tables, checking af ratio with w/b.

kvu

My last question,could someone explain why my scan tool reads the same gr/sec @ x load regardless of what I do to the maf tables?

HighHopes85

kvu-It is kinda hard to follow all your posts when you start the topic off with a snippet from a different topic. How about either using a link to the topic in question or actually give credit to the person who's snippets you are taking. I could follow it better that way. TIA, -Matt-

Killr TA

yeah

P J Moran

I haven't commented in awhile, but feel compelled to jump in here with a question or two.

Mass is mass. The MAF sensor measures mass. Why does elevation matter? The air is thinner, the vacuum is lower, and the mass of air coming in under a given situation is smaller. But the MAF sensor knows that! It measures less mass. Why is the calibration off? Has it more to do with the TPS than the MAF sensor? It takes more throttle opening to get the same airflow at higher elevations. Isn't the MAT sensor used for temperature corrections? Now, as for humidity, I don't know how that figures in. We do have the O2 sensor, block learn, and integrators, you know.

And where in the h.e. double-toothpicks is the hack that "everybody" seems to have their hands on?

What am I missing, here?

32V_DOHC

Mass is mass. The MAF sensor measures mass.

Nope the sensor output is indicative of heat drawn from a constant temp wire.

Why does elevation matter? The air is thinner, the vacuum is lower, and the mass of air coming in under a given situation is smaller. But the MAF sensor knows that!

No it does not. It does not know anything. It only indicates how much current it takes to heat the wire. The amount of current is determined by the temp differential between the "fluid" and the wire, The speed of the "fluid", the amount of heat required to raise the temp of the "fluid".... With more elevation the "air" must move faster through the sensor which would cause the sensor to use more current than the same mass flow rate at a higher pressure. Changing the air temp has the same effect. the larger the difference between the air and the wire the more current it takes for a given mass. Humidity changes the amount of heat required to raise the air temp. This is because water takes much more heat than dry air.

It measures less mass. Why is the calibration off? Has it more to do with the TPS than the MAF sensor? It takes more throttle opening to get the same airflow at higher elevations. Isn't the MAT sensor used for temperature corrections?

TPS is used to determine pump shot and power state. IAT is used for EGR. That's what Glenn said about needing a real IAT.

HTH

John

Grim Reaper

32V, you've explained that so beautifully, I have a tear in my eye.

That's precisely why the MAF (as installed on 3rd Gens) is not "perfect". It is using a relationship based on the cooling of a heated wire to measure air flow - it doesn't actually measure the volume of air. The relationship is good, but it's not perfect - and it's the changes in elevation, ambient air temp and humidity that "skews" the relationship.

Hence, my conclusion that if you are reasonably close to 128 (say +/- 5) considered it "tuned" because elevation, ambient air temp and humidity is going to work against your perfect 128/128. Besides, this is often a heck of a lot closer than GM ever had it.

And when you start tuning for WOT, just tune the PE tables with the aid of a WB O2 sensor and your BIN will be tuned better than anyone else can do without having actual "hand's on access to your car".

Just realize that if your are going to change elevation for any lenght of time or the air temp/humidity has changed due to the time of year/season, that you may have to "tweak it" if you want "optimum performance".

Heck, before I found the MAT Correction Tables for the $8D SD Bin, I was quite prepared to have a "summer" and "winter" bin for my car because the differences were so pronounced.

kvu

Now what if I get 128s,is that a bad thing?Here is my bin that will get me that.I'm just wondering if tuning for 128s and staying in the same elevation on a neutral weather day would be bad.I think the rift between me and grumpy might have been bc I live at a higher elevation and could not get my cal right.I guess that explains the skewed results I was getting.

Grim Reaper

Oh, here is a link to an article by Johnny H. from GMHPP Mag regarding Magnum TPI where they ran a test WITH and WITHOUT a MAF to determine who restrictive a MAF is.

https://www.thirdgen.org/techbb2/sho...hreadid=115686

Grumpy

there are other quotes, reguarding that, loss do to a MAF. In a none magazine environment, a GN showed a 65 difference at 700 HP. Which just seems a little more believeable. The cork seems larger as the bottle grows. Making 2x the HP of the oem setup, dugh, ya it's more of a resriction.

That article looks more like and ad for an Accell 7 system then much of anything else. On thing about these dumb old GM ecms, the support for them just doesn't stop. Unlike some of the aftermarket stuff. A friend has several MOTECs and was just told it'll cost as much as buying a new one to get his old ones updated ($3,500 each). Then on another board is a guy wheeping about having an old ACCEl and no software, or cables or place to get them.

Like I've been saying for YEARS now, you want a go quick in a III Gen, wire up a 730.

Get the source code straightened out, and the aftermarket has nothing on the old GM box till you get to 55#/hr injectors and have to switch drivers.

P J Moran

OK, we're getting into semantics, here. I realize what the sensor actually does. I was speaking effectively. Because of the current needed to maintain the temperature, It "knows" how much air is flowing past it. Yeah, the ECM actually calculates that, but you see what I was saying. I was trying to keep it simple.

But I'm still not sold on the elevation thing. Because there is a lesser pressure differential, the air flows past slower, not faster. And, the air is thinner. Both of these factors give it a lesser cooling effect. Less current is required to maintain the wire temp, so the result is a lower mass reading. It's self-correcting for elevation. Right?

It would seem that it is self-correcting for temperature, too. Humidity, though, I'm not so sure about.

Grumpy

There is alot going on in the intake tract if you were just measuring the thermal losses of the wire it would be one thing, but your not.

The air isn't steady state in the intake. It fluctualates, and is full of eddies and swirls, never mind REVERSION.

The MAF only does a rough estimate of what's going on, that's why there is so much filter in a MAF code. It's also what leads people to think it learns or compenstates for changes better then a MAP system.

The closer you get to taking you load calculating data to an intake valve the better you final results will be.

Grim Reaper

It is a pity they didn't try using a 7730 and "tweaking the eprom" as a third alternative. I really wish SOME magazine would do an article on "eprom burning"...

From reading John's post, I got the impression that all tests were done with the Accell 7 and ran it with the MAF installed and uninstalled to see how much the MAF itself restricted the air intake. I was just kind of shocked on the HP difference.

tpi_roc

Glenn

I imagine magazines haven't picked it up because there's no "All in one" prom burning package with an idiot interface. That and im sure digikey or Xtronics didn't sponsor the magazine.


Magazines dont do the shady tree mechanics articles they used to, now its all monatarily motivated.

However, you could probably get someone like 2600 to do an article on it.

Grumpy

Watch the ads when they look for writters, the first thing they want are literary majors. Swinging wrenches is hardly a literary art. It's again about being PC. Marlan Davis to some extent at least tries to grasp what's going on, but the McFarland and Yunick type writters are all gone.

Mike Pitts post the difference years ago in the GN community, some times need to ask the guestion to get the answer. I do believe I mentioned it in one of the final answers, but since it wasn't in HotRod Magazine it wasn't taken as being true.

Unless the mags get some wake up calls, hence my reply in the TPI board they will just continue to slop off things from the trough.

And I get flamed, go figure.

tpi_roc

Imagine how you came out though to some innocent fool just trying to get his post on


You came in swinging pretty strong unprovoked.

goneracin

KVU, what bin is that based on, the 1 you posted. Is it an arap bin with a different timing curve or??????? thanks
Bob

Grumpy

Again with the PC stuff.
Uncle
Swinging?, geesh just having an opinion is swinging?.
Scares me to think of what you'd have to say about the language used in a stressful condition, or in frustration.

If I'm not impressed, I'm not impressed.
You might just be tickled to death, with the idea of trowing money at a project. Kind of a different strokes thing.

Just remember the money end of it when it all gets to be about $2K ecms, and having tuners actually spin the dials to tune your ride in.

tpi_roc

Well Grumpy at any rate, I like ya man.

At least we know he's not sitting over there wondering where your nickname came from right?

Grim Reaper

I have to agree with Bruce on this one. ANYONE can be fast if you toss enough money at it. I am from the old school where I am impressed by the guy who went the fastest with spending the least amount of money....and not be ripping off his buddies by scabbing parts for virtually nothing.

It's a lot like tossing a 400 HP shot of Nitrous on a stock 3rd Gen and then bragging how you ran 12s (once). Big deal.

Had Johnny done all of his fancy testing with a re-programmed 165 and 7730, then I would have been quite impressed. Johnny stated the EASE of using DFI, but did he EVEN LOOK at the ease of programming the stock 165 or 7730? All of us who have programmed eproms for the last 6 months using bin editors like TunerCat know that making changes IS NOT rocket science.

Generally, the most difficult issue is overcoming some "picky" driveability issue that has been bugging us since the day we bought our cars (or made a major mod).

Magazines make money two ways, selling magazines and selling advertisement. Yes, the ACCELL unit is going to bring in more advertising revenue, but I bet that if they did a magazine article on burning eproms, they'd SELL more. (And ultimatley, that brings in more advertising in the long run). Guess I'm too much of a "bean counter".

hectorsn

Yeah, he mentioned a lot about ease of this and that. Well if it was so easy, he should have been able to do it all himself and not have the car taken from one shop to the other. Quite frankly, to me it's not about the money. When I want something and it costs $'s, I get it. But if something works as well or better for less, duhh..... The thing that bugged me was that he just wouldn't say that the factory ecm had a chance at working. It was a no brainer, bam, DFI 7.0. Did he even look at what the factory ecm is capable of?

Damn, I feel bad for KVU, this thing has gone way off topic.

kvu

It's not a bad thing,I think people has cooled since my last post.I'm glad nobody hates me .I'm not going to even comment on some idiot that running two ecms for no reason.We are real engine tuners here.The article only showed the possibility for restrictions by using maf.Thing is I know the maf itself can be a restriction.But the ducting to get a maf inline is what kills power on more milder setups.

Let's get back on topic though.One thing is that I have been led to believe the maf scalar tables THE conversion table from vdc to gr/sec.I took the maf table 1 and put all of em to 0 gr/sec.Then drove around checking the gr/sec readout thruogh aldl.The gr/sec was the same before and after on my scan tool.To me this apears to mean the is a seperate conversion table from vdc to gr/sec.I could tell you what I think this means.But I would like to hear what yall think.We'll tackle this one first.

RBob

iTrader: (1)

I've been staying away from controversial subjects. However, I
just might be able to provide some MAF code insight. In studying
the $32 BUA hac the scalar tables are used for calculating the
gms/sec airflow. This is the value as displayed by the ALDL.

There are also minimum and maximum gms/sec values that are
applied after the calculation has been completed. The code goes
something like this:

According to an option byte either read the analog or digital
MAF and save a raw MAF air flow value. If there is a MAF
malfunction calc the gms/sec term from tps & rpm, then skip the
rest of the calculation.

(edit: with no MAF malf reported, code continues)

The appropriate scalar table is then selected and a lookup is
made. This value is then added to the values from the last
4 lookups and divided by 4. This is a rolling average function. In
the code it is called a sliding filter.

This value is then tested against a minimum value. If less then
this value the gms/sec term is set to this minimum value.

This value is then tested against a maximum value. The maximum
is from a lookup based on RPM. If the calculated value is
greater then the max allowed by RPM then the max value by
RPM is used as the gms/sec term.

Otherwise the calculated value is used as the gms/sec term.

HTH's

RBob.

RBob

iTrader: (1)

I just went through the $6E mask (IE: ARAP) and
discovered that the code is basically identical
to the $32 code. The only real difference is
that $6E only supports an analog MAF.

One significant discovery that I touched on in the
previous post is the use of a max gms/sec vs RPM
table. Both $32 & $6E use this table.

What it means is that no matter (sic) what the MAF
is reporting for air flow, it will be max limited
to the values in this table.

Here are the table values as in ARAP:

As you can see at 4400 RPM the maximum possible
gms/sec airflow will be 236 gms/sec. Folks running
MAF 383's and larger may want to keep this in mind.

RBob.

kvu

Is there any support for that table in the bin editors yet?I have a 400 and I'M going to check that.But how to tell what the actual gr/sec my engine is consuming.That is since the aldl is not showing raw gr/sec from maf.Also does anyone know why my scan tool showed the same gr/sec regardless of maf tables?

jwscab

interesting.....that means that for larger cubic inch engine that max the MAF at lower RPM, you could change those max values to 'recurve' the table to match more cubes, obviously though, you would max out faster, so more of the entries would be 255, and you would have to rely on the other PE vs RPM or whatever that is called to compensate. Is that a correct assumption?

Grim Reaper

That's the way I read it. This is probably why a number of guys say "Why is it that my 383 never exceeds 236 gm/sec at a certain rpm", or "I am not maxing the MAF past 236...Thus I am not hitting 255 and have room to spare".

Thanks RBob, I think you've answered a lot of questions for some of the MAF guys.

Guest

Edited my reply eh? Fine.

drive it

iTrader: (1)

Hmmm, I just checked a diacom log.....and havn't changed the "mass air flow vs rpm (diag.)" table.....at about 3600+rpm the diacom log shows more airflow than the values in that table!!!
Go figure???

RBob

iTrader: (1)

I can not explain what you or kvu are seeing regarding
you MAF's. However, there are a lot of open ends.
Is it possible that someone else changed that
table before you? It is also possible that Diacom
is not displaying the proper gms/sec value.

For kvu, it is possible that the ECM is thinking
that there is a MAF error and it is going n-alpha
(default based on tps/rpm). This would show the
effect that you are seeing.

Trying to follow the MAF malf code is difficult. I
do know that there are 2 immediate MAF malf bits
that if either is set the gms/sec goes n-alpha.
These bits are not the same bits that are reported
through the ALDL line (the immediate bits are 6 &
7 of RAM location $40 (L0040)).

I do not have access to a MAF vehicle. So I can not
help in the testing/checking required to figure
out why the MAF does strange things (add sound
track from the Twilight Zone). The best I can do
is to go through the code.

RBob.

kvu

RBob could you check this out and give me some more insight?https://www.thirdgen.org/techbb2/sho...hreadid=107093

RBob

iTrader: (1)

Ah, I think I figured out why Diacom is showing
a value greater then the max limit table. They
are grabbing the immediate gms/sec value and
displaying that.

While this is all well and good, it is not a
true representation of the airflow used for
calculating the LV8 and other items.

This immediate value is only used for hi MAF malf
and hi TPS malf testing. The final filtered/limited
gms/sec value (also available on the ALDL) is what
is used for LV8. This is the important term.

RBob.

RBob

iTrader: (1)

Sure. However, I would like to go through the
entire chain of events leading up to the final
gms/sec airflow value.

1) The MAF ADC input is read. The ADC Vref value
is 5.1 volts. 5.1 / 255 = 20mV per/count. So a
MAF output of 2.1 volts will be 2.1 / .02 = 105.

The value 105 is the value within the ECM.

2) The ADC value is multiplied by 7 and stored
as a double (2 bytes). This is required as the
MAF scalar tables are a holdover from the digital
or frequency based device.

105 * 7 = 735 = $02DF (I'll use hex from time to
time as it will be easier at some points).

This value will be referred to as: MAFv*7

3) An overflow test is made on this value. It is
a holdover from the digital MAF and is not
required for the analog MAF.

4) The MAFv*7 value will be broken into two
pieces: the MSB and the LSB. The MSB is $02 and
the LSB is $DF (from step 2).

If the MSB is 1 then the MAFv*7 value is divided
by 2 (halved). This is required as the 1st MAF
scalar table has half the resolution as the
others.

5) The MSB of MAFv*7 is used to select the MAF
scalar table. As the MSB is $02 (2) then the
second table is used. If the MSB was $03, the 3rd
table would be used.

6) A 2D lookup is done into the selected MAF
scalar table. The loookup index is the LSB of the
MAFv*7 value. Here it is $DF or 223 decimal.

As it is an interpolated lookup the value retrieved
from the table will be 237.

7) Now the table scalar value comes into play.
The scalar for this table is 48. The math is
to multiply the look'd up value by the table
scalar and divide by 256.

(237 * 48) / 256 = 44.4 gms/sec airflow

The 44 gms/sec value is saved in L00BD. This is
the immediate unfiltered, unlimited airflow term.

The gms/sec value plus the remainder are saved
in L00F1 & L00F2 as a double. This is the same
value as above without the / 256.

This is done so that the filtering and LV8 calc
has higher accuracy.

8) Dependent upon an option bit the full gms/sec
term is filtered (done in ARAP).

9) The gms/sec term is now tested against a
minimum airflow (3 gms/sec). If less then that it
is set to that.

10) The gms/sec term is then tested against a
maximum airflow based on RPM. This is from the
table as descibed in a previous post.

-done calculating the gms/sec term-

It is this final gms/sec term that is used to calculate the load variable LV8.


So now, we get to a MAF scalar table:
The column following the FCB is the actual value
that will be found in the bin. Every column after
that one is informational. All of the above math
may be applied to the columns.

Take the line with 'FCB 198'. If you take the
198 and multiply it by the scalar and divide by
256 the result will be gms/sec:

(198 * 48) / 256 = 37.125 gms/sec

The BIN value of 672 is the ADC counts * 7:

672 / 7 = 96, 96 * 20mV = 1.92 volts

The #/Hr column is probably the conversion from
gms/sec of air to lbs/hr of air. Have to find the
conversion for that to prove it.

In closing, I'd like to point out that if the table
scalar term is changed, the entire table changes.
This is due to the math in step 7 above.

RBob.

It would be interesting to change the ALDL table
to output the intermediate values along with
the MAF status byte L0040. It would be easy
to follow the code and discover what is happening
at any point in time.

hectorsn

Once again this proves that we need to understand the code. It's not just useful if you want to make changes to it but to be able to comprehend the instructions is very worthwhile. This post and the one Bob made in the TBI board on how the ecm changes between sync and async gives the user true insight on why things are happening that they can't rationalize. Thanks for the replies Bob and keep them coming at the pace you have been giving them. It gives us time to absorb them and not be overwhelmed by them. Not only that but it should force us to try and pick things up by ourselves by looking at the code. I think we should all be very grateful for your replies. Thanks again.

kvu

Thanks RBob, that helps alot.This is the direction I wanted this post to go.I just don't understand why maf is so controversial.I have a few questions,if you don't mind.:hail: You indicated the filtered air flow rate(gr/sec) was used to calculate LV.How does the maf tables work with and/or change LV8?The 37.125 gr/sec is the gr/sec I've been changing using bin editors?If so the what happens if the 37.125 was changed to 35.125.I would imagine that would change 198*,scalar 48 or 256.I don't think it changes the scalar.What is the FCB 198 value?I have more questions but I don't want to bother you too much .We can use my car for some testing.Just tell me what to change in the bin and I'll give you a winaldl log.I would love to do some mild testing,just let me know.

RBob

iTrader: (1)

Easy enough:

LV8 = inverse RPM * airflow * scalar

This causes a higher LV8 at a lower RPM (given the same gms/sec).
And conversely the higher the airflow (gms/sec) the
higher the LV8. The scalar may be found before the
beginning of the MAF tables.

Quote:

The 37.125 gr/sec is the gr/sec I've been changing using bin editors?If so the what happens if the 37.125 was changed to 35.125.I would imagine that would change 198*,scalar 48 or 256.I don't think it changes the scalar.What is the FCB 198 value?

I would imagine that changing the gms/sec value in a bin editor
will change the bin value. The only way it could do this correctly is
to use that tables scalar term.

The way to check this is to use a binary utility (hex workshop) to
look at the bin values before and after editing.

RBob.

kvu

Would'nt a BIN value be in the calculation along with(198 * 48) / 256 = 37.125 gms/sec? I just can't figue out what column changes. guess that would be one more piece of the puzzle .

Thanks for all your help RBob:hail:.I downloaded hex workshop,but can't figure it out .There is two bins up in the post. I have changed the maf tables in one.Could someone check em out and see what column changes?