Summary

A lot of focus in math channels tends to focus on math inside your analysis software. This webinar will look at some uses and techniques for defining math inside your logger so it can be used in real time, both for the driver and engineers.

 

00:00 - Hi guys, welcome to today's members' webinar where we're talking all about live logger math.
00:05 Now what I mean by live logger math is math channels that we are computing inside of the datalogger itself as opposed to computing them inside of the analysis project which is the more typical way people are usually familiar with math channels.
00:18 Before I get into that, I just wanted to do a little bit of a refresher on what a math channel is and how we use it so we'll go through a little bit of that now.
00:27 If you come across to the overhead camera, essentially the way we use math channels is we've multiple streams of data coming into our datalogger, now this could be, this is our logger, we've got things like wheel speed, engine speed, we might have things like steering we might have brake pressure, whatever, all the different things that you can log and go into your logger.
00:52 Now the point of a math channel is that we're doing something inside of the logger, some operation where we're taking a combination of inputs, so that can be either one or multiple inputs, doing something to them, some operation and sending it out as a entirely new piece of information.
01:08 So the idea here is that you can take, as I said, either one or multiple things and do some sort of mathematical operation, maybe you're adding 2 things together, maybe you're taking the average, maybe you're looking for the maximum and the minimum, we'll go through lots of examples of the kinds of things we can do with math a little bit later but essentially all we're doing is manipulating some of the initial data and using it to do something useful.
01:31 Now the way we're often using math channels and certainly what we talk about the vast majority of everything we talk about inside both of our data courses, that's our data analysis fundamentals and our professional motorsport data analysis course is more focused around math channels that you are using inside your data analysis project.
01:48 So what I mean by that is we've already downloaded the data from the car, we've got it inside our computer, inside our software that we're using to visualise that data, then we're going to make math channels and modify them and update them into post processing that data that we're going to review after the fact, after the data has already been gathered from the car.
02:08 Now when we're talking about doing it live inside the logger, you can probably guess, we're doing similar types of math but we're doing it in real time and all of those math channels are being computer inside the logger themselves.
02:19 So it's going to depend a lot on the sophistication level of your logger, if you're starting with something more entry level, the complexity of the math, for a start there may be no math definable at all or you may be only able to do basic math or you may be limited on the number of math channels you can define in there.
02:37 At the other end of the spectrum, let's say a more high end system, it's almost limitless what you can do, you can do some really complicated math, there's some really high end processes in some of these modern high end loggers.
02:49 So you can do some really really trick and clever stuff in real time and there are a few different advantages to doing it, there's also pluses and minuses in different directions.
02:56 So one of the pluses of doing things in your analysis project is that you've got the flexibility to change the definition of the math.
03:04 So let's say you've got the car come into the pit lane, you've downloaded it, now you've got the data inside your computer, now if you want at any stage later, you want to update the definition of how your math works, whatever channel you're computing, you've got the ability and freedom to do that.
03:17 If it's being computed inside the logger then that math channel which is going to be output in the same way that any other log channel will be, it'll be available to you just in the same way a log channel would be, its definition is not updateable, you can't go back and update the definition of that, it's essentially that value has been logged as it was computed inside the logger.
03:36 Now the upside of that is that it means if all of the math that's computed inside the logger doesn't then need to be held inside each person's analysis project.
03:45 So let's say, the demonstration I'm going to use for today is going through a MoTeC system, that means in my MoTeC project, anything that's computer onboard inside the logger, anyone can open that data and have access to those logged math channels without having to compute them for themselves inside their analysis project.
04:03 So you can see there are a couple of different pluses and minuses depending on what's most important to you.
04:08 Obviously one of the biggest advantages with doing it onboard the logger in the first place is that we've got options to use anything that's happening inside those math channels in real time either to control logic on the car or to display something to the driver, and we'll go through lots of different examples of that today and I'll show you guys exactly how you can make use of that for youself.
04:28 Before we get any further, I just want to show you guys an example of how we use this typical math channels inside of an analysis project just to give you guys a little bit of a refresher if you haven't seen them before.
04:38 So over here on my laptop screen I've got some logged data in MoTeC's i2 software.
04:43 i2 is simply just the analysis tool that goes along with MoTeC's logging package.
04:50 So if you've, typically each logger manufacturer will supply their own software to visualise that data so for example if you've got an AiM system, AiM provide a piece of software to visualise all the data, same with MoTeC, same with VBOX, same with PI and Cosworth.
05:06 They all essentially have their own data is designed to be viewed in their own logging system so that's all i2 means, it's just MoTeC's piece of software.
05:13 So here I've got some logged data.
05:15 The actual log data I've got on my screen here isn't important right now because all I want to talk about is the math channels.
05:19 So if I just bring up the math channel dialogue, I've got some basic examples here, so this first one, this is a really simple example, you can see this is how the math is defined, we've got the name of the math channel up here, I'm just saying steering angle corrected, this is just doing a correction on the steering angle.
05:38 In this particular situation, this is where I might want to reverse the sign or invert the sign of a steering channel which is something you want to do sometimes.
05:46 Usually the best way to do this is to invert the signal inside the logger so the correct signal gets sent directly to the user but in this case as an example I just did an inversion on the software side rather than on the logger side just as an example.
06:01 You can see we've got some definitions of units here.
06:03 But essentially the way the math channel works is we're taking the value of steering angle which we can see the way MoTeC shows is that when we've got a log channel shown, all we need to do, it's shown by bold so here we're taking the steering angle which is a logged channel coming out of the logger and I'm just multiplying it by -1 so here we've got the syntax says -1 times steering angle is going to be the output of steering angle corrected and that means that the corrected value of steering is going to be inverted to the original value of steering so that's just a simple example of how we might use a math channel, we've got a couple of other examples here.
06:37 So let's say, something a little more complicated, I've got one here for wide open throttle lambda so that's what WOT lambda means, WOT usually stands for wide open throttle so one of the times you're going to care most about what your lambda readings are is when you are at wide open throttle so the problem is looking at lambda without gating it or without looking at it just at the wide open throttle is that you end up with so much variation and it ends up swamping what you're usually really interested in looking at.
07:02 So if you're only looking, interested in full power or wide open throttle you can put a gate on here to say I'm only interested in the lambda value when we have a wide open throttle condition so that's all this is saying.
07:12 So if we go from left to right here, this is just choose is just MoTeC's syntax for how it does a gating function so basically it's saying if this, do this, otherwise do this.
07:23 So there's 3 parts to it.
07:25 The first part here is we've got choose statement and it says throttle position greater than 95% so that value of throttle position needs to be greater than 95% for us to evaluate this properly.
07:35 The next part of it says, so we've got a comma separating here, the next part says lambda left, so that's saying that's the true part so what this is saying is if throttle position is greater than 95%, it'll give me the true part which is the value of lambda left which in this case is the particular lambda sensor I want to look at and then the third part to this expression is this invalid, an invalid statement is simply MoTeC's syntax for saying nothing so return nothing so what that's saying, from left to right that's saying, if throttle position is greater than 95% tell me the value of the lambda left, otherwise tell me nothing, show me nothing.
08:11 So that would be no value or null value shown to the user.
08:14 Let's see if we've got any other useful points here.
08:18 Here's another one on smoothing.
08:19 So this is essentially just giving us a smoothed value of damper position.
08:23 So smooth function is simply just, essentially applying a moving average filter to the signal so instead of having very, let me just sketch that to make it clearer, instead of having a very, if you've got a very rough signal like this, it's essentially putting a moving average filter so it's essentially having a moving window that's moving throughout the data and it's essentially applying a moving average so as this window moves through the data it ends up applying a smoothed, essentially a smooth curve to what would otherwise be really noisy data so there's lot of different ways and reasons you would use smoothing, we've been through it in some previous webinars where we've been talking about advanced data analysis.
09:01 But this is just an example of how you'd apply a smoothing function.
09:05 So all of these are examples a lot of you guys would have seen before but my point is that all of this is actually happening inside the analysis software but we're talking about taking the same concept but doing it live and onboard the logger instead.
09:18 So let's have a look at a configuration, so I'm going to bring up here, the next thing I'm going to bring up is an example configuration so this is for a MoTeC dash unit, the idea here with this software is this is what we use to do all of the programming of the logger or the dash so in some cases it's going to be a combined logger dash and in other cases it's going to be a black box, I've actually got one physically sitting up here that's what we see on the screen but this is really similar to the unit that I'll be applying the configuration to today so essentially it's just an aluminium casing.
09:58 We've got an electrical connection on the back and then we've got a display for the driver and then we have up here also some lights that we can use that we'll go through a few examples on how we can use those lights as well but essentially a lot of the time it'll be if we want to make changes to the way, what's displayed to the driver and everything through this screen and how the logging is working, we're going to do all of that through this configuration software here.
10:22 So to start off with I guess onboard logging math is something that probably tends to scare a few people off, it sounds complicated but the first thing to understand is that there's actually a lot of built in math happening inside your logger anyway that's already got baked in functionality that's a lot of the hard works's done for us and we're just tweaking some of the parameters.
10:42 One of the examples of that is a shift light.
10:44 In a way it's kind of a math channel, it's just some built in logic where we are telling it at different engine RPM steps when we want each shift light to turn on at.
10:52 So let's go through and look now that is defined here.
10:55 So we've got a place up here to define our shift light logic, so I'm just going to start off with a simple configuration here.
11:03 We don't need to worry about too much of the details of how MoTeC implements it, I'm not really too interested in going through all of this but essentially we just define which channel we want to use for engine RPM and then if we go into the upshift mode here, we've got 4 lights selected so that means we're going to have 4 stages of lights we're going to use for our shift lights.
11:21 These channels are going to be output as a result.
11:23 So in some situations, we'll be sending this to an external shift light module if it's in the case of a unit something like this then we've got the ability to use these lights for whatever we want including shift lights so in this particular case, all of those messages are going to be handled onboard the logger inside itself.
11:38 But the point I really want to get to here is this section down here with the settings which essentially all this is saying is which RPM point each shift light is going to go on at.
11:48 So this is a super simple example but it's essentially a concept similar to onboard logger math, it's already all set up for us and we're just putting in different parameters but that's an idea of what a logic equation might look like so essentially all that's saying is that at 4500 RPM light 1, 5200 light 2 so on and so forth until we get to 6600 and light 4 will go on.
12:10 So you've also got the option of going with a more complicated pattern and all this means here is, sorry let me just get rid of that, so I'll come back into it.
12:21 So in the simple definition of shift lights it's just at any time the engine speed is above those values it'll turn the logic on for those lights.
12:31 You can do a gear dependent one as well so what you're quite often doing is tuning your shift lights quite specifically for each gear to maximise the accuracy of each shift light.
12:42 So because you have a different acceleration rate in each gear, the lower gears you've got more torque available or more force available, more force available from the tyres, your acceleration rate's higher and as a result you tend to have to time your shift lights differently than what you do at higher PRM so the goal traditionally is to have the shift lights on for equal intervals of time so the driver can get into a rhythm for it.
13:04 But essentially all we've got here is a gear dependent light version.
13:08 So you can see here we've got 1, 2, 3, 4, 5, 6 gears in here and for each one of those lights we've got a different engine RPM point, shift point for each one of those gears.
13:16 So again, really simple example but that's essentially one way that's already built in to make use of onboard logger math.
13:23 We'll get into a couple more simple examples about how they can work so I've got one here for user conditions that I want to go into.
13:31 So if we go across to user conditions you can see there's a whole lot of different options here, different ways they define math, I'm going to go through a few of them today, I'm not going to get too bogged down with the different syntax or how MoTeC deals with it, it's more the concepts that I want to get across here.
13:47 So one of the things that MoTeC has available to it is the idea of user conditions.
13:52 Basically it's a pre defined template setup to say basically if this thing is true or if this set of conditions is true then do this.
13:59 You can sort of see how there's a bit of an analogy here to what we had set up in the math channel function of the analysis software but the way the logger tends to break it up is to try and make it a little bit easier, make things a little bit more pre defined and set up these templates for you so that's kind of what a user conditions is, rather than writing the full syntax of the math channel out which we'll get to a little bit later which you can do with some more complex math, this is essentially a pre defined template to say if these conditions are met then give me this value and that's something you can use in logic control later on.
14:29 So essentially all this value I'm looking at here, this value into pot, all that means, maybe the wording on that is a little bit strange but this is talking about a fuel pot so we've got our main tank and we've got our surge tank which is what some people call a fuel pot, the idea here is that we've got a level sensor inside that fuel pot and particularly when you're doing endurance racing or when you're getting really accurate with your fuel calculations, it's really important to know how much exact fuel you've got left in your fuel pot so usually you're doing a fuel calculation the whole time so you know pretty accurately but still approximately you're calculating how much fuel you've used based on a fuel calculation that's coming from your engine's ECU.
15:09 So in real time, the engineer's will be looking at how much fuel's being used, how much we're going to be calculating constantly, how much further you can go, when your fuel windows are, how far you can go, when it the soonest you can go back on how much fuel you can use, all this sort of stuff but this channel is just giving us essentially a bullion or an on/off signal for whether we are into the fuel pot and what I mean by that is whether we've started to use fuel out of that surge tank 'cause once the main tank is completely exhausted, at that point the surge tank or the pot is no longer going to be refilled and from that point once the fuel pot starts getting used, it's going to continually go down, obviously you know you're going to need to make your pitstop pretty soon.
15:46 So this is just essentially like a warning light to say here we've got 2 different ways of defining this, we've got a momentary and an activate/deactivate which we can think of as latching.
15:56 So momentary type condition is only when this thing is true, it'll be on and it'll automatically turn off as soon as that condition is no longer true within a latching or an activate/deactivate which is what we've got selected up here.
16:08 That's saying we've got our activate box up here and our deactivate box down here so that's going to say, as soon as this condition is true which is fuel level surge tank which is just a channel that we've got available in our logger, a value with less than 5.7 litres, that warning or that value is going to switch to 1, it's going to become active and it's not going to become inactive until this condition down here which is fuel level surge tank greater than 6 litres for 2 seconds so let's dig into a little bit how those are defined.
16:36 So you can see how we've got some of this logger math predefined for us, these templates these user conditions.
16:41 It's essentially doing a comparison so all we do is select the channel that we want to do the comparison on so we've got the fuel level surge tank so that's a value that's being logged by the logger from a sensor inside the surge tank.
16:52 We've got different options here for how we can, what sort of logic we can do with it so in this case we're doing less than but you can see we've got greater than and equal to or equal to.
17:01 True, false whatever it is, you can choose whatever suits your application.
17:05 Then we input a value here, so this can either be a fixed value or a constant value like we've got selected here or it can be compared to another channel that you've got live updating in your logger but in this case it's just a fixed value and then down here we've got for a number of seconds.
17:21 So from top to bottom, all this reads is the comparison is, give me the value of the fuel level surge tank if it's less than 5.7 for this much time, that value goes true and then on the other side of the deactivation it's saying the fuel level surge tank must be greater than 6, a value of 6 litres for 2 seconds, so that's a time where we're actually using that timing function so it's essentially just giving you a bit of a hysteresis on that so it has to be true for a certain amount of time before it will come true and the idea here is that you don't necessarily want this value flicking on, off, on, off, on, off you want it to be more steadily true for a while then that value of the into pot which is the value we've got shown down here, that value of the into pot will be called 0 again once that deactivate condition is true.
18:14 So that's one way MoTeC handles some of the templates for what we call user conditions.
18:19 Another built in function or pre defined math function that a lot of loggers have is the idea of an alarm.
18:27 So I've got an example here of an alarm I wanted to go through.
18:32 So you can see we've got lots of different alarms configured in this particular logging configuration but this top one here is turn off engine.
18:41 So this is something, a message we're going to show to the driver so it's not something we're controlling with logic as far as going to have a real output in the car, it's just that we want to display something really obvious to the driver to make sure we turn the engine off if we lose oil pressure.
18:55 So if we go through, we can see the structure of this template for an alarm is a little different to what we had for user condition but we can also see a lot of similarities so this is the conditions so you can see we can have multiple sets of conditions so there's multiple types of things that can trigger this alarm but in this particular case we're only using 1 comparison or 1 set of conditions so there's 2 things that have to be met here, the engine speed must be greater than or equal to 3000 RPM for 2 seconds and the engine oil pressure needs to be less than 5 psi for 4 seconds.
19:25 So if we go into the logic we can see it's really similar to how the user conditions work.
19:31 We select our value that we want to do the comparison on, we select the comparison, we select the value, again that can be a constant value like we've got defined here or another channel and then we've got our timing on there as well, must be greater than 2 seconds and as you'd expect we've got something really similar for the oil pressure here, the oil pressure must be less than or equal to 5 psi for 4 seconds.
19:51 So when that's true, in the message tab here it's going to send this message, the way this is defined for MoTeC anyway is that these messages are always available to whatever display you've got.
20:04 So particularly if you've got a MoTeC display, any of these messages you've got defined as alarms become available to use and to display to the driver as and when you want.
20:12 So that's another example of how alarms work, I don't think there's anything else too interesting in here but that is an example, another way of a math channel like input that we can use that's already pre defined inside our logger that we don't actually need to write from scratch.
20:29 Let's see what else we've got here.
20:31 So a more basic example of something that's actually written by the user or something a little more complicated is we've got an example here under channel maths.
20:40 So channel maths is again another simplified type of math channel, it's another category you can kind of see how each one of these different styles or templates of math channels is useful for different situations.
20:52 There's all sorts of different ways you can achieve any of these pieces of logic, it's important to understand that there are usually multiple ways of achieving the same thing, it's really just down to how you've decided to make it work or how you're making it work depending on how you want to make that data available to other things, either inside your logger or to a dash or to your ECU or how you want to send that data.
21:10 But the example I wanted to go through here is the example of converting a raw suspension signal into a damper position signal.
21:21 So what I mean by that is we've got a situation where we've got a suspension position signal which in this case is just the raw value, the raw suspension value that's coming off our damper pot.
21:33 So we're looking at one corner of the car, one of the damper potentiometers, there's a raw channel coming off that which is not meaningless but essentially it's mapping a voltage to a position but the value of that isn't so useful by itself.
21:47 We usually want to apply an offset to it based on our current ride height position so we can actually use it for something reasonable.
21:53 What I mean by that is we can then, if we convert the raw suspension signal into a usable damper position we're essentially mapping the raw signal to a real signal that means, that's telling us where our damper is within our stroke.
22:07 Now what we've got here is we've got an input, sorry we've got 2 inputs and we're going to have an output, so we've got an input tab here and an output tab, I'll go through from top to bottom how this works.
22:19 So essentially we've got this suspension position front left signal, so that is a raw, as I said, that's that raw damper signal coming from the damper potentiometer.
22:29 Then we've got the option here to apply some operation to it.
22:32 So you can see we've got lots of different operations we can apply to this thing.
22:35 We've got add, subtract, multiply, divide, we've also got some more complicated ones that we've talked about in the past, things like integrations and differentiations depending on whether you want to integrate or differentiate over seconds, minutes or hours.
22:47 Mins, maximums, toggles, absolutes, whatever it is, there's lots of different operations you can apply to that channel and then get to an output.
22:54 So if we were to for argument's sake do an integration over seconds, that second option for having another channel in there becomes, it doesn't mean anything anymore so it's disappeared but let's leave it as subtract, what we had in there before.
23:07 So essentially what that's saying, it's saying subtract, take the damper position, subtract this value which can either again be a fixed value like we saw with constants but in this particular example, we're subtracting a damper offset value so for this particular situation this would be taking a damper offset value that your data engineer would typically record from the car when the car's in the setup patch, the idea here is that mechanics go through the entire setup of the car, everything's sitting on the patch, the car's sitting level, it's essentialy ready to finish the setup and put the car onto the trailer but the last thing you want to do, sorry the final thing you want to do before you take it off the setup patch is to make a note of the suspension positions, you apply that raw suspension offset as a value, you can then program that into the dash and by using, subtracting that offset value from the raw value, you've now got a usable value so that means that at ride height you've got sort of a new virtual channel which is going to be a damper position rather than suspension position that's going to show a value of zero when the car's sitting at its static ride height.
24:06 So if we go over here to the output channel you can see the channel that we're outputting here is damper position front left so just a reminder we had suspension position front left as the input channel and the output channel here is damper position front left so that's what we're going to get out of it.
24:20 Now you've got also some more options as far as the logic, we've got the conditions we can assign here so you've also got the option of only evaluating this expression when something is true so it says we've got no conditions in here and we will see an example soon of how these conditions can be used to turn that value on and off but we've got a little bit of an explanation here that says leave blank if assign always and that means if there's nothing written in those conditions, that means that calculation will always be done, there's no time when it won't be done.
24:55 So the other example I thought was quite interesting to go through was an example of the ride height.
25:01 So what we're taking here is the value of ride height and we're only going to compute it at certain times.
25:09 So the actual calculation of the right height is done elsewhere in the logger, that's another math channel that's being computed, I'm going to go through a couple more examples and you'll see how something more complicated like that can be defined but essentially it's not important how we're going that ride height calculation or what information we're getting that from, we've got some information coming in, we're doing a ride height calculation and we're using this channel math to only compute a certain value at certain times.
25:33 So input channel here is ride height front so that's our input channel and our calculation type here is none so we've got selected one from there, so we're doing no operation, we're not doing any manipulation on it, all we're going to use this for which we'll see next is the gating function so the input here is ride height front, the output is ride height front at 40 kph.
25:55 Now the meaning of that, the physical meaning of that is to give us an understanding of what the ride height is when the car's in the pit lane.
26:02 The reason we often do it in the pit lane is because we want to have a rough estimation of what the ride height is when the car is unloaded and one of the common places to do that is to use the car when it's in the pit lane or travelling steadily to give an esimation of the ride height.
26:19 One of the reasons, or one of the ways you might want to do that is let's say we did our damper offset like we talked about before, so you could use that for your ride height calculation straight away.
26:28 The problem is, let's say you go and then do a ride height adjustment throughout your session, now your ride height calculation isn't realistic anymore, without any additional inputs to your software.
26:39 The idea here behind doing a ride height calculation in the pit lane is that essentially you're giving yourself a new reference for when the car is in the pit lane travelling steadily so as we'll see here in the conditions, essentially when the car's not accelerating, when it's driving in a straight line, driving at a constant speed, a low speed, the low speed's important because we don't want to be doing this when there's any downforce on the car because that would be offsetting our ride height measurement as well.
27:01 But essentially what we're doing here is coming up with a datum position, making an estimation of the static ride height when the car is in the pit lane so let's go through this condition here.
27:10 So we're taking the raw ride height value and we're only going to output it when we're travelling in the pit lane and this is what we're using this condition for that we talked about in the previous example.
27:21 So just reading this out here it says assign expression to output channel, if any of the following conditions apply.
27:27 So we've got the option to specify multiple conditions here, we're only using one of those conditions but because we've got this and in between each one of them, it's saying that each one of these things needs to be true for this thing to be calculated, for this ride height value to be output so let's go through them one by one.
27:43 So it's saying here, the pit switch must be true for one second, so we dive into that, it looks really similar to what we've seen in the past.
27:49 So we select a value, we select the logic that we want to apply to it so in this case it just says pit switch true for one second down here.
27:58 The next condition is brake pressure less than or equal to 14.9 psi so that's obviously going to be a value that's going to be different it's going to be car dependent.
28:07 In this particular case it's just saying the driver is not using the brakes but this is because when we're sending this ride height situation out, we don't want the car to be braking or accelerating, we just want it to be travelling steadily in a straight line.
28:20 So we know one of the ways we're doing that is with our pit switch, that means the pit limiter's on, that means the car's travelling at, should be travelling at steady speed.
28:28 We're using the brake pressure here to ignore then time when the car's entering the pit box and when it comes into its pit stall, obviously the driver's going to use the brakes to stop the car.
28:37 Any time that the brakes are on, we don't want to be using, taking the ride height for this estimation of the static ride height because obviously the car's going to be pitching when the brakes are on.
28:46 We've got a value here for the absolute value of the steering angle.
28:49 So that's just simply looking at the abs steered angle and all abs means, absolute, it just means taking the value, whether it's, all we're interested in is the magnitude, not whether it's a negative or a positive because obviously you can have negative steering one way and positive steering the other way, this is the convention, normally left hand corners are positive and right hand corners are negative.
29:10 But we're just taking the absolute value of that so all we're interested in is magnitude not the sign.
29:16 And we're saying it has to be less than or equal to 0.5°.
29:18 The idea here with that one is obviously we only want to look at the ride height when the car is travelling in a straight line.
29:24 We don't want anything taken into account when the car is either turning through a pit lane because lots of pit lanes are different, some of them have windy parts where the car's going to be slaloming through cones and different obstacles, maybe missing other cars or even pulling into that pit box before they get into the brakes.
29:40 We want to ignore all of that because obviously that's going to change the dynamic ride height that we've got in the car and the last one here is that ground speed must be greater than or equal to 35 kmh.
29:51 Again, that's just because we're interested in having constant speed only.
29:56 We don't want to take times when the car's oscillating or slowing down or speeding up out of the pit box.
30:01 So that's a little bit of the logic there and how we might use that condition value for doing something like an estimation of the ride height when the car is static.
30:12 So we're sort of slowly building up more and more complexity here in these examples.
30:15 The next one I want to look at which is quite common which is looking at the locking math.
30:21 What I mean by that is an indication to the driver of having a brake lock so I'm just going to bring up an example of that here.
30:28 We'll come down to our advanced math section and I've got a couple of channels here, the ones I'm going to specifically focus on for a start are locking low and locking high so I'm just going to open that one there and we'll go through in a second.
30:40 So the way this is often used is we have, what's quite often happening is you enter a corner, you want to give the driver warning that you've got a brake lock starting.
30:51 So obviously once the wheel's locked it's going to be usually relatively obvious to the driver but what we're essentially doing is trying to give him some warning of that so they can do something about it before it gets too late and we completely lock up that tyre.
31:01 And the way we often indicate that is with a series of lock lights.
31:04 So these lights up here, this is one way you could do it.
31:08 Obviously a lot of people are using these for shift lights but the beauty of using a really advanced logger of something like this is you can use these lights for all sorts of things and sometimes in some cases simultaneously they can be doing multiple functions at the same time so one way we could be using this is to display brake locking to the driver.
31:25 Now showing it visually with either a value on the screen or lights on the top is one way you can also use this logic to trigger something audibly so in the past I've been involved with teams where we've transferred that locking signal via essentially an input via their radio into their ears and the idea here is that a lot of people find it naturally quicker to react to audible sounds than they do to visual things so the idea here is it wouldn't matter what they're seeing on their dashboard, or where they're looking or where they're looking at the car in front or out the side of the window or wherever they're looking, they would always get that warning coming through to them and we would essentially vary that tone in the same way we would vary those lights in response to the amount of brake locking you're getting.
32:07 So usually that brake locking is happening on the inside front tyre, you turn into the corner, the inside front tyre is going to be obviously trying to slow the car down but it's obviously much more lightly loaded than the outside tyre because you've got some lateral load on it already so that inside front tyre is usually what we're most interested in protecting as far as stopping locking.
32:27 So the idea here is that we've got in this particular example we've got 2 states of locking, well 3 states really.
32:32 First state is none, there is no locking, the second state is low locking intensity and the third state is high locking intensity.
32:39 And this is a channel that we're using to define which of those 3 cetagories we're in and depending on which of those categories we're in, we can show, use different logic to apply either audibly or with a message on the screen or with the lights or whatever output you're controlling.
32:53 So the particular channel I've got here is front left locking low.
32:57 So that's just looking at what's happening with the front left tyre and looking at the low intensity locking.
33:02 So this display here is starting to look a little bit more general purpose and what I mean by that, it's quite similar in layout to what we have inside the analysis software and the good thing about that is it's starting to become a lot more flexible.
33:13 We can start to do more complicated things with more channels and start to use more of the power that the logger has to do more complicated things with it.
33:22 So in this particular case, let's go from top to bottom what this means.
33:26 It says at the top that's going to be the name of our output channel.
33:30 Front left locking low, so that's the channel that we're going to be outputting this comparison on, the result unit is an on or an off, that means a 1 or a 0 or a bullion value.
33:40 Just means it's on or off, there's only 2 states to it, there's no intensity value, it's just an on or an off.
33:47 And here's where it starts getting interesting in the expression.
33:50 So we've got that choose value here which is again exactly the same syntax and same name as what we use inside the main MoTeC i2 software when we're on the analysis side, it's the same logic, works in exactly the same way.
34:00 And the way it's broken up here is nice into different lines because it makes it a little bit more readable so let's go through it line by line here.
34:08 So the first part of the choose statement as we remember from before is the comparison it's saying these are the things that must be true for this value to be evaluated so what it's saying here, is wheel speed front right minus wheel speed front left, must have a value of greater than or equal to 20 and both of those are in units of kmh so it says the difference between those 2 wheel speed signals must be at least 20 kmh.
34:34 And the wheel speed front right minus wheel speed front left must be less than or equal to 50.
34:43 Now that's important because it's saying it must be greater than 20 but it must be less than 50 so that's the sort of bound that we've defined in this case as what a low lock intensity is going to look like.
34:53 And you've probably guessed how we're going to use the high lock intensity next but essentially it's important to understand that that's giving us our bound.
34:59 So greater than 20, less than 50, that's our zone in the middle that we're considering anywhere between 20 and 50 is what we're considering a low locking intensity on the front left corner of the car.
35:09 The other condition here is that the brake pressure must be greater than or equal to 50 psi so one of the reasons you might want to do this is let's say you've got a situation where you're turning into a corner and it's not that you've got a genuine brake lock situation, it's that maybe the inside front tyre has come off the ground and in that case, even though you may still be trail braking, it's not really a properly locking situation because of the tyres completely off the ground, any amount of brake force, any tiny amount of trail braking is still going to essentially stop that wheel turning so in that case if you've got the wheel off the ground, you don't actually care about locking, it's not a real locking signal that we really care about so that's why we're using this value of greater than 50 because it's only when you're doing a really heavy braking event and then we've got this last condition here which is an ignore lock which is just a way for us to control, another, a separate math channel that we control separately in the logging configuration that says there might be certain parts of the track that we want to ignore locking.
36:04 So there might be some tracks, particularly when you've got a lot of elevation change where you might again have wheels off the ground when you're in the middle of a braking event so there might be certain times when you can gate those out based on distance where you might want to be ignoring that lock so that's just saying, ignore lock must equal zero, that's just saying this other channel that we're evaluating elsewhere must also be equal to zero.
36:25 Now all of those conditions that I just went through, they must be all true or met and if they are we're going to get this value of 1 here which is what we see and then comma 0.
36:34 So the way that's working is saying if all of those conditions are true, the output of the value of this channel will be 1, the value of the front locking, the front left locking low channel will be 1, if any or all of them are not true it'll be equal to 0 So hopefully that's clear and as you see we've got the option to add comments here which is just a way to maybe keep track of how you're evolving your math channels.
36:56 We've got the ability to come down here and choose any of the logged or other math channels we've got available inside the logger and we've got all of the functions we'd expect to see down here as well.
37:08 Which a lot of similar functions than what we'd expect to see in our normal analysis software as well.
37:14 So hopefully you can see the similarities, let's go through to the high value locking as well just for completeness here.
37:20 So I'm sure a lot of you can already anticipate exactly what this is going to look like.
37:23 We've got our same familiar choose statement and then we've got the comparisons which is wheel speed front right minus wheel speed front left must be greater than or equal to 50.
37:32 The brake pressure must be greater than 50 and ignore lock must be equal to 0 so it's really similar to our low lock expect it's only looking at the a greater than 50 part so before in the low lock it was between 20-50, now we're only looking at 50 and onwards when we're going to consider a high lock.
37:47 Now those 3 states, what we might have, 1 way we might display it to the driver is you might have no lock, you'd have no lights, low lock you might have a few lights, or a colour, let's say yellow to indicate low locking intensity on the front left and then maybe when you've got high locking you might have a few more of them and change them to say red lights or something like that so from the driver's perspective when the front left was locking, they would see a progression of both colour and intensity of a locking on the front left and you can have it working from the right hand side as well just to indicate which ones's going to be locking.
38:18 It's generally going to be pretty obvious to the driver which one's locking based on the direction they're turning and everything but it's still nice to have that intuitive touch as far as giving them a little bit more information and making use of some of the complexity that we've got as far as the logic control on those lights.
38:32 So there were a couple of other things I wanted to go through here as far as different ways we can use these math channels.
38:37 We've got 1 here for switching on and off the alternator.
38:40 So one of the things you'll see in high level racing is people actually switching the alternator off in certain parts of the track just because the alternator is obviously, while it's generating useful electricity for us, there's certain parts of the track where having the alternator on is going to give, obviously it's going to give you more drag when you've got that going and at certain parts of the track, eg the straights, we want the car to be as fast as possible on a straight line.
39:01 We'll actually switch the alternator off to give us more, slightly but nonetheless noticeable amount of, or useful amount of more straight line performance so this is what this logic here, is essentially we've got some distance gates to say between this distance and this distance, switch it off and then this distance and this distance switch it off, here let's go through that, we've got our familiar choose statement here, we've got alt off distance control is the channel and we're going through here with a choose statement saying if the lap distance is less than 210, so that's saying, obviously when we cross the start/finish line the lap distance is going to be reset to 0 so that's saying anywhere between 0 and 210 or lap distances between 345 and 720 you can see how this is going on essentially giving us certain blocks of distance along the track where we want to switch the alternator off.
39:46 Everywhere else, the alternator's still going to remain switched on.
39:49 So obviously all of these distances are going to be circuit specific.
39:54 There's only certain parts of the track that we're going to use lap distance from to trigger the alternator to be on or off.
39:58 So that's another way we can make use of that.
40:01 And the last one I wanted to go through here was on the antistall which is actually quite an interesting one because it's controlling some real system on the car.
40:09 So I've got that under a user condition down here, and it's number 5.
40:15 So the important thing to understand about antistall is the idea here is that if the car gets stalled, usually the way this would be triggered is, the case it's set up for here is if the car is stalled in the pit lane.
40:27 So normally what will happen the car will come in for its pitstop, it'll have its fuel done, its tyres done, it'll get dropped back on the ground and the driver is usually trying to find that balance between not spinning the wheels too much to damage the tyres and also getting a fast takeoff out of their pit box as well and we want to make that as repeatable as possible for them and the idea here behind this logic is if the car is stalled in the pit lane so when the car comes back down off the air jacks and the driver wants to drive out of the pit lane, if the car stalls, we'll use the logic in the logger here to trigger something in the PDM to automatically restart the car.
40:59 So let's go through what this means so this is a case of a momentary condition.
41:02 So before we went through one of the previous examples of user conditions was using this activate, something to turn it on and something else, some other condition to turn it off, the difference between this is it's this condition is only true when this momentary condition is true so as soon as that thing's, as soon as any of these conditions aren't true anymore it becomes a negative output or an off so we've got an antistall timer here which is something that, it's not too important to go through here but it's essentially just a timer for how long the antistall system has been running for.
41:35 The other condition that must be true is the throttle position sensor must be greater than or equal to 15% so that means if the driver's off the throttle, it's an important condition because if the driver's on the throttle obviously it means they're trying to drive away but if they're off the throttle, it means that we don't want this condition happening because that means that the antistall condition could be true, could happen when the car's sitting there.
42:00 Let's say for argument's sake the car's sitting there in gear but there's nothing on the accelerator.
42:05 If this thing triggered it would obviously start itself and drive off all buy itself so we only want this to be true when the driver is actually requesting some throttle position in this particular case, 15%, that's sort of an indication of the amount, the minimum amount of throttle we'd expect to be using on pit exit and when leaving the pit lane.
42:20 Another value here is ignition switch must be true so that's a value that we are reading from the PDM as whether the ignition's on or not.
42:28 We've got a antistall timer must be less than 4 seconds, so again that's saying it's only, that's just something to say that the antistall trigger is only going to last for a maximum of 4 seconds so once it starts it's eventually going to stop, we don't want this thing to be staying on forever, it's essentially, if it's working properly it's just going to be a case, the car gets stalled because the driver let's say either doesn't use enough throttle or lets the clutch out too fast, it's only going to go for a maximum of 4 seconds before this whole show's going to get shut down and it's going to stop doing that.
42:57 The engine speed must be less than or equal to 1200 RPM.
43:00 So obviously if engine speed is equal to 0 that's going to be triggered or even if the engine speed dips below 1200 the reason we're not just using a 0 there is because if it sees a drop in the engine RPM it's already anticipating and going to be trying to restart the car.
43:14 Because you can lose quite a lot of time in restarting the car in the pit lane like that, we're trying to catch it before it completely stalls as well.
43:20 Obviously you can see how a lot of these values are going to be car specific and it's something you need to tune for yourself.
43:25 And the last value here is that pit switch must be true.
43:28 So that's an example and probably a really important example to go through of how we can use logger math not just to display warnings or different lights to the driver but actually to trigger and control a real system.
43:39 So we'll be using this value, this antistall output condition that we've got defined down here, that's something that we'll be sending over to the CAN bus to the PDM and the PDM if it ever sees that value as true, it will be triggering the starter solenoid.
43:53 So in the same way that there'll be a PDM control for triggering, turning the starter motor on from the driver.
43:59 The other way it can be turned on is with this antistall logic which is being controled by the logger itself which is a pretty interesting way to use the logger to do something real on the car for you.
44:09 So guys if you've got any questions that have come up about anything today, specifically about onboard logger math but I'm also happy to answer anything else about data analysis in general or race engineering or setup or anything that RaceCraft covers, chuck those through to Sam and he will put those through to me now.
44:26 The other thing I wanted to talk about was to compute something, the other important thing to talk about here with logger math is that because we're doing it live it makes it available to the engineers in the pit lane as well as to the driver inside the cockpit.
44:42 One of the things that's important about that is with telemetry it's always quite limited as far as the amount of information you can send over telemetery.
44:50 So just to be clear about the difference between telemetry and log data, log data is data that is logged to the solid state memory of the logger itself, the car comes in the pit lane, we plug our cable into it and we pull all the data down onto the computer that you're using for the download.
45:05 Telemetry on the other hand is data that's being sent real time wirelessly from the car back to the pit lane.
45:11 So there's 2 main techniques for that, it is we'll be doing it wirelessly via radio signal or wirelessly over the cellular network so traditionally radio telemetry has been the much more common way to do it, increasingly now more and more cars are relying on cellular and as more and more racetracks get better cellular, all I mean by cellular is just a normal cellphone reception, it's essentially the same hardware that's sending that same information or that logged information across the telemetry network, across the cellular network, it's exactly the same as what's inside a cell phone.
45:46 Whether it's coming from a radio or a cellular source, there's a limited bandwidth.
45:49 What I mean by that is we can only send so much information at once across that cellular or a radio network before essentially the pipe's not big enough and we just can't fit enough data through it.
46:00 So typically you're always sending lower frequency or a lot less data over telemetry than what you're actually logging.
46:06 The important thing about that is if you do have something, let's say something really complicated or something that needs to be computed at really high frequency, that's not something you're going to be able to send over your telemetry, certainly not with the current bandwidth requirements we've got in current 4G cellular and radio telemetry which is the vast majority of everything you'll see most cars running out there.
46:29 So the reason that's important, if you do have something high frequency that you're calculating, let's say you're doing something with damper position where you're doing some really interesting frequency domain analysis where something needs to be logged at let's say 500 Hz, the ability to send really high frequency data like that over telemetry in most cases is not going to be an option but it means you can compute all of that stuff inside your logger, crunch all the numbers and just send a simple output to the engineers back in the pit lane rather than trying to send all of that information required to compute it on your computer, you can be computing it on the logger and just send an output, the result of that computation rather than all of the information required for that computation.
47:06 Of course once the car comes in the pit lane, you download it, you can do that computation for yourself locally on your computer but the idea here is that we can do it all on the logger without being as constrained from our telemetry as we otherwise would be.
47:19 So guys remember we've got our driver course which I talked about before which is our race driver fundamentals course which will be coming out at the end of the quarter which is currently in production.
47:30 It's going to be something a lot of you guys I think are going to be interested in.
47:33 We've got a high quality local race drive teaching and delivering that course.
47:37 There's going to be some really great content in there for you guys.
47:40 And remember as well guys if you are watching this after the fact, you're not watching it live, you can always jump into our forums and ask any follow up questions you've got as a result of this webinar in the forums and I'll jump on and get to your questions there as well.
47:53 So guys that's it for the lesson part, I'm just going to jump across and see if we've got any questions that have come as a result.
48:00 It looks like there have been, oh no there wasn't and now one just popped up, OK.
48:04 There's a couple here.
48:06 Rucorey asks, when doing motion ratios, would you use a filter? Seems like a noisy visual.
48:14 Yeah so I guess when you say motion ratios there, I'm assuming you're talking more about using damper positon data.
48:21 Obviously usually applying a motion ratio to the damper position.
48:26 If you're actually talking about computing the motion ratio and applying a filter to it, it shouldn't really be noisy or it should be quite a steady smooth signal anyway.
48:34 So I'm going to assume you're talking about damper position data.
48:37 Just to be clear, what that question means here, I'm just going to draw that out.
48:41 So I'm not sure exactly what you're asking so I'll draw out both but if you were computing motion ratio for example, if that's your wheel, that's your strut or that's your damper, you've obviously got, for a certain amount your wheel goes you've got a different amount that your damper's moving depending on the motion ratio that you've got and the relationship between those 2 things, if you're going to plot wheel vs damper, depending on your kinematics, the relationship between those 2 things should be relatively smooth, you shouldn't have unsteady signals, if you've got that, you've got bad measurement data and you need to go back and remeasure that.
49:13 But I'm going to assume maybe what you're talking about is maybe more damper position data which traditionally is really noisy so this might mean let's say you're logging the position of the front left damper, it might look like this.
49:23 So what we've got is the general trend of what's going on here is what's happening is the car moves through the track, let's say this in the corner, the front left corner of the car is heavily loaded so we've got a lot of compression in the front left corner but in between we've got all these bumps affecting our signal as we go.
49:38 And depending on what you're using that damper position data for, you're going to want to do different amounts of signal processing or different amounts of filtering as the question is here.
49:48 So if you were doing something like looking at damper histograms or doing fourier transforms or any sophisticated damper analysis, you're not going to be wanting to use a filter because that really high frequency content information is really important for doing the analysis, however if you're looking at something like ride height, maybe something like pitch for example, you were doing some math inside, either inside your logger or inside your analysis project, quite often you will want to be applying a filter to it because it just makes it a lot more visually easier and clearer to understand.
50:17 So what I mean by that, let's say this is, let's pretend for argument's sake, this is our pitch channel here.
50:23 We're computing how much, if that's our 0 pitch and this is how much the pitch of the car is changing over a certain position of the lap, we're really much more interested in, or obviously depends on what the time scale is here but you've got to use your judgement as far as the filtering.
50:37 We're generally more interested in the actual shape of that pitch rather than these high frequency variations.
50:41 So it does depend on what you're using that data for as far as how much filtering you're using but absolutely, definitely making a lot of use of filters on anything, things like accelerometers or damper position, anything that's been sampled at a really high rate.
50:55 OK another question, Shane Plohl, Shane asks, ​do you think you could configure the locking lights without advanced math functions on the c125? So I don't know off the top of my head exactly what the default ability is of a C125.
51:11 This is a C125 here that I showed before but I don't know, well for anyone that doesn't know, the way MoTeC essentially manages most of their hardware is you buy the hardware and the idea here is this thing is capable of heaps out of the box but the idea here is they sell it at a reduced price and each time you want to unlock certain features of it, you can pay to essentially, they give you a code, you put that code into your logger through your configuration software and it opens up a new ability.
51:40 Sometimes that's the ability to log more channels or the ability to do more sophisticated math.
51:47 Like the example I went through today was with a fully unlocked situation where you've got all of the potential, all of the capability of the logger available to you but it's important to understand with a lot of these things, well particularly with MoTeC products while they can be incredibly powerful tools, they don't come completely unlocked from factory unless you pay for it.
52:05 So what I'd say Shane just because honestly I just don't know off the top of my head what a locked version of a C125 normally comes with, jump into the forums and maybe we can discuss it a bit more in detail there, maybe you can send me some screenshots or maybe I can play around with a locked version of a C125 and we can try and figure out together the logic for how we might do that.
52:26 I would be pretty confident we would be able to come up with a way of doing that.
52:29 I've got a feeling that C125s do have the ability to do a fair bit when they come from factory but I'd have to open the configuration and check that for myself, yeah just jump into the forums and let's continue that conversation a little bit further.
52:43 OK we've got another similar question here from HP Data, dashes without the maths aka C125/C127 (tables and any user conditions) any hints? Yeah so my understanding with a C125, maybe I'm wrong, my understanding was a C125 does have the ability to do onboard math.
52:59 This question is implying that it doesn't so I'm not sure if it actually doesn't overall or it just needs to be unlocked to do it.
53:05 I mean essentially you can make use of, I'm sure you can make use of things like user conditions along the way.
53:12 This is really similar to Shane's question before.
53:14 I'd have to actually sit down and go through the programming of a locked system to figure out what was possible.
53:21 I would be surprised if you couldn't but this is definitely a case, and this is the case lot in the case of data analysis whether it's setting up the logger or actually analysing it for yourself, there's so many different ways to achieve the same thing.
53:32 And a little bit of creativity when it comes to thinking about how you can make use of different channels, use of different functions inside your logger.
53:39 They can be really flexible and you can use them for all sorts of things but both guys we should probably continue this discussion in the forums where I can give you guys some higher quality information on that because I just don't know off the top of my head how we'd do that but we can play around with it together, no problem.
53:53 OK question from MrJon, do you have any good tips for ensuring that setup changes get reflected in all of the math channels you might be using? Yeah absolutely so every system will be a little bit different.
54:04 When I say system I mean whether you're using a Cosworth logger, whether you're using a MoTeC logger, whatever it is.
54:10 But generally all of them have the ability to map a setup sheet to your log data or to your data analysis project.
54:18 What I mean by that is that let's say, depending on how you are managing your setup throughout a race weekend, whether you're doing it by pen and paper on a paper setup sheet or whether you're doing it electronically, essentially you have the ability to map inputs from your setup sheet to your log data and use them live.
54:36 Now I do have some examples set up on my computer but I don't have any that I can show you right now.
54:42 Essentially the idea here is let's say for argument's sake you've got your static ride height values and this has come from your mechanic's setup sheet.
54:50 The way it's handled in MoTeC is they interface by default with an Excel setup sheet so in Excel just a spreadsheet so essentially you have a row for each setup and a column for each value so I'll just sketch out exactly what that looks like for anyone 'cause that might not be a very clear explanation so far.
55:07 So essentially we've got i2 in this case for MoTeC which is our analysis package which is running on our PC.
55:14 And at the same time in parallel with that we've got another process running which is our Excel setup sheet.
55:21 And the idea here is that in broad terms each row is for a new setup so let's say you've got, we're at event 1 and this is download 1.
55:32 And we've got download 2 and download 3 and so on and so forth.
55:36 And the way personally I use this is that I generally keep a given setup sheet for a given chassis or a given car and it becomes an entire setup history for that car so generally the only things I've got listed in the setup sheet, there's lots of things in the reel, set up on the real setup sheet that I'm not using electronically inside of the data analysis project.
55:56 But there's lot of examples of things I'm not actually going to use inside my analysis but I do want to actually set up on the car.
56:04 The only things I'm going to have in this spreadsheet are the things I actually want to make use of inside my math channels.
56:09 So just maybe to go back one step on this, maybe I've jumped ahead a little bit too fast on this is that the way you could manage this is that you could have value of let's say your front ride height, your static front ride height is an important value for you to use inside of your logger or inside of your math channel.
56:22 If you have, if it's hard coded into your analysis project, let's say I could have to make a constant value of front ride height, make that 60 mm, whatever it is for argument's sake.
56:35 The problem is, that's going to be a constant value and each time I update that constant it's going to be applied throughout my entire analysis project, there's not way to map a different constant value to a different log file, that's the purpose of using a setup sheet or an electronic setup sheet in this way.
56:48 So the idea here is let's say I've got front ride height as one of my inputs and let's say I've got another one for rear ride height or any other input that I might want to make use of.
56:59 So let's say download 1 when I roll it out of the truck at the start of the weekend, my front ride height was 60.
57:04 Then after download 1 I put the car back on the patch, I made a setup change, now it's 65.
57:09 Download 3 was also 65 and whatever it is, however else it evolves throughout the race weekend.
57:15 Now what's going to happen is inside my analysis project, I use the same convention for each log file.
57:21 So we know down the sides here and I'll just show you guys on my laptop screen the way this looks.
57:26 I don't actually have it mapped here but I've only got 1 data source available here and you can see this one here we've got some information about where the data was gathered, which event it was, what the driver was, that the car number was, sorry what the chassis number was in this case.
57:41 Got DL4, that means it's the 4th download of the day and the reason that's important is because I'm using it to map which setup aligns with which log file so in this case let's say I've got DL1 in my analysis tree here and I've got DL2.
57:55 Then I've got DL3 so that it means here is that any time I'm looking at the data for download 1, if I've got a math channel that says whatever it is, let's say our math, for argument's sake as a rate calculation and let's say for argument's sake it's just simply rear ride height, let's make it really simple, minus front ride height.
58:19 And this rate calculation is now going to be dependent on these values.
58:23 So rather than writing a hard coded value of let's say 60 like we would normally in here and whatever it is the rear, we've got a parametric value that's coming in live from our linked setup sheet here.
58:33 So in this case it's going to be using 60 minus let's say 118 or whatever it is here, whatever values we've got.
58:39 In this case, might have constant values of rear ride height and just be changing the front ride height so that means for each one of these download files, we'll download, each one of these is a log file, we're going to be using the appropriate value of setup, the value that's in our electronic setup sheet so that's the way it's handled in most software packages, certainly things like PI from Cosworth, Bosch with WinDarab, with MoTeC and i2, they certainly allow you basically to make a link between the setup on the car or any other parameter you want to use and how your math channels are working as well.
59:10 I'll just go back and see if we've got any other questions.
59:12 OK that's all the questions I've got but they were some really great questions guys, I'm really glad you guys put those through because they're definitely all really valid points when it comes to making you some math channels inside both your logger and also in your analysis system.
59:23 So guys that's it for the webinar today, anything else that comes up, feel free to jump in the forum and we can take it further.
59:29 Thanks very much guys, I'll see you in the next one.