The Value Of Things We Cannot See, Hear, or Touch (or Smell)


Let's say that someone would offer to sell you a muffler that is legal for your competition class and would make your car faster, and you would gain, on average, about a second/lap on your favorite track - or your money back?

Moreover, that muffler would ONLY work on your car - your competitors would not be able to use it. It's $1500. Does that sound like a good deal?

Now consider another situation. Someone offers you a deal: you would install $500 worth of sensors on your car and pay a race engineer and a race coach $500 each to review the data after your race weekend. Based on that, they will make recommendations for adjustments to both your setup and your driving. The deal has a guarantee that you would gain a second/lap, on average, as a result (if you follow their recommendations). Or your money back.
Does this sound like a great deal? Are you reaching for your credit card already?

Even though on the surface the value is identical, in reality most racers (including performance-minded HPDE drivers) see one as a clear investment/return exchange, and one as a leap of faith of sorts, something that requires consideration of expenses and benefits, recommendations, assurances, and so on.

In this article, I am going to look at some of the reasons behind this and some ideas on how to shift some of the perceptions.

Let me start with the quote from "Speed Secrets":

"Speed Secret 10: You will never win a race without understanding how tires work"

Ross Bentley, Speed Secrets: Professional Race Driving Techniques.

First of all, it's true. I have not won a race, until I understood how tires work (in the case of my first win, rain tires).

Second, it is important that the statement is about understanding. You may want to read it again. I did not fully get that part until after I won my first race. Maybe it's about understanding more than it is about tires. Note how Ross does not write "You will not win a race until you buy some really good tires", or "You will not win a race until you set your tire pressures just right". Not even "You will not win a race, until you hire someone who understands how tires work" (which would had been a reasonable - understandable - thing to do, given Ross's trade, I think). I am going somewhere with this, hang on.

Let's consider information (and understanding, which is a kind of information). Can't see it, hear it, touch it or smell it (in most cases). It's almost as if it is not completely real sometimes, isn't it?

When we go to our first driving event (or our first crew/race support experience), very few of us have much focus on information.

When I instructed novices at the track for example, I often had to explain the basics about things like tire pressures or brake pad wear - which are actually explained in the car's factory manual that has been in the student's glove box all along.

Unfortunately, most instructors are quick to "fill the gaps" in their student's understanding, without taking time or effort to impart how important it is that the student is put on a path of self-learning/self-coaching and seeking out (and verifying!) important information on their own as much as possible.

Substitute "student" for a first time crew member and "instructor" for team owner/crew chief, and a very similar picture often presents itself. Let's call this event "Experience 1" (I like to color code things, but I will spare you that for now - so I will just number the experiences)

Of course, I have met (and worked with) a number of both HPDE/Competition novices, and instructors, coaches, and team owners, who make understanding, and self-learning (directed or not) a priority, while showing (or encouraging) curiosity and critical thinking. Keep up the good work! You are the reason I stuck with this, actually.

Second formative moment (and this one is specific to drivers):  It occurs when we first come upon a "limit", especially if that happens in our search for success in competition. I mean, one of those big, frustrating, baffling "limits": "Everyone is faster!" "Why can't my car/I do this?!" "I am definitely flat out!"

More often then not, first few of such limits are (mostly) in our minds, and through some experimentation, practice or maybe advice from someone with experience, we overcome them.  So some limitation which existed (mostly) in our mind was holding us back, and all we had to do was just drive "better". Some understanding may go along with such "a-ha" moment, and some information may had been important here - but the experience often reinforces focus on action, rather than understanding. Let's call this "Experience 2."

Another important moment comes once we got the basics worked out and achieved some level of consistency. Now adding a mechanical benefit has clear advantage. Such advantage (in most cases) requires nothing beyond money to be realized. You paid for it, and it works. And you are faster. Every time. Or your pit stop is quicker. Or your transporter gets to the track in one piece and on time.

Maybe you even win or complete your first enduro with the car stll running. Or you finally get the car out for that first warm-up session instead of unloading it for an hour. "Experience 3!"

Now things start to get complicated. The driver is consistent, the crew is efficient, and the car had all important "go fast"modifications (at least, affordable ones.) Any gain at this point is measured in tenth of a second, maybe less. Most gains are no longer automatic but require higher level of both preparation and focus to achieve. Often preparation and focus of several team members at the same time.

What to do?

Let's look at data. But do we have a data system? It was not a part of any of those positive, reinforcing experiences! Or maybe we have one, and no one knows how to use it. Or (and this one's my favorite), what we see in the data contradicts what we experience on the track/what the driver is telling us.

Now what?

OK. We can try a change based on what we see (what we think we see) in the data (which we think we understand) Does it help?

It is too bad we are well past type of gains that would be as clear and consistent as what happened during Experiences 2 and 3. 

Doubly so, if the data is coming from a phone app, basic lap timer or un-tested system, and if it is reviewed using software that is either not accessible to novices or has accuracy/clarity problems of it's own.

So, the 4th "formative" experience takes place. This one is not positive. Do any of these sound familiar -

