Navigating Atlas & Parameter Names
Introduction
When designing or data-logging a tune, it is important to not only record accurate datapoints and modify the right tables, but it is also critical that you understand what each data stream (or parameter) and table is referencing. For example, data-logging a "Ignition Timing Base Final" parameter is not referencing the same ignition timing value as logging your tune's "Ignition Timing Commanded Final" parameter. Base Final =/= Commanded Final.
Atlas as a platform is designed to emphasize very granular access to ECU logic, and therefore the definitions we release to the public are often more detailed and expansive than you may be familiar with on other platforms. Due to the increasing complexities of modern ECUs, we choose to offer definitions that give you more access in between distinct pipeline elements of all tuning areas we support. Our objective is to give you everything you need to work around OEM behavior and logic and be able to ground your understanding of the ECU logic in lower-level parameters if you choose to do so.
Having more data points to log and more tables to edit does introduce a steeper learning curve, and so our definitions can be more confusing to navigate and comprehend quickly and may take longer to get familiarized with. However, we do have several systems in place that will assist you in getting comfortable with the Atlas workflow.
Navigating Atlas
Advanced Parameters
We have a system that allows you to filter generally unimportant tables and parameters. For these unimportant items, we will mark them as advanced. By default, Atlas doesn't show advanced parameters and tables as most tuners are not trying to get quite as specific as these elements offer. You can either choose to show or hide these based on the level of granularity you are looking for in your tune by using the Show advanced button in the project tree tab.
Here are some examples of advanced items:
- Tables (or maps) that are seldom, if ever, modified in a general street tune, but have some theoretical benefit or purpose to very specific applications or scenarios.
- Flags or modes that are generally only needed when diagnosing specific tune logic issues, such as operating mode numbers, esoteric low/high signals, or decision outputs needed during development of the definition for quality assurance purposes.
- Parameters that are highly granular, such as those used between pipeline stages. An example of this might be the "Table" output of a table that has been directly computed by the ECU, perhaps after blending operations (i.e. TGV & AVCS).
Documentation Graphs
Additionally, Atlas is designed with a built-in graph editor that we use to create illustrations of ECU logic for you to explore. Laid out from left to right, several graphs are available in supported definitions that demonstrate the data flow of decisions in specific areas of ECU logic (i.e. Fuel, Ignition, Wastegate, etc.). If you are unfamiliar with tuning a platform, we strongly recommend taking a look at these. If you'd like to look up a table or parameter in a graph, right-click it in the project tree and click Find in Graph. This will automatically open the corresponding documentation graph, center the parameter or table you are searching for, and highlight it with a flash of yellow.
Parameter Names
Atlas does not have a strict standard for naming rules, but we do offer a dictionary of terms that assists in developing a loose standard for helping end-users understand what each parameter is intended to imply to you.
|
Naming |
Description |
Example |
|
Table or Base Table |
The value immediately after performing table lookup and any associated blending has been applied. For example, in the case of Subarus, this would be the result of all associated TGV and AVCS blending has been calculated on a given 4- or 5-dimensional map. |
Ignition - Primary - Base Table |
|
Base Base Final Final |
For different stages of a pipeline, Base and its corresponding Base Final may be used to distinguish distinct book-ends of a pipeline operation. For example, when combining ignition timing, there may be a "Combine Base" and a corresponding "Combine Final". It is also possible for parameters to be named simply as "Base" and "Base Final"
|
Idle - Target Airflow - Base - Base
Idle - Target Airflow - Base - Base Final |
|
Corrected |
For referential data in the ECU, and especially for the Mass Airflow (MAF) sensor, Corrected is used to name the corrected value of some base parameter, and is generally used by the ECU instead of a corresponding base parameter for its own calculations. |
Airflow - MAF - Mass Airflow Corrected (g/sec, uint) |
|
Primary Secondary |
These are placeholder names that names a parameter whose behaviors and relevance have been yet-uncharacterized. |
|
|
Target |
Target is used to name a parameter that the ECU will reference through some other proportional/integral control system; this is also knows as the set-point in closed loop control systems. Targets are not commanded to the hardware electrically.
A target might be, for example, the target airflow used to determine the commanded throttle position. Note that in this example, the target isn't commanded to the hardware, but the throttle position references the target and is commanded instead.
Another example would be boost. Boost pressure cannot be commanded; instead, the waste-gate position is 'Commanded' by using the boost target and target torque as a wastegate position table that is then adjusted through its own closed (or open) loop control system, referencing the 'Main Boost Target' table as the set point.
Targets may themselves be split into their own Target Base and Target Final sub-parameters. In these cases, Target Final will be the target that is referenced by the ECU for closed loop control, while Target Base is left in the definitions for diagnostic purposes and will likely be marked as advanced. |
Idle - Target Airflow - Target Base (g/sec, ushort)
Fuel - Targets - Closed Loop - Target Final (λ, ushort)
|
|
Commanded Final |
For parameters that involve digital to analog conversion (DAC), such as ignition timing and fuel pulse width, Commanded Final references the last available value before the ECU physically commands the associated hardware elements to take action. No other modifications or alterations of the value takes place in the pipe-line after this point.
In the case of ignition timing, this would be the amount of time referenced to determine a timer delay for ignition spark from the MCU.
For direct injection fuel platforms, this would be the pulse width of the signal sent to the injectors through any associated amplification hardware present on the ECU. |
Fuel - Pulse - Commanded Final
Ignition - Commanded Final
Airflow - Turbo - Wastegate - Position Commanded Final |