Introducing CINTI

"CINTI" is a Competition Data Analytics system I have been working on, for some time.

For about a year and a half, it's been a disjointed collection of data crunching scripts, experiments, math channels in I2Pro and other packages, half formed ideas, and so on. It had finally come together into a package that has some cohesiveness to it. There are few teams/racers/race prep shops, that have been kind enough to agree to work with me in 2017, to apply real world experience to what's being built here. Some of their advice has already been tremendously helpful in focusing the work, and I am very excited about these collaborations, and what we are going to create here.

This particular article is not meant to be any sort of marketing pitch, or a presentation of value CINTI may or may not bring to someone looking to move their data-driven competition to the next level (Ok, that's starting to sound like a sales thing. Sorry!)

Instead, I wanted to talk about some of the motivations and goals behind building this, and to describe  some of the principles that are guiding the development.

Here's a brief preview of early prototypes/mock-ups, for a couple of modules:

Main idea is that CINTI CDA will create a kind of a "funnel" for several common and (usually) important analysis scenarios, with a focus on "actionable insights". This would be accessible to anyone comfortable with selecting things by dragging boxes around them, and clicking one button out of a dozen or so offered. Here are some examples of analysis scenarios:

• The driver improved his or her best time at Portland International, by 1.5 seconds.
• Was it the engine tuning change? Drafting another car on the straight, better grip from the tires? Maybe driver coaching during the test day made the real difference here?
• If it was some combination of the above, what proportion of the improvement came from each specific area?
• Did tuning change actually slow down the car, but fresh tires and higher corner speeds made up for it, and then some?
• Can this gain be repeated/taken further? If yes, how? If no, why?
• The data from 2 cars  and 2 drivers is compared. Both post similar performance in terms of lap times
• Do cars and drivers perform similarly in all aspects, or are there advantages and shortcomings that balance out?
• Can we learn something from such comparison, to make both cars (and drivers) faster?

If you have done this sort of analysis, I bet your experience was probably along one of these 3 scenarios:

1. You already had some knowledge about the car and the driver involved. You coached quite a few drivers, and/or set up quite a few cars. Maybe you run arrive-and-drive business, or you belong to a group of spec car racers who are willing to talk to each other in between filing all the protests.  You had pretty good guess about what could had been going on, and you were able to look at one of the pre-configured views to confirm or disprove it quickly. That's great. The only problem, is that if your guess was correct, and you confirmed it, you may had missed another 3 things that were going on. If your guess was not correct, and your ego is somewhat flexible (unusual but not impossible), you are moving on to the Scenario 2 below. 

Missing important secondary patterns/trends is probably the most common pitfall here, especially with analysis methods that over-focus on differences in speed traces and section times. Yes, sure, the car was over-slowed for turn 4. But WHY? Yes, the driver went on (or off) the brakes too early, but WHY? Yes, the brakes were used efficiently in all other corners, but turn 4, but WHY? Was the difference in braking the MAIN reason the car was over-slowed? Could the car REALLY carry more speed through turn 4, on that day, in that session, on that lap - and if it could - if the driver could - WHY didn't he (or she)*?

You can see the risk of prematurely separating the analysis from the data, and moving into the area of guesses, intuition, and personal expertise. Not a problem, if you have been doing it for years, and you have managed to combine accurate judgement with flexible ego (rare, but not impossible). What if that's not the case?

2. You open up your analysis software and start piling traces onto each other, looking for patterns that could be related to your question (That's how I started out - bad old days...) If you are lucky, and the software compatible with your logger allows you to lay stuff out efficiently, and mix/match different types of data on the same screen - without things looking like a bowl of spaghetti thrown against the wall - you may even learn something, before you have to pack up your efforts for the night, or your brain starts to hurt - or you have to pack up because your brain started to hurt. Or, you are flinging your food against the wall, in frustration.

In my experience, true "exploratory" analysis is utterly incompatible with "out of the box" analysis software out there. To the point where I would not bother with it anymore, unless I know I have at least 3-4 hours to spend on 1 days' worth of data, and that's for a single car/driver. Or I am getting paid very, very well for my frustrations.

In any other industry, this situation would be silly to unacceptable, and would lead to bankruptcies and other kinds of shame and failure, eventually resulting in progress. For some strange reason, in racing, it is the norm to require such enormous investment of time and expertise, just to answer a series of simple questions.

3. You are professional (or aspiring) race engineer, you have worked with all types of data out there, you have a library of math channels you developed to make exploratory analysis efficient, and you would not work with a team until they install a dozen of sensors on the car, so every critical input and/or response is logged at the right sampling rate. 

Life is pretty good. This is where I thought I was going with this.

Life is good - but only until the pulley on the steering sensor comes loose, the fuse on the power supply to suspension sensors' hub has burned out, and mechanics forgot to plug in the harness for brake pressure senders when they fixed seeping brake line. In addition, no useful information can be extracted from the driver, even after "special measures" had been applied.

OK. Let's see you figure out cornering balance and braking efficiency now, Mr. Engineer!

If you really do this seriously, you know that even the basic accelerometer and speed/position signals have information about those things**. If you are like me, you may had even tried to create "math channels" to extract that, and, inevitably, ran up against the limits of the analysis software - which is why you demand space shuttle levels of instrumentation.

Let me put it this way - if it is possible to look at the speed trace, and 2 accelerometer traces, and to make really good guess about the car, say,  understeering mid-corner (I highly recommend "Data Power" book by Buddy Fey, if you do not believe me on this) - if that is possible, then why can't your basic data analysis software do this today? Oh sure. You can pay MoTeC nearly $1000 for "Pro" version of I2, and install steering angle sensor, and then use the "Oversteer" channel. The results are underwhelming at best, and confusing at worst, until you've used that for a while... And written yet another math channel to calibrate/clean up the output, and set up just the right view. And the sensors get zeroed out. And then -  you have to use someone else's laptop one day -  and... oops. How do I do this again?

The popular software packages used for this have been on the market for 20+ years - why can't they do this? The book I mentioned - It was published before I was born! Today, we have software that can sequence genome and find planets based on nothing but their gravitational effects on things light-years away from us, we can predict the next thing someone will impulsively buy on Amazon, but we need the damn steering angle sensor signal, and 3 math channels, and then another special one for rain conditions, to confirm that the car is unstable in transition after turn-in?

So, my goal is to start moving away from all 3 of these "modes" of analysis, while still having an option for "Expert Exploration".

How?

There are 2 parts to that. First: automating how the information is extracted from the data. Information is something you understand, something you want to know, something you can choose to act upon. If it's there and then it disappears, you are not happy.

Data is data. It's just... there. It's like old paperwork in the box, in the attic. Do you need it? Maybe. Is it worth keeping it around? Maybe. Is it useful now? No. Will it be useful at some point? Maybe. Are you going to be really upset if it disappears? Probably not?

Separating the two has been the focus of R&D done so far, and the results have been simply stunning - more on that, including some demo videos, in a minute.  Second: presenting the information in a way that simplifies and encourages actionable insights, instead of making them nearly impossible, without years of experience - and a frustrating process even once you've accumulated that experience. I will talk about that part another time - some research is still ongoing in that area.

For most of the analysis scenarios, similar to what I listed in the beginning, my goal is something like 10 minutes to answer  a question (once the data is loaded and initial automated processing completes).

How would this me accomplished? Here's how. I declare the War On Math! Read. My. Lips. No. More. Math.

OK. To be fair. I like math, and it's the core of CINTI (not to mention that math is the very basis of our  universe, and our reality at large).

But - to require that racers, driver coaches, and race engineers use math as a critical tool/skill to extract information from data - that is ridiculous, especially in this day and age. This is EXACTLY like requiring one to be able to solder together microprocessor boards - just to use a smartphone.  Not to fix or to modify it -  just to turn it on and to check the email!
Another analogy - you know how you have to adjust your fuel mixture before you start your street car first thing in the morning, and how sometimes you forget to pull the cable to close the choke after it warms up, as you drive to work? NO? You don't have to do those things? Hmm. That's interesting. Ever wonder why these things got automated?
I really need to drive this point home, so bear with me for the rest of this rant.
I do not know the resistor/capacitor values that are needed to build a volume knob that results in a good range and does not introduce noise. Yet, I can adjust the volume of my radio. I am good at it!
I have no idea how to sort out liquid crystal matrices to end up with large sheets with no defects - yet my TV and my computer monitors have no dead pixels.  I do not have a working knowledge of how internal registry and caching structures of popular CPUs on the market are configured, yet I can write software that will work on ANY of them, with predictable efficiency. I can make tea or coffee, yet I have very basic understanding of chemistry. I can turn on the lights in my bathroom, without having to figure out power and voltage values involved.

So, can any one explain to me, why "racing data software" cannot  tell me if the car is understeering mid-corner, has a stability issue at turn in, or if the driver is disrupting the traction balance by the brake application, without me becoming an expert in math and automotive physics, mastering arcane (and often deficient) math channel "languages", not to mention accumulating years of experience driving, fixing, tuning, and building race cars? Anyone?


Here's what's under CINTI's hood. This is a part of the development "sandbox", where I create software that extracts information from data - in this case, extracting the point at which the car is turned into the corner, plus a measure of how quickly the cornering force builds up. To be fair, it is more complicated problem than it seems at the first glance, given varieties of corners,  cars, tires, and driving styles. In fact, almost insurmountable for most "racing data analysis" packages out there.

Yet, it is easily solved with the right tools and technologies. This is relatively basic algorithm - it can (and will) be made more accurate (by orders of magnitude), as time goes on. Already, it's approaching accuracy of reasonably competent human reviewing the data, while being tens of million times faster (in the video, the process is greatly slowed down artificially). Remember, the machine does not need to be more accurate in every case, when it can analyze more data in a few  days, than all race engineers in history of racing combined, in their lifetimes.

So, that's great - but this is "under the hood" view. What if I need to change - tune - how this works for a particular car or track. We are back to math, right?

I don't think this is necessary. Why not tune your Analysis Channels (CINTI has no "Math" Channels, of course, only Analysis Channels) same way you would tune your tire pressures? Make an adjustment - and get feedback about how it works! Keep adjusting until it works well, and you are done!

This is a prototype interface for this, it will get cleaned up with time. For now, I use it to actually develop analysis logic, and so on  - but in the future, this would be a way for "advanced/pro" user to customize it, to improve effectiveness of automated/"instant" analysis, or perhaps, even to "teach" the system to recognize and process new things.

You can see me adjusting one out of 3 parameters, to get CINTI to improve how it recognizes driver initiating corner entry for Turn 2 at Thunderhill. Once that has been done, it will recognize that point, apply changes to all other corners (and update all calculations that use it) for thousands, tens of thousands, whatever number of laps - no more tinkering required.
Again, to be clear - this is not analysis per se, but "tuning" the analysis by changing one out of 3 available parameters, to get the result reflecting the expectations:

By the way, other colored boxes with numbers in them are other Analysis Channels. All of those are created and updated automatically, and contribute to higher-level analysis and "insights".

Here's an example where this data is actually used. This is comparison of 3 drivers, covering about 150 laps (ever tried to look through 150 laps' worth of data for a single corner?). Vertical grouping is based on drivers. Color of the points represents section times (lighter = faster). X (horizontal) axis is the lap distance point at which the car was turned in (we just tuned that).

You can see that there are 2 important patterns here:
1. Driver 3 is consistently initiating the turn earlier than other drivers (the points are shifted to the left of the chart) AND there is a specific range (circled in white) of turn-in points that seems to be closely related to faster section times. Turning in even earlier than that (yellow circle) does not produce faster times.
2. Drivers 1 and 2 have similar turn-in points, but Driver 2 has faster times, on average (more lighter-colored dots). The difference is likely due to something other than this particular aspect.

Switching X axis to another view confirms this - there is a significant difference in Min. Speed for that corner, explaining the difference between Driver 1 and Driver 2's times:

Again, this is not the final "analysis" UI, nor does this represent one of those "analysis funnels",  just a demonstration of how "Analysis Channels" are used in higher level calculations/processing.

To be absolutely clear - all of the statistics/measurements/groupings in this example are calculated, processed, and aggregated automatically, there are no "math" channels. If you need to change how CINTI detects "corner entry", there's an adjustment for that  - see the last video - but everything else is done automatically.

Igor Levine
Momentary Racing

*"The onion must be peeled even if it's making you cry."

** To be clear, I am not saying that having extensive instrumentation has no purpose. Serious point here is that mainstream analysis software flounders UNTIL extensive instrumentation is in place - and even then, it has some serious issues separating signal from noise, and information from data.

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: