Changing Table Scaling using Scaling Functions

Collection of newbie questions and common tuning concepts

Moderators: cgrey8, EDS50, 2Shaker, Jon 94GT

User avatar
Posts: 10741
Joined: Fri Jun 24, 2005 5:54 am
Location: Acworth, Ga (Metro Atlanta)

Changing Table Scaling using Scaling Functions

Post by cgrey8 » Tue Jun 16, 2009 6:36 am

Table Scaling Video:
Youtube>BinaryEditor Table Rescaling (GUFx)

Scaling Functions are used to change the Column/Row scaling of Tables. Scaling functions associate columns/row numbers with values associated with each column and row.
TableColumnRowValues.jpg (72.64 KiB) Viewed 6638 times
In BE, there are links to a given table's scaling functions above and to the left of the table assuming the table uses scaling functions. The Link spells out the PID of the scaling function (e.g. FN071).
TableScalingFunctionLinks.jpg (45.85 KiB) Viewed 6638 times
When you click those links shown above, a search window comes up searching for anything that references, the scaling function you clicked. The Scaling function is often the 1st entry in the search list although this is not a guarantee. The other entries are to inform/remind you of what all OTHER tables you will be affecting if you change the scaling in a scaling function. Most tables, like the spark tables, do not have their own dedicated scaling functions. Scaling functions are often shared by multiple tables. For instance in the GUFx strats, the Sealevel, Alt, and Base Spark tables as well as 1/2 dozen other tables all use the same 2 scaling functions to scale their RPM columns and Load rows.

Another important characteristic to rescaling tables is that table columns and rows always begin with Row 0. So the 1st row is Row 0, 2nd row is Row 1...and so on. Same with columns.

The simplest and probably the most common rescaling is renaming a row. A common scenario is a person just upgraded their engine with a supercharger and they want to rescale their Spark Table so they can represent Boost Load spark values. By default, the tune is probably setup to only map values up to around 75% Load. But Boost can run Load well above 100%. So in this application, the simplest and quickest way to handle this is to change the 75% Row to represent 130% or whatever boost Load you want. To do this, you go to the table's Row Scaling function (FN071 in GUFx strats) and change the Row7 entry in the scaling function from 75% (or whatever your tune's default value is for Row 7) to 130%. In the case of an A9L.bin being modified this is what it looks like by default:
Scaling01.jpg (16.09 KiB) Viewed 6638 times
Modify it to look like:
Scaling02.jpg (14.46 KiB) Viewed 6638 times
Now go back over to your table and notice that the top row is now associated to 130% Load:
Scaling03.jpg (65.95 KiB) Viewed 6638 times
As of the writing of this document, BE has a bug that doesn't show this modification right off. You need to select a different table, then go back to the table you were trying to rescale to see your change in effect. Leaving and returning to your table forces BE to "refresh" the table view.

When you are only wanting to modify a single row, and that row is explicitly defined in the scaling function, the above method works. However what if you are trying to rescale a row that isn't defined OR you want to rescale multiple rows at once? This is where Table Scaling gets a little more complicated. Also notice not all rows and columns are explicitly defined in scaling functions. In some cases, row & column values are assigned implicitly based on the row/columns that are defined. Look up at the screen captures above. In the example above, notice that the 50% Load Row is not explicitly defined as Row5. It is being defined implicitly.

So lets say you have the following scaling function to define RPM columns in a table:
6000 6
4000 4
2000 2
0000 0

In the above scaling function example, column 0, 2, 4, and 6 are defined explictly. The odd columns are defined implicitly. They are:
Column 1 is the 1000 RPM column
Column 3 is the 3000 RPM column
Column 5 is the 5000 RPM column

Notice the implicit column values are 1/2 way between their neighbor values. But what happens when the scaling function skips more than 1 column? Then the spread is not 1/2, it's a division of however many columns are being skipped between explicit entries. Lets say the 4000 RPM row was missing from this scaling function. This would mean that rows 1, 3, 4, and 5 are now implicitly defined. This makes the spread between 3, 4, and 5, 1/4 of the difference explicitly defined between 2000 and 6000. In this example, the values of each column without the 4000 RPM row just happen to end up being exactly the same, but that's not always the case. What if the 2000 value was actually 2500? Give it a try in a real tune. Play around with modifying some scaling functions, then flip back to a table using that scaling function to see the results of your change. Remember, you may need to select a different table then come back to your table to see the change.

