A/F ratio not changing with increased fuel pressure?
Posted 09-08-2019 11:10 PM
Looking at just this slice I see why the OP was baffled, it plainly suggests the opposite of the expected response to increased pressure. However, I would still very much want to confirm that the one single point and lap averages are not misleading. A single point is just that, and while averages are great for some things the average AFR (or Lambda) isn’t a very reliable indicator, it just varies far too much throughout a lap swinging between on & off throttle, and we care only about on. That’s where the graphs tell a much clearer story at a glance, but only if rescaled and correctly color coded by lap. Perhaps that was done, and it probably still produced the same conclusion, but I wouldn’t be certain enough of anything from what little we have here to take action.
Posted 09-08-2019 11:31 PM
Edit: I do see RPM way off in the left margin but it doesn’t quite track with GPS speed. Of the two I guess I’d be inclined to trust RPM but that would depend on what I know about how clean and consistent the signal is. Again, the graphs can tell SO much more with fewer assumptions.
Posted 09-09-2019 10:54 AM
Steve, I agree that it is a fools errand to try and decipher anything from six plot's of data overlaid on each other. That is why I pointed out that even having this cluttered lap profile graph, there was useful info for the one point where the cursor was as well as the statistical summaries provided by AIM with the arrows. I typically only have two laps of data on screen and use the thinnest line thickness in order to be able to see what is going on even when the lines are running close together. I also set the graph scaling depending on what it is I am looking at so that I can see the fine detail. For A/F (Lambda) I will put my lower scale limit at 0.70 and upper scale at 1.0 to 1.1. This way you get good separation and still get the actual data values as they are recorded regardless of the scale you use.
I typically look at each track to identify the areas where engine rpm is from 6000 to 6500 and Gear Position is 4th and there is a good length of acceleration around this point. Finding more than one or two areas like this can be difficult and you can if needed use 3rd or even 5th but you will not likely see any 6000+ rpm there.
I am currently starting to try a new approach which goes against your premise of using average data but here is what I am starting to use.
First I make a map that has one or two segments that are purely WOT accel's.
Then, using the AIM channels report feature and by checking "view statistics" I get my overall lap summary data along with the MIN/MAX/AVG/Std.Dev. summary information along with the lap by lap data. The data I select for the Channel report fields are GPS Speed, Fuel PSIG, Fuel Temp, and Min and Avg. for Lambda.
The next AIM feature I use is to check the MAP Split box options for Slitting Group by Lap and Split Numbers. This gives me an additional summary of data based on the Map segments. This data is displayed giving Depending on some other option choices) the Split Number Segment ET and Segment length (ft).
From this data I also have the time and distance info being reported which I can utilize to calculate the average vehicle acceleration in feet per second which is useful indicator for assessing how the car is responding to any changes going on.
Having this report information for the track "Splits" set to analyze A/F lets me see the same min/max/avg/STD data summary as for the individual lap data. From this I can see the average of the min to compare against the average of the average (I pay no attention to the Max info as it is useless). What I look to see is if I am getting reasonable min data and reasonable avg dat with a small range between the two. Obviously if my mins turn out to be .60 and my averages turn out to be 1.05 I do not have good data but if I see 0.81 for avg min and 0.83 for average of avg. I have a good picture the system is operating in a good balanced range.
Hope this helps to show the powerful capability of the AIM Analysis software but it takes time to understand and figure out how to use these feathers which in the end can be very useful.
The person who has help me the most on this is Ray Phillips, owner of Precision Driving Analytics who's web site is the same name w/o spaces and caps and a dotcom.
Posted 09-09-2019 11:21 AM
There are also a couple of other factors that could be coming in to play here and which could be put to rest with a little preventative maintenance, The first is what is the condition of the O2 sensor that the ECU is referencing for it's data. And secondly, what is the condition of the Evap Canister as a saturated canister can feed a lot of vapors which might also affect how the data looked after making a mid session A/F adjustment of a hot car that has come in and stopped doing a heat soak while the adjustment is made.
Posted 09-09-2019 12:38 PM
We’re already way past what anyone else cares about this but since it’s you and I I’ll toss out a closely related analogy.
I’ve already conceded that averages are certainly useful but over an entire lap they aren’t very enlightening for something like AFR. That’s WHY we have these systems. Consider the old days with someone in the pits using a stop watch and noting lap times for you to review later and compare to a teammate. What you get is an average for the entire lap. Helpful, maybe, but very low resolution and potentially leads you to try too hard in places where you are already getting 100% from the car. So you put several people around the track with stop watches and get segment times. Much better, you can focus on segments where you are slower, but still only averages with none of the other relevant factors which account for those averages. Now technology allows us much higher resolution and numerous channels of related data, but our brains are incapable of absorbing, organizing and correlating all of that as raw data. So someone creates software to handle that load and we choose how to have it presented. I’ll start with the simple old fashioned low-res aggregates to help me decide which track segments or data elements to prioritize, but then I’ll almost always look for the answers in the graphical representation which allows my eyes to quickly see what my brain can’t efficiently pull from thousands of data points per second of track time.
2 user(s) are reading this topic
0 members, 2 guests, 0 anonymous users