Build a useful data picture before you analyze the lap

Generated from content/lms/data-interpretation-for-drivers/01-understanding-data-systems/04-data-acquisition.md; edit the source file, not this page.

Source path: content/lms/data-interpretation-for-drivers/01-understanding-data-systems/04-data-acquisition.md

Course: Data Interpretation for Drivers

Module: Understanding Data Systems

Estimated duration: 55 minutes

A data system does not make you faster by being clever. It helps you get faster when it gives you a clean enough picture of what happened that you can decide what to practice next. Before you chase a lap, compare traces, or argue about where the time went, you need to build that picture.

For an intermediate driver, this is the step that separates useful data work from staring at squiggly lines. You are no longer just checking the lap time and looking for the biggest gap on the speed trace. You are building a disciplined view of the session: what the car was doing, what you were doing, what the conditions were, which laps deserve attention, which laps are distorted by traffic or mistakes, and which channels can answer the question in front of you.

The principle is simple: do not analyze a lap until you have enough context to know what kind of lap it was. A stopwatch can tell you that a lap was quicker or slower. The speed graph can tell you where the time was gained or lost. The driver report can tell you what you were trying to do and what you felt. The basic channels can show whether your memory matches the car. Multiple laps can show whether a pattern is real or just a one-lap event. Metrics and run charts can show whether a change repeated across a run instead of appearing only in the one lap you happened to open first.

That is the useful data picture. It is not every channel. It is not every math channel. It is not a screen packed with so much information that you can no longer see the driving. It is the minimum reliable picture that lets you ask the next good question.

Why the picture comes before the answer

Data acquisition records what the car and driver were doing. That sounds obvious, but it matters because your memory is not a logger. You may come in convinced you stayed flat, braked at the same point, or picked up throttle earlier. The data may show a small lift, a different brake release, or a later throttle application. Some drivers reject that uncomfortable discovery and blame the system. That wastes the value of the logger. Your job is not to defend your memory. Your job is to combine memory, data, and context into a better model of the lap.

The corpus gives you a strong order of operations. Download the logger every time the car comes in, even for warm-ups and rollout laps, because ordinary laps can still contain relevant information. Begin with the vital channels before performance analysis. Listen to the driver because the driver report makes it easier to know what to look for. Then observe what the car is doing through speed, acceleration, and driver activity before trying to explain why it is doing it through deeper vehicle channels. Do not focus only on the fastest lap. Analyze all laps and look for consistencies and inconsistencies. Account for traffic. Look for the obvious first.

That order protects you from the most common data mistake: treating analysis as a treasure hunt. A driver opens the fastest lap, sees a gap in one corner, and immediately starts inventing a cause. Maybe the brake trace is different. Maybe the throttle is different. Maybe the car understeered. Maybe the driver was blocked by traffic. Maybe the lap before overheated the tires. Maybe the channel is scaled wrong. Without the picture, every explanation is too early.

The mechanism is comparative. Data becomes useful when you compare one lap to another, one run to another, one driver to another, or your actual lap to the lap you intended to drive. Comparison reveals the effect of setup changes and driver performance. Metrics pulled from logged data and visualized in run charts help you see patterns quickly instead of making judgments from a single trace. That does not mean you ignore the lap overlay. It means the overlay comes after you know which laps and questions deserve it.

The data picture has five layers

Layer one is the session story. What were you trying to do? What changed since the previous run? What did the car feel like? Where was traffic? Did you make a mistake that will contaminate the lap? A driver log is not paperwork. It is data. Before each session, write the objective and the driving technique you plan to use. After the session, record track conditions, changes to the car, and the result. When you return to the same track, or when the same problem returns, that record stops you from starting over.

Layer two is the health and sanity check. Before you ask why you lost time in Turn 5, confirm that the car and logger were behaving. Vital channels such as temperatures, pressures, and battery voltage come first. A failing sensor, bad connector, or strange voltage event can send you down the wrong path. You do not need to become an engineer to do this as a driver. You need the habit of checking that nothing obvious is wrong before you turn performance conclusions into driving changes.

