Summary

The term telemetry is often used interchangeably with the term logged data, in a motorsport context it has quite a different meaning and the actual data we use with telemetry has some important differences. In this webinar we’ll look at what some of those differences are and how to make use of it.

Timestamps

0:00 - Introduction

0:10 - Difference between telemetry and logged data

1:25 - Why not only use telemetry?

2:55 - How is the data transmitted?

5:35 - Radio vs cellular

8:50 - MoTeC T2 software walkthrough

15:20 - MoTeC i2 software walkthrough

17:10 - Track map

18:45 - Tyre pressures

22:00 - Lap time

22:55 - Lap gain/loss

24:55 - Last lap time

25:15 - Fuel per lap

25:50 - Button use

28:00 - Fuel number

28:55 - Reliability

29:55 - Cool suit current

31:00 - Powertrain reliability

33:40 - Tyre monitoring

35:55 - Accelerator and brake trace

36:30 - Steering input

37:20 - Brake bias

39:10 - TPMS

42:20 - Crash tab

45:20 - Reliability page

46:10 - Receiving telemetry for multiple cars

47:05 - Security

48:05 - Questions

Transcript

- Hey team, Tim from High Performance Academy here. Today we're talking all about motorsport telemetry systems. Now to start with I just want to get right down into the weeds to discuss what the difference about logged data is to telemetry. And this is something I see a lot of confusion about in the maybe more amateur side of the motorsport industry. So as a general rule, the way I characterise this anyway is logged data is data that is logged inside the data logger and that's what we go and retrieve once the car comes back to the pits, we plug into it or we take the SD card out of it, whatever that transfer system is, that's data that we are downloading all in one go after the car has finished its run on track.

Everything we're going to be talking about today which is the topic of motorsport telemetry, is all about sending data in real time off the car and being able to analyse that without having to have the car in the pit lane. So what do I mean by that? I mean that the car is heading on track and we've got data coming back to someone looking at a computer in the pit lane and they're seeing everything that's happening on the car in real time. So there are a lot of pros and cons with using telemetry vs logged data. In reality if you're using telemetry you'll be using both, you'll be using the logged data when you get back into the pits as well as using the telemetry in real time. So the first thing to understand about the way telemetry works is we're usually sending it either over a radio system or over a cellular network which I'll come back to in a little bit more detail later.

But the important thing to understand about telemetry and maybe it's probably natural to think of it, OK why do we have logged data in the first place if we're able to send it in real time, what's the difference? So the problem with telemetry, at least with the technology that we currently have, is that the telemetry files are always bandwidth limited. So what I mean by that is we can't send all of the information all in one go reliably so when we're logging data on the car, we're usually logging things at much higher frequencies, we're logging all the channels that we might be interested in logging. Typically you're not able to send all of that information reliably over a telemetry system, you've always got, you can think of it as being a big pipe and a small pipe. The logged data, it's got this big pipe, we can hose a whole lot of data down there all in one go, we can record it all. Telemetry's a much smaller part, we can only fit so much through it so that means either sending a reduced number of channels or alternatively reducing the rate at which we're sending them so that's the logging frequency.

So typically the way you've got your logger set up, the logger's typically at the centre of all of this. You might be logging a whole lot of channels, you might be logging 100s of channels at really high frequencies, and then you'll have a separate list, all of the data sources the same but you'll have a separate list where you'll say these are just the channels I want to send over telemetry rather than being logged. These higher frequencies I want to send them at low frequencies and I only want to send the critical ones that I know I'm going to need in real time. Maybe get rid of a whole lot of stuff you know you're not going to be able to make use of when you're actually sitting in the pit lane anyway. So I just thought I would maybe just draw maybe a quick schematic exactly what this system looks like for anyone who's not familiar with it already.

So just on the overhead here, so if we've got our car on track, I'll just draw a really pretty little racecar here. So what we'll have onboard the car is a logger and like I said, the logger is normally the central point for all of the data that we're logging and dealing with on the car. So as I said, the logger will be recording to its onboard memory, all of the logged data and we'll also be sending over, if we've got a telemetry system fitted we'll also be sending that externally. So depending on the system it'll have a modem here and there are two different types of modem that I'll come back to in a second between whether it's cellular or radio, we'll have a talk about that in a second. But essentially we are sending this data stream, all of our telemetry data, we're sending across this data stream to the modem.

This has got some aerial on the car and this is transmitting back to a matching modem in the pits. So this is the pit side modem which has also got an aerial there. Now from there what you've typically got is a data stream coming in and you'll be coming into a server. So this is our telemetry server so we'll get that raw data stream coming in here. All of that is being dealt with by the server and from here, from the server we can distribute that to anyone you need to.

So in some cases, that might just be one person, in the other case on a large race team this may be many many engineers looking at all of this simultaneously. So you might have this being broadcast over the team's WiFi network so anyone, might be connecting to that over WiFi which is quite common. Alternatively you might have hardwired connections to different computers for the engineers and these are the screens where people will be looking at those squiggly lines in real time and getting that information. So I should say as well, all the system that I've got here, this can be compressed down much smaller. So the particular system that we use here at High Performance Academy on for example our SR powered GT86, all of this equipment is all fixed on one laptop, it doesn't need to be a bit elaborate system.

In a team situation what you may have in between the server and these computers is a full team network as well which this may run to and this may be distributing from your network rather than being run to the computers. It really depends on your exact IT setup that you've got. As I said, it's the way I've got it set up in the demo for today, all of this is actually being done on my computer so rather than sending the information out and being broadcast over a network and having to be translated, it's all actually happening on one computer which simplifies it a lot as well. Now I said I'd talk a little bit about the difference between radio and cellular. Now traditionally telemetry has all been based over radio frequencies so that's just really conventional, radio frequency channels which have to be reserved like any other radio channel, like walkie talkie or anything else like a broadcast radio signal.

Now the great thing about radio is it does tend to work anywhere where you've got a decent line of sight between the pit and the car. So what I mean by that is if you're not in a really congested environment with a lot of buildings or a lot of trees or a lot of hills, as long as you've got some sort of line of sight to the car regardless of where you are in the world, the radio telemetry does tend to work quite well. One of the downsides of radio telemetry as you can probably guess, it's got a pretty limited bandwidth. You can send a lot less data over a radio system than what you can over a more cellular based system so again if we're sending radio data, we'd typically be stripping down that telemetry list even more, we'll be stripping down the number of channels we're logging, we'll be stripping down the logging frequencies which is obviously degrading our data. But at that point if you're stuck with a radio system for whatever reason, you're stuck with what you've got and you'd always rather have something rather than nothing.

