Okay so last night I got this bright idea to try to make EvoScan calculate air mass in either g/s or lbs/min or some other usable measurement to see exactly how much air is going into the engine. This is nothing new as DSMlink and many other systems have been doing it. I have tuned/logged some Subarus and they have the Load already calculated in g/s (least in the software I was using) and this was really really easy. Lbs/min is what most compressor maps are axis'd in, its an easy bench mark to see how much power the car is making (rule of thumbs is lbs/min x 10 for power) so there are a few good reasons to log this.

Strategy 1- The MAF size is listed in g/s (whether it is or not I do not know) and is listed as 357.5 g/s. Using a handy dandy online calculator we find the conversion is: 1 gram per second = 0.132277357 pounds per minute. Theoretically this means that the Evo MAF (as I currently understand it, though subject to error) is rated in size as something like 47.29 lbs/min. Can we log g/s throught the MAF?

Strategy 2- This is the one I tried last night and currently havent been able to get to work. Make EvoScan do it by adding all the conversion factors into the eval lines of the data.xml. It is telling me to get lost currently which means the request ID (which I have none to go by) is wrong or the formula is wrong as I entered it. I dont think Eric did it incorrectly I am sure I did when I put it in. The formulae can be viewed in this thread:

https://www.evolutionm.net/forums/sh...4&postcount=26

The EvoScan formulae (as I understood them and tried inputting them) look something like this:

<DataListItem DataLog="Y" Color="" Display="Air Density" LogReference="Airdens" RequestID="00" Eval="[Baro]/14.6956/.08026/([AirTemp]+273.15)*28.9" Unit="units" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="500" ChartMin="0" ChartMax="500" ScalingFactor="1" Notes=""/>

<DataListItem DataLog="Y" Color="" Display="Air Mass" LogReference="g/s" RequestID="00" Eval="(-1*10^-08*[AirFlow]^3)+(2*10^-05*[AirFlow])+(0.1228*[AirFlow]-1)*Airdens" Unit="g/s" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="500" ChartMin="0" ChartMax="500" ScalingFactor="0.1" Notes=""/>

Strategy 3- I am sure there are requests that we currently havent found ( I am limited in my understanding of code and disassembly but I am trying to learn it as fast as I can) or realised what they were or linked to. I also think there are others working on this, maybe not using EvoScan, that have some insights that would be helpful should they care to share them.

Anyway this is some of the stuff that I have been working on, not so much for MAF scaling just for logging purposes and seeing how much of the potential of the stock turbo or Green, or whatever might be on the car using the stock ECU is being used.

JB

 

John,

I was able to get this to work in LogWorks. Just looking at your EvoScan formulas, I see you have [AirTemp] and [Airflow] listed. Is that the right name and syntax for the intake air temp and Hz airflow in Evoscan? If not, that my be part of your issue.

I will look for a few screenshots that I used when doing the MAF scaling.

I know for a fact that the ECU has this already calculated somewhere.... just wish someone would find it. Actually, I think the load numbers that are in our fuel and timnig tables are actually mass/rev values, like g/rev. If we can find this out for sure, then logging mass airflow would be trivial. Simply log load and do a simple calculation to get to g/rev and then to lb/min.

If I have some free time, I will see if I can find the correlation, if there is one, based on my formulas and logged load.



Eric

 

John,

I found one of my old logs where I used this formula. I wasn't logging 2 byte airflow, so they are only good up to 1600Hz.

You can see in the 4 boxes the values for g/s, lb/min, airdensity, and g/rev at those points in time.



The code that I am using in LogWorks is this:
##Nairdens-massair

##[Forumla to calculate air density from baro and intake temp and then calculating mass airflow (g/s) based on formula for L/s vs Hz using the maf compensation table in ROM.
##]
#Forumla to calculate g/s from airflow.baro.
#and intake temp
airdens=Atmospheric_Pressure /14.6956/.08026/(Intake_Air_Temp +273.15)*28.9
massaircalc=(-1*10^-08*AirFlow^3 + 2*10^-05*AirFlow^2+ 0.1228*AirFlow - 1) *airdens
massaircalc1600=(0.1339*AirFlow + 2*10^-12)*airdens
LbsPerMin=massaircalc/454*60
LbsPerMin1600=massaircalc1600/454*60
MC(airdens;g/L;0;2) = airdens
MC(massair_calc;g/s;0;500) = massaircalc
MC(massair_calc_1600;g/s;0;500)=massaircalc1600
MC(LbsPerMin;lbs/min;0;50)=LbsPerMin
MC(LbsPerMin1600;lbs/min;0;50)=LbsPerMin1600
##Ngrams per rev

