Professional Motorsport Data Analysis: Math Channels Explained
Watch This Course
$197 USD $98.50 USD
-OR-
Or
8 easy payments of only $12.31
Instant access. Easy checkout. No fees.
Math Channels Explained
06.28
| 00:00 | - With the raw data collected and logged, it's time to talk about math channels. |
| 00:04 | While a lot of our analysis is done working with data in its raw form, math channels give us the ability to take things to a higher level of complexity and get creative with the ways in which the data can be used. |
| 00:18 | The data we log from the car is recording the raw output of every sensor. |
| 00:24 | It's telling us how the measurement of each sensor is changing over time. |
| 00:29 | We use math channels to manipulate and combine multiples of these different log channels to make a new channel that's useful to us. |
| 00:38 | At its most basic level, a math channel can be thought of as a simple input/output relationship. |
| 00:45 | We have an input which is either a single or multiple log channels, then we carry out a process or manipulation on that logged input data. |
| 00:54 | The output of that manipulation is a new channel itself, a math channel. |
| 00:59 | The analysis software then autmatically carries out this process for us for each log file that is opened. |
| 01:06 | The math channel itself can be treated as a new channel in its own right and we can go back and modify how it behaves at any time. |
| 01:14 | In fact, we can even use existing math channels as inputs to new math channels which is helpful in gradually building up the level of complexity. |
| 01:24 | Math channels can be defined and computed either within the logger itself in real time or in the analysis software after the data has been downloaded. |
| 01:33 | If the math is defined inside the logger, it means the output of that math channel is available in real time and can be used to indicate something to the driver over telemetry or to automatically control a system with a real output. |
| 01:48 | If internal math channels are logged, when we download the data from the car, it will appear as a normally logged channel in the same way any logged channel would. |
| 01:58 | A downside to computing it inside the logger is that the definition of the math is not editable from inside the analysis software because the data is fixed within the log file. |
| 02:10 | On the positive side, it does mean that if we have multiple people reviewing the same logged data, they don't need to math channel within their analysis project to be able to view it. |
| 02:20 | So as you can see, there are different approaches suitable for different situations. |
| 02:25 | Math channels that are defined within an analysis project are computed and updated in real time so if the definition of the math channel is updated, the output is updated instantly everywhere throughout the analysis project. |
| 02:38 | As we touched on earlier in the frequency and logging rates module, this is where we may feel the impact of data logged at an necessarily high frequency. |
| 02:48 | Each math channel is calculated individually for each data point for the channels it relies on. |
| 02:53 | So if the logging rate is unnecessarily high then this increases the amount of processing the PC is doing in evaluating each math channel. |
| 03:03 | In many situations, the user won't notice the difference but in cases where many complex math channels are defined within an analysis project, and a lot of high frequency data is loaded, the lag and load time when analysing that data can be noticeable and cause the software to become unstable. |
| 03:22 | Now let's look at some simple but helpful uses of math channels. |
| 03:25 | One common use would be to reverse the sign of a sensor output. |
| 03:29 | Let's say that the G sensor in our car has been configured within the logger such that the longitudinal channel gives positive values when the car is braking and negative when the car is accelerating. |
| 03:41 | We want to correct this so it's consistent with our sign convention. |
| 03:45 | Clearly the best option here is to reconfigure the sensor setup inside the logger such that the logged value is correct. |
| 03:53 | But let's imagine we don't have access to this because we're in a spec series that doesn't allow us to make any changes to the logger configuration. |
| 04:00 | We can write a math channel that simple multiplies the original channel by -1 to correct the sign. |
| 04:07 | The original channel will still be avaialble in the logged data but we wouldn't use it. |
| 04:11 | We'd instead name the new math channel the same as the original channel but append a core to the end to indicate the value has been corrected. |
| 04:21 | Another common case would be combining two channels to find the average value of both. |
| 04:26 | Which may be more useful in some situations. |
| 04:29 | Let's say we want to find the average of both front wheel speeds. |
| 04:33 | So two channels are the inputs and the math channel simply computes the average. |
| 04:37 | Both of the original channels are still available to use inside the project but we can now plot the average value as well. |
| 04:44 | Automatically computing the ratio between quantities is helpful in a lot of situations. |
| 04:49 | For example, we can calculate the brake bias using the front and rear brake pressure data. |
| 04:57 | The convention to represent ratios like this is the percentage that applies to the front so we want to know the percentage of the total brake pressure that is applied to the front axle. |
| 05:08 | We take the pressure for the front and divide it by the front and rear pressure added together and multiply the whole expression by 100. |
| 05:16 | This gives us the hydraulic brake bias expressed in percentage front. |
| 05:21 | Gating is a concept where we allow the calculation to take place in some conditions but not others. |
| 05:26 | This is useful because there are many cases that we might not want to carry out the calculation due to it not being relevant at all times. |
| 05:34 | Let's take the previous case of brake bias as an example. |
| 05:38 | Naturally, we only care about what the brake bias is when the car is actually braking. |
| 05:43 | Not when we're accelerating or at mid corner. |
| 05:47 | However even when the brakes are not being used, there will always be small changes in the pressure measured by the brake pressure sensors which are just measurement noise, even if you might have to zoom right in to see them. |
| 06:00 | In this case, taking the ratio of these tiny measurements, will result in non sensical bias values calculated by the brake bias math channel that won't have any use to us. |
| 06:11 | Having the bias being calculated at all times just makes the plotting messy and less readable when a relevant value is shown. |
| 06:19 | So we can add a gate or condition that has to be met for the math to be calculated. |