On the other end of the spectrum, which is definitely what I would call the standard these days is a cellular based system. So these can either be 3G or 4G. I'm sure in the near future we'll also have 5G systems as well. Now the beauty of using a cellular network is we can make use of all of the infrastructure that's already around us. Now straight away that means you don't need line of sight, it means you can now broadcast and receive over much much greater distances.

As long as the car has a cellular connection and the pit side has a cellular connection, all of that's going across the internet, you're suddenly removing a whole lot of these restrictions as far as congestion in city areas or trees or hills or mountains or whatever it is, certainly some racetracks, you go to somewhere like Spa or Bathurst or anything like this where you've got really really mountainous terrain these are places where radio telemetry's really going to be problematic for you because without having a whole lot of radio repeaters, which is another way to deal with it but it adds a lot to your infrastructure having to have all these radio repeaters put around the racetrack, radio telemetry really isn't usually an option. So this is where cellular comes into its own. Cellular does tend to have a much higher bandwidth and what I mean by that, again it's just got that bigger pipe, we can send much more information down it and as 5G comes along, I think we'll see telemetry, the amount of telemetry information we can send over telemetry as opposed to log, I think we'll see those as time goes on merging closer and closer together. Certainly 5G is going to be a big step up as far as the amount of instantaneous information we can send over the network in one go. Now I would say again cellular is not the silver bullet.

What I would say is most race series I'm part of, wherever you go around that particular country, there's always some circuits where the cellular service isn't great. So some countries are better than others but certainly when we race here in New Zealand there's some tracks which the cellular coverage isn't as great which means we may sometimes revert back to our radio system rather than use our cellular system. Obviously it's a bit of a balance and you've just got to find what works best for you. So the demo I'm going to give you guys today is based on two different pieces of software. One of them is our server and one of them is our analysis package so I went through in that schematic I drew in the overhead here, our server is what is receiving the data and essentially taking all of that jumbled information and putting it into something usable that we can then send to our analysis program which is what we're going to go through today.

So if we can jump across here to my laptop screen, what I've got is a very unexciting piece of software, well unexciting looking piece of software I should say that we'll go through and I'll give you guys a little bit of an idea of how it works. So what we're looking at here is MoTeC's T2 software. So I should say as well, all of the demo I'm going to do today is based on the MoTeC system. But I would say largely our system architecture and the way you're using the logged data isn't really going to change regardless of the logged data system that you're using. Whether you're using a Cosworth PI system, whether you're using an Atlas system, a Bosch system, a MoTeC system, all of these concepts are really applicable no matter what.

So what's going on here, there's two main things I want to point out here. We've got our input side here and we've got our output side here. Now I should say today I'm actually cheating, I'm not taking real logged data from a car in real time, instead what I'm doing is replaying an old log file and treating it as if it's a telemetry file so that's one of the things you can do on a lot of different telemetry systems. What I'm doing here, and what I'm going to do is double click on the input here. You can see I've got a couple of different tabs, I've got general which I've just named here HPA webinar demo which is obviously just an example we're doing for today.

I've got the input stream and I've got the output stream. On the input stream side, I can decide, I've got a little bit of information for how I want to configure what I want the output to be. So the protocol, obviously we're going to be using is the native T2, T just standing for telemetry. And the type here is the bit that I really wanted to dig into. So you can see I've got LD file selected there.

Now LD file is simply MoTeC syntax for what they call a log file. So here we could, this information could alternatively be coming from a serial port, it could be coming from a network or it could be coming from a few different options that I don't want to get too down in the weeds discussing from today but essentially if we were taking it from a network or a serial source, that's where we'd be connecting to that modem, that pitside modem. So remember I said the car's got a modem, the pit side's got a modem and then the telemetry server connects to that modem on the pit side. So typically you'd either be using a serial or a network connection depending on the type of modem that you're using. Serial is something maybe a bit more old school, what more old school modems would tend to use.

Certainly today when you tend to be using things like 3 and 4G modems, these are almost always using a network connection rather than a serial connection. But that's really by the by, for all of our other purposes today, it's not going to matter that we're using a log file here as our source, from this point on it's all exactly the same, all it means is I'm feeding this thing a log file rather than feeding it live data from the car. Other than that it's really exactly the same. After that you've got, down here you can see the path. I've got pointing to the log file that I'm using for the demo today which is just from a GT car running at one of our local racetracks here at highlands motorsport park.

There's a bit of information which I've stripped out of here which is things about driver event session type, stuff like that, nothing too interesting there and then we've got the output stream here which we've got a few things we can configure. Basically how we're going to configure the output, so I've talked so far about the input into the server, now this is the output so we can send this out in a whole lot of different ways, not going to get too down into the details of this but essentially all this is saying is I'm broadcasting this information that I'm taking from this log file, T2, the server, is now broadcasting this over my local network so when it says all interfaces there that just means it's broadcasting over the local network. So that's a real quick run down of what T2 is doing. In here what is going on is you'll see, actually I'll show that again, what I can do is pause and play the replay here. So normally when the car's on track and this things running around in real time we don't have the ability to pause and play, you've got no option but to just take this data in real time.

What I've got the beauty of doing in a replay like this, and this is really good if you want to debug or practice with your telemetry software before you head to the track, is I can play or pause the replay and you can see both of these sections up here go red when I stop so if I pause up here, you'll see both of these eventually slow down and go red saying that there's no input and nothing being sent over the, there's no data being sent over the network here. But if I play again, and I've also got this little slider bar so I can drag this through. So this particular log file looks like it's about 46 minutes long, I can see that written in the bottom right there. And that's just telling me where I am within that log file so I'm roughly 12 minutes into that log file. We've got a little bit of information here about the source of that log file, the meta data file.

Essentially the meta data file is just, this is the way MoTeC deals with it anyway, essentially every time you have a new logger configuration which is obviously the piece that's sending us the telemetry over the network, every time you save a new configuration to that logger, it makes a matching meta data file which essentially is a description of the entire configuration or at least as much of a description as the telemetry server needs to understand how the logger's set up and what sort of information it's going to be receiving. So the idea is each time we save the configuration on the logger side, we take that meta data file which is just essentially to us it's completely invisible, all we know is it's some file with something in it, we don't need to know what's inside it. All we need to do is transfer that to the server computer and that means that the server can now essentially understand exactly all of the information that's coming from the car in real time. So that's all that's saying, that's essentially a long string that uniquely defines the meta data file which can be useful if you're going through and trying to debug while your telemetry isn't working. If you have the wrong meta data file in your server, you've got no match between your logger configuration and the meta data file you've got in your server, the telemetry's not going to work so that's usually one of the first places to go and check problems.