Layer three is the lap set. A single fastest lap is rarely the whole truth. The fastest lap may include one excellent corner and one poor corner. A slower lap may contain your best execution of the section you are trying to learn. A traffic lap may explain a lost straight speed that has nothing to do with your exit. The useful picture includes all laps in the run, with the obvious labels attached: out lap, in lap, traffic, mistake, clean reference, personal best, best sector, and representative average. You are building a set of laps that can answer different questions.

Layer four is the basic driving trace. Start with speed and the driver inputs you have: throttle, brake pressure, steering angle if available, and acceleration traces if they are reliable. Speed shows where time is gained or lost. Throttle and brake show what you commanded. Steering and lateral data can help describe cornering behavior. If the question is understeer or oversteer, the useful channel set expands to speed, throttle position, front and rear lateral g, steering angle, and understeer angle when available. But the order still matters: see what happened first, then move toward why.

Layer five is the wide-angle pattern. Metrics and run charts are how you step back from the lap trace. A metric can be as simple as lap time, minimum corner speed, maximum straight speed, throttle pickup timing, brake pressure peak, or consistency across laps. The point is not to bury yourself in numbers. The point is to make important portions of the data detectable quickly and to avoid building a conclusion from one dramatic-looking squiggle. When the pattern repeats across laps, your confidence goes up. When the pattern appears only once, you ask what made that lap different.

The pre-analysis sequence

Use this sequence before any serious lap analysis. It is deliberately plain. The goal is not to impress anyone with data skill. The goal is to keep you from drawing the wrong conclusion.

First, capture the run. Download the logger every time the car comes in. If you are sharing a car, running short sessions, or using a simple device, do not let the smallness of the run talk you out of saving it. Rollout laps, warm-ups, and odd laps can still establish whether the system is working, whether the car is behaving normally, and whether a later pattern has context.

Second, write the driver report while the sensations are still fresh. Keep it short and useful. Name the objective, the corners you were working on, anything that felt different, where you met traffic, and any lap you know was not representative. The quality of sensory information matters because your visual, kinesthetic, and auditory impressions are part of the evidence. They are not perfect, but they give the data a search direction.

Third, check the vital channels and obvious logger problems. If pressures, temperatures, or battery voltage are strange, make that the first issue. If a cable or connector problem is likely, do not build a driving conclusion from the affected channel. If a channel flatlines, spikes, drops out, or disagrees with reality, downgrade its authority. The picture is only useful when you know which parts of it you can trust.

Fourth, build the lap map. Open the session view and label the run. Mark out and in laps. Mark laps affected by traffic. Mark laps where you made a known error. Mark the fastest lap, but do not crown it as the only lap worth studying. Look for the cleanest lap, the best execution of the target section, and the laps that repeat the same pattern. This is where intermediate drivers start to make better decisions than novices. You are no longer worshiping the personal best. You are selecting evidence.

Fifth, scan the speed trace across the run. The speed trace is the first performance story because it shows where time appeared and disappeared. Look for sections where one lap carries more speed, where speed drops more than expected, where exit speed changes, and where straight-line speed is affected by the previous corner. Do not explain yet. Just observe. Where is the car slower? Where is it quicker? Does the difference appear more than once? Is it in a braking zone, midcorner, exit, or straight?

Sixth, add the driver inputs. Once you know where the speed changed, look at what you did there. Did the throttle close earlier than you remembered? Did you stay off throttle longer? Did you brake harder, softer, earlier, later, or with a different release? If steering is available, did you add more steering for the same or lower speed? This is where the data starts coaching you, but only because you first found the relevant location on the speed trace.

Seventh, compare against a useful reference. That reference may be another driver in the same car, another similar car, your own previous best, your best sector from a different lap, or the mental program you planned before the run. The corpus is clear that another driver can be valuable, but you do not need another driver to compare. Self-comparison is powerful when you compare actual driving with previous laps, previous sessions, and the lap you meant to drive.