##[Uses the air dens calc and mass airflow calc to calc g/rev
##]
#Forumla to calculate g/s from airflow.baro.
#and intake temp

airdens=Atmospheric_Pressure /14.6956/.08026/(Intake_Air_Temp +273.15)*28.9
massaircalc=(-1*10^-08*AirFlow^3 + 2*10^-05*AirFlow^2+ 0.1228*AirFlow - 1) *airdens

GperRev=massaircalc*60/Engine_Speed
MC(GperRv;g/rev;0;5) = GperRev


LogWorks3 beta is having a bit of a problem with it though. I haven't really logged that much at all in the past few months, but when I get some time, I will try to find a correlation with g/rev and load. If load is based on that, it would be great.


Eric

 

Eric, thank you tremendously for sharing your insight. The syntax and log references are what EvoScan calls each of the functions. I made a flowchart to follow what you were doing with Logworks and then did my best to replicate it in EvoScan. I think some of the problem might be trying to express powers with the ^ function and EvoScan not being able to recognise it.

There are some other calculations that rather than try the shorthand have the values longhanded out despite being several powers out (billionths, trillionths, etc.) in form. I am going to try altering that as well, then doublecheck the formulae to make sure I didnt close off something that I need. Can you help me to understand how the Massaircalc1600 fits in? It seemed to be and add'l. value that I cant use to come up with a solution so I had left it out. Because EvoScan uses .xml I am limited (mostly because of my lack of programming experience) in how to implement the rest of your code.

It doesnt help that its been 12 years since college (when I was very heavy into math) and havent really used alot of my algebra since....well at least polynomials. One more question, in the second equation you have the Airflow being cubed yes, where its [Airflow]^3?

JB

 

I also am wondering if I have this properly expressed where I have it now as:

(-1*10^-08*[AirFlow]^3)+(2*10^-05*[AirFlow]^2)+(0.1228*[AirFlow]-1)*Airdens

Should it maybe be bracketed as follows?:

(-1*10^-08)*([AirFlow]^3)+(2*10^-05*[AirFlow]^2)+(0.1228*[AirFlow]-1)*Airdens

I am not sure that seperating the Airflow to the third power would make a difference as far as the calculation. I mean I understand the proper way to solve it but I dont know that EvoScan does necessarily.

If "load" is something like how Subaru composes there maps where Load IS g/s and the maps work in g/rev, then it would be a very simple solution.

As a thought exercise if I was seeing a peak 2 byte load of 290, then 290 * 0.132277357 would be 38.6 lbs/min. Now while I know its not a hard and fast rule, I do have logs of cars that put down 334whp on a DynoDynamics with stock cams that is doing this with S1's now. It is also running 25.5-25.7psi at peak torque to generate these numbers.

I must do some thinking now.

JB

edit-airflow formula correction as Eric notes below

 

The 1600 equations are for the airflow past the 1600Hz mark. Since the MAF scaling table stops at the 1600 Hz mark, beyond 1600Hz the relationship is linear (assuming that the last value in the table is just used past 1600Hz)
So, basically, the polynomial is used to best fit before 1600Hz (0<Hz<1600) and the massaircalc1600 and LbsPerMin1600 are used after 1600Hz (1600<Hz). You will have two lines for the same value on your graph, but just ignore one below or above 1600 Hz, unless EvoScan let's you do this with the graphing settings.

Yes, this is just a best fit polynomial from Excel when I was figuring out the MAF scaling table. So, it is has airflow cubed, squared, then itself.

I'm not sure how EvoScan wants it, but you are missing your square (^2) on your second AirFlow in the equation.



Eric

 

Oh well that certainly wasnt helping then was it. I will go back, fix that and try again. The other thing I am currently working on is 2 byte airflow, and I know others have it working and soon as I do I could conceivably replace the [airflow] with something like [2byteAirflow] and then it would continue to calculate past 1600 on its own.

JB

 

The 1600 calculations are not just to calculate past 1600Hz. It is because the equation is actually different past 1600Hz, since that is the last value in the MAF scaling table.

So, you would still need both. One is relevant below 1600Hz and one is relative above 1600Hz. Hope that makes sense.

For example, in my logs, since I wasn't logging two-byte airflow, the 1600 calculations are completely irrelevant, since I couldn't log over 1600Hz of airflow.


Eric

 

Just for confirmation, MAF scaling/smoothing load unit values are infact Hz *10, right?