And then we've got some information here about the logger type and the logger serial number there as well. So that's a real quick introduction to T2 or to MoTeC's, their telemetry server. Now the next step is, we've got this information, we've taken it from our virtual car, which I've told you I've cheated for today, we're taking it from the server and we're broadcasting it on the network. Now if someone else was here with a laptop next to me, they would also, if they were in the same network as me, they'd be able to fire up i2 which is MoTeC's analysis software which we'll go through in a second. Anyone would be able to just sit here and connect to that data stream and also look at that data in real time.

The way I'm doing it for this demonstration is just doing it all in one computer. So I've got the server broadcasting it and my software receiving it in real time on the same computer but essentially this is behaving exactly the same as far as using multiple computers. So here I have MoTeC's i2 like I talked about before and what I've got set up here is a typical telemetry screen that I would use as a race engineer so every car's a little bit different depending on the number of sensors it's got, depending on the type of racing that you're doing. You've always got different, you're always tweaking your telemetry layout so you can see the information you need. So I thought what I'd do is just give you guys a little bit of an introduction into how I make use of telemetry, how I lay out the screens, a few of the basic ones anyway.

So here in the top left you can see I've got this data coming through in real time and you can see as this little cursor here moves across the screen here you can see, I'll go through this data in a second what this is but you can see as we're virtually moving through this lap and you can see also here in the top left we've got the car moving through the racetrack. Now you can see obviously this stuff, it's updating at given steps, it's not necessarily so smooth, every system's different, it'll be a little bit different again if you connect to a real source but it is updating relatively quickly but it's not a completely smooth process. So obviously the track map is really useful for understanding where the car is on track. What part of the track the driver's dealing with, so one of the real useful ways I will use this is if race control will say something about, there's an incident at turn three, straight away if I don't know already I can look at the racetrack map, that track view and I can see exactly where the car is on track and if the car's approaching that corner or going to be approaching that corner soon, I'll radio to the driver, say look out there's going to be an incident on track in turn 3, just have caution. If not, if I'm already well past turn 3 and it may well be that incident will be clear by the time I get to it, I probably don't want to interrupt the driver at all, I'll just hold off that message until I get a message from race control saying whether that incident has been cleared or not.

If it's not, I can go ahead and warn them again. So it's just a way to understand where they are on track. Also, the other way I tend to use this is usually, and this is a bit driver dependent as well, some drivers are more tolerant of being talked to on the radio than others in different parts of the lap. So some drivers, totally fine, you can talk to them, come on the radio in the middle of a braking zone when they're mid corner and it won't worry them at all. Other drivers are much more sensitive to it and don't like to be talked to in certain parts of the track.

They find it a little bit overwhelming which is fair enough. So the other thing it's really useful for is just understanding whether the car's in a position on track where it's going to be safe to talk to them on the radio. So in a track like Highlands, typically the place I'd talk to most drivers would be down the two straights. So that's this straight here and another straight out of the hairpin heading in this direction down here. So if possible, as long as there's no emergency to deal with, I would generally try and leave my radio messages to the points on track where I know they're going to be comfortable with me talking to them on track.

Obviously if it's something urgent I'm going to talk to them no matter what. Underneath that I've got a small time/distance plot of my tyre pressures. so what's going on here, you can see I've got 4 different channels shown here, each with a different colour. And the way I tend to do all of my data, all of my channels, particularly when they relate to a different corner of the car, is I have the same colour convention for each corner of the car. So what I mean by that, you can see, if I just highlight this area here, I've got the front left, the fright right, the rear left and the rear right and I always use that same colour convention.

So for me, red is always front left, green is always front right, I've always got rear left is blue and orange or yellow as the rear right and the reason I do that is because it means I don't actually have to look at the channel legend to understand which corner of the car I'm looking at. Once they've used it for a while it means you can just look at a piece of data and you know straight away which corner of the car that piece of data relates to without having to look at the legend which I just find another thing just to help speed up my analysis which I think it really important. So this particular car obviously has tyre pressure monitoring system. So that is useful both from a safety and performance perspective. So obviously for performance, we're making sure the tyre pressures are roughly in the right tyre pressure window.

That's a really really important thing to get right in order to maximise the performance of the car on track. Anyone who's played around with their tyre pressures quite a lot will understand that the behaviour of the car really does change quite a lot if you don't have your tyre pressures exactly where they need to be. So this is something as a race engineer, I do tend to put quite a lot of effort into. I've usually got one person dedicated doing nothing but tyres on a car for a race weekend, so that's setting all the cold pressures, taking the wear, taking the hot pressures, stuff like this. And it's something as an engineer I'll be paying quite a lot of attention to.

So that's why it gets its own plot on here because I'm always making adjustments to the tyre pressure to make sure that they're as close as possible to my hot target. The other thing it's really useful for is from a safety perspective. So if I see here on this plot that one of these tyres has a downward trend on it, so let's say here for argument's sake on this plot if I see something like this going on with tyre pressure, straight away I'm going to see that I've got a tyre going down for some reason so whether that is 'cause it's got a cut in the tyre, whether that's because we've got a value failing on it, something like that, that's the reason I've got this data plotted over roughly two or three laps here. It gives me an idea of what's happening with the trend of the tyres. So in this particular plot we can see there's a slight upward trend in this data and that's because obviously as this car builds throughout the stint, that tyre pressure is going to be evolving so in this particular car, the tyres are always heated.

So we always put them in the oven so when they go onto the car they're always hot. But to some extent you always get some sort of evolution so sometimes when they come out of the oven they might come out at 80°, if the driver's just getting up to speed, the tyres might initially drop in temperature and pressure before building up again. In this particular case, as the car settles into its stint, we've got the tyres just gently on an upward trend before they start stabilising later in the stint. It looks like they're well on their way to stabilising, they certainly aren't going crazy as far as pressure growth. That noise you can see there is really just the pressure in the tyres changing as the car moves throughout the lap.