"I looked at the data, and it was not that useful".

"I overlayed <basic data logger or phone app> data over google maps, and it showed me driving through the forest, kind of hard to trust anything after that"

"Maybe someone else can use that, I just need to drive faster"

"Yeah, it shows I am slower in this corner compared to X, so now what? I probably need new tires? New car?"

Some of the statements above are direct quotes... (a couple were re-worded for clarity).

Now let's look at the "programming" that has been established in our hypothetical not-so-novices-anymore, each corresponding to one of the numbered experiences above:

1. I can rely on someone to volunteer relevant, useful information for me to use, even if I invest little effort into obtaining access to it.

2. "Just driving faster"/"fixing" obvious driving technique issue produces big gains.

3. Making an obvious mechanical upgrade produces consistent, predictable gains.

4. Data analysis can be confusing, requires hard to justify expenses, and does not produce consistent, predictable gains.

All of those statements are true in the context of those experiences, yet they add up to a picture that mis-represents benefits of systematic, rigorous, and efficient application of proper data acquisition and analysis (in terms of both coaching the drivers, and tuning their cars, perhaps even improving team-level operations).

Here's the bottom line: Once your performance has consistency and your equipment is as good as rules and budgets allow, ALL you have left is information, understanding that information, and taking action based on it. Not once, or twice or every few weeks- but as a central component of your "program".

If you don't, someone who does will beat you and keep beating you (assuming somewhat comparable resources, of course.)

Let's say you make a change to your rear spring rates on someone's advice. Seems to feel good at first. Does it work in the dry and the wet? Does it work better when the car has full fuel load? What about fresh vs. "aged" tires? Will the change be even more effective if you "add" some anti-roll bar? Add spacers to wheels on opposite axle?

Shit. What to do? 5 test days just to figure out the spring rates? Or a guess?

 OK, how about you just do what everyone else does. Same setup, same engine builder, same wing, same anti-roll bars, same tire sizes. That makes it simpler, right - at least we're "even" (if you naively assume everyone else takes this path...)

But wait, why is everyone driving away from you in turn 3! What is going on?! Is something broken? Did you forget how to drive? Were you no good of a driver to begin with? That spring change - put the old one back in!!! NOW!

Guess what. You ignition system has a miss on days with high humidity at about 4700 RPM. You happen to be unconsciously compensating for that when entering turn 3, by throwing the car faster into the corner (so you are above 4700RPM), and trailing the brakes longer, to get it to turn in.  That changes your entry, and puts you across the seam in the pavement, which disrupts the balance of the car (as you are releasing those brakes with a very tense foot, as you do not want to be over this seam), and now you have to wait for the car to settle, before you get on the throttle. While everyone else is happily driving away...

I can guarantee you, that in an average club racing class, at least half of cars have at least 2 or 3 mechanical issues reducing their speed potential, which their drivers/crew chiefs will not discover, except by accident, or by the issue resulting in catastrophic failure at some point. Is this your car too? Stay tuned to find out...

In any case, this is a lot of stuff to track down - with nothing but your mobile phone or lap timer, basic analysis software to help, and about 12 minutes before you have to get back into the car. That muffler deal sounds real sweet now, right?

What we need here, is a system for understanding things we do not understand yet.

The point I am driving at is that the only way to continue improvement here is through generating,  understanding and ultimately applying, high quality information - as a core component of your effort. It's not about the equipment. I think, this starts with a shift in attitude of sorts and de-programming at least some of those 4 experiences.

Here's how to start on this path. It's almost free! (So, cheaper than that muffler)

Forget phone apps and "budget" data loggers. You will only frustrate yourself in the long run (and worse, you may learn things you may need to unlearn later). Maybe phones and phone apps will get there one day. I've seen some cool stuff but nothing I'd use on my race car yet.

In other words, I am skeptical about what ends up being marketed as "entry level" solutions (and I have data to prove they do not work well), but I would be overjoyed if someone proves me wrong.

Anyway. Here's how to start your very own "Competition Data Analytics" (CDA) program:

1. Get a notepad and a pen. Carry them with you.
2. Take notes and review them - after every time you (or anyone else) drives the car.
3. Watch videos of your races/test sessions and take notes as you watch them.
4. Take notes when you prepare the car for the weekend.
5. Review notes before making changes to the car
6. Review notes when making decisions about how the team operates
7. In an endurance race, debrief all drivers, take notes and review notes with all drivers as they get ready for their stints.  Debrief pit stop crew and take notes. Watch videos of driving stints and stops (and, you guessed it, take notes!)

This works. Or your money back (for the notepad)

Eventually, your ideas on costs and benefits of "information processing" will start changing as your experience grows. Data logging equipment and data analysis equipment/services will simply become next logical step. No one will need to "market" them to you.

Enjoy.

Speed up your race data analysis

Going through your data from a race weekend, or a test day can take a long time.
Racers do not have a lot of time. So, tough deal, right.

Yep.