Eighth, turn the pattern into one action. The output of the data picture is not a ten-item to-do list. It is one next driving experiment. If you found that your best corner exit came on a lap where you released brake pressure more cleanly and picked up throttle earlier, the next session objective is not to fix everything. It is to reproduce that exit with a specific cue. If you found that traffic contaminated the fastest lap, your next step may be to ignore that lap for technique comparison and use a cleaner reference. If the car health check revealed a problem, the next action is mechanical or logging-related, not driving-related.

Sub-skill one: separate what from why

The first job of the data picture is to tell you what happened. The second job is to help you decide why. Mixing those too early creates confident wrong answers.

What happened is observable. The car was slower from corner entry to apex. The throttle trace closed. The brake pressure lasted longer. The speed at the end of the straight was lower. The lap had traffic. The same loss appeared on three laps. Those are what statements.

Why it happened is interpretation. You braked too early. You released too slowly. You hesitated because the car felt nervous. The car understeered. The tires were past their best. The setup change affected aero balance. Those may be true, but they require more evidence. The corpus recommends observing speed, acceleration, and driver activity before trying to understand deeper causes. Follow that. If you cannot describe the what without an explanation attached, you are not ready to change your driving.

A practical test: after opening the data, say the first finding as a plain observation. For example, the car was slower from the brake zone through midcorner on three clean laps, and the brake trace stayed active longer on those same laps. That is a useful observation. Then you can ask whether the longer brake release was intentional, whether it matched the car feel, and whether it helped or hurt exit speed. The observation earns the interpretation.

Sub-skill two: make the driver report specific enough to search

A vague report wastes time. A useful report points the analysis. Do not write that the car felt bad. Write where and in what phase. Entry under braking, midcorner at maintenance throttle, exit when you unwound the wheel, or straight-line acceleration are different problems. Do not write that you were inconsistent. Write that you changed your braking point for Turn 3 after traffic, or that you were experimenting with a later throttle pickup in the final corner.

The driver report also keeps your learning honest. If you wrote before the run that the objective was earlier throttle in one corner, the data should be checked against that objective. Did you actually do it? Did the speed trace improve? Did the change carry onto the following straight? Did it work once but not repeat? That is a better use of data than roaming the screen looking for something interesting.

This connects to mental programming. A driver is faster when the intended lap is clear enough to execute. Data lets you compare the intended lap with the actual lap. If the plan was to stay full throttle through a section and the throttle trace shows a small lift, the issue is not moral failure. It is a mismatch between program and execution. Now you have something specific to practice.

Sub-skill three: choose reference laps with discipline

The fastest lap is a reference, not the reference. Sometimes it is the right lap to study. Sometimes it is a mixed lap with one great section, one compromised section, and one lucky tow. The data picture helps you choose reference laps by purpose.

Use the fastest clean lap when the question is overall execution. Use the best sector lap when the question is a specific segment. Use a representative lap when the question is consistency. Use a slower but clean lap when the fastest lap has traffic or a known mistake. Use a previous session when the question is whether your change worked. Use another driver when the question is what is possible in the same or similar equipment. Use your mental program when the question is whether you did what you planned.

The Track Attack example in the corpus makes this point directly. The lesson shown there warns that looking only at the fastest lap would miss important information, and it shows synchronized GPS speed, throttle position, and front brake pressure. The teaching point is not that red or blue is always better. It is that the useful lap may be assembled from evidence across more than one lap. One lap may show better entry discipline. Another may show better exit commitment. Your job is to identify the repeatable skill, not just admire the best final time.

Sub-skill four: use the speed trace as the doorway

Speed is not the whole answer, but it is usually the doorway into the answer. A stopwatch tells whether the lap was slow or quick. The speed graph shows where. That is why you start there.

Read the speed trace by phase. On the approach, look at terminal speed and whether traffic or the previous corner changed it. In the brake zone, look at where speed begins to fall and how steeply it falls. Near entry and apex, look for minimum speed and whether the bottom of the trace is sharp, flat, or dragged out. On exit, look at how early speed begins to build and how long the benefit carries down the next straight. Then check the driver inputs in the same location.

