Average PW for a given Mafload varies by drive

[Kzcleve]

Hello all,

I am having an issue that is driving me nuts and at this point, I really don't know where to turn. The pulse width for any given mafload value is higher (roughly 2% higher) in the morning after the car has sat over night than it was the night before. This remains true even if I drive the car at operating temperature for a long time in the morning. I just don't know what could be causing the pulse width to be higher on the first drive of the day than on other drives? The pic i attached shows the average pulse width for each mafload value for two logs. The blue line is the average pulse width by mafload for my drive home from work last Monday night and the green line is the average pulse width by mafload on the way to work the next morning. I have also attached my MSQ. This problem has been present for as long as I can remember and I have been running my car on MS3 for a few years. I am using MS3x with the 1.3.3 beta 2 firmware. full-sequential 8 cylinder with a GM frequency maf for fuel load, no mat correction turned on. Optispark for crank and cam input. I have warm-up enrich set to 100 across the board. I'm just out of ideas and I am hoping someone else has some. The logs I used to make the image are pretty large but I can post a small piece of both logs if it would help.

AM PM log comparison.jpg

[jsmcortina]

Please zip up and post the logs and the spreadsheet used to generate the graph.

James

[Kzcleve]

Here are the logs. I added a copy of the pivot table from the spreadsheet i used to make the chart. The whole spreadsheet is just too big. However, all i did to make the spreadsheet is take the two logs that are attached and copy and paste them into a single spreadsheet, add a field with an identifier for each log (you will see those at the top of the attached pivot table), then i ran a pivot table/chart with the log identifier as the legend field, Mafload as the x axis and average pulse width as the value. I had to trim the evening log to get it to fit but I only cut repetitive stuff like pieces of long idle sections. If you still want the whole spreadsheet I can email it or just try to figure out how to compress it a bunch more. Thanks for taking a look.

[Kzcleve]

I worked on the issue a little yesterday but I had no luck. I also thought I should mention that the AFR agrees with the pulse width change. That is, the AFR is about 2-4% leaner on the evening drive than on the morning drive. I am sure I have some setting wrong but I can't figure it out.

[kaeman]

What is the morning air temp, verses afternoon air temp. You could just be getting the MAT correction for the difference in the morning or afternoon. Also does your trip to work involve an elevation change. do you have the second map sensor in stalled for baro correction. I have friends that kinda have the same problem you have but its because where they work is at a different altitude and the baro correction is determined at startup in the two locations, so a change in elevation would result in a small change in fueling.
I don't know if this is a help but its an observation.

[jsmcortina]

I've had a look at this and I'm not immediately seeing anything wrong in the way the software is handling this.I double checked on the stim too. The code isn't supposed to take any account of MAT and it doesn't.
MAFload includes air density, but the core MAF fuel calculation does not.
See http://www.msextra.com/doc/ms3/fuelcalc.html

Perhaps in your case there are other factors outside of the base calculations that could benefit from enabling the optional air density correction curve.
EDIT: I also note that many of your sensor readings are noisy and you are using close to 100% for the lag factors. While that is good for response, some smoothing would likely be beneficial here. Try reducing the numbers somewhat.

James

[shauer]

MAFload includes air density, but the core MAF fuel calculation does not.
See http://www.msextra.com/doc/ms3/fuelcalc.html

James

I have a question related to the above statement.

I understand that PW is controlled by MAF, and not MAFload. MAFload is a synthetic (artificial) value that approximates a load value so you can use it in various tables for the load axis. I personally use MAFload as the load axis variable for all tuning tables.

What I question is if the relationship between MAF and MAFload as it's currently calculated is correct? Is it possible that there is some error built into the inclusion of air density in MAFload where MAFload can diverge from MAF based on changes in air density like from cold air in the morning to warm air in the afternoon?

The reason I ask is that I think I see some variability of a few percent in MAFload as well. For me it's mostly in the noise and slightly effects which bin I am running on my MAF trim table (ve1table).

For example, I can run VEAL on my trim table and get 2% - 3% change in trim values on a fully warmed up engine between morning (cold air) and afternoon (warm air). I suspect that the trim table bins shift a little based on changes in MAFload and the effects air density has on its calculation that are different to how my MAF sensor operates.

I guess what I am asking is if there is any knowledge of the percent error in the MAFload calculation? By its nature it has to be an approximation and it is not used to calculate fuel so some deviation between fuel calculation and MAFload should be expected by I'm curious if there's a way to determine how much error? I also assume that this would depend on how accurately your MAF sensor is able to determine air density based on it's installation.

Thoughts?

[subwoofer]

I feel MAFload should be calculated at some nominal air density, just to keep ignition and trim from bouncing around. The actual amount of fuel and air is given by the mass flow and thus in-cylinder conditions should be very close to the same, regardless of IAT.

[shauer]

I feel MAFload should be calculated at some nominal air density, just to keep ignition and trim from bouncing around. The actual amount of fuel and air is given by the mass flow and thus in-cylinder conditions should be very close to the same, regardless of IAT.