Below are some of the tips based on what I have learned over the years to "optimize" how data analysis time is spent. After all, the goal is not, necessarily, to spend less time reviewing your (or another driver's) data - the goal is to get a return on your investment.

What's this return I speak of? Think of it as "Actionable Insight". What does this mean?
Insight - "The driver and/or engineer learned something he or she did not know." Or, perhaps,  confirmed something that was only suspected. Or even better - disproved something  that was suspected, putting an end to some crazy theory.  Examples:

• "Turn 2 has a lot more impact on lap times than Turn 1"
• "The car loses power once Oil Temperature crosses 240 degrees"
• "I did not forget how to drive a race car, all of a sudden - I just need to do better compensating for overheating tires, next time"
• In left hand corners, at low speed motion range, right rear shock spends more time in compression than in rebound

Actionable - "The driver (or the engineer) is willing and able to do something about what is discovered", - i.e. to take advantage of the Insight gained. Examples:

• "I will focus on Turn 2 Entry, even if it has to come at the expense of Turn 1 Speed"
• "I am going to put secondary oil heat exchanger in, and check the data again to see if that "postpones" the power loss until later in the race
• Next time I am waiting on the grid, I will remind myself  (or ask my crew to remind me) to stay aware of tire conditions if the car changes its handling halfway through the race
• Ask the crew to turn down compression damping on the right rear, re-evaluate damping dynamics after the next session, as well as changes in the car's behavior in left hand corners

Some of the things one may learn from the data  may appear interesting and even useful, but are not "Actionable Insight". If you want to maximize effectiveness of time spent with data, such discoveries can be classified, generally, as a waste of time. One exception is if you are just learning capabilities of a particular analysis method/approach, so your goal is practicing the process itself, rather than gaining an 'Actionable Insight"

• I am faster than Carl. Carl sucks at this driving thing
• Now that I put on the supercharger, I can go 163 mph down the straight
• My fastest lap is faster than some other lap
• Carl gets on the throttle much earlier than me, in turns 2 and 6*

*The last one pretends to be an "Actionable Insight"- but it's a fake! Let me explain.

When was the last time you were in the corner, and thought "Hmm. I just don't feel like getting back to the throttle. It's too much work. I'll just wait and see if someone else would do it for me"?

In the majority of cases where there is delayed throttle application, the driver has a reason for it- very often some very good reason, that indicates that something is taking place at a deeper level, and the onion is begging to be peeled! So, strive to peel the damn thing, until you get at that reason - which can be addressed (or, perhaps, it would make clear that there is nothing to be addressed and the focus should be shifted elsewhere), either way, an "Actionable Insight" is likely to follow, for  example:

• The driver turned in early and failed to rotate the car decisively. Getting to the throttle early will cause understeer, and the car will run out of track at the exit
• Car is using all of its grip, and adding throttle will cause either front or rear to lose traction
• The driver thinks that the car is using all its grip and adding throttle would cause the car to lose grip
•  There is another car in front of the driver
• The seating position makes it difficult to depress the pedal fully until the lateral force is decreased (YES, THAT HAPPENS!)
• There is another car behind the driver, and the driver is too distracted watching his or her mirror.
• The driver is not looking far enough ahead
• The driver got on the throttle too aggressively initially, had to go off line to "save it", and is now hanging onto the wrong side of the track.

I could go on, I have another dozen lined up :) The point is - not figuring out what it is, that can be addressed to get to the throttle earlier, makes the insight non-actionable. Thus, mostly useless. On the other hand, peeling the onion will make you cry. I mean, will result in you gaining an Actionable Insight (which may or may not make you cry...)

OK. Here are the promised tips:

1. Invest time into learning about capabilities and limitations of your data system, and analysis software you are using. Are you only using 20% of analysis software capabilities? 50%? 90%? Are there more efficient ways to go about your analysis? What if you plugged those numbers into Excel? What if you put this on one screen, and this on the other one? Never assume that what you are able to do today, is the most effective way of achieving your goals. Just like your driving... You got better at driving by methods other than doing the same thing over and over, this is no different.

2. Take notes at the track, and review them before you dive into the data. This can be a huge time saver - in both picking the right sessions/laps too look at, and at setting goals for what kind of  "Actionable Insights" you are after. I, sometimes, get out of the car and take a note "need to check/confirm XYZ in the data". Even if it's weeks before I look at the data from the session, the note is there, so I can focus on what was important (and it often serves as a tool to recall specific events that prompted the note)

3. Same as above, with the video. If you don't have time to review whole session's worth of video before reviewing the date, at least watch 2 or 3 complete laps, and a few seconds for all other laps (this will remind you what kind of traffic you were dealing with, and what the track conditions were).

Note: Some systems will allow you to integrate video with your data analysis software, so as you scroll the data around, the video frames follow (to be clear, I am not talking about tools that just overlay/paste few selected channel values onto the video, to produce a video you are going to show off to your youtube "friends" -  but, rather, a solution where the video becomes one of the analysis channels).
If you can afford time and effort to set this up, it will take your analysis to the next level, guaranteed.