This prevents a common trap. If you start with throttle, you may decide earlier throttle is the answer in every corner. If you start with brake pressure, you may decide later braking is the answer. The speed trace forces the question to stay connected to lap time. Did that input change actually make the car faster where it matters? Did it improve exit or just create a bigger midcorner correction? Did it repeat on clean laps?

Sub-skill five: widen back out with metrics and run charts

After you inspect the key trace, step back. Metrics and run charts are not only for engineers. They help drivers see whether the story they found in one lap holds across the run. If you were trying a different braking approach, a run chart can show whether the relevant braking or speed metric changed across laps. If the car seemed to fade, a run-wide view can show whether pace or speed changed gradually. If traffic distorted lap time, a wider view helps you avoid blaming technique for a blocked lap.

The key is to keep the metrics tied to the driving question. For a throttle pickup question, a useful metric might be related to throttle application timing or exit speed. For a braking consistency question, the useful view may be speed loss and brake pressure behavior in the same zone across laps. For a setup change, the expected channels matter. The corpus notes that aerodynamic changes most likely show up in speed and wheel load traces. That means you do not stare at unrelated channels hoping for a story. You decide what should move if the change mattered, then you look there.

Sub-skill six: protect the picture from traffic and outliers

Traffic can have a considerable influence on lap time. That sounds simple until you are excited about a new personal best or frustrated by a slow session. A lap with a compromised pass, a missed apex behind another car, or a lift for safety can still contain useful driving data, but it should not be treated as a clean comparison for every question.

When you build the lap map, tag traffic. Then use the lap correctly. A traffic lap may be useless for judging terminal speed on a straight. It may still be useful for studying a brake release before you caught the slower car. An out lap may not be useful for full pace, but it may reveal a channel problem. A lap with one mistake may still contain a best execution elsewhere. The point is not to throw away imperfect data. The point is to stop pretending all laps answer the same question.

Sub-skill seven: let the data challenge your senses without replacing them

Driving depends on sensory information. Visual, kinesthetic, and auditory input affect what you do in the car. Data adds another form of input after the fact. The best drivers do not treat these as enemies. They use each to improve the other.

If you felt the car push midcorner and the data shows more steering angle for no gain in speed, that may support your sensation. If you felt you were full throttle and the trace shows a small lift, the data gives you a calibration target. If you thought you braked at the same point every lap and the speed trace shows varying deceleration starts, your sense of reference points needs sharpening. Data is not there to shame you. It is there to improve the quality of the information feeding your next lap.

Worked example: the red lap and blue lap problem

Imagine you finish a session and see that the blue lap is your fastest lap. The novice move is to open that lap, compare it to nothing else, and declare it the model. The better move is to build the picture.

Start with the session story. You were working on braking and throttle timing. You had one lap with minor traffic and several clean laps. The Track Attack figure in the corpus shows GPS speed, throttle position, and front brake pressure, and the surrounding teaching point warns that if you only looked at the fastest lap, you would miss important information. That is exactly the scenario.

Open the run and tag the laps. Identify the fastest lap, the clean laps, and any lap with traffic. Then compare the blue lap with a red lap that may not be fastest overall but contains a better section. On the speed trace, look for where each lap gains. If the red lap carries better exit speed from one corner onto the straight, that matters even if it loses time somewhere else. If the blue lap has a cleaner brake phase in another corner, that matters too. Add throttle and brake pressure only after the speed trace tells you where to look.

The useful conclusion is not that the driver should copy the whole blue lap. It may be that the driver needs to combine the red lap's exit habit with the blue lap's braking habit. That is the phrase from the source idea, turned into a driving task: if you put the best repeatable pieces together, the next session has a clearer target. You are not chasing a magical lap. You are identifying the pieces that already exist in your driving and making them repeatable.

Worked example: the slight lift the driver did not feel

Now imagine you come in convinced you were flat through a section. The data shows a small throttle lift. The source material describes drivers being surprised when data acquisition shows they lifted slightly, and some drivers becoming defensive and abandoning the system. Do not do that.