Obviously as the vertical load and the forces in the tyre change you are going to get small differences in the internal pressure as well. Moving down from there, in this whole block here, it's really all about lap time information. So the reason this is important is because I want to understand exactly how the car's going on track relative to its reference time. I also want to know what the driver's seeing on their dashboard. So in most cases the drivers will always have things like the last lap time, the reference lap time and their delta, how they're going on that time variance relative to the reference lap.

So what I've got here is I've got the ref, in this box here, ref lap. That's telling me what the reference lap that's stored in the dashboard, it currently is. So that's really important to understand, depending on which driver's in the car, certainly in endurance racing you've usually got a faster driver and a slower driver or a pro and an am. It's really important for me to understand what that reference lap time is then the next one along here I've got my predicted lap time. So that one is the lap time that I predict the car to get when I finish this lap based on how the car's going in its lap currently.

Next one along is the gain/loss which is also what we, which is often called the variance channel. So the variance is what we can think of is what is the gain/loss over the lap relative to the reference lap? So you can see I've got a 90.2 second lap in there. The lap time predicted is 96 currently. So that's currently predicted to be over 6 seconds slower than the reference lap time. So that's a lot slower so looking at that gain/loss, that's telling me that on this particular lap relative to the fast lap is 6 seconds.

And you can actually visualise that, I'll just quickly bring that up on the, it's actually too slow, 6 seconds is too much to even see it on the graph, it's off the scale but essentially you would see that evolve as the lap goes on and maybe I'll just quickly sketch that out just because I haven't done a data analysis webinar with you guys before. But essentially the way we'd look at that time variance plot is as we move along the lap, if the straight line is our reference lap and anything below it is we're doing better than the reference lap and anything above it is we're doing faster so if we were sort of matching, if one driver was matching the first driver it would be equal to the reference lap and they lost a whole lot of time at turn one, the variance might look like this and then they lose a whole lot more time at turn two, it may look like this and then let's say at turn 3 for whatever reason they're doing something better than the reference lap, they're driving it better, so it actually starts to drop and they gain a little bit of time back with respect to the reference and then let's say they have a bad run out of the following hairpin and so not only do they lose time out of the hairpin but they lose time all the way down that next straight as well. So the reason the time variance plot is really useful is it helps us understand how that time loss is evolving throughout the lap so we should be able to see that now that we've started a new lap, no it's still not on there. I'll come back and look at that in a second when I get into the actual plot itself. You can see there that I've got a red background coming on there and that's just, I've got it set up so when the time loss is positive or when you were losing time I've got it come up with an automatic red and it'll go green if it becomes faster than the reference.

So again, I like to use colours quite a lot, I find it speeds up being able to understand what's being shown on the screen. Then up here we've got the last lap time so you can see here for whatever reason, whether the car's bad or whether they're stuck behind a slow car or the driver's just really struggling for whatever reason, this is a huge amount slower but we've got, the last lap with a 99 second lap which is 9 seconds slower than the reference lap. The next one along here is the fuel per lap so that's how much fuel the car's using, the car used on the last lap. So every time the car crosses the finish line that fuel number will update. So I can just keep a track on my fuel consumption.

The way it's doing that is there's just simply a fuel model inside of the ECU which is basically keeping track on how much fuel is being squirted in by the injectors. That's something you do tend to check throughout your race weekend by checking how much fuel you're putting into it, how much you're pumping out of it, vs how much the ECU is predicting it's using. But again, it's not an exact number but it does allow you to understand how your consumption is changing over a race or changing with different drivers and stuff like that, it's just a really convenient thing to have there. Down the next row here I've got a little bit of information about what's happening with which buttons, some of the critical buttons in the car. So in this particular case, I've got the pit limiter, I've got shown here.

Next one across is the rain light, so it's just for me to understand whether the driver's got the rain light on or whether they've got the pit limit button on. Particularly with the rain light, what will quite often happen is you might have, well not quite often, hopefully not quite often, but you might have a situation where you get black flagged because your rain light's not on, maybe it's raining on track so when it's raining, everyone has to put their rain lights on and you've asked your driver to put their rain lights on because the race has been declared wet. At that point, maybe let's say if you've got a problem with your rain light, whatever, straight away you're starting to debug it because you know if your rain lights not working you're going to have to come into the pit lane and fix that which is obviously going to completely destroy your race so you want to avoid that. So the first step is to actually understand whether the rain light has actually been switched on or not and that's something you can do as well as sending all of these really flash and high frequency channels, you can really just send simple stuff like 1s and 0s for whether a button's on and off which is just really the first step in understanding what's happening when you're trying to debug a system. The next one on here is the radio button so again that's something I tend to have for debugging purposes, let's say I've got a situation where the car's on track and I'm getting no communication between me and the driver, first thing I'll be trying to understand is, is it because they're not pressing the button at all or is it because the radio's not plugged in or maybe there's a problem with the radio itself, whatever it is, if I can see that button being pressed, because you can essentially log the current that's being sent to the radio to energise the radio circuit.

Straight away if I see that flashing up that they are actually using the radio but I'm getting no comms then I know that helps me straight away understand more about the system and helps me debug it straight away as well. The last one there is just the headlights. Again in some situations I might be interested in knowing if the headlight button's being used. That's not necessarily telling me, I could be looking at what the headlight current is, that's another thing you can be looking at but in this particular case I'm just looking at whether the headlight button is actually switched on or not. Down here is the fuel number so before I talked about the fuel per lap which is this one here and below it is the fuel number so that's the total amount of fuel used since the last time we did a reset so in this particular case I think it was a race simulation.

We're looking at how much fuel has been used since we started the race so we're using, the last lap we used 1.9 litres or approximately 1.9 litres and we've used 24.4 at this point, litres total since we started the run. So again if I know how much fuel we started with, in this particular cars it's a roughly 120 litre tank so I know that if I start with a full tank, I know that it's just a safety margin for me to understand roughly how much fuel I've got left in the tank. Typically in endurance racing you're doing really accurate fuel calculations in the background, you might be doing them yourself or you might be a data engineer doing it for you but this is just another foolproof method of being able to keep track of roughly how much fuel you've got onboard in the car without having to do any complex calculations. Down here I've just got the gear, so what gear is currently selected in the car? Then we've got a couple of reliability things here, we've got the battery voltage. So again if the driver's starting to report problems to me on the track and if it looks like, usually what happens when you start losing battery voltage is a whole lot of systems start doing really unusual things about the same time.

