Custom graphing software for logging fuel trims and recalculating speed density maps

[rolls]

So I was a bit underwhelmed with the histograms in livelink and HP tuners so I wrote my own software package to plot 3d graphs.

My software has the addition of working out average, min, max and standard deviation per cell. If you standard deviation is high due to large span of data the average value is kind of meaningless.

You can then trend the data in that cell vs a 4th variable, manifold pressure is usually the problem. If you see your fuel trims go lower as the pressure goes lower you know you have a problem with the offset not the slope.

Basically it makes it really easy to tell if you should be adjusting offset instead of slope.

Here are some screenshots of some old data I had which had terrible trims on low load.

Standard deviation view:


Count view:


plotting the actual value against a 4th variable (MAP in this example)


As you can see from the last screenshot there is a large standard deviation in cell 10 degrees cam at 2000 rpm. You can see at very low MAP of 5kPa there is a trim close to 0.84 and at higher map values it trends to 1.00, this indicates there is an offset error, not a slope error.

Tweaking the "map at zero airmass (high res)" value would fix this issue, opposed to tweaking the "MAP per airmass (high res)" value which would simply shift the error.

I'll post a link up to the beta software shortly

[rolls]

Can download it here:
https://dl.dropboxusercontent.com/u/...taAnalyser.exe

You need .net 4.0
https://www.microsoft.com/en-au/down....aspx?id=17718

[Keith@HPTuners]

Looks nice. You can do similar stuff in 3.0 with the new math engine.

Also, .net 4.0 is required for VCM Suite, so users should already have that installed.

[rolls]

Looks nice. You can do similar stuff in 3.0 with the new math engine.

It is pretty basic at the moment, I mainly wrote it as I wanted to check standard deviation and then view a 4th variable easily. If people actually find it useful I'll polish it though.

Is there any way to trend a 4th variable in scanner currently? The only other way I've been able to do it is export to csv and filter 3x in excel, eg filter for an rpm range, cam angle range and trim range. Being able to visualise it makes it a lot quicker though as you can very quickly see a relationship.

[DarrylC]

Nice work rolls

As Keith implies you can do this in the 3.0 scanner. I did it using mapping CAM Angle vs RPM vs LTFT and made sure the axis matched the breakpoints in the tuning tables. Worked a treat.

Agree that you will need to analyse MAP to get the values fixed for MAP at Zero Airmass though, just create another graph.

Unfortunately for the Australian Fords the scanner will not log Airmass correctly so you can't easily calculate an incorrect injector offset. I still have to use SCT to do this.

[rolls]

Yeah I use the SCT for all my data logging which has fairly average data logging software, I've been using it to log to CSV and then graphing it in my package.

I will have to play with the VCM scanner software some more as I couldn't work out how to do that when I tried.

[schpenxel]

That's pretty slick. Going to have to try it.

[rolls]

For anyone interested I can now calculate pulsewidth from rpm, map, cam angle sensor and plot it over actual logged pulsewidth (via SCT) with a r^2 value of 0.987

If I calculate fuel mass via the same method and compare it to fuel mass back calculated (using injector slopes) I can get a r^2 value of 0.989

That is with no transient fuel modelling implemented, if I figure out what the transient fuel modelling does I should be able to get it even closer.

For now this is good enough to use for automatic SD map recalculation.

[schpenxel]

Nice. I'll have to check it out

[schpenxel]

What format is it expecting data to be in? I tried exporting a log to csv and loading that and it wouldn't load--tried just loading an hpl file direct and that didn't work either

Is the link posted earlier in the thread the latest version?

"Error: Input string was not in a correct format"

[rolls]

The version I posted earlier won't do any of the things I discussed in the latest post, it will only do what I posted in the OP, graph it vs a 3rd variable. Once I get the the application polished (alpha stage at best currently) I'll post up a version where you can paste in your SD maps and injector settings to have it output the injector ms/fuel mass I discussed. Unsure when/if I will do this.

