Check the simple channels before you wrench
Generated from
content/lms/race-car-mechanic-reference/04-diagnose-track-symptoms/02-check-simple-data-before-you-wrench.md; edit the source file, not this page.
Source path: content/lms/race-car-mechanic-reference/04-diagnose-track-symptoms/02-check-simple-data-before-you-wrench.md
Course: Service the race car that has to finish
Module: Diagnose track symptoms into mechanical hypotheses
Estimated duration: 55 minutes
The mechanic's gate
The skill in this lesson is a gate. Before you change springs, bars, alignment, tire pressures, brake parts, or engine parts because the car felt wrong, you check whether the simplest available data agrees with the complaint. If it does not agree, you keep diagnosing. If it does agree, you still do not jump to the most expensive explanation. You use the simple channels to narrow the problem until the next physical inspection or setup change has a reason behind it.
This is not a lesson about becoming a professional data engineer. The bonded material points the other way: keep the work simple, focus on the basics, get your hands dirty with the data, look for incongruencies, dig for details, use other channels when available, compare when you can, calibrate the picture to your own driving, imagine what a better trace would look like, and set objectives for the next session. That is the whole discipline. You are not trying to explain every squiggle. You are trying to prevent one bad assumption from turning into three unnecessary setup changes.
The reason this works is that track symptoms are shared by the car and the driver. A data system records what the car and its driver are doing, and the same basic analysis techniques apply whether the vehicle is a high-end race car or a road-legal car used at a local drag strip. The hardware has become accessible enough that many drivers have speed, throttle, brake, RPM, gear, GPS, and simple acceleration information. The problem is no longer only getting data. The problem is extracting the right conclusion quickly from a large amount of information. A team or driver who uses ordinary channels efficiently has an edge over a driver who treats every feeling as a setup order.
For an intermediate driver, the trap is usually not total ignorance. You already know enough to name understeer, oversteer, brake fade, poor traction, lazy acceleration, or a bad line. The trap is that each of those labels can be produced by several causes. A car that feels tight can be front tires that are genuinely overworked, or it can be too much entry speed, too much steering, an early throttle demand, or a line that asks the front tires to do too much. A car that feels down on power can be engine output, or it can be a throttle trace with hesitation, an early lift, a wrong gear, or one driver slowing more than another in the first half of the corner. A brake complaint can be a real hardware problem, or it can be a light and long brake application, inconsistent pressure, a long tail, or a mismatch between what the driver remembers and what the pedal trace shows.
The principle is simple: do not wrench on a story until the simple channels support the story. A story is the driver's memory. A symptom is the repeatable place on track where time, speed, input, or vehicle response changes. A diagnosis begins when the story and the symptom can be seen together.
What counts as simple data
Simple data is the first layer you can check without building a complex model. Start with segment or section times, fastest rolling lap, theoretical fastest lap, speed, throttle, brake pressure or brake pedal position, steering, RPM, gear, GPS line, G-sum, total steer angle, and a throttle histogram if your tool gives you one. You do not need every channel for every car. The useful habit is to ask what each channel can answer and what it cannot answer.
Segment and section reports answer where the loss occurs. They do not tell you why by themselves. If the driver complains that the car is bad everywhere, the section report usually forces the complaint into a smaller place. If the loss is only in one section, you now have a target. If the loss is spread evenly, you may be looking at a broader driver rhythm, weather, tires, fuel load, or mechanical condition, but the first gate is still to locate the loss.
Speed answers when the car is actually slowing or failing to accelerate. It is one of the best first checks because it is hard for memory to preserve exact speed. In the Going Faster material, one example compares two drivers in the same section and attributes the difference to one driver slowing too much in the first half of the corner. That is exactly the kind of finding that stops a bad wrenching decision. A driver may report poor exit drive, but if the speed loss began in the first half of the corner, the first question is not engine power. It is why that speed was given away before the exit.
Throttle answers whether the driver asked for acceleration cleanly. The bonded Data for Drivers process asks you to look for coasting, hesitant application, early application leading to a lift, and lifts in fast corners. Those are not tiny details. They are diagnostic gates. If the throttle trace shows hesitation, a coast, or a lift after early application, you do not yet have clean evidence that the car would not accept throttle. You first have evidence that the driver's request was not clean enough to make that conclusion.
Brake data answers whether the braking event matches the complaint. The simple brake channels include speed, longitudinal g-force, brake pedal position, and brake line pressures. The brake pressure trace can be judged for shape, initial application, trail, a long tail, inconsistent pressure, and whether the event is light and long or hard and short. That does not mean every brake problem is a driver problem. It means the brake complaint must pass through the pressure and speed picture before you turn it into a parts order.
Steering answers how much front tire demand the driver is creating. Steering by itself is not a diagnosis. Steering paired with speed, lateral g, throttle, and GPS line becomes useful. A typical MoTeC screen described in the Van Valkenburgh material uses only four channels in a 100-mph turn: lateral g, steering, speed, and throttle. The class notes on that example identify understeer, front tires overused, and throttle being allowed on. That is a powerful reminder. You can see a lot from a small set of channels when the channels are related to the question.
RPM and gear answer whether the engine and gearing story is plausible. If a driver says the car is flat but the trace shows an unexpected gear choice, a low RPM recovery, a delayed throttle request, or a lift in the place where the car should be accelerating, the first wrench is not an engine wrench. The first diagnostic action is to separate the input and gear state from the vehicle response. If the input is clean and the gear/RPM picture is consistent, then a physical inspection has a stronger reason.
GPS line and G-sum answer whether the vehicle path and total load support the complaint. A driver can make a normal car look bad by driving a line that asks the tires for too much at the wrong time. GPS line can show whether two laps or two drivers are asking the same question of the car. G-sum can help you see whether the car is being loaded differently even when the driver describes the corner with the same words.
The nine-pass check
Use this as your default before you touch the car. You can complete it in a short post-session review if you stay disciplined.
First, take an overview. Do not zoom straight into the corner that annoyed the driver. Look at the session shape. Which lap is representative. Which lap is fastest. Which section is costly. Which symptom is repeated. If the complaint is vague, this pass makes it specific enough to test.
Second, look for incongruencies. An incongruence is a mismatch between the driver's story and the simple data. The driver says the car would not put power down, but the throttle trace shows coasting or a delayed request. The driver says the brakes went away, but the pressure trace is inconsistent lap to lap. The driver says the car would not rotate, but the steering trace shows the front tires being asked for more while throttle is already coming back in. Incongruencies do not prove the driver is wrong. They prove you are not ready to wrench.
Third, dig for details. Once you find the mismatch, do not flatten it into a slogan. Ask where it starts. Is the throttle hesitation before apex or after apex. Is the brake pressure long and light from the beginning, or does the tail continue too far into the corner. Is the extra steering a one-lap event or present every time through the section. Details keep the diagnosis from becoming a personality contest between driver feel and mechanic instinct.
Fourth, use other channels if they are available. This is the main protection against single-channel mistakes. A speed dip by itself may look like the car is slow. Add brake pressure and throttle, and you may learn the driver coasted. Add gear and RPM, and you may learn the exit was compromised before engine output mattered. Add steering and GPS line, and you may learn that the driver created a higher cornering demand than the comparison lap.
Fifth, ask why. Keep asking until the explanation connects to a channel. Why was the exit slow. Because speed was low before the apex. Why was speed low before the apex. Because the driver was light and long on the brake, then coasted. Why did the driver coast. Maybe the car felt unstable, maybe the entry line was wrong, maybe confidence was low, or maybe the previous setup change made the driver cautious. You may not answer all of that from the simple data, but you can stop yourself from calling the symptom a horsepower problem.
Sixth, compare if you can. Compare the driver's good lap to the problem lap. Compare the fastest rolling segment to the complete lap. Compare to the theoretical fastest only as a clue, not as a fantasy lap you expect to drive immediately. Compare to another driver when the car, session, and conditions are close enough. The comparison point matters because data without a reference can make normal style look abnormal.
Seventh, calibrate to your driving. This is one of the most important intermediate steps. Your trace has a signature. Some drivers brake hard and short. Some are light and long. Some roll speed well but delay throttle. Some are early on throttle and then lift. Calibration means you learn your own patterns before declaring every pattern a car fault. A trace that looks imperfect can still be normal for you. The question is whether the trace changed when the symptom appeared, whether it changed in the costly section, and whether the change explains the complaint.
Eighth, imagine the better version. You are not pretending you drove a perfect lap. You are forming a practical target. If the problem is a throttle hesitation, the better version may be a cleaner and more committed application with no unnecessary coast. If the problem is a brake long tail, the better version may be a pressure shape that releases with purpose instead of dragging into the corner. If the problem is excess steering in a fast turn, the better version may be a smaller, calmer steering demand supported by a line that does not overload the front tires. The point is to turn data review into a next-session action.
Ninth, set one objective. Do not leave the laptop with six ideas and three setup changes. The bonded process ends with objectives for the next session because the next session is where the diagnosis is tested. A good objective is observable in the same simple channels that produced the diagnosis. If the objective is cleaner throttle, you should be able to see less coasting, less hesitation, or fewer early-throttle lifts. If the objective is a better brake event, you should be able to see a different pressure shape. If the objective is less front-tire overload, you should be able to see steering, speed, throttle, and lateral load tell a more coherent story.
What makes data mechanic-safe
Data becomes mechanic-safe when it survives cross-checking. A driver complaint alone is not mechanic-safe. A single trace alone is not mechanic-safe. A comparison without context is not mechanic-safe. A useful pre-wrench conclusion has three parts: where the symptom happens, what simple channels agree with it, and what next action will test it.
Where is the most important first word. The car is not loose. It is loose at a particular part of a particular corner, or it is loose only on one lap, or it is loose when the driver applies throttle early, or it is loose in fast corners when the driver lifts. The more precise the location, the less likely you are to make a global setup change for a local problem.
Agreement is the second word. If the driver says understeer, look for evidence in steering, speed, lateral load, throttle, and line. If the driver says no acceleration, look at throttle, RPM, gear, speed, and acceleration rate if you have it. If the driver says braking instability or fade, look at speed, longitudinal g, pedal or pressure, and the shape of the event. You are looking for channels that tell the same story from different angles.
Test is the third word. The next action should produce evidence. Sometimes the next action is a driver objective. Sometimes it is a mechanical inspection. Sometimes it is a conservative setup change. But the action should be tied to a channel you will review again. If you cannot name the channel that will show improvement, the action is probably not ready.
This mechanic-safe habit also protects the baseline. Another lesson in this module covers preserving the baseline, so do not turn this lesson into a logbook lecture. The cross-reference is simple: checking simple data before you wrench keeps the baseline meaningful because it stops you from stacking changes on top of an unverified complaint. If you do change the car later, the baseline and the data review tell you what you expected the change to fix.
It also protects the driver-versus-change decision. Another sibling lesson covers separating the driver from the change. This lesson gives you the first evidence. If the same driver, same section, and same basic input produce a different response, the car-side case gets stronger. If the response changes because the input changed, the driver-side case gets stronger. The simple channels do not settle every argument, but they make the argument more honest.
The pre-wrench worksheet
Use this exact worksheet until the habit becomes automatic.
Name the complaint in one sentence. Keep it concrete. The car would not accept throttle out of Turn 6 is better than the car was bad on exit. The brake pedal felt long after three laps is better than the brakes were bad. The front washed in the fast right is better than the car understeered everywhere.
Name the place. Use a section report, segment time, GPS line, or a consistent corner reference. If the place cannot be named, start with the overview and section report. You are not ready to diagnose the car until the symptom has a location.
Pick the comparison. Choose the best available reference: your best lap in the session, your previous clean lap, another driver in the same car, fastest rolling section, or theoretical fastest as a clue. Do not use a reference that changes too many things at once unless you label it as weak.
Open speed first. Ask whether the loss is entry, middle, exit, straight, or spread across the section. If the speed loss begins before the place the driver named, the story needs revision. If the speed loss is after the driver named place, the named place may be a consequence rather than a cause.
Open throttle. Ask the Data for Drivers questions in plain language. Was there coasting. Was the application hesitant. Did early application lead to a lift. Was there a lift in a fast corner. If any answer is yes, do not call the car unable to accelerate until you understand why the driver asked for less acceleration.
Open brake. Ask whether the shape fits the corner and the complaint. Was the initial application decisive. Was the trail purposeful. Was there a long tail. Was pressure inconsistent. Was the event light and long or hard and short. Pair this with speed and longitudinal g. If you have brake line pressure, use it. If you only have pedal position, be honest about the limitation.
Open steering and line. Ask whether steering demand is growing while the car is not giving more cornering result. Ask whether the GPS line changed. Ask whether total steer angle is higher on the problem lap. Pair steering with speed, lateral g, and throttle. Steering by itself can accuse the wrong thing.
Open RPM and gear. Ask whether the car is in the same gear as the comparison, whether the RPM range supports the acceleration complaint, and whether the throttle request lines up with the expected acceleration. This is especially useful when a driver reports a power problem.
State the verdict in three sentences. The first sentence is the symptom location. The second sentence is the channel evidence. The third sentence is the next-session objective or the inspection you will do before the next session. If you cannot write those three sentences, you do not yet have a mechanic-safe diagnosis.
What good feels like
Good does not feel like staring at data for an hour. Good feels like the complaint gets smaller and more testable. You begin with a broad feeling and end with a narrow question. Instead of the car is loose, you have throttle lift in the fast corner appears on laps four and five, with a different GPS line and higher steering than the clean lap. Instead of no power, you have exit speed is down because the driver slowed too much in the first half of the corner and waited on throttle. Instead of bad brakes, you have pressure is inconsistent and the event is light and long compared with the faster lap.
On track, good feels like one objective. You are not trying to fix the entire car during the next session. You are testing the diagnosis. If the data said the issue was hesitant throttle, you go out to make the throttle request cleaner in the named place. If the data said the issue was a long brake tail, you go out to reshape that event. If the data said the issue was overusing the front tires in a fast turn, you go out to reduce the demand that produced the symptom. Afterward, you check the same simple channels again.
On the laptop, good looks like fewer contradictions. The channel picture starts to agree with the driver story. The section time moves in the expected direction. The speed trace changes where you intended. The throttle or brake shape shows the objective. Steering and GPS line stop arguing with the complaint. You do not need the trace to look professional. You need the trace to answer the question you asked.
In the paddock, good sounds calmer. The conversation shifts from opinions to evidence. You can still respect the driver's feel. In fact, the data makes the feel more useful because it locates the feeling and checks it against the car's recorded behavior. The goal is not to beat the driver with squiggly lines. The goal is to keep the next action honest.
When the simple check says to inspect the car
This lesson is not a rule against wrenching. It is a rule against guessing. The simple check can absolutely send you to the car with tools in hand. It does that when the complaint is repeatable, the driver input is reasonably consistent, the comparison is fair, and several channels point to the same physical question.
For a brake complaint, that might mean the speed and longitudinal g picture degrades while the pressure request stays comparable, or the line pressure data raises a question that belongs in the brake system rather than in the driver's right foot. For a power complaint, it might mean the throttle, gear, and RPM picture are clean enough that a straight-line acceleration issue deserves inspection. For a handling complaint, it might mean steering, speed, line, throttle, and lateral load are coherent enough that a car balance or tire issue is plausible. The exact repair is outside this lesson. The skill here is earning the right to inspect.
A useful boundary is this: simple data can justify a physical check before it can justify a specific repair. If the data says the brake event is not producing the expected deceleration under comparable input, inspect. It does not automatically say pads, fluid, rotors, bias, or a sensor. If the data says acceleration is poor under clean throttle and comparable gear/RPM, inspect. It does not automatically say engine, fuel, aero, or gearing. If the data says the car is overloading the front tires despite a coherent driver request, inspect the setup and tires. It does not automatically prescribe a bar change.
That boundary keeps the lesson aligned with the bonded corpus. The corpus supports a process of extracting maximum information from the hardware at hand, drawing right conclusions quickly, checking simple channels, and setting objectives. It does not support guessing a detailed setup recipe from a short complaint. Your job is to move from complaint to evidence, not from complaint to folklore.
Cross-references inside the module
Use this lesson after you have turned fuzzy feedback into a symptom map. The symptom map tells you what the driver thinks happened. This lesson tests that map against simple data.
Use it before preserve the baseline becomes difficult. If you make changes before the simple check, the baseline becomes muddy. If you check first, the baseline remains a reference instead of a memory.
Use it with separate the driver from the change. Simple channels are the first separation tool. Throttle, brake, steering, RPM, gear, GPS line, and segment times show whether the driver asked a different question of the car.
Use it before close the loop in the logbook. The logbook entry should not just say changed rear bar because car loose. It should record the symptom location, the channel evidence, the comparison, the action, and the next check. That keeps the data review from becoming an isolated laptop ritual.
The rule to remember
Before you wrench, make the story survive speed, throttle, brake, steering, RPM, gear, line, and comparison. You will not always have every channel. You will not always get a clean answer. But if you practice the gate, you will stop treating every sensation as a setup command. You will make fewer changes, learn faster from the changes you do make, and build a cleaner link between driver feel, simple data, and mechanical work.
Worked example: a 100-mph turn with understeer and throttle
In the Van Valkenburgh material, a typical MoTeC screen from Claude Rouelle's seminar uses only four channels in a 100-mph turn: lateral g, steering, speed, and throttle. The notes on that screen identify understeer, front tires overused, and throttle being allowed on. That is almost the whole pre-wrench lesson in one example.
Imagine the driver comes in and says the car is tight in the fast turn. The easy mechanic reaction is to search for a front-end fix. The simple-data reaction is slower and better. Open the four channels. Does steering demand rise as the corner continues. What happens to speed. What happens to lateral load. Is throttle coming back in while the driver is still asking the front tires for more direction. Does the pattern repeat, or was it one lap.
If the pattern shows the driver adding steering while the front tires are already overused, and the throttle trace is also coming in, the first conclusion is not a setup prescription. The first conclusion is that the car and driver are asking the front tires to carry too much combined work in that part of the turn. The next-session objective might be to enter with a cleaner speed and line, reduce the steering demand, and make the throttle application agree with the car's ability to accept it. After that session, you check the same four channels again.
If the driver improves the steering and throttle relationship and the car still produces the same complaint, the case for a car-side inspection gets stronger. If the complaint disappears or section time improves, you saved yourself from wrenching on a driver-created overload. Either outcome is useful because the simple channels gave you a testable path instead of a debate.
Worked example: same section, same car, one driver slows too much in the first half
The Going Faster material describes a data-acquisition comparison in which two drivers differ on the same section of track because one driver slows too much in the first half of the corner. This is a classic way a driver can report the wrong end of the problem.
Suppose the slower driver says the car needs more exit drive. If you begin at the exit, that sounds like a power, gearing, tire, or setup issue. But the speed comparison says the time was lost earlier. The driver arrived at the exit with less speed because the first half of the corner had already been compromised. Now the diagnostic question changes. Why did the driver give away speed before the exit.
Open brake pressure or brake pedal position. Was the braking event light and long compared with the faster trace. Was there a long tail. Was pressure inconsistent. Open throttle. Was there coasting. Was the throttle hesitant. Was early throttle followed by a lift. Open steering and GPS line. Did the driver ask for a path or steering demand that made the car feel worse than the comparison lap.
The mechanic-safe verdict might be: the time loss begins in the first half of the corner, before the reported exit problem. The simple channels show a longer brake phase and delayed throttle compared with the faster section. The next objective is to clean up the first half of the corner, then recheck exit speed and throttle. That verdict does not deny the driver's feel. It explains why the feel appeared where it did.
Worked example: road-legal street car acceleration complaint at a local drag strip
The Segers material explicitly says the same analysis techniques apply even to a road-legal street car on a local drag strip because the dynamics of vehicles and drivers remain the same. That matters for track-day diagnosis because it keeps the process from becoming class-dependent. You do not need a prototype car to use the first layer of data well.
Take a simple acceleration complaint. The driver says the car feels weak. Before you wrench, check the request. Was throttle fully and cleanly applied, or did the trace show hesitation. Was there a lift. Was the gear what you expected. Did RPM support the complaint. Did speed or acceleration rate change consistently lap to lap or run to run. If the input was not clean, the data has not yet isolated the car.
If throttle, gear, and RPM are clean and acceleration is still inconsistent, then the simple check has done its job. It has not diagnosed the exact part, but it has justified a physical inspection. If the throttle trace shows hesitation or lift, the next objective is a cleaner request before the engine is blamed. This is why simple data protects both the driver and the mechanic. It does not care whether the car is fancy. It asks whether the recorded behavior supports the complaint.
Common mistakes
The first common mistake is the favorite-fix diagnosis. You already have a setup change you like, so every complaint becomes evidence for that change. The correction is to make the complaint pass through location, comparison, and simple channels before you choose the wrench.
The second mistake is the single-channel verdict. A speed dip does not automatically mean the car is slow. A steering increase does not automatically mean the setup is wrong. A throttle delay does not automatically mean the driver lacked courage. The correction is to use other channels when available. Pair speed with brake and throttle. Pair steering with lateral load, throttle, and line. Pair acceleration with throttle, RPM, and gear.
The third mistake is treating coasting as a chassis problem. Coasting appears directly in the throttle trace, and it can make the following corner phase feel like a car problem. The correction is to ask why the coast appeared and to test a cleaner throttle objective before prescribing a setup change.
The fourth mistake is ignoring brake shape. An intermediate driver may remember only that the car would not slow or would not turn after braking. The pressure trace may show inconsistent pressure, a light and long event, or a long tail. The correction is to judge the shape before judging the hardware.
The fifth mistake is overusing theoretical fastest. Theoretical fastest is useful because it points to available time, but it is not automatically a realistic whole lap. The correction is to use it as a clue, then return to the actual segment, lap, and channel evidence.
The sixth mistake is failing to calibrate to your driving. Your trace has habits. If you do not know them, you will mistake your normal style for a new problem or mistake a new problem for normal style. The correction is to compare against your own clean laps and ask what changed when the symptom appeared.
The seventh mistake is wrenching on one unsupported lap. One lap can contain a missed shift, a traffic lift, a cautious brake event, or a different line. The correction is to check consistency lap to lap and compare the problem section against a usable reference before changing the car.
Drill: three-session simple-channel gate
Run this drill at your next event for three consecutive sessions. The count is one symptom per session. The time box is 15 minutes after each session. The success criterion is that you can state the symptom location, the supporting or conflicting channel evidence, and one next-session objective before any non-safety setup change.
After session one, choose one complaint and one place. Open the section or segment report, then speed, throttle, and brake. Write three short lines: where the time or speed loss begins, what throttle shows, and what brake shape shows. If you find coasting, hesitant throttle, early throttle followed by a lift, inconsistent pressure, or a long brake tail, your next objective must address that before you call for a setup change.
After session two, repeat the process but add steering, RPM, gear, and GPS line if available. Compare against your best usable lap or fastest rolling section. The goal is not to admire more channels. The goal is to find whether the added channels agree with the session-one story. If they do not, revise the diagnosis.
After session three, set one objective before going back out or before touching the car. The objective must be visible in data. Cleaner throttle should appear in the throttle trace. A different brake event should appear in pressure or pedal shape. A different cornering demand should appear in steering, speed, line, or lateral load. If you cannot name the channel that will show the result, the objective is too vague.
You pass the drill when you stop saying the car was bad and start saying the costly part of the section began here, these channels support or challenge the driver's feel, and this is the next thing we will test. You also pass when the right answer is no change. No change backed by evidence is a professional decision.
When this principle breaks down
The principle breaks down when you treat simple data as more certain than it is. Missing channels, weak comparisons, different traffic, different tires, different fuel load, driver fatigue, and sensor limitations can all weaken the conclusion. The bonded process accounts for this by telling you to use other channels if available, compare if you can, and calibrate to your driving. Those phrases matter because they keep the method honest.
It also breaks down if you use data review to avoid necessary inspection. This lesson is about performance diagnosis before setup or repair decisions. It is not permission to ignore safety, obvious damage, or a car that should not return to track. The race-car engineering corpus treats safety as a separate category, and that boundary matters. If the car needs a safety inspection, inspect it.
The final breakdown is analysis sprawl. Race data can become a mass of information that defies fast analysis. If you open every channel and chase every wiggle, you have missed the lesson. The pre-wrench check is intentionally small. Overview, incongruencies, details, other channels, why, comparison, calibration, imagined better trace, next objective. That sequence gives you enough structure to act without pretending that simple data answers every possible question.
Author Review
No quiz questions are attached to this lesson.
Sources
| # | Document | Chunk | Pages | Score | Collection |
|---|---|---|---|---|---|
| 1 | Data for Drivers | cabda699642b26311b0a7ef998da2c71 | 15 | 1 | uio_books_raw_v1 |
| 2 | Data-for-Drivers-PRINT | bbb02386-778f-20ec-ad16-b9c016921743 | 16 | 1 | uio_books_raw_v1 |
| 3 | Analysis Techniques for Racecar Data Acquisition | 7500ea75-aa7b-b200-8b21-aa0a2ca9482c | 6 | 1 | uio_books_raw_v1 |
| 4 | Race Car Engineering Mechanics Paul Van Valkenburgh | f721fe85-812c-0bdc-d9b3-212cd51c14f7 | 149 | 1 | uio_books_raw_v1 |
| 5 | Analysis Techniques for Racecar Data Acquisition | 5eeea298-6191-0fb2-1054-b10fe574a804 | 2 | 1 | uio_books_raw_v1 |
| 6 | Analysis Techniques for Racecar Data Acquisition | d0db9128-dc9a-aec3-14a8-5f101654753f | 3 | 1 | uio_books_raw_v1 |
| 7 | Going Faster Mastering the Art of Race Driving - Carl Lopez | 4285b990-c3e7-880e-5596-99af145b469c | 300 | 1 | uio_books_raw_v1 |
| 8 | Race Car Engineering Mechanics Paul Van Valkenburgh | 8260513e-cde0-cc8a-046b-ba10e5cf93e9 | 155 | 1 | uio_books_raw_v1 |
| 9 | Data-for-Drivers-PRINT | b80dc634-a0a7-d6de-d470-353aed47e2a6 | 17 | 1 | uio_books_raw_v1 |
| 10 | Race Car Engineering Mechanics Paul Van Valkenburgh | 78daf4d4-ae31-c711-edd8-a0f8d2995419 | 173 | 1 | uio_books_raw_v1 |