So maybe the engine starts misfiring, maybe the dashboard starts flickering, maybe they start having trouble shifting gears if you've got a paddle shift system. You typically find a few strange things start happening at the same time, you think that was weird, and then another thing happens and another thing happens and straight away you come here and your battery voltage, you think oh OK I'm down to 11 volts, my alternator's not charging. So that might tell you, if you're close enough to try and limp to the end of the race, if you're close enough to the end and you don't want to come and again trying to destroy your race, you may well decide whether you think you can try and push to the end of the race based on your battery voltage, or whether you need to come in and fix it because you're only halfway through the race and there's no way if you started losing charge already and you've got a lot further to go there's no way you're going to finish the race so you're going to have to come in, otherwise you're going to end up stranded on track when the car just simply dies. The other one I've got showing here is the cool suit so this is the cool suit current. So in endurance racing we quite often make use of something called a cool suit which is essentially like an ice vest that the driver wears which is, the idea is it circulates cold fluid through them so they plug it into the car and there's a pump they can turn on and because it can be really a hot unpleasant environment in there, it just pumps cold water around in there for them and it helps keep them comfortable.

Now often there can be problems with cool suits and again just having that current there, the cool suit pump is using, it helps me debug the situation so I know that in some situations if an ice box is frozen or there's some other problem with the car, I can understand whether maybe the cool suit has frozen or whether the pump is drawing too much current or not enough or whatever it is, again it just helps give me a little bit more information so I can talk to the mechanics before the car comes in, if we have to do something about it I can say look I've got no current in the cool suit, I think the box has frozen or we think there's a problem with the pump or whatever it is. So it gives us a little bit of preparation time before the car actually arrives in the pit lane. The last two ones I've got shown there are the ABS and the traction control so this particular car has a motorsport ABS system which you can twist a dial and change the amount of assistance, it has an adjustable traction control system so the driver can dial in to allow traction control assistance. At the bottom here I've got a few different gauges which are just showing me the basic reliabilty things to do with the powertrain. So I've got fuel pressure, transmission temperature, coolant temp, engine oil temperature and engine oil pressure.

The other thing you'll see, obviously as the car moves throughout the lap you see them slowly bobbing away and changing and that's not what I'm worried about, I want a way to quickly understand if I've got a problem with the car and what might be causing it so the way I've got set up there is I've got all of the values shown, the colour of them is defined as green when I define them in a safe zone and the colour changes to another colour when it's unsafe. So let's for argument's sake say here if my oil pressure got really low, you can actually see just down the bottom here you can see this red rectangle in the bottom down here, actually there's an example of what's going on right here in the right rear corner. So if you look in the right rear corner of the car you'll see occasionally, I'll get to this in a second, this is my tyre pressures but because I'm getting slightly on the higher side of my right rear tyre pressure, you'll see this bar graph turn orange, I just saw it flicker there orange for a second. Essentially the idea here is with all of the reliability stuff, rather than go through and read each number individually, I just want to be able to scan the screen in a second and if I see green everywhere then I know I'm good, green is no problem, I don't have to go through and read each individual number. So you can see that right rear there has gone orange because my tyre pressure has gone over a limit that I've set in there as a warning limit, so you can see it's sort of creeping up over the into quite high pressures there.

And you can see different ranges for different colours so I'll show you what that looks like now. So you can define the colour that you're, sorry the channel that you're looking at and then I've got these different bands. So in this particular case if I'm between 17 and 24, it's going to be blue, 24 to 28 it's going to be green, 28 to 30 is going to be orange and 30 to 50 is going to be red. So each one of these little bar graphs has got that same, well not the same, it's got the same style limit put on it. The idea there is exactly what I said, I just want to be able to scan this array of sensors really quickly and if I see green it's no problem.

Alternatively you could come here and read the actual number which I've got shown down here in each one of them, that's really not something that's going to be time efficient to do. Usually as a race engineer you're much more, you'll want to be much more concentrated on the performance aspect. Obviously the reliability stuff's important but it's not something that typically needs a huge amount of looking at, if you can sort of scan it and see a range of colours, straight away you know you're good, you don't have to worry about it, you can move onto concentrating on the important stuff, of trying to win the race. So the last few things I want to go into on this main screen, all on the right hand side here this is all tyre pressure stuff which as I said before, this does tend to be something you spend quite a lot of time on as a race engineer. So the top 4 here are all my tyre temperatures so this is from the same sensor that I've got coming from my TPMS, my tyre pressure monitoring system.

So this is front left, rear left, rear right and front right so they're all laid out in of bird's eye view in a group of 4 how they would be from the car. So here again I can see, I can read the exact temperature, so this particular point on track my front left tyre is 77°, my rear left is 83 but I can also see, because they're all in the green, I know I'm happy with those temperatures, there's nothing to be worried about there. Might have been too cold or too hot or anything like that. The bottom group fo 3 is my tyre pressures. Again the same thing, I could be coming through here and reading the absolute number but it's just a way to give me a visual indication of whether I'm in the right sort of zone.

You can see the right rear corner, quickly come back up into my tyre pressure plot, you can see the trend of that right rear just creeping up to be a little bit higher. It's not too bad I mean we're talking, what are we currently, 27, 27.5 pounds, let's say my hot pressure might have been 27 in this case or maybe 26 in the front and 27 on the rear, I'm not sure, I don't remember what it was but that's giving you an idea of how you might use a couple of those different displays. Then of course in the middle I've got a time distance plot and the way I've got it set up like this is you can see this little cursor here, it's moving along throughout the lap as the car completes each point on track, that cursor will move along there and from top to bottom what I've got is the engine RPM at the top. Then in purple I've got the vehicle speed. This little yellow one here which is these tiny little spikes, these are the intervention of my traction control system.

So that's for me to understand how much traction control intervention I'm getting. So that might be a situation if I see a whole lot of traction control intervention where I don't want it, it may well be where I tell the driver, we might want to turn the TC own here because I think we can get more performance out of the car. Alternatively if the driver is struggling with stability or struggling with exit stability in particular, that might be a situation if I can see no intervention there, it might be a time I tell him to turn the traction control up. Further moving down the channels we've got here as we wait for this cursor to come along here, I've got two overlapped here and a lot of you guys can probably anticipate what these are, these are the accelerator and the brake. So the accelerator is in green and in red is showing the brake pressure.