Regarding the error it expects a CSV file, here is a link to an example, it is quite easy to convert a hpt log into this format. Currently HPT scanner does not log a "pure" csv file, it has a header on top which my application does not currently strip off. This would be easy to add I just haven't done it.

https://www.dropbox.com/s/t6owdqidgmw7z62/test.csv?dl=0

edit: Open the example in notepad++ and compare it to your csv log file, then edit yours to make it a true csv file.

[schpenxel]

I'll have to mess with it a bit more later--yeah if it were able to just use straight up VCM Scanner csv exports that would be a lot easier for us mortals to mess around with. I quickly pulled the header off of a CSV file from Scanner and it didn't work either, but the remaining column headers didn't match what you have on yours so maybe that's why. I'll mess around with it a bit later

[rolls]

Will now open .csv files created by VCM scanner. I've also added some error handling for files that have invalid numbers, blank entries, text instead of numbers etc.

[rolls]

Ok here is the direction I am heading with my program with some examples.

What I'm concentrating on at the moment is using the LTFT to show a trend against a variable (MAP) for a given rpm and cam angle. If the standard deviation is large you will see a curve. Eg in the screenshot below you can see when the MAP is low the LTFT is very lean, when the map goes up the trim comes closer to 1.00. This sort of curve indicates my program should modify the map at zero.

Eg you've got a spread of 26% in the LTFT vs map at idle (10 degrees cam, 750rpm), you view this graph by clicking on "View Cell Vs U" and select the idle cell.