I like that idea. I may have to download the current 1.3.x source and try that out to see if it has any noticeable effect on the bouncing around I see. I still have the development environment from when I worked on the MAF integration changes.

I'm having a hard time thinking that a 20-30 degree F change in IAT or a change from a low pressure to high pressure weather system is really effecting MAFload to the point where I'm seeing these changes but this would be a pretty simple experiment to run to prove/disprove the effect.

[Kzcleve]

Thanks for the input everyone. I'll try to address all of your points.

What is the morning air temp, verses afternoon air temp. You could just be getting the MAT correction for the difference in the morning or afternoon. Also does your trip to work involve an elevation change. do you have the second map sensor in stalled for baro correction. I have friends that kinda have the same problem you have but its because where they work is at a different altitude and the baro correction is determined at startup in the two locations, so a change in elevation would result in a small change in fueling.
I don't know if this is a help but its an observation.

The air temp is quite a bit warmer in the afternoon than in the morning but that should not affect the PW calculation on my setup. For a while I thought it might be the air temp correction so I replaced my MAT sensor with a pot and while driving varied the temperature input from -40 to 260 degrees and it made no difference at all (EDIT: I should say it did not make the difference in AFR or PW I was expecting). I do not have Baro correction enabled so that should not affect PW calculation. Maybe a question for James, how would Baro correction if enabled effect MAFload?

I've had a look at this and I'm not immediately seeing anything wrong in the way the software is handling this.I double checked on the stim too. The code isn't supposed to take any account of MAT and it doesn't.
MAFload includes air density, but the core MAF fuel calculation does not.
See http://www.msextra.com/doc/ms3/fuelcalc.html
Perhaps in your case there are other factors outside of the base calculations that could benefit from enabling the optional air density correction curve.
James

Thanks for you help James. Does this mean that the MAFload value in my logs will be affected by air density but the MAFload used in the fuel calculation will not? If that is the case then I am just left trying to work out why fueling is leaner after work. If I enable the optional MAT correction curve does that mean the old built-in ideal gas law curve is enabled and I can tweak that in the MAF MAT correction table, or is the MAF MAT correction table the complete correction?

EDIT: I also note that many of your sensor readings are noisy and you are using close to 100% for the lag factors. While that is good for response, some smoothing would likely be beneficial here. Try reducing the numbers somewhat.
James

Thanks for the heads up on the noisy sensors. I have used more smoothing in the past but it seems to give me some cyclical oscillations in the fueling. Are there specific sensors you think I should be smoothing more? I also have one other question about lag factor smoothing, how does it affect digital inputs like my MAF?

As for the discussion between Shauer and Subwoofer, I think you two are on to what is going on with my MAFload vs PW differences and possibly the AFR differences. If MAFload with air density correction is not being is not being used for fuel calculations but is being used for load calculations it air temp changes could effect other correction tables such as a VE1 or VE2 trim table (which I am not using right now) or the individual cylinder fuel trim tables (which I am using right now) and that would mean that air density correction for MAFload would be indirectly effecting fueling for me.

[subwoofer]

As for the discussion between Shauer and Subwoofer, I think you two are on to what is going on with my MAFload vs PW differences and possibly the AFR differences. If MAFload with air density correction is not being is not being used for fuel calculations but is being used for load calculations it air temp changes could effect other correction tables such as a VE1 or VE2 trim table (which I am not using right now) or the individual cylinder fuel trim tables (which I am using right now) and that would mean that air density correction for MAFload would be indirectly effecting fueling for me.

As James said, MAFload is NOT used for fueling, so plotting PW against MAFload will give a variance no matter how stable the AFR is. But my worry is that a MAFload based spark table or VE compensation table may drift quite a bit over the operating conditions I experience over the course of a year, IATs from -25C to +35C will give a change in air density...

Anyway, AFR will never be perfect, FPRs are mechanical devices affected by temperature and baro pressure, injectors may or may not be affected by temperature, MAFs and MAP sensors have finite accuracy, etc. As long as EGO can keep AFRs on track, you are good to go.

[shauer]

The mods may want to move this thread over to the MS3 development forum, or I can start a new thread over there. Whichever is most appropriate.

I'm running a little experiment suggested by subwoofer. I modified the 1.3.2 source code that is available and set mafload equal to an internal variable mafload_no_air which was already being calculated for the fuel equation. The mafload_no_air uses a hard-coded air correction value of 100% (no correction). This removes the IAT variability from the mafload and also uses the same load variable that appears to be used for the fuel equation.

I did a drive into work this morning and everything appears to still be operating normally. I am re-base lining my trim table using VEAL and will then see if I can tell if removing the air correction term from mafload is helping or hurting consistency. I have a very non-linear operating region at low RPM so I have a lot of trim table bins packed very close to each other with only a few percent load separating them. As expected all these trim table bins have changed with this modification to mafload calculation. I should be able to get a feel for consistency once these bin values are re-established.

