MAF implementation, ideas and discussion

[subwoofer]

My car has been off the road for a month and a half, but celebrating its return to rolling status I upgraded to 1.3alpha5 to gain the MAF logger.

I am seeing the same problem as shauer did in this thread: http://www.msextra.com/forums/viewtopic ... b2#p362417
MAF is only sampled (or at least logged) every 180°, sort of negating the point. The discussion was sort of intertwined with others discussing other aspects of alpha4, so I really can't tell if there was a solution to the problem.

At least it still ran after upgrading...

[shauer]

You are correct, the MAF logger still does not work 100% correctly. I contacted James about this a while ago via PM and this is the response he sent me:

I need to look at the code in more detail. My test MSQ was using "event average" and logged continually. Your MSQ is using "timed minimum" and logged once per event.

If you change the MAP sampling to use "event average" then the MAF logger works correctly. I have done this myself and the MAF log was very useful. When MAP sampling is set to "timed minimum" with the sampling curve then MAF logger only samples once per cycle. So, in the short term, switch to event average and grab a MAF log, then go back to timed minimum and use the MAF logger data to set points on the sampling curve.

This is cumbersome and James told me the investigation and eventual fix is now on his "to do" list but I have no ETA from him.

The MAF logger is very useful, on my engine the MAF signal looks nothing like the MAP. When I set the sampling to provide the best MAF signal there are places where my MAP now looks really really bad. It's a good thing I do not use MAP for anything at all any more. I think a nice thing to do in the future to to allow separate independent sampling timing for MAF and MAP.

With optimized MAF sampling, I was able to pull about 10% variation out of my trim table.

Hope this helps.

[subwoofer]

Actually, I believe the OEM way is a twist on the MAP average theme, accumulating the decoded value and effectively integrate under the curve.

Even an averaging of the voltage could be close enough.

[shauer]

Actually, I believe the OEM way is a twist on the MAP average theme, accumulating the decoded value and effectively integrate under the curve.

Even an averaging of the voltage could be close enough.

I agree to a point. Integrating the area under the curve would most likely be ideal. This has been discussed and there are currently some cpu limitations on doing this if I understand correctly.

The point I was attempting to make with my last statement was that I do not think MAF sampling should be tied of MAP sampling. Whatever the actual sampling algorithm is can be debated, but best way to get a MAF reading should not be assumed to be the same as the best way to get a MAP reading. I personally do not have a strong opinion on how the sample is collected as long as it is consistent and I can shift the timing of the sample to tune around resonant points in my intake, or the sampling method can some how remove the false data caused by a resonant point.

My own personal opinion is that the current sampling methods offered in the MAP sampling settings work just fine for MAF and I just wish they would be split into two identical setups, one for MAF and one for MAP.

[jsmcortina]

A review of this is on the TODO list.

James

[subwoofer]

Ehem, guys?

"Use event average" simply transformed the feel of the car at the flick of a switch. I don't think I'll be needing the log I made, it ran so much better right off the bat. Stopped, turned off the compensation VE table completely and it was within 1 AFR the whole range from idle to WOT@redline.

Strategy just changed, methinks, simple voltage averaging actually works.

[subwoofer]

Tuning the MAF curve is now just about done after two logged runs of 15 minutes each, fueling should be within +/- 2% now. Scatter plots really make short work of it.

At least for me, Use Event Average fixed the mess caused by intake tract resonance, the MAF logger revealed that the flow varied 110 ADC points over a single cycle at 2000rpm, i.e. a difference between high and low of close to 30%. No wonder it jerked! Now it is dead smooth, running better than ever.

[Kzcleve]

I am happy to see that the MAF logger is working with MAP sample set to event average. I am wondering if this will work on the digital GM type MAF or only on the voltage ones.

[jsmcortina]

I am happy to see that the MAF logger is working with MAP sample set to event average. I am wondering if this will work on the digital GM type MAF or only on the voltage ones.

Probably the voltage ones at the moment. I'll add frequency based to my TODO also.

James

[shauer]

Based on the discussion recently in this thread, I have also tried running and tuning with "Use Event Average" in the MAP Sample Settings. The results look encouraging on my engine. Most areas appear to be better after my initial tuning run. I cannot say that it transformed the car but the scatter plots show a tighter correlation between regions of different load/rpm but the same air flow.

One question for the developers. Is it confirmed that "Use Event Average" is actually taking a separate independent voltage average of the MAF sensor as well as the MAP? I could have easily missed it, but I do not see this documented anywhere. I want to be sure the effects I'm seeing are the result of an actual change in sampling algorithm and not just a selection of a different discrete sampling point. At this moment, I could see either as a possibility.

Thanks!

[shauer]

At least for me, Use Event Average fixed the mess caused by intake tract resonance, the MAF logger revealed that the flow varied 110 ADC points over a single cycle at 2000rpm, i.e. a difference between high and low of close to 30%. No wonder it jerked! Now it is dead smooth, running better than ever.

I have just been looking through the most recently available source code and I see where the code is accumulating and taking the average of MAP readings but I see no such code for MAF. I think this has been discussed before, but I really suspect that there is no averaging taking place of the MAF reading even with "Use Event Average" on MAP. Hopefully James or Ken will step in and confirm if this is true. I suspect that the improvement you are seeing could also be caused simply by having the code use a different sampling point for a discrete MAF reading. I was able to get similar improvements with timed sampling by selecting different sampling times.

[Kzcleve]

I am happy to see that the MAF logger is working with MAP sample set to event average. I am wondering if this will work on the digital GM type MAF or only on the voltage ones.

Probably the voltage ones at the moment. I'll add frequency based to my TODO also.

