l2r99gst

iTrader: (2)

Sophie,

I am rescaling the MAF scaling table so that it is L/Hz vs Hz. It has nothing to do with a voltage.

I didn't post how to change the scaling in ECUFlash at this time because I need time to iron out the scaling better when I have the chance to log more and get more data. I will be using Mitsulogger and Scantech along with my equation for mass airflow from Hz, baro, and temp to correlate the scaling.

Then I will have to start changing values in the table, log with Mitsulogger, and see if the changes in AFR correlate with the correct Hz value for my scaling. Only then will the table be complete.

But, my main point is that this table is really a table for volumetric airflow/Hz per Hz. The exact L/s and Hz values aren't verified yet, though.


Eric

SophieSleeps

iTrader: (19)

Ok, so basically I'm going to wait for someone smarter to finger it out...and then I'll sort of jump on your nuts and see what information I can grab.

Sounds good. Good luck.

dubbleugly01

iTrader: (24)

lol, yeah, I'm looking to pile on also.

To all you guys working as "developers" for EcuFlash, a big thanks!

SophieSleeps

iTrader: (19)

Hope he has long pubic hair. A lot of people will be riding.

l2r99gst

iTrader: (2)

Well, if all of this pans out, in a nutshell, if you have an intake or somthing that alters the maf reading at idle, you should be able to adjust the first one or two values in the maf scaling table (have to verify the Hz scaling first) a certain percentage up or down to compensate for the misreading at idle.

For example, if you had trims that were +10% at idle, then you could adjust the first one of two values in the table to be 10% larger, which would tell the MAF that there is actually 10% more airflow than it is reading, which would in turn add more fuel.

That's what I am trying to figure out with all of this. If I am right on the meaning of this table, that is what it can be used for.


Eric

l2r99gst

iTrader: (2)

I'm not really doing any development work. If you want to thank people, thank guys like Jack, John, Bez, Colby, and the others that I forget that are really doing ECU dissembly. They all deserve the real credit.

I'm simply using data that was already found by others, like the people that have done DSM dissembly and the people mentioned above, and trying to relate it our ECU to figrue out the table, it's scaling, and it's use.


Eric

ez

iTrader: (15)

Bingo...this is what I am after as well. I did play with a few MAF parameters over the weekend but was not able to affect the idle fueling the way I wanted...

l2r99gst

iTrader: (2)

Out of curiosity, what did you do and what happened, or didn't happen?

Eric

jcsbanks

Eric, this is just as much in terms of development as disassembly, datalogging apps etc. Practical experimentation and describing the less understood maps is highly valuable.

DB Performance

I do this all the time on cars. It is useful for getting the idle/low airflow fuel trims dialed in on cars with a different intake or bigger injectors that need more than just injector size scaling and battery voltage offset help at idle/low airflow.

All you have to do is fix the incorrect scalings in EcuFlash and then do some logging of Hz vs fuel trims in Evoscan or whatever and then add or subtract "airflow" to get more or less fueling at that specific Hz.

To fix the scaling in EcuFlash, change the data value to "uint8". And then make your own custom scaling for the Y Axis load. It should be something like an "uint16", "little endian", Rom to display "x/10.24". The Hz range should then be like 19, 25, 50, 75, 100, etc. 25 increments in the lower airflow levels then jumping to 100 and 200 increments later in the higher airflow. If you have ever done chip tuning on DSMs, the Hz values will look extremely similar.

MalibuJack

iTrader: (5)

I have been doing this also since I figured out the scaling.. I think the actual scaling starts at around 30hz, as airflow seems inconsistent below that..

The scaling I had been using is the scaling used by MUT, which makes sense.. you don't need a custom scale as the axis does already exist for this..

use x/6.29 and x*6.29 , UINT16 and also Little Endian..

Remember that this axis is a configurable parameter for different MAF sensors and the range should also be able to be modified (I have seen this in a Lancer ROM that of course is a different size and has a different MAF range..

and it correlates almost perfectly with the range of the MAF

l2r99gst

iTrader: (2)

DB Performance,

Thanks for the input. Using x/10.24 however only scales the compensation to 1600 Hz. I haven't had the chance to test this yet, but I would venture to guess that the Evo ECU has the Maf compensation scaled for a Hz range a bit higher than that.

This should be relatively easy to test though. Just change a value somewhere down the list so that it is richer, do a pull and see the Hz value where the wideband shows a rich spike. That's what I am planning on doing to really see what the Hz scale is actually scaled to.

But, for now, I was just using x/6.25, very similar to what Jack mentioned about x/6.29.


Also, just to add to this, I have read more about how the DSM ECU at least (and I think the Evo ECU) handles this and the other MAF tables. To do the final calculation for mass airflow in the ECU, this compensation table value gets added another value, what I have seen called an adder, and then the Maf size, what we see as 357.5 in ECUFlash, is the multiplier. So, the Maf size, as I understand is sort of the 'global setting' and the compensation map is the fine tuning for the Maf curve, which also uses an 'adder' for the final calculation.

This really shouldn't change how I am doing things, though. It may change the fact that the L/Hz value really isn't an absolute L/Hz value, but it is simply an adder and multipler away.

But, anyway, thanks for the input. Hopefully in a few days I can get this testing done and see what both scales really should be scaled to.


Eric

DB Performance

The 1G DSM ECU is scaled pretty much the same and goes to 1600hz also. It isn't hard to break 1600hz on a 1G DSM with a stock 14B either. Mitsu probably assumed that at higher airflow the MAF would be pretty linear and not need the fine scaling like you need at low airflow. The MAF Scaling table is most useful during closed loop. During open loop you do the fine tuning with the main fuel table.

Just look at how perfect the numbers come out though when you use 10.24. It has worked for me on the dyno with a lot of cars.

DB Performance

On a different note a month ago or so, I thought I migth have found a way to read load by logging the ISC steps and making some changes to the idle stepper table, since the ECU seemed to open up the idle motor more and more in direct relation to load, but it seemed to max out too early and I haven't gone back to playing with that.

l2r99gst

iTrader: (2)

Yes, they certainly do. I can't disagree with that. It's not that I don't believe you or your tests....I'm just the sort of person that needs to test it for myself. I wish I could go out and test right now, but I think it will have to wait for this weekend.

Thanks again,
Eric

P.S. If you search this forum, a way to log the real 2 byte load has already been accomplished.