WinOLS Mastery: Map Identification & Editing: Using Logged Data to Find and Validate Maps
Watch This Course
$299 USD
-OR-
Or
8 easy payments of only $37.38
Instant access. Easy checkout. No fees.
Using Logged Data to Find and Validate Maps
02.43
| 00:00 | - One of the problems with tuning modern ECUs is that you'll often find that there are a multitude of maps for the likes of lambda targets, ignition timing and requested torque just to name a few. |
| 00:11 | These various maps might be switched between by the controller based on the likes of knock activity, barometric pressure, gear, speed, or any number of other things the manufacturer may have considered important. |
| 00:24 | Often we may find that many of these maps are never actually used in a specific controller. |
| 00:30 | This can however make it hard for us as tuners to know how to approach making changes to these maps. |
| 00:38 | A common technique is to simply make all of the maps the same or alternatively make the same magnitude of change to each map. |
| 00:45 | How you approach this is very much a personal preference but either of these approaches has the potential to, in some cases erode some of the safety the manufacturer has intended in the first place with these maps. |
| 00:59 | A more thorough option is to use our logging to help validate which map the controller is accessing while we're performing our tuning and if we want to get a little bit more involved, it's often possible to start drawing some conclusions around how and why the ECU will switch between various maps. |
| 01:17 | This might for example help us identify the current ignition map by logging the ignition timing as well as the parameters used as the axis for the tables we're interested in. |
| 01:27 | We should then be able to line up the logged value for ignition timing and the location with the specific table that was being used. |
| 01:36 | This is just one example and I've purposefully kept it simple, however it's important to understand that there may also be modifiers acting on the final value relative to the likes of charge air temperature or something similar that makes this process just a little more complex. |
| 01:52 | The other way we can use our logger would be to highlight something like a single value boost or charge limit. |
| 02:00 | Often this will undo all of our hard work trying to raise the boost pressure and because this is a single value it can be quite hard to find if you don't know that it exists and where to look for it. |
| 02:12 | On the other hand, if we've logged the boost pressure where our limit appears to become active then we can search through the binary file for instances of this value. |
| 02:21 | Remembering of course that the boost limit in the binary file will be unscaled. |
| 02:26 | These are just two instances where datalogging the engine in stock form can help us with the reverse engineering process in WinOLS but of course there are plenty more cases where careful use of the logger can be a huge benefit. |