Build the picture before you argue. First, confirm the throttle channel looks sane across the run. If it behaves normally elsewhere, take it seriously. Second, compare the lift lap to previous laps and to your plan. Did the lift happen every lap, only when following another car, or only after a moment that felt busy? Third, overlay speed. Did the lift cost speed immediately, reduce speed at the end of the next straight, or have little measurable effect? Fourth, connect it to your sensory report. Did you see a reference late? Did the car feel light? Did you hear a change in engine note? Did you add steering at the same moment?

The action is now specific. If the lift was a one-lap event caused by traffic or safety, you label it and move on. If it repeated on clean laps and cost exit speed, the next session objective is to drive that section with a clearer visual reference and a throttle commitment cue. If the data shows the lift but no meaningful time cost, the lesson may be different: your mental program still does not match reality, and the next step is calibration rather than heroics.

Worked example: setup change before driver blame

Suppose a setup change was made between runs and the driver reports that the car feels different at high speed. The wrong process is to open the fastest lap, see a time loss, and immediately tell the driver to push harder. The right process is to build a picture that can separate driver performance from the expected effect of the change.

Write down the change and the expected channels. If the change was aerodynamic, the corpus points you toward speed and wheel load traces. Start with vital channels and basic sanity. Then compare similar clean laps from before and after the change. Look first at speed in the relevant high-speed sections. Then check whether the driver inputs changed. Did the driver lift more because the car felt uncertain, or did speed change even with similar throttle? Did the loss appear in the same places across laps? Did traffic distort the comparison?

Only after that do you decide what to do. If the channels expected to move did move, the setup may be part of the story. If the driver inputs changed significantly, the driver adaptation is part of the story. If both changed, the next run should isolate one thing instead of piling on guesses. This is where a useful data picture protects the driver and the car from bad conclusions.

Common mistakes

Fastest-lap tunnel vision is the first mistake. It feels efficient because it starts with the best result, but it can hide the best learning. Good looks like opening the whole run first, tagging clean and compromised laps, then choosing the lap that fits the question.

Squiggly-line wandering is the second mistake. You open channels without a question and wait for something to look interesting. That creates stories, not evidence. Good looks like writing the session objective, finding where speed changed, and then adding the channels that can explain that specific location.

Arguing with the logger is the third mistake. If the data contradicts your memory, you dismiss it before checking it. Good looks like checking channel sanity, then using the mismatch as calibration. If the throttle trace shows a lift you did not feel, that is a practice target.

Skipping the health pass is the fourth mistake. You jump straight into performance analysis while a vital channel, connector, voltage issue, or sensor problem is trying to get your attention. Good looks like a quick vital-channel scan before you make driving decisions.

Explaining before observing is the fifth mistake. You decide why the car was slow before you have described what happened. Good looks like plain observation first: where speed changed, which laps repeated it, what the inputs did, and whether traffic or mistakes were present.

Ignoring traffic is the sixth mistake. You compare a blocked lap with a clean lap and treat the difference as technique. Good looks like tagging traffic and using each lap only for the questions it can answer.

Overcomplicating the first pass is the seventh mistake. You reach for advanced channels before the obvious story is clear. Good looks like speed, driver inputs, lap context, and repeatability first. Deeper vehicle channels come after the basic picture tells you where to look.

Poor notes are the eighth mistake. You rely on memory after the sensations fade. Good looks like a short objective before the session and a short report after the session, including conditions, changes, traffic, and results.

Drill: the three-run data picture routine

Use this at your next event. Do it for three on-track sessions in one day. Each repetition should take about five minutes before the session and fifteen to twenty minutes after the session.

Before the session, write one objective. Make it narrow enough to verify with your channels. Earlier throttle in one corner, cleaner brake release in one braking zone, or consistent minimum speed through one complex is useful. Going faster everywhere is not useful. Also write the reference you plan to use: a marker, a previous lap, a coaching target, or a mental program.

