- With the raw data collected and logged, it's time to talk about math channels.
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.
The data we log from the car is recording the raw output of every sensor.
It's telling us how the measurement of each sensor is changing over time.
We use math channels to manipulate and combine multiples of these different log
channels to make a new channel that's useful to us.
At its most basic level, a math channel can be thought of as a simple input/output
relationship.
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.
The output of that manipulation is a new channel itself, a math channel.
The analysis software then autmatically carries out this process for us for each
log file that is opened.
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.
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.
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.
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.
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.
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.
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.
So as you can see, there are different approaches suitable for different situations.
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.
This is where we may feel the impact of data logged at an necessarily high frequency.
Each math channel is calculated individually for each data point for the channels it relies on.
So if the logging rate is unnecessarily high then this increases the amount of processing
the PC is doing in evaluating each math channel.
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.
Now let's look at some simple but helpful uses of math channels.
One common use would be to reverse the sign of a sensor output.
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.
We want to correct this so it's consistent with our sign convention.
Clearly the best option here is to reconfigure the sensor setup inside the logger such that
the logged value is correct.
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.
We can write a math channel that simple multiplies the original channel by -1
to correct the sign.
The original channel will still be avaialble in the logged data but we wouldn't use it.
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.
Another common case would be combining two channels to find the average value of both.
Which may be more useful in some situations.
Let's say we want to find the average of both front wheel speeds.
So two channels are the inputs and the math channel simply computes the average.
Both of the original channels are still available to use inside the project but
we can now plot the average value as well.
Automatically computing the ratio between quantities is helpful in a lot of situations.
For example, we can calculate the brake bias using the front and rear brake pressure
data.
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.
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.
This gives us the hydraulic brake bias expressed in percentage front.
Gating is a concept where we allow the calculation to take place in some conditions but not others.
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.
Let's take the previous case of brake bias as an example.
Naturally, we only care about what the brake bias is when the car is actually braking.
Not when we're accelerating or at mid corner.
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.
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.
Having the bias being calculated at all times just makes the plotting messy
and less readable when irrelevant values are shown.
So we can add a gate or condition that has to be met for the math to be
calculated.
That was just one of the 44 modules taken from the Professional Motorsport Data Analysis course.
If you want faster, more consistent lap times, along with an understanding of the tools used
by the pros, then you'll be interested in this course.
We start with a summary of advanced logging concepts and sensors before covering advanced
math channels, driver analysis, damping analysis and much more, before we wrap it all up with a
simple 7 step process that you can then easily apply to your own data logging projects.
This course will take you from simple sensor setups for your track day car, all the way
through to the tools and techniques used to log and analyse data for serious professional
level race cars.
If you're a serious amateur or aspiring professional, then this is the course for you.
For more information, click the link to enrol now.