4. Use "Channel report"/Section time summary views. They will save you A LOT of time. Set them up so they show you some measures of braking, cornering, and acceleration performance in critical sections, and you can easily track both consistency across laps/sections, as well as any patterns that may develop lap to lap. I spend as much, if not more, time in various summary/statistic-type views as I do browsing through actual channel traces.
Here's an example of a simple view - for each channel, some measure of its values is summarized for each lap:

Here's more advanced view - now summarization happens per section (more on sections below). I know it looks busy, but you are taking in A LOT of information quickly, if you practice to interpret these, as opposed to "trace" views, where, at best, you are only getting a lap or two's worth of data before you have to scroll around:

5. Related to above - ensure that you have pre-set map sections set up for the tracks you drive the most. Here's the main method I use to set up track sections/segments:

• Each section begins just before "normal" beginning of braking point. This confines any issues resulting from braking performance to a single section, the same one as the one most affected by such changes.
• If a corner is followed by a straight with a single upshift, that straightway is part of the same section as the preceding corner.
• "Long" straights (2 or more shift, or some other separation method), get their own section
• Corners that are "stringed" together in such a way that changing something in the first one affects how you drive the following one, become parts of the same section, even if there is brake application in between.

The idea behind such method is that any performance (car or driver) patterns specific to a specific type of situation (i.e. braking for a specific corner, accelerating out of left hand corners, issues with a racing line in a specific corner) are confined to corresponding sections. For example if something happens under braking for turn "11" (sharp blue left hander on the map below, with number 6 over it), it would be confined to section 6, as would most of the consequences.

Here's an example, with annotations illustrating the method described:

  I have seen some drivers set up sections so that the sequence of numbers matches official track maps. There's little value in that, compared to the benefit of an approach like the one described.

6. If you are not getting anywhere, watch the video of the session. Nothing works as well to focus your analysis as "immersing" yourself into the actual experience of being in a race car on the track.

7. Check and maintain calibration of all critical sensors. For a discussion of accelerometer correctness, including an explanation of why it is critical, and procedure to correct as needed, see my earlier post

I hope you can find practical use for these. Remember: "Actionable Insights"!

Correcting longitudinal/lateral skew in accelerometer data traces.

Hmm. The title does not convey the importance of the subject. How about
"How to make your data to stop lying to you"?

I promised to cover the subject in Truths and lies of your basic racing datalogger.

 

What is actually the problem here?

As described in that post, there are 2 ways to get your acceleration values: one is through accelerometer's signal ("Proper Acceleration"), and another, through taking a second order derivative of your movement along or across your direction of travel ("GPS Acceleration", for the lack of a better term). As demonstrated in that post, "GPS Acceleration" can only be considered an approximation of what is actually going on. In most cases, very poor approximation indeed, requiring heavy post processing to result in anything resembling actual acceleration, as experienced by your race car and yourself or your driver.

"Proper Acceleration" measurement can have its own problems, it turns out. Here are 2 race cars. In the one on the left, accelerometer is positioned "square" with Longitudinal and Lateral axis of the car (yellow and white axis are aligned). Life is good.

In the one on the right, the accelerometer is rotated (yellow and white axis are not aligned) Now, when the car experiences Longitudinal acceleration, some component of it gets picked up by accelerometer's Longitudinal axis, and some - by its Lateral axis! Same for Lateral acceleration.

So, when you go and examine your data after the fact, you now see that your car has non-zero lateral acceleration when it is driving down the straight!

Here's an example:

Something is clearly not right. The car is driving down the straight yet it shows up to 0.1 G of Proper Lateral acceleration.
Of course, you can add an offset, of, say, -0.1 G, but now it's off in other sections. And, this also means that Longitudinal acceleration is off as well, without any clear indications of how much.

Your logger may offer a tool to calibrate itself to re-align the axis. To be honest, I have seen more cases where it did not work, than the ones where it did, so this is not my preferred way of resolving this issue.

By the way, you may ask, what's the big deal?

Well. I am glad you asked.

If we are talking about basic data logger that only records GPS and accelerometer data, and your Longitudinal and Lateral acceleration data is skewed - even by few degrees - here  are types of analysis you cannot do, since your results will range from meaningless to dangerously misleading:

• Everything except staring at GPS Speed trace and your lap/segment times.

And here are types of analysis you can still do with skewed accelerometer data:

• Staring at your GPS Speed trace
• Lap/Segment times

I hope you enjoy staring at your GPS Trace... You can actually get a lot of useful info out of  Segment times analysis, so there's that.

Do you want to look at brake application profile? Engine performance? Cornering grip? Sorry, your results will be off, possibly to the point your analysis is hurting more than helping. Garbage in, garbage out, and all that.

Luckily, this is fairly straightforward problem to fix

