Enhancement suggestion for Lambda overlays
Posted: Fri Sep 23, 2011 3:23 pm
I have a few suggestions that I think would make the lambda overlay more usefull. I suggested the first one a few months ago on S2KI, and "Hondata" responded that he would add it to the list. I figured I'd mention it again anyway.
1) Use the WOT Lambda adjustment low / high tables within the loaded calibration as the basis for the fuel change suggestions when in open loop. This would make the WOT Lambda tables much more usefull, since the tuners could simply set the values in those tables first to whatever they want to target, then adjust the Fuel low and high tables until the actual AFR's match the WOT Lambda tables. Once the fuel low and high tables are dialed in, it would be very easy to try different AFR targets.
2) Use the overrun manifold pressure tables from the current calibration to filter out data points from the datalog so that the fuel suggestions aren't artificially inflated by injector overrun cutoffs.
3) Use the Closed Loop criteria from the loaded calibration to filter out datapoints from the datalog that don't indicate the correct fuel status for that MAP and RPM. I believe this would greatly improve the suggestions in the high cam fuel map, since columns 1-7 often show huge negative fuel adjustment suggestions due to false rich AF values while fuel status is 1 or 4.
4) Use the VTEC engagement criteria from the loaded calibration to filter out datapoints that don't indicate the correct VTS value for the given MAP and RPM values.
5) Filter out datapoints that occur immediately before or after a change in VTEC state, or give an optional criteria for time before or after change in VTEC.
6) Use the TPlate and TPedal values to filter out datapoints where there is a significant mismatch between TPlate and TPedal indicating a change in state. Obviously, there are lots of conditions where TPedal and TPlate don't coincide at all, like at idle and when the cruise control is enabled, but that seems easy to overcome.
7) Add another overlay that shows the number of datapoints that were used to calculate the suggested fuel adjustment, or allow the user to enter a minimum number of qualifying datapoints in the Options window.
8) Add another overlay to show the deviation between the datapoints used to calculate the suggestions, or allow the user to enter the maximum deviation allowed for the datapoints that are used to calculate the suggestions.
9) Allow users to merge datalogs and eliminate sections of datalogs, so that they can create "superlogs" that are void of datapoints that they know will introduce error.
1) Use the WOT Lambda adjustment low / high tables within the loaded calibration as the basis for the fuel change suggestions when in open loop. This would make the WOT Lambda tables much more usefull, since the tuners could simply set the values in those tables first to whatever they want to target, then adjust the Fuel low and high tables until the actual AFR's match the WOT Lambda tables. Once the fuel low and high tables are dialed in, it would be very easy to try different AFR targets.
2) Use the overrun manifold pressure tables from the current calibration to filter out data points from the datalog so that the fuel suggestions aren't artificially inflated by injector overrun cutoffs.
3) Use the Closed Loop criteria from the loaded calibration to filter out datapoints from the datalog that don't indicate the correct fuel status for that MAP and RPM. I believe this would greatly improve the suggestions in the high cam fuel map, since columns 1-7 often show huge negative fuel adjustment suggestions due to false rich AF values while fuel status is 1 or 4.
4) Use the VTEC engagement criteria from the loaded calibration to filter out datapoints that don't indicate the correct VTS value for the given MAP and RPM values.
5) Filter out datapoints that occur immediately before or after a change in VTEC state, or give an optional criteria for time before or after change in VTEC.
6) Use the TPlate and TPedal values to filter out datapoints where there is a significant mismatch between TPlate and TPedal indicating a change in state. Obviously, there are lots of conditions where TPedal and TPlate don't coincide at all, like at idle and when the cruise control is enabled, but that seems easy to overcome.
7) Add another overlay that shows the number of datapoints that were used to calculate the suggested fuel adjustment, or allow the user to enter a minimum number of qualifying datapoints in the Options window.
8) Add another overlay to show the deviation between the datapoints used to calculate the suggestions, or allow the user to enter the maximum deviation allowed for the datapoints that are used to calculate the suggestions.
9) Allow users to merge datalogs and eliminate sections of datalogs, so that they can create "superlogs" that are void of datapoints that they know will introduce error.