So I typically overlay those, the only reason I do that is it just saves a little bit of space. Because of the way the accelerator and the brake tend to be used, there's not usually a lot of overlap between them so it's usually pretty clear to be able to look at those both ontop of each other. So it just helps me keep each one of those plots a little bit bigger so I tend to leave them at that sort of height like that but we can see how the accelerator and the brakes are being used. Down from that, I'll start with this orange one here, this orange one we've got down here is the steering input. So that's how much the steering wheel is being turned by the driver in this case.

It can be logged at the rack, it can be logged at the column, it doesn't matter really. The idea here is that we can see how much steering input the driver is using. So the steering input's really really helpful for understanding stability and balance in the car as to whether the driver's using a lot or not much or whether they're catching a whole lot of slides and it's really unsteady, the steering channel is really one of those channels that, it tells you a lot about way not only it's been driven but the way the car's behaving. So often taking into account things like tyre pressures and maybe entry stability, you see a whole lot of problems in the steering trace, you can learn a lot about what's going on with the car in real time just from what I would call a relatively limited number of channels that we're sending over telemetry in this case. This little yellow one here, these little yellow squiggles that you see jumping in here, these are actually my brake bias.

So the reason I'm calculating that is because this car, like a lot of racecars has an adjustable brake bias system in that they can turn a knob on the dashboard, in this particular car it's electronic but it doesn't matter, it's always doing a similar thing where it's essentially moving the balance bar inside the pedal box and it's changing the amount of hydraulic bias you've got going to the front axle relative to the rear. So because your brake bias is adjustable, it's something I generally want to keep track of so again, if I see something going on in the car, maybe the driver's complaining about a particular handling trait, maybe inside front locking or they're struggling with entry stability when they're heavy on the brake pedal, this is a place I can look to understand what their brake bias is set at relative to somebody else. And I'll come back and do an overlay in a second and talk a little bit more about how we do comparisons between them. At the bottom here, this is, a lot of you guys have probably guessed, this is simply the gear position. You can also bring up, I probably should have brought it up before, maybe it would have helped quite a lot actually.

You can bring up the legend which I've just brought up the top there. I don't typically have that because I just find it just gets in the way of my data and once you're used to looking at the data in a particular format you know what line and which squiggly line is which data channel, you don't need to have that legend up there for you. But one thing it does give you is it gives you the actual values in real time as well which can be helpful in some situations to look at the real value, whether it's speed value or a brake pressure or whatever like that. But I don't typically tend to have it on when I'm actually analysing the data. So I thought I'd take you through a couple more screens that we typically have set up.

Obviously when you're working with a car, you may have many many screens, you may have 50 different screens set up depeneding on what sort of things you're interested in looking, whether it's a reliability thing or a performance thing or a suspension thing or whatever it is. In this case I'm just going to take you guys through probably what I would call some of the main most important ones that I would suggest setting up. So the first one I've got here is TPMS or the tyre pressure monitoring system. So again as I said, as a race engineer you're typically paying a lot of attention to what's happening with the tyres. If you're lucky enough to have a TPMS system you can learn quite a lot about how the tyres are performing on track and how they're evolving over a run.

So going from top to bottom here the legend channels are shown in this, they are shown in this case. So we've got our ground speed, steering angle, we've got the raw tyre pressure numbers coming in here and below that we've got a couple of math channels. What I'm going to do is just stop that telemetry for a second, just allows me to zoom out so we can see a little bit more information about how these pressures are evolving as we move throughout this run. So what we can see here, if we look at the raw pressure channel which I've got shown here, I can see how as we, sorry just let me bring that back again, I started that replay. Just bring that back to looking at it all.

You can see here that at the start of the stint, I've got relatively low pressures before they build and stabilise. So that's a little bit what I was talking about before is that depending on what temperature they come out of the tyre oven, we're using blankets or a tyre oven, in this particular case it was a tyre oven, depending on what temperature they come out of the oven or alternatively what temperature they start at if you're sitting in the pit lane for a while, it will depend on how they evolve. So in a case where they're coming out of the oven really nice and hot, they don't tend to drop too much. In this particular case it looks like the car has been sitting around for a long time because we've got the tyre temperatures which is what we've got in the bottom here, down around, what are they sitting at, in the 30° which is really far too cold. But again we see the pressures evolving as we move throughout the start of the stint and then by this point in the stint here we have started to stabilise and they're really pretty consistent.

So this is just a nice way for me to come and visualise the evolution of the tyre pressures in a little bit more detail than what I have set up in the main telemetry screen. The next one down from here is the gated corner pressure. So what I mean by gated corner pressure is this top one here is just all of the raw tyre pressure information so that's telling me at every single point on track what the tyre pressures are doing. If I'm gating it, all I'm doing is looking at the tyre pressure in a certain position on track so let me just quickly sketch that out, exactly what I mean by that on the overhead. So if we've got our time/distance plot and our tyre pressure looks like this over a lap, whatever it is.

If I'm gating it, it just means I'm only looking when a certain condition is true, so I might only be looking at this one and this one here, everywhere else I don't care about, I just want to know where it is in these points here. Now in this particular case, what I've got set up in this math channel is just looking at everywhere where the tyre is on the loaded side of the car. So that just means that in this case the outside tyres are loaded so I'm interested in the tyre pressure when the outside tyres are loaded so obviously in right hand corners I'm going to be looking at the front left and the rear left, in left hand corners I'm going to be looking at the front right and the rear right. So I'm just saying ignore all of the times that those sides aren't loaded and only give them to be when they are loaded and the idea here is I can go away and do some statistics and do some more useful predictions on my tyre pressures than I otherwise would do. So let's go across to the next tab here, the next one is what I call a crash tab which unfortunately isn't something I plan or want to use but it is something that comes in handy every now and then.

So what I mean by that is if you've got a car that has an incident on track, I want to be able to understand really quickly what's happening with that car. Is there something wrong with it, do we need to tell the driver to stop, what's broken on the car? In this particular car and in most cars there's actually quite a few sensors we can use to understand certainly whether it's safe to continue or what might be happening in the car. So the reason, again it's really important, I know I've brought it up a few times now is that if this, I can get some more information if I'm looking at the telemetry, it gives me time to prepare my mechanics for when the car's going to come into the pit lane, I can say look I think there's something wrong with the front right corner of the car and we'll get to looking at that in a second so be ready, maybe bring all the spares for the front right corner, whether we're going to be doing a whole, maybe it's going to be a control arm change or whether it's going to be a damper change or maybe it's just a bad sensor, we don't know yet but just buys me a little bit of time so we can be a little be more prepared when the car does come back to the pit lane, if we're going to have to do some work on it. So I'll just really quickly go over there so in the top left here I've just got my tyre pressures, again if the car's had a crash, the first thing I want to look at is do we have tyre pressure. Obviously as long as the driver's safe and OK because that's going to tell me straight away whether I've got a puncture, I'm going to be able to know, tell the driver look, you're going to have to be really careful, you've got a left rear puncture or whatever it is.