We will be using math channels, and applying some high school geometry.(https://en.wikipedia.org/wiki/Rotation_(mathematics) - see "two dimensions section"). You remember your two dimensional vector rotations, don't you?

OK, here's how to set it up.

 Let's use AiM Race Analysis. After all, AiM solo is nearly 100% likely to be mis-oriented to the axis of the car it is mounted on... When you make something too easy, you run the risk of making it too easy to get it wrong.

By the way, this assumes that the accelerometer is, at least, aligned vertically (i.e. not tilted up/down, or, Euclid forbid, is lying down "on its face").

If not, the principles are similar, but you will have to correct in 3 dimension. Easy, right?


So, here we go.

Step 1.

Load up the session and create 2 “X-Y Plots”: Click “X-Y Plot” button, then select “create new”, instead of “activate existing”. Do it twice.

Step 2.

 Now, click on the windows resize button, to make the UI allow you to lay out all windows (instead of default single-tabbed-window view). For reasons we will never understand, that button is called "Restore-Down"...

 

 

Step 3.

 Now, it will look like RA just had a stroke. Don't panic, and calmly arrange 2 XY plot windows next to each other, don't worry about anything that may be hiding under them (don't worry if what's in the actual plot windows looks different, at this point)

 

 Step 4.

 Right click on the right plot, and go to "Plot Settings" (NOT "Settings"!)

 

Step 5.

 Select "GPS_LatAcc", or whatever it is called on your AiM logger as X axis.

Step 6.

Make sure you have same X-Y Plot selected (click anywhere within plot area). Now, in the "Measure list", on the left, select "GPS_LonAcc", and un-select everything else.

 Now, the right hand plot should look like this:

If it does not, and you are not able to make it look similar to this, I would recommend that you look through AiM tutorial/help files on X-Y Plots or call your AiM dealer and ask for help. I personally find that UI bewildering and illogical, not to mention outdated by about 30 years (just an opinion, ya'll), so I am not the best person to explain the basics of it to others...Err. Good luck. If you are REALLY stuck on this, email me.

OK, now we are going to create some math channels. If you never created AiM math channel, I highly recommend that you watch this video first, which walks through the basics of creating a calculated gear math channel:

 

 

Anyway, we are going to create 3 channels:

A. "G Angle Correction"

Set it as per this screenshot, I highlighted fields you will need to configure:

 

In "Formula", enter "0" instead of "-9", for now. everything else as shown.

B.  Corrected_lat_acc:

 

"Formula" value to copy/paste:

Longitudinal_a*sin(DEG2RAD*G Angle Correction)+Lateral_acc*cos(DEG2RAD*G Angle Correction)

Note: If your accelerometer has Longitudinal and Lateral acceleration values named differently than "Longitudinal_a" and "Lateral_acc", you will have to update those names, obviously. Use whichever ones you see in the "Identifier" list on the right (what, you mean it was not obvious that "IDENTIFIER" means  "LOGGED OR CALCULATED CHANNEL in Italian?!" Jeez...)

C. Corrected_long_acc:

"Formula" value to copy/paste:

Longitudinal_a*cos(DEG2RAD*G Angle Correction)-Lateral_acc*sin(DEG2RAD*G Angle Correction)

 Note: See above regarding channel names.

 

OK. Now you can leave math menu and finally configure X-Y plot on the left.

Basically, you are doing same exact thing as steps 4,5, and 6 above, but now use Corrected_lat_acc as X axis value, and Corrected_long_acc as the ONLY selected measure for the left hand plot.

 

Whew. If you had done everything right, and Pinocchio did not play any tricks on you along the way, you are going to see 2 "Friction Circle" plots, one of which is "rotated":

 

 

 

In the other post, I mentioned that GPS Acceleration values should not be trusted. Well, I was not entirely correct there. They can be trusted in terms of generalizes trends/distribution - i.e. as a baseline to understand how much "skew" we have in our accelerometer data. I am sorry, Pinocchio. I hope you can find it in your hard, wooden heart to forgive me.

Where was I? Ah OK. If you entered "0" in the G Angle Correction math formula, AND the left friction circle plot is not rotated relative to the right one, you are all set. You do not have any skew in your accelerometer data. Don't be mad at me for wasting your time, you have 2 new shiny friction circle plots to play with!

If the left one IS rotated, now comes the fun part. Go back to Maths menu, and enter a different value into G Angle Correction formula. Let's say, -20!

 

 

 

Well?

 

 

Oops, too much. Go back and back that value off a bit. It may take a few tries. Eventually, you should get something that looks like this:

 

 

Sweet!

 

All you have to do now, is use Corrected_long_acc and  Corrected_lat_acc in your analysis!

By the way, before you do anything else, go back to Maths, copy all 3 channels to "General" tab, and set checkbox for all of them to be inserted into new files automatically. This way, you will not have to repeat all this for every log file. Obviously, if you change orientation of your logger, or load someone else's file, you will need to go and adjust that value. Use "double friction circle" view to check alignment in new files and you should be golden.

Oh, to go back to "classic" RA view, just hit "Maximize" button on any of the windows...

 

 

Here's how much difference this can make:

 

Highlighted are the sections where data skew was creating a pattern that was outright wrong for what was actually going on with the car. This was about 9 degree rotation of the logger relative to the car.

 

Here's more extreme example, where the logger is rotated nearly 20 degrees:

 

Hopefully, these examples drive the point home, regarding how critical it is to

1. Check if your accelerometer is aligned with car's axis

2. Create corrected channels if it is not, and use ONLY those channels for your analysis.

 

 

 

Speeding up your section time/performance analysis, using maths and sciences.

(originally posted on facebooks, this is edited/updated version)

I know that most of you pick your data system based on cost and "peer pressure". Let me make a case for the importance of choosing a system that gives you access to real analysis capabilities, for example, basic statistical analysis. This could mean that you may need to go outside of software package provided by the manufacturer of your data logging device.


Today, even Excel gives you tools for fairly advanced statistical analysis and visualizations - so if your "racing" data logger software suite does not, and you do want to unlock the miracles of modern data analysis and visualization technologies, you can export your data to a different analysis package. For example, Microsoft Excel! Or, if you want to really impress your friends, MATLAB...

OK, so let's consider specific example having to do with section times and "fastest laps". If you ever switched back and forth between your segment time charts and trace views, trying to figure out if your best lap still "left some time on the table", perhaps in specific sections, you may find it easy to relate to this example.

If, on the other hand,  you are not sure what's the deal with delta/lamda/variance/diff traces, or segment/split reports, you can start by watching James Colborn's video about driver/lap comparison:

Watch the video for an example of how both difference/variance trace and segment time reports can be used for the analysis, and how valuable the data encoded in both of those views can be - as a very nice bonus, it also has an example of how exporting data into Excel for analysis can help you get around limitations of "native" analysis software.

Anyhow, onward to the example.

So, the Variance trace (or "Delta") trace can be used to compare laps (again, if you are not sure how, check out the video above). Orange highlight in the screenshot shows pretty typical one.

While occasionally, those traces are straightforward, if you look at enough of them, especially from the same car, you will come across many that go up, then down, then up, then down, etc., when comparing 2 or more laps, likely creating somewhat mixed and confusing picture.

Maybe it goes down sharply, then gradually rises? And then does the reverse? Does it go down in the corners, then up on the straights? Up in left handers, down in right handers? Up under braking, down on turn-ins? Up when your spotter is keying the radio accidentally, down when you remember about that cold beer you stashed in the cooler?


In fact, I am willing to bet that most drivers or aspiring race engineers, who give up on going deeper into data analysis (and/or on applying it to better their racing program), do so after seeing really bewildering things that such trace can do...  We hear a lot about importance of variance/delta traces - but aside from a views like the one above, there are not really any tools or examples on how to "un-confuse" what real world data often looks like.


Of course, you can flip to section/segment time view (or put it on the second monitor, etc):

while it does allow you to review all of the data at once, unfortunately, this is really good way to overload your brain when you switch to, and away from this view, repeatedly.

"Wait, was I looking for times in Turn 5 or 6? Is difference between 7.995 and 8.071 more important than difference between 5.841 and 5.728? Let me flip back to trace view... Then back again. Where was I?"

For whatever reason, our brains do not work well when trying to put together tables of numbers with a bunch of squiggly lines, to form a comprehensive answer to a complex question. I guess that's what happens when your brain evolves as a result of chasing venison across grassy plains. Bummer. Why couldn't cavemen spend more time on maths, statistics and race cars? Oh, right...

Well, since we already have the concept of track segments, why not make the Variance trace run "per-segment". After all, really interesting questions are not "How this lap came to be this much faster than that one" or "Which car/driver is faster", but the ones like:

• "Where can I do something differently as far as my driving technique, to improve my time, and what exactly should it be?"
• "Which specific segment/transition should I optimize my setup for?
• "Which section may be exposing a mechanical problem, holding me back"? 
• "How can I do all this in 10 minutes I have before the car goes to the grid for the next race/session"?

The idea is that if you can, at a glance, see where there is significant gain/loss between two laps, instead of dicking around with comparison cursor (drawing even more lines - ugh) or introducing another view of data (segment tables) - if you can do that in the same view you do most of your analysis in, you get to important insights faster, meaning that you will find more of them in the time you have. Perhaps, more than your competitors will, given the same time!

Well, such view is quite possible, and here it is:

Is that easier to read? I highlighted some obvious patterns. This view , actually, turns out to have sort of a language of it's own:

• "Shallow slope" triangles (i.e. green highlights above):  acceleration/drag  differences, or grip in sustained load/sweeping corners - see green highlighted sections
• "Steep slope" triangles: throttle or brake application differences  - see beginning and middle of first red highlighted section)
• "Very steep slop" triangles, nearly rectangular in shape: difference resulting from brake applications - see second red highlighted section
• "Up-and-down/sine wave" shapes (in the same corner-straight sequence) - these are usually trade-offs between entry speeds and early/mid corner grip and throttle application - see last red highlighted section

While it may take a little getting used to, this view has proven very effective at not only identifying significant/important areas of the track, or aspects of tuning changes that go in the right or wrong direction, but also at classifying them quickly, which focuses more detailed level of analysis on areas likely to produce useful, actionable insights.

Real analysis software makes it relatively simple to set up. I added some information of how such view can be created in MoTeC software, at the end on this article.

Another idea - what if, looking at traces of your "best" lap, you could add a trace that tells you which sections of it are not actually "best" - and, by how much. Perhaps, best lap has 8 sections, which, on 2 other laps, had better times (and 3 of those sections had significantly better times), even though those other 2 laps were not faster overall?

With the approach commonly taught/practiced (and the only one possible with more basic analysis software), you will need to look through segment time table OR go through variance traces for at least 2 more laps. See how long it takes you to find 3 sections on laps other than 1.46.9 lap, which are significantly faster (at least 0.1s)?

Are you SURE you found the right 3? Maybe there are 4 of those! 2? Better check again...
And this is just 6 laps! What if your data set has 40 laps? How about 400?

Why not have a trace that simply tells you how far each section time is from your "best" time for that section?

Ah, so there are only 2 sections that have times faster by at least 0.1 sec on other laps, not 3! The third one is only 0.096s faster :)