After the session, complete four passes. Pass one is the driver report: what you tried, what you felt, where traffic appeared, and which laps you already know were compromised. Pass two is the health pass: vital channels and obvious logger sanity. Pass three is the lap map: tag out lap, in lap, traffic, mistakes, fastest lap, clean reference lap, and any lap that contains your best execution of the objective. Pass four is the evidence pass: start with speed at the target section, then add throttle, brake, and steering or lateral data if available.

The success criterion is not a lap time. By the end of each post-session review, you must be able to say three things without opening another screen: which lap is your clean reference, where the target section gained or lost speed, and what one action you will take in the next session. If you cannot say those three things, the picture is not built yet.

After three runs, look for consistency. Did the same issue appear each time? Did your notes get more specific? Did the data confirm that you performed the intended change? Did the speed trace show a benefit in the target section or on the following straight? If the answer is unclear, narrow the objective for the next event. The drill is not about becoming a data engineer. It is about becoming a driver who can turn a run into one useful practice decision.

Calibration cues: how you know your picture is getting better

You are improving when your post-session routine becomes faster and calmer. You no longer bounce from channel to channel. You download the run, write the report, check health, tag laps, inspect speed, add inputs, and choose a next action.

You are improving when your findings survive the full run. A one-lap discovery is interesting. A repeated pattern across clean laps is stronger. A pattern that matches the driver report and the trace is stronger still. A pattern that changes after a deliberate next-session experiment is real learning.

You are improving when you stop treating the fastest lap as the only teacher. You can explain why a slower lap matters because it contains a better section. You can explain why a personal best may not be the best reference for the current question. You can separate clean evidence from traffic noise.

You are improving when your memory and data begin to calibrate each other. You still report what you felt, but you invite the data to challenge it. If you lifted and did not know it, you learn what that lift felt like. If you were smoother than you thought, you learn what good execution felt like. Better sensory input leads to better skill, and data can sharpen that input after the run.

You are improving when your next-session objective is specific. Data work fails when it produces a lecture. It succeeds when it produces a practice cue. Earlier throttle at a named corner. Cleaner brake release in a named zone. Use the same reference point but adjust how you use it. Compare clean laps rather than traffic laps. Check a sensor before trusting a channel. Those are actions.

How this lesson connects to the sibling lessons

This lesson sits before the other data lessons in the module. Use data to catch what you missed is about the moment when the logger corrects your perception. Turn channels into answers is about matching a question to the right trace. Trust each channel for the right question is about channel authority and limits. Turn telemetry into coaching evidence is about communicating the finding well enough to change driving. The skill here is earlier: build the picture that keeps those later steps honest.

If you skip this step, the later skills become fragile. You may choose the wrong channel, trust the wrong lap, ignore traffic, miss a setup change, or coach yourself from a sensor problem. If you build the picture first, the later analysis has a foundation.

When the principle breaks down

There are times when the data picture tells you not to analyze. If a critical channel failed and no backup exists, do not pretend the channel can answer the question. If the whole session was traffic, you may still learn from fragments, but you should not draw clean-lap conclusions. If the car has a vital-channel problem, the performance question waits. If the corpus is too thin for the exact question, or your logger lacks the channel that would distinguish two causes, the honest answer is that you need more evidence.

That restraint is part of being good with data. Efficient teams and drivers do not win because they stare at more screens. They win because they draw the right conclusions quickly from the information they have, and they know when the information is not enough.

The finish: the one-page data picture

Before you analyze the lap, you should be able to make a one-page picture in your head or notebook. Session objective. Driver report. Car and logger health. Lap labels. Clean reference lap. Fastest lap. Best target-section lap. Traffic notes. Key speed-trace locations. Driver input differences. Repeated pattern. One next action.

That is the useful data picture. Once you have it, lap analysis becomes much less mysterious. You are no longer asking the screen to tell you everything. You are asking a precise question of the right evidence. That is how data becomes a driver tool instead of a distraction.

Worked example: the red lap and blue lap problem

The useful conclusion is not that the driver should copy the whole blue lap. It may be that the driver needs to combine the red lap's exit habit with the blue lap's braking habit. You are not chasing a magical lap. You are identifying the pieces that already exist in your driving and making them repeatable.