Down here I've got a few basic engine parameters, I've got my engine oil temp, my coolant temp, my trans temp and my engine oil pressure. And again I've got plots for those as well so I can see how all of those are evolving over time so I can see if I've got a step or a spike or whatever it is, I can come here and see that really quickly. In the top here I've got a turn engine off alarm, so this is simply something that'll flash at me, basically if I've got no oil pressure and the engine's running, I can tell the driver no matter what, if I know I've had a crash, I've come to this page, if that thing's flashing at me I'm going to say, you've got to stop the engine because we know there's no way we want to destroy the engine so straight away I can come in over the radio and tell them without having to do a whole lot of analysis, look at graphs or whatever, straight away I just know tha the engine's got to be turned off to save it. On the right hand side here we've got a few basic things like steering angle, wheel speeds, damper positions and tyre pressures, again I can use things like steering angle, if I can see, let's say the car's gone through the fence somewhere, I know that they're bringing it, they've said look I'm bringing the car back to the pits to get fixed or I'm going to continue on track, if you see an offset in the steering channel, straight away you know that something's bent in the steering. So usually it means an upright or a toe link or something like that is bent.

Again it's just about having more information to be able to relay to the driver, I can see that your steering's bent or being a bit more prepared for understanding what you expect the car might be like depending on how bent the steering is, whether you need to come in and fix it or whether you're happy to let it run on track. Same with the damper positions down here, that can just help you, so if you've got a big offset in one of your corners of your damper positions, it can help tell you, you might have a bent control arm, or a problem with the damper or whatever it is. It's just a way to give yourself a little bit more information. After that, the last one we'll go through is just a basic reliability one which obviously, all of the main engine parameters, things like temperatures, pressures, I've got manifold pressures up here, this particular car has, it's a V style engine so there's a manifold pressure sensor on each side of the engine. Again fuel pump currents down here, again just a place to come, if I'm maybe wondering what's going on and I see something on the main telemetry page and I want to dig in a little bit further, rather than to make that plot from scratch, I can just come here and I can dig into exactly what's going on with it as far as a reliability issue.

So guys, if you've got any questions about what we've talked through today, whether it's about telemetry, whether it's about car setup or maybe the transition even from putting all the RaceCraft stuff over to High Performance Academy, chuck those in the chat and the guys will put those through to me and I'll get onto them in a second, we're just about to finish up here. So the other thing I wanted to mention here is that with a telemetry system, typically you can have your telemetry server set up to receive multiple cars. So in this case I'm only using one piece of logged data from one car, if I was using it in a team environment you might have two, three or four cars even set up coming through that main telemetry server. The reason you would often have a single server to do that is because usually when you're operating as part of a team, you're usually sharing data. So typically, for example in the previous team I worked in, the V8 Supercars, we were a 4 car team, even though I'd be concentrating on my car and my car alone, sometimes I would want to see what's happening with the other team car on track, what are their tyre pressures like? What is their balance like? Maybe what are some of their temperatures or pressures like compared to me? I can just quickly come across there and select their data file and see what's happening with them on track.

Obviously that's only possible in a team environment but it is possible to have multiple data streams coming into a single server. The other thing I wanted to say as well is about security. All of these telemetry systems have security systems built into them so obviously we're wanting to keep, I talked about operating as part of a team and data sharing, if you're in a different team, it's the worst thing you could almost think of to have your logged data being sent to another team or have someone intercept your data. So it's really normal to have security systems on here, I know the way MoTeC handle it is they do a lot of work with encryption. That's just something you need to set up on the logger side and you set up on your server side and after that, it's really transparent to use, you don't even notice it's there but the idea here is that there's not way that another team can practically speaking take your data and use it because even if they were able to intercept it, which is probably a challenge in itself but if they did do that, if they were able to find your information and intercept it, it would be encrypted and it would be useless to them anyway.

So guys, let's jump across and have a look at if we've got any questions that have come from today's webinar. OK I've got a couple of questions here, one from Gordo. Gordo asks, ​not sure how much application it has for those watching, but have you looked at reverse data transfer? Can't recall the correct term, where the telemetry link is used to re-map while the vehicle is driven on-track? It's banned in some motorsport series but could be useful in future for something like endurance racing? Yeah Gordo so there are a couple of different applications there, what Gordo's essentially talking about there is at the moment everything I've been talking about so far is taking data from the car that's happening on track and sending it to the pit, that's a one way thing. So it's just a one way transfer of information. There's not usually a way of, well we don't typically send information from pit to car, it's just car to pit.

The exception of that being radio messages, that's really the only thing you're typically allowed to do. Most of that comes down to rules. I can't think, there's one exception I'll talk about in a second but apart from that I can't really think of any major racing series I've been part of where you're allowed to send anything back to the car in terms of data. The reason they're doing that is because they're trying to stop people have the engineers having direct control over the way the car's working. So they want to avoid engineers making mapping changes to the engine, maybe sending a different configuration to the ECU, they want to stop us interfering with the way the driver's driving the car, maybe we could be there looking at the different parameters and tweaking the traction control system for them so the driver didn't even have to worry about that.

That would be called, normally be called something like illegal driver interference. The idea is that they want the driver to be driving the car alone with no assistance. So that's typically why that stuff is not allowed. One exception to that which isn't actually from the team side but from the race control side is that in V8 Supercars a couple of years ago, they brought in a system where they could send flag information from pit to car. So what I mean by that is whether it was a single yellow flag or a double yellow flag or a safety car board, this was specifically for a racetrack we've got in this part of the world called Bathurst, which is, if you're not familiar with it, it's a super hilly and quite treacherous racetrack and there've been quite a few problems over the years with cars coming around really fast blind corners, particularly at the top of the hill, coming around and having huge impacts with a car that had already had a crash.