Now for those that got lost in the explanation above or just feel better about knowing what math being applied behind the scenes, here's the formulas for figuring implicit column/row values from the explicit defined ones.

Vhigh = Column/Row that has the higher value
Vlow = Column/Row that has the lower value
Spread Divider = 1 + Number of column/rows skipped

Implicit Column/Row value = Vlow + (Vhigh - Vlow) / Spread Divider * Row/Column from Vlow

Note that column/row is NOT column divided by row. Everywhere you see column/row shown in the equation, think of that as column OR row.

Now lets see the formula working in an example.

Lets say you have:
6000 6
2000 2
0 0

Focusing only on the area between column 2 and 6, you have columns 3, 4, and 5 that's 3 columns defined implicitly. That's the first key piece of info so you can calculate the spread divider.

Spread Divider = 1 + 3 = 4

With that, we can find the value of column 3, the 1st column after explicitly defined column 2. The formula will look like this:
Value of Column 3 = 2000 + (6000 - 2000) / (1 + 3) * 1
Value of Column 3 = 2000 + 4000 / 4 * 1 = 3000 RPMs

Applying the same formula to calculate Column 4 (the 2nd column from 2), the formula looks like this:
Value of Column 4 = 2000 + (6000 - 2000) / (1 + 3) * 2
Value of Column 4 = 2000 + 4000 / 4 * 2 = 2000 + 1000 * 2 = 4000 RPMs

Applying the same formula to calculate Column 5 (the 3rd column from 2), the formula looks like this:
Value of Column 5 = 2000 + (6000 - 2000) / (1 + 3) * 3
Value of Column 5 = 2000 + 4000 / 4 * 3 = 2000 + 1000 * 3 = 5000 RPMs

Because of how the math works, you NEVER want to change the order of the scaling function values such that the column/row numbers are out of numerical order nor do you ever want to go from low-to-high when the default order is high-to-low.

Additionally, you never want to enter a column/row number that is greater than the number of columns/rows the table actually has. If you do, you will be introducing a potential corruption scenario into your tune that will only happen when you enter a running condition that occurs when the code thinks it needs to use a column/row that doesn't exist so a mistake like that may not be immediately obvious.

Using BE, play around with putting different numbers into a scaling function and see how it changes things.

Another important thing to keep in mind when modifying scaling functions is when you edit a scaling function, you may be affecting multiple tables. Thus you may need to go fix up other tables to ensure the table values are still appropriate for the new scaling. This is less of an issue when updating an RPM column from 4000 to be 5000. But it is a HUGE deal when updating rows for boost and suddenly rows that represented 75% Load now represent 150% Load. Spark values that are good for 75% Load will NOT be safe for 150% Load, so you'll need to fix all affected tables that boost rescaling affects.

People that have working EGRs may find that while scaling Spark tables, they also rescaled the EGR tables. Thus they need to fix those EGR tables up as well or they may find the tune trying to introduce EGR gas into the intake at boost Loads. So instead of pulling exhaust into the engine as would happen during a vacuum condition, the boost is blowing air into the exhaust which could make a Wideband in the exhaust believe the engine is running lean when in actuality, the engine is likely running WAY too rich since part of the metered air just went out the exhaust without being burned, but the fuel that was supposed to accompany that same air was injected into the engine. The good news here is while technically this could happen, it's not likely to be a real issue. Opening an EGR valve requires vacuum to open the valve. Unless your mass accumulator (aka vacuum cannister which is usually located up by the AC stuff) is plumbed to include the EGR solenoid by accident, the intake is under pressure. There's no vacuum to open the valve with. This is just an example of how you can have unexpected/unintended consequences to scaling function changes if you aren't careful and review all tables affected.

Generally speaking, Scaling Functions will only be used on Tables with like-numbers of Rows or Columns. For instance in GUFx strats, the HEGO Bias/Amplitude/Delay tables have the same number of rows as Spark Tables, but a different number of columns as compared to the the Spark Tables. So the HEGO Tables use the Spark Table's Row Scaling Function, but have their own Column Scaling function to accommodate a shorter table.
...Always Somethin'

89 Ranger Supercab, 331 w/GT40p heads, ported Explorer lower, Crane Powermax 2020 cam, 1.6RRs, FMS Explorer (GT40p) headers, Slot Style MAF, aftermarket T5 'Z-Spec', 8.8" rear w/3.27s, Powertrax Locker, Innovate LC-1, GUFB, Moates QuarterHorse tuned using BE&EA



Who is online

Users browsing this forum: No registered users and 1 guest