The next trend I look for is this, a spread of 4% in LTFT in another cell (0 degrees cam, 2000 rpm), this one needs the map slope adjusted only as the trend is linear (although 0.98 is good enough so I wouldn't bother)


Finally I also look at this trend of fuel mass vs injector ms vs fuel trim, as you can see it goes lean around the breakpoint, this implies there is a slope/break point issue as well where the breakpoint x,y point should be shifted slightly to make it richer at this point.



This trend using the MAX option makes it even more probable that the fueling problem is around the breakpoint. Note that if you just happen to mess with speed density cells that only get hit at approximately the breakpoint, it will look as though the breakpoint/slopes are the issues even though they are not. If somehow you had this scenario and used my program to adjust the slopes you would most likely end up with transient fueling issues as the slopes are used in the transient fuel model. I'm still thinking of ways to discern between the two issues, SD tables out of wack or slopes out of wack. Curious if anyone has any thoughts or ideas about this.



I'm still deciding how to make my program automate all 3 issues together, eg map at zero, map slope and injector slopes/breakpoint.

At the moment I think I'll simply leave it up to the user and let them choose whether they want to modify slopes or map tables based on some visual data similar to what I've shown here.

Another problem I ran into was SCT was logging spurious values occasionally, eg a fuel trim of 650%, or an injector pulse value of 50,000ms, to get around this I've implemented data conditioning based on standard deviation. Eg if the standard deviation of the data in a cell is 0.10*trim (eg 10% trim) but you get a trim of 50 (5000% trim) it will go max trim accepted =*3.14 (user editable) *0.1*+ median (lets say this is 1.01 trim) = 1.324*and min trim accepted = 3.14*-0.1+median = 0.696, 50 is > than 1.324 hence it is dropped and not graphed.

edit: Note that the program linked in the OP will not let you do any of this stuff yet as I'm not happy enough with it to release yet.

[rolls]

Image comparing the emulated injector ms from my program vs the real injector ms logged

[DarrylC]

rolls, really like your work and your approach to removing the "fear" of tackling the SD tuning.

I do it differently but we are trying to achieve the same thing.

To get injector slopes I plot Aircharge => Fuel Mass vs ipw. Then graph it and find the slopes and breakpoints directly. Doing this you will also find the Offset correction. By looking at the graph you can pick points on each slope of the slope to do an linear analysis and produce the equations for the Fuel mass vs time.

Once this is done you can do the SD calculations.

With respect to the SD calculation I do a regression analysis of the RPM/cam angle with the MAP and LTFT. By doing this I can calculate both "MAP at Zero Airmass" and "Map per Airmass" directly. Obviously you need to filter out the non closed loop values.

To get good data I drive the car for about 80km before I start logging. Then go for a decent drive and "cruise" around the breakpoint values to collect data.

Note you can do Injector first and then correct the LTFT values for the SD calculation but without programming skills it might be a bit tricky.

SCT logs important stuff like MAP per Aircharge, MAP at Zero Aircharge, Aircharge and it is a shame that HPT does not log this stuff for us and we still have to use SCT.

Hope this helps.

Excellent work rolls

[rolls]

To get injector slopes I plot Aircharge => Fuel Mass vs ipw. Then graph it and find the slopes and breakpoints directly. Doing this you will also find the Offset correction. By looking at the graph you can pick points on each slope of the slope to do an linear analysis and produce the equations for the Fuel mass vs time.

Could you detail what you do there to find the offset correction? You plot fuel vs pulse width with aircharge over the top? I think I need a visual to understand what you are doing. Sounds interesting and perhaps I'm missing something that could improve the result I'm generating.

To get good data I drive the car for about 80km before I start logging. Then go for a decent drive and "cruise" around the breakpoint values to collect data.
:

This is something I missed at first, was doing tunes and trying to log 10km later, you really need 50-100km for the LTFT to dial itself in. I think if we can put tips like this with a nice tool it will make tuning "at home" infinitely easier for the average bloke.

edit: The aircharge that SCT logs, do you know what units it is in? It seems to be approximately 25% of a lb which makes no sense to me. Even if I put them back into the equations I get wrong injector ms and wrong fuel mass yet my calcs seem much closer. Do you know why they might be wrong?

[DarrylC]

Could you detail what you do there to find the offset correction? You plot fuel vs pulse width with aircharge over the top? I think I need a visual to understand what you are doing. Sounds interesting and perhaps I'm missing something that could improve the result I'm generating.

No problem, its been a while but here goes:

Xcal 2, Livelink 6.5 and I log AIR_CHARGE which is the cylinder air mass in lb.

Basically: At idle I had an AIR_CHARGE of 0.000397489 and an injector pulse width of 0.001627 (1.627ms). Assuming stoich then you compute the fuel mass for this pulse width (0.000397489/14.64 = 2.715e-5 lb of fuel for a pulse width of 1.627ms).

So, AIR_CHARGE => Fuel mass and you have the pulse width for this fuel mass. Plot this and then calculate the two slopes and breakpoint. If you find that you end up with a line that is slightly offset from zero then that is your offset correction I did this for my LPG injector and found the line was basically 0.05ms away from zero and that is what I added to my injector Offset. Fixed a whole heap of decel trims.

Hope this helps.

[rolls]

So you were effectively graphing the actual injector pulse and seeing how much the pcm had added to it to get stoichiometric. By checking at as close to zero fuel mass as possible you can determine the offset error.

Makes sense. I guess the order you should make corrections should be.

Offset
Breakpoint
Slopes
Map zero
Map slope.

I'm doing almost the same technique as this for map zero. Finding the lowest map value possible, seeing how much the pcm has added to the pulsewidth and adjusting the map zero value to effectively get the same answer.

Do you know how smart the ltft calculations are internally? Do they simply add an offset correction/multiplier for each map vs cam cell? If it doesn't add big an offset and multiplier the ltft would effectively chase itself. I don't know how they would calculate this internally though, would be quite complex.

[rolls]

I know why when I logged air mass it was wrong, "mass of air being inducted into one cylinder" is some other number, "air charge" is actual air mass per cylinder.

edit: I tried plotting aircharge vs injector pulse width (both measured via SCT) and the scatter plot is just a huge mess, you can roughly see a trend but the r^2 is so low I don't see how you can accurately calculate an offset error from it.

Did you get a nice graph when you plotted it? Here is my plot of fuel mass (via air charge) vs injector ms. It looks like garbage. I'll try doing some filtering on it, eg remove any sample at the minimum pulse width, above the breakpoint and beyond maybe 2 standard deviations and see what it looks like.