[jsmcortina]

All good stuff. Looking forward to seeing the results.

James

[Kzcleve]

Thank you Subwoofer. I think we are saying the same thing. All I was trying to say is James's comments were clear and I could seethat MAFload will not directly influence fuel calculations. But, if MAFload is drifting with air conditions then the tables that use it will drift as well. I am using individual cylinder fuel trim which uses MAFload. Once you and Shauer started your discussion I realized that the drifting MAFload was moving me from the trim on cells to the trim off cells which in turn was messing with fueling. I changed the breakpoints between the trim and no trim cells and now my trim calculation is consistent. I understand there will always be variation in AFRs but if the variation is consistent and repeatable, I should be able to calibrate for the cause instead of relying on the o2 sensor. I really hope removing air density from MAFload will prove to make MAFload more consistent. I look forward to seeing the results of Shauer's testing. Shauer, I am happy to run your modified firmware if you want a second source of data.

[subwoofer]

I'm running a little experiment suggested by subwoofer. I modified the 1.3.2 source code that is available and set mafload equal to an internal variable mafload_no_air which was already being calculated for the fuel equation. The mafload_no_air uses a hard-coded air correction value of 100% (no correction). This removes the IAT variability from the mafload and also uses the same load variable that appears to be used for the fuel equation.

I did a drive into work this morning and everything appears to still be operating normally. I am re-base lining my trim table using VEAL and will then see if I can tell if removing the air correction term from mafload is helping or hurting consistency. I have a very non-linear operating region at low RPM so I have a lot of trim table bins packed very close to each other with only a few percent load separating them. As expected all these trim table bins have changed with this modification to mafload calculation. I should be able to get a feel for consistency once these bin values are re-established.

Any more results from the experiment, Steve?

[shauer]

Any more results from the experiment, Steve?

So far it is looking promising as far as improving the stability of the selected tune table bins based on mafload. I was out of town over the weekend and my O2 sensor decided to act up as well so I just got all that sorted. Today should be a good test case for me. It was about 50 degrees F for the drive in this morning and should be almost 80 degrees F this afternoon when I drive home. Normally this temperature change would result in a 1% - 3% shift in a large number of my trim table cells when running VEAL. I'll see what happens this afternoon.

I have emailed a copy of the code to Kzcleve and I am waiting for his feedback as it sounds like he has his tune set up to really measure the small changes caused by the load calculation. If anyone has a MAF based tune that is stable enough to detect a change of a few percent in tune then I would be happy to share this experimental code to see if we can get enough data to prove/disprove this modification.

[Kzcleve]

Sorry it has been a bit since I posted. I got the firmware from Shauer loaded and running and it is looking pretty promising. My MAFload dependent tables are much more stable and for the first time ever VEAL is not just tuning in circles as MAFload drifts. I have one good log since I started using the firmware from Shauer and I need one more with cooler temps in the morning to see if the drift I was experiencing is gone. I should be able to get the second log tomorrow morning or Friday morning. I will post some details once I get the second log.

[Kzcleve]

So here is where I ended up on the MAFload and airtemp testing. The biggest difference I have seen in Shauer's version of the 1.3.2 code is more consistency in it the table cells dependent on MAFload. I don't mean the cells are different, just the cell the car operates in at a given temperature. I realized that the slight changes in table cell was being intensified by heat soak in my air inlet tract (making the MAT sensor run pretty high relative to ambient temp.). I have been meaning to move my MAT sensor. I have also been meaning to change my GM frequency MAF sensor out for a Hitachi slot voltage MAF sensor. This past weekend i made the swap and started using the MAT/IAT sensor in the MAF sensor. My MAT readings are now much more consistent and close to ambient air temp. What this means for me is that even with MAFloat using air temp, the changes in temp from morning to afternoon are not affecting which table cell i run in as much. In short, the difference between MAFload with air correction and without air correction is only slight for my setup. I can't say i have a recommendation on moving forward. I like the consistency of the MAFload no air though.

On a side note. I have to say well done on the new MAF code for the voltage MAFs. I am amazed at how much better the car runs now. It ran pretty well before but with the voltage MAF and the MAF "integration" it runs incredibly smooth and consistent. I was able to get the transfer function with less than 2 percent error at every point in my operating range in about a day and a half.

[shauer]

My results have been similar. Using the version of mafload without the air correction makes the selection of cells in the tables more consistent. Depending on the relationship between your MAF sensor and the IAT sensor this difference can be noticeable and cause inconsistent tuning.

My request would be to either change the mafload calculation to either remove the IAT always, or make it configurable similar to the "multiply map" setting. Both versions are already being calculated right now it would be straight forward to make it a configuration option on the MAF settings dialog as to which one to assign to the externally available mafload variable.

thoughts and/or comments?

[subwoofer]

How large are the temperature swings you have tested over yet? Over the course of a year, I see IATs from -25°C to +40°C, that could make quite a difference in MAFload.

My vote is C: configurable.