How long did it take you to find 3 sections that are "not like the others" on this last view?

I really love this view - it allows me to see right away, how much important information there is in the "fastest lap", vs other laps in the session.  And, there is no need to go to section time tables, or to spend hours of my life untangling endless variance/delta squiggles, until I know exactly which section of which lap I want to look at.

It also makes it easy to see that even  though the reference lap was the fastest in session, it left about 0.3 sec on the table, based on section times collected from ALL laps - again, without any need to switch the view away from trace view.

Now, imagine how powerful this method is, if you are looking at data from endurance race, with possibly hundreds of laps..

Well, congratulations if you have gotten to this point :)


Here's how by-section Variance can be set up in MoTeC I2 Pro:

First, you need to set up "SectionRunningTime" as

'Calc Outing Time' [s]-stat_start('Calc Outing Time' [s],1,range_change("Outings:Laps:Track Sections:Default"))

If you did it right, it should show up like this:

 (This is where AiM stuff chokes, as it doesn't seem to allow a way to reference data by-segment. It could do some stuff by lap, but it does not expose ability to create and manipulate ranges/segments inside laps without some serious hacking that would need to be replicated for each track - if you can figure out reasonably portable way how to do that - let me know)

Next, we need to take care of timing "jumps" around edges of segments, otherwise the chart looks a little insane.

For this, I create function called DeltaSectionSmoothness:

derivative(variance_dist('SectionRunningTime' [s]))

Here's what it does:

Think of it as "alarm" that goes off when there is a sudden "jump" between running total for a section distance across 2 laps - which is what happens when the transition between 2 segments n 2 laps is slightly shifted in relation to each other (you can search for "GPS Drift" if you are interested in underlying reasons for why that happens, sometimes)

Now, we can write a formula for our section-specific Variance:

choose(abs('DeltaSectionSmoothness') > 0.8, invalid(), variance_dist('SectionRunningTime' [s]))

What it says, is: Calculate by-distance Variance, between 'SectionRunningTime' values of two laps, EXCEPT when 'DeltaSectionSmoothness' has triggered the "un-smoothness" condition.

If we were to remove that condition, we'd get some ugly vertical lines between some sections, here's example of both un-smoothed, and "smoothed" versions:

Well, that's it. Building "Delta with Session Best" trace is a little more complicated, so I will leave that out.

Weight Transfer Visualization

(originally posted on facebooks)

OK, if you have ever taken a performance driving class, or club HPDE ground school, or read anything at all about race track driving, you heard all about "weight transfer". Well, guess what. Weight transfer is just like bank transfer, with the money that you borrowed!
You have to pay interest, and they only accept grip as payment. Not fair. But what can you do? Well. Borrow only what you absolutely need!
This analogy is becoming silly. Or - maybe - not so silly! See the video for a practical demonstration:

Truths and lies of your basic racing data logger.

Your most basic racing data logger has 2 main components: GPS unit and accelerometer. It is helpful to understand what each does, what are the limitations of their signals, and how accurate are the measurements which are derived from their signals.


To simplify things somewhat, GPS unit records current time (as received from the satellites above you), as well as your location in reference to some satellites above you, while accelerometer records forces acting on your car in 1, 2 or 3 dimensions.

Most useful pieces of information that GPS unit will record, will be your position on the track, as well as your speed along the track's direction, calculated from 2 or more of your positions and associated times (first order derivative). If your data analysis software has some level of sophistication, it could also calculate your accelerations as derivatives of such speeds (second order derivative). We'll refer to such measurements as "GPS Acceleration".

Accelerometer will record "Proper Acceleration" - yes - that's the actual term for that, specifically "instantaneous" effects of forces acting on the car, along up to 3 axis. Of these, most interesting are Longitudinal acceleration (acceleration along rear-to-front axis of your car) and Lateral acceleration (acceleration along left-to-right axis of your car). Longitudinal acceleration is a measure of how hard you brake and, well, accelerate, while Longitudinal acceleration reflects how hard you are cornering. This is somewhat of simplification, but it'll do. For now.

If I already lost you at this point, sorry. Didn't I say this will be tedious and boring?

GPS uses antenna and mini-microprocessor. Cool! Accelerometers use variety of technologies, most basic being a weight suspended on some springs. Leonardo Da Vinci would had been proud. Modern ones use piezoceramics and quantum tunneling. Now we're talking.

Here's an example:

Red line is speed recorded by a wheel sensor. Purple line is speed recorded by GPS microchip. Notice that GPS speed is not always accurate. Sometimes it "lags" sudden changes in "Actual" speed, sometimes it has weird fluctuations. If your software shows GPS Speed as perfectly smooth, with no artefacts like that, your software is lying to you! This is particularly a problem for "certain" software developed for karting, then finding its way into road racing by means of clever, and somewhat shameless, marketing.

But why? - you may ask. Why can't I have perfectly smooth, always accurate GPS Speed? Well, GPS signal does not work that way. It is, at best, an approximation of reality when it comes to speed, and speed senor measuring revolutions of your speed or your driveshaft will almost always have higher precision, especially during acceleration/deceleration.

What? Well, remember that what GPS is really good at - what it is designed to do, in fact, is determining your time and position. That's how you get a bomb to land in a back of a Toyota pickup.
Speed is a "first order derivative". Without going into too much math, it's basically a calculation with an order of accuracy sacrificed, to get more data. Basically, it would be like watching someone eat 3 pounds of ice cream, then "deriving" a conclusion that this person will be 3 pounds heavier for the next 2 hours. You may be a little off. It may end up being 2.7lbs for the next 2.8 hours. But you "derived" more information about the situation. This is not  the greatest analogy, I must admit.
Anyway. (nearly) Every time you take a real world derivative, you sacrifice some precision.

So, if you take a derivative from speed, you get acceleration (Physics and Math magic, just trust me on this). That is the green trace above. Notice, that while it generally follows yellow trace (direct measurement of proper acceleration, from accelerometer), it is sort of all over the place. That's normal and expected. It can be smoothed and filtered, of course - but then it may not be as accurate at any given point. Tough choice.

Here's how you spot when your software is "massaging" the data behind the scenes, to make those 1st and 2nd order derivatives look smooth and neat (which can easily mislead, or, at least, misinform your data analysis):

Ah, those wonderful, smooth curves, sweeping peaks and valleys. Lies, all lies. Pink line is GPS Speed (first order derivative). Can it be more precise than speed measured by the wheel rotation (light blue line)? Nope. Not possible. Even if it was measured by a military grade GPS chip, and not $400 pocket lap timer, it would still not be as precise measuring speed, as wheel speed signal. So, Pinocchio is pulling the fast one on you.

Now, check out green trace. This is a second order derivative, "GPS Acceleration" (Lateral, in this case). Compare it to the brown Lateral trace from actual accelerometer (which, by the way, is also smoothed and "fixed" by the software - thanks, I guess). Is it possible that 2nd order derivative is more accurate than direct, "proper" measurement? Nope. Can you eyeball how much ice cream your friend ate, and then tell precisely how much heavier he (or she!) is? Nah-ah. So, how can it be so smooth and neat? Only as a result of doctoring, approximating, and smoothing the values to the point where they are so off from the actual measurement, they become close to meaningless. Shame on you, Pinocchio. Back to your go-kart, stay away from my race car!

OK. But is this all important? Well, that depends. When you use your racing data, do you want to be sort of in the ballpark, or dead on?

Is it important that your data traces make for nice, good looking curves, with simple messages about your (or your competitors) driving, or do you want to have access to all the complexities and nuances of hardware signal resolutions, sampling rates, GPS drift and signal strength?

Priorities will, of course, vary, but at the very least, the choices should be informed.

Coming up next time - how to fix mis-oriented (disoriented?!) accelerometer signal in your data.

Preview:

Welcome to MR blog

Welcome!

I am starting this as somewhat of a permanent place to record various bits and pieces of information that materialized around requests for advice or opinion, as well as unsolicited messages to the racing community I interact with.  Most of it will  have to do with collecting and understanding racing data, as well as practical applications of insights gained that way. Some may have deal with my personal racing experiences.

Some of you may find this stuff interesting, useful, or amusing. Most will find this boring and overly technical.

That's too bad.

Modern civilization owes little to great politicians, generals, musicians, or poets (or racing drivers) of the past. Nearly every benefit of modern world we have at our disposal, is a result of work of scientists and engineers (rarely appreciated or even remembered), tirelessly applying methods that most find boring, in search of advances in our understanding of ourselves and the world around us.

Also, race cars.

In the last few month, some people asked me for a reference to a place to look up information about my team, and what we do. I suppose this would be it. Do not expect PR-polished messages, or praises in support of our sponsors. There are other places for that. This is simply about information and a place to share comments and opinions.

Every time I describe this side of my life on the Internets, I inevitably receive questions from strangers about how to become a racing driver. I suppose that's inevitable that this will generate a few more of those. While I will continue to answer such questions, you'd have to contact me through some other means for that, this place is for different kind of subjects.

Igor

P.S. Here is one of my most favorite race car development pictures. I call it "Reflections".