James

Thanks James.

[hardline]

Forgive me for such a noobish question, but where would I find MAF logger in TunerStudio?

[subwoofer]

Under diagnostics, in the dropdown list where you also have MAP logger and trigger logger.

[elaw]

"Diagnostics" tab - it's in the list with "Composite logger" etc.

You'll need a fairly recent version of both TS and the MS3 firmware. I don't *think* a registered version of TS is required, but I'm not 100% sure about that.

[hardline]

It must be on the paid version. I do not see those options (MAF or MAP) in the free one. I have the paid version on the tuning laptop. Will check it at lunchtime

[hardline]

OK, I have a MAF log and a Datalog of the same timeframe. Now what do I do with it? Trying to tune out really bad reversion in the lower rpm range.

[shauer]

OK, I have a MAF log and a Datalog of the same timeframe. Now what do I do with it? Trying to tune out really bad reversion in the lower rpm range.

What I did that worked pretty well was to examine the MAF log in the RPM range where you have the reversion (mine is between about 1500 and 2300 RPM). My MAF log in this area was a mess, it looked like a noisy sine wave with a lot of bad peaks and valleys where they did not belong. What I did was pick a crank angle from the MAF log where the MAF reading appeared to make the most sense. For me it was on a specific falling edge of the sine wave portion of my reading where there was the least reversion noise.

I did the above for several RPM points and created the MAP sampling curve that I entered into the timed minimum MAP sample settings. I have the number of samples set to 1 so I know exactly when the sample will be taken and that it will be used.

Then with a baseline sampling curve established I did a series of tuning runs and tweaked the sample timing to get the best response out of the MAF sensor. I was not able to eliminate the reversion but I was able to significantly reduce it. I'm running with VE trim table so I measure success by how much trim correction I need in the reversion area of the trim table. I have a couple columns in my trim table where at moderate load I need about 115% trim but at high loads I need about 70% trim.

I have spent some time looking through the MAF sampling source code and as far as I can tell there is no way to have MAF averaged over a cycle like is done with MAP. From what I can figure out it looks like setting the MAP sampling to average will just capture a single MAF reading at the time the MAP average is completed. I would like James or Ken to confirm my interpretation of the source code in this area.

I am looking forward to the planned MAF re-write that is mentioned in the software road map. I have another MAF sensor that can detect reverse air flow and it uses the voltage range between 0 and 1v to report reverse flow and the range from 1v to 5v to report forward flow. It would be nice in the future if some sort of average or integration could be performed and also have it take into account a reported reverse flow. For right now I think the best you can do is use the timed minimum MAP sampling and carefully select the MAP sample timing.

- Steve

[jsmcortina]

Steve is correct, the MAF is not being sampled exactly as you might expect.

There are a some options for MAF sampling, please discuss.
1. option to take minimum (or maximum) during same window as MAP
2. same but use its own window
3. average over MAP window
4. average over own window
5. true event average

The summing and windowing are actually fairly code intensive as that code runs 7812 times per second (isr_rtc.s). I'm wary of adding much more code there as it adds to the overhead of the code. (It is in single digit percentages of the CPU time available.)

Adding a second set of window code just for the MAF adds a lot of code. The event scheduler would need updating to include that event and on each tooth on the wheel the code would need to check for it, plus the additional code in isr_rtc.s

James

[shauer]

There are a some options for MAF sampling, please discuss.
1. option to take minimum (or maximum) during same window as MAP
2. same but use its own window
3. average over MAP window
4. average over own window
5. true event average

The summing and windowing are actually fairly code intensive as that code runs 7812 times per second (isr_rtc.s). I'm wary of adding much more code there as it adds to the overhead of the code. (It is in single digit percentages of the CPU time available.)

Adding a second set of window code just for the MAF adds a lot of code. The event scheduler would need updating to include that event and on each tooth on the wheel the code would need to check for it, plus the additional code in isr_rtc.s

James

Here is my opinion on the MAF sampling:
1. I think that MAF sampling should be 100% independent of MAP sampling. The two really have nothing in common except that they both start with air entering the engine. The optimal point for sampling MAP will often not be the same for MAF due to the fact that they are being measured at very different portions of the intake.
2. Unless you plan to dramatically change things, MAP is not used at all when MAF is selected. It appeared to me that the map load was actually over written with the maf load in the code. If this is true then all the MAP sampling and averaging code is dead code when running in MAF. You could bypass all the cpu intensive MAP code and use that cpu overhead for accomplishing MAF sampling and averaging. When running MAF, the only thing that I think MAP is used for is data logging and in that case a simple single sample would suffice.
3. If you bypass all the cpu intensive MAP code then I think you could re-use the existing windowing exclusively for MAF. Consider making MAP and MAF sampling and windowing mutually exclusive since MS is effectively already doing this anyways. This would prevent the need to duplicate the windowing code, it would just be used for one or the other and never both.
4. I would like to see some sort of integration or averaging of MAF over an intake cycle or some other user specified window. I understand that the calibration table lookup per sample to allow averaging of g/s may not be possible. I think that within a single intake cycle, the MAF is operating in a narrow enough region of its curve that you could get away with simply integrating the MAF voltage/frequency over the cycle and then perform a single calibration table lookup/multiply at the end of the average, similar to the MAP approach. While this is not 100% accurate, I'm guessing that it would be close enough.
5. In addition to #4 above, it would be nice to have the option to specify a "zero crossing" voltage/frequency for the MAF sensor. MAF readings below the zero crossing point would be integrated as negative air flow and points above would be positive air flow.

Hopefully this will kick off some discussion...