Eric, how close is your AirFlow to your 2 byte airflow 1600 and below?

 

I forgot how the original table definitions were setup, but the scale is in Hz. You can look at the maf scaling thread to see how I changed it.


I'm not quite sure what you mean.

Airflow in the loggers is just the Hz value for airflow from the MAF sensor. Two byte airflow is used so that this Hz value isn't clipped at the 1600 Hz mark.

What John is asking about here is how to correlate this Hz value into a mass airflow value. When I was doing work on the MAF scaling table, I created an equation to fit, based on logged Hz value from MUT-III and logged mass airflow values from OBD-II, using the Hz value, baro, and intake temp, along with the profile of the MAF scaling table, since this is basically a L/Hz calibration for the MAF.


Eric

 

I mean if you were to log both AirFlow and your 2 byte Airflow, would they both read, say, 575Hz or would there be a difference - like 532hz for airflow and 575hz for 2 byte?

I get about a 2-5% difference between the two
You cant correlate the two, their two different things - hz is an unit of Airflow measure (velosity), g/s is the volume (mass/unit of time).

The hz value can translate to g/s but this depends on the barometer, temperature, humidity, and even pollution, CO2, farts, and so forth.

I just wish I knew how the barometric/temp comp tables interact with the smoothing/scaling.

Would that equation you supplied up there be it?

 

Yes, they should be identical (I was confused because you said my 2-byte airflow...it's just the original airflow that has been in the loggers since the beginning). Airflow and two-bytw airflow are the same exact variable in the ECU...just like load and 2-byte load. It's just that the 2-byte value will not be clipped.

If you are seeing a difference, it could be the lag in reading the MSB and LSB of the two byte value.


But you can.

That is what my equations above are for. They use the calibration of the MAF, which is the MAF scaling, which is basically a L/Hz value. So, this way you can find the volumetric airflow from a Hz value.

With the pressure (baro) and temperature (intake air temp), it is then easy to calculate the mass airflow.


Also, your idea of Hz for the Mitsu Karman MAF is a little off. Hz is the measure of vortices of air that is created by the sensor. The ECU then measures the volumetric airflow based on the calibration of the MAF, or the MAF scaling table as we see it. Basically, L/Hz * Hz.

That is why our MAF sensor also have a baro sensor and intake temp sensor in them. That is how the mass airflow is found by the ECU. I simply made my own equation to do it, hopefully similar to how the ECU is doing it.


Eric

 

I thought of one other way to do this last night. If the IDC's were 100% accurate, you new exactly what the AFR was, and the exact size of your injector you could calculate airflow in cc/m and therefore L/min which is a start as I understand it.

Example:

80% IDC of 750cc injector at 11.5 AFR would be 750 x 0.8= 600cc/m and we know the AFR is 11.5:1 so then we arrive at 600 x 11.5= 6900 cc/m or 6.9 L/m. But we also need to know L/hz so I am correct in thinking that if we cross the data for L/m at a given rpm/hz point we know how many L/hz we are at?

6.9 L/m @ 7500 rpm (lets say) equals 2200hz at the same RPM at a given level of boost. To convert this to mass what other data do we need and what formula(e) are required? I havent eaten lunch so I am foggy...must get grub.

JB

 

John,

If you knew that your IDC and AFR were exactly correct and you knew the specific gravity of your gasoline, then calculating the mass airflow is even easier than you think.

AFR is just a ratio of the mass or air to the mass of fuel. So, let's say that you had the following:

750cc injectors
11.5 AFR
IDC 90%
specific gravity of gasoline, about .73

First, calculate the mass of gasoline:

750cc/min*4=3000cc/min
3000cc/min*.73=2190g/min (since the weight of water is 1g/cc)

2190g/min*.9 (for IDC)=1971g/min of fuel, or 1971/454=4.34 lbs/min of fuel

To find the mass of air, just multiply the mass of fuel by the AFR:

4.34*11.5=49.9 lbs/min of airflow


So, for a rough estimate of airflow, these simple equations can be used. The only issues with this is that IDC and AFR are not going to be exact. So, this will get you in the ballpark for comparison from run to run, but won't be an exact calculation.

Also, this isn't taking temperature into account. Specific gravities/densities change at different temperatures.


Eric

 

Just more reason for logging IPW and 2 byte air. People tie up all there time figuring how to log psi (which is good don't get me wrong) but it's an independant variable useful when compared to itself as a form of load only when all conditions remain same - which is never the case, just use a boost as a monitoring tool .

The only effective means of logging boost is with a pitot contraption - not practical

The important data is right in your face already the MAF -