Worked example: the slight lift the driver did not feel

Imagine you come in convinced you were flat through a section. The data shows a small throttle lift. The source material describes drivers being surprised when data acquisition shows they lifted slightly, and some drivers becoming defensive and abandoning the system. Do not do that.

Worked example: setup change before driver blame

Common mistakes

Drill: the three-run data picture routine

Use this at your next event. Do it for three on-track sessions in one day. Each repetition should take about five minutes before the session and fifteen to twenty minutes after the session.

When this principle breaks down

There are times when the data picture tells you not to analyze. If a critical channel failed and no backup exists, do not pretend the channel can answer the question. If the whole session was traffic, you may still learn from fragments, but you should not draw clean-lap conclusions. If the car has a vital-channel problem, the performance question waits. If your logger lacks the channel that would distinguish two causes, the honest answer is that you need more evidence.

Author Review

No quiz questions are attached to this lesson.

Sources

#	Document	Chunk	Pages	Score	Collection
1	Analysis Techniques for Racecar Data Acquisition	48d56105-c3c5-81ff-d649-243a1cd43c35	6	1	uio_books_raw_v1
2	Speed Secrets Professional Race Driving Techniques Ross Bentley	a009c9a4-cb8d-b3b5-063d-33e44ea0b5cb	76	1	uio_books_raw_v1
3	Analysis Techniques for Racecar Data Acquisition	ad559d04-3651-61c2-d02b-5455aba0d7cc	7	1	uio_books_raw_v1
4	Analysis Techniques for Racecar Data Acquisition	5eeea298-6191-0fb2-1054-b10fe574a804	2	1	uio_books_raw_v1
5	Analysis Techniques for Racecar Data Acquisition	41138569-fa56-a0a4-38c5-301475e4131a	21	1	uio_books_raw_v1
6	Data-for-Drivers-PRINT	c493f39d-9ba1-5829-3168-d38e471cc061	9	1	uio_books_raw_v1
7	Inner Speed Secrets	6be60db9-6866-c26d-9492-81169f5e9119	2	1	uio_books_raw_v1
8	Analysis Techniques for Racecar Data Acquisition	d0db9128-dc9a-aec3-14a8-5f101654753f	3	1	uio_books_raw_v1
9	Analysis Techniques for Racecar Data Acquisition	52e7d5ab-412b-acc5-fb49-cb0e8d5511b1	6	1	uio_books_raw_v1
10	Analysis Techniques for Racecar Data Acquisition	9ee3c928-9190-4c5d-2314-158932244c31	22	1	uio_books_raw_v1
11	Inner Speed Secrets - Ross Bentley	faf47214-2619-0395-43b8-f1f6523e5a80	32	1	uio_books_raw_v1
12	Inner Speed Secrets - Ross Bentley	42cd9797-25c1-9bbb-d1f4-7aa50b893094	189	1	uio_books_raw_v1
13	Data-for-Drivers-PRINT	b80dc634-a0a7-d6de-d470-353aed47e2a6	17	1	uio_books_raw_v1
14	Going Faster Mastering the Art of Race Driving - Carl Lopez	4285b990-c3e7-880e-5596-99af145b469c	300	1	uio_books_raw_v1
15	Ultimate Speed Secrets - Ross Bentley	6ed5a221-3ddc-b723-f630-f8e637080726	208	1	uio_books_raw_v1
16	Ultimate Speed Secrets - Ross Bentley	6054ef2e-10b7-b9ee-1f7a	513	1	uio_books_raw_v1

Worked example: the red lap and blue lap problem​

Worked example: the slight lift the driver did not feel​

Worked example: setup change before driver blame​

Common mistakes​

Drill: the three-run data picture routine​

When this principle breaks down​

Author Review​

Sources​

Worked example: the red lap and blue lap problem

Worked example: the slight lift the driver did not feel

Worked example: setup change before driver blame

Common mistakes

Drill: the three-run data picture routine

When this principle breaks down

Author Review

Sources