So maybe there's a car, it's had a crash all by itself, the car comes around a blind corner and just absolutely t bones this thing. It's a huge safety issue. And part of the reason that this was happening is that the drivers were struggling, they're so concentrated on what's happening with the car and the way they're driving with it they weren't able to pick up the flag points quickly enough. The other part of that as well is obviously if a flag marshall going for a yellow flag or a double yellow flag or a safety car board, there's a latency involved, race control have to call that over the radio, they have to receive that message, they have to decide to grab the right flag and put it out so there's probably two or three seconds minimum there involved in getting that flag on track. The idea here is that race control can just press a button, it's instantaneously sent over the channel to the cars and we were showing the flags, flashing them up on the dashboard for the driver so that was just really a safety issue which I actually thought was quite a nice innovation.

There was certainly, I wouldn't say it was a totally smooth transition into that system, there were certainly a few bugs to figure out along the way but it was, that is an application I can think of where that two way communication has worked. Got a question from Suhas, Suhas asks, what's the cheapest method to get started and implement telemetry? Well there are all sorts of options. One of the ones I actually discovered quite recently, I don't remember the exact, it may have been HP Tuners Track Addict app which is essentially a datalogger app that you can use on your phone. I could be wrong but from what I remember, there was a live data option you could possibly use on that app. So typically when we're talking about data loggers, we're talking about a full on motorsport system that you mount to the car, you plug it in, you wire it, you configure it, there's quite a lot of overhead involved with that.

At the other end of the spectrum, there's a lot of people using their cellphones for this stuff. A cellphone's got a lot of, certainly I should say at the amateur level anyway, a cellphone's got a huge amount of sensing information already built into it and this thing's got, what has it got, G sensors, gyros, GPS, camera, straight away you've got a lot of the ingredients of an entry level data logger built into them. As well it's got a screen so you can use this thing to put in your dashboard, whether it's looking at time variance channels or whether it's even hooking it up, a lot of them have the ability to hook up and show live engine data by using the OBD system, being able to interface with that. Long story short, is that I'm pretty sure I saw an option on that particular app here you could send telemetry data live, obviously your cellphone's connected to the cellular network so potentially you could be sharing that data in real time. So I stand to be corrected on that but I'm pretty sure that and I'm sure quite a lot of other cellphone based loggers have the ability to be able to share live data in a telemetry style format so I would definitely say that is the cheapest way to implement it.

If you're talking about a more conventional logger system. It really depends on the system you're using. The actual telemetry system itself isn't actually particularly expensive. Regardless of whether you're using a cellular or radio system. These days by and large as long as the circuits you're going to have got good cellular coverage, which more and more, as time goes on they do then a cellular system is what I'd recommend.

And they don't have to be particularly expensive, you might be talking in the $200, $300, $400 $500 range for a matching pair of modems. Alternatively at the higher end stuff with really high quality stuff, it gets to the eye watering thousands very quickly but it doesn't have to be particularly expensive to start with. OK from a BoostanEthanol, can you give an example of when you've looked at telemetry to diagnose an issue with the car? Yeah I mean all the time. I would say maybe the most recent one I came across is when we had a fuel pump issue. We had a situation, well there's actually two I can think of, happened on the same race weekend.

We had a fuel pump issue where we had, we could see the driver wasn't actually complaining about anything at that point but we could see when I showed the two different fuel pump currents, so obviously, this is the car that's got a PDM or power distribution module so we can log the currents that are going into each electrical system which is really handy for diagnosing this stuff. So we could see we had one fuel pump that started to drop off or started to do really weird things with its current. So straight away, we knew we had a fuel pump current issue. Now that wasn't actually during a race, that was during a time session. So the beauty of that is that straight away I can see that even though it's not stopping the car, that particular car can run on just one of its main pumps, it's designed as a redundant system.

I can tell the mechanics, look we've got a fuel pump problem, it's not a problem now because we're going to be coming in, the race isn't until tomorrow anyway, just dig out that fuel pump when the car comes in at the end of the day, we will change that pump over and the beauty of that is it gave me an early warning before it even got to the race so it didn't have a chance to even fail. Another one on the same race weekend is that particular car, and it was actually the reason I pointed out those manifold pressure signals, is we had the manifold pressure, there's a sensor per bank and what the ECU is trying to do the whole time, it's trying to basically take both of the banks and look at, it looks if there's a discrepancy between them. So it is actually a known fault on that car that one of the manifold pressure sensors can give problems and so it's something we keep quite a lot of an eye on. We have the ability to do in the car, I can see it's starting to crap out, I can see one of the signals is starting to go a bit weird. The driver started reporting some weird alarms on the dash, I think they were getting a lambda warning on the dash which is obviously an indication that something's going on with the fuel mixture.

So these two things going together, I could see the sensor was going, I could see I was getting a report from the driver that the car was starting to behave weird, it was starting to get a bit weird in acceleration, it was starting to get some alarms on the dash. We've got the ability in that car to be able to force the ECU to use just one of the sensors, so it's got two sensors. In default mode it uses both and takes an average and uses that as an output. Either that or you can force it to use either the left bank or the right bank. So because I could see which bank was having the problem, I was able to tell him just go to left bank and from there it's a bit of a failsafe to be able to use.

It's obviously not ideal, the mixture's not going to be as perfect as it would be if you were taking both signals but it means that the car can continue without having to come back in and pit. So they're just a couple of examples I can think of recently I've used telemetry with. And I've got one last question here from Bismo, how's Barry's kp61 going? Haven't seen any follow up videos since the first one. Mate, tell me about it, what is that guy up to? I will be sure to give him a ribbing when I get back to the workshop. He is so lazy, he doesn't get any work done.

No that's a lie, he's actually going for it all the time. He has made progress on it, I would say it's probably slower than he would have liked but the roll cage is taking more shape in the car. I know he's in the process of making some composite parts for himself. He's recently got hold of for himself a little CNC router so he'll be at some stage, he'll be going hell for leather making a whole lot of really, I'm sure attractive CNC moulds so he can make some more carbon fibre parts for that car. But you're right, the progress hasn't been as quick as any of us would have liked but I'll give him a bit of a rev up for you and hopefully you guys will see some more progress on that in the future.

So guys, that's all the questions we've got. I hope you guys learned something in today's webinar, I hope you found it interesting. Keep an eye out for future courses, as I said, all the RaceCraft courses have come across to HPA, that's where you'll be seeing more of me in the future. Keep an eye out for future courses which the next one coming down the line is a suspension, motorsport suspension course that I will be releasing soon and if you guys aren't watching this live remember you can go through our archive, see all of our old webinars and if any questions come up out of looking at this video after the fact, you can jump into the forum and ask your questions there. Thanks very much guys, see you in the next one.