Turn channels into answers
Generated from
content/lms/data-interpretation-for-drivers/01-understanding-data-systems/02-data-software-channels.md; edit the source file, not this page.
Source path: content/lms/data-interpretation-for-drivers/01-understanding-data-systems/02-data-software-channels.md
Course: Data Interpretation for Drivers
Module: Understanding Data Systems
Estimated duration: 55 minutes
Data software does not make you faster because it has many channels. It helps when you turn those channels into a clear driving question, put the right signals together, compare them against a useful reference, and leave the screen with one decision for the next session.
That is the skill in this lesson. You are not learning every analysis feature in your logger. You are learning how to build a small, disciplined data view that answers one question at a time: Did I brake differently? Did I get back to throttle later? Did the gearing choice cost me on the straight? Is the car pushing, sliding, or is my steering input creating the problem? Is this a driving issue, a car issue, or a measurement issue?
The bonded sources give you a simple structure for this. Race data begins as a large set of logged numbers. A logger can create megabytes during one practice session or race, depending on sensors and sampling rates. The analysis job is to reduce those numbers into something that makes sense quickly, either by graphing the signals or by summarizing them statistically. That does not mean simplifying the driving problem until it becomes vague. It means selecting the channels that belong to the question and ignoring the channels that are only interesting noise for that moment.
For an intermediate driver, this is where data starts to become coaching evidence instead of decoration. You already know what speed, throttle, brake, steering, RPM, and lap time are. The next step is to stop opening every trace and hoping the answer jumps out. The better habit is to choose an analysis question, open a prepared template, inspect the minimum useful channel group, and translate the pattern into a driving action you can test on the next run.
The principle is channel discipline. A channel by itself is a measurement. A useful answer comes from a relationship between channels. Speed without throttle can show that you were slower, but not whether you created the loss by waiting on throttle, choosing the wrong gear, over-slowing the entry, or scrubbing speed with steering. Throttle without speed can show driver demand, but not whether the car accelerated well. Brake position without speed can show where you pressed the pedal, but not how much speed you actually removed. Steering without lateral response can show hand activity, but not whether the car obeyed efficiently. The channel group is what lets you reason.
The source material gives several ready-made groups. For driver activity, use speed, throttle position, steering angle, and brake pedal position. For gearing, use vehicle speed, engine RPM, throttle position, and gear ratio. For understeer and oversteer, use speed, throttle position, front lateral g-force, rear lateral g-force, steering angle, and understeer angle. For lambda, use engine RPM, throttle position, and lambda. For vital functions, use RPM, water and oil temperature, oil pressure, gearbox and differential temperature, and battery voltage. These are not random bundles. Each group puts related signals on the same screen so the traces can answer a specific type of question.
Preparation matters because the track is a bad place to design your analysis system from scratch. The sources are blunt about this: configure the software before arriving at the racetrack. Prepare display templates, graph limits, colors, and useful channel groups before you need them. The reason is practical. During an event, you are short on time, attention, and sometimes calm judgment. If you have to hunt through channels after every session, you will either skip the analysis or stare at too much information. If the templates are ready, you can move directly from question to evidence.
A useful template is not just a pretty graph. It is a prebuilt answer machine. When you want to know whether you lost time entering Turn 3, you should be able to open a driver activity display and see speed, throttle, steering, and brake together, preferably over distance so the same part of the circuit lines up lap after lap. When you want to know whether a shift point hurt acceleration, you should be able to open a gearing display and see speed, RPM, throttle, and gear ratio together. When you want to know whether a corner problem is car balance or driver input, you should be able to open an understeer and oversteer display and see steering demand beside speed, throttle, front lateral g, rear lateral g, and understeer angle.
The difference between a beginner data user and an intermediate data user is not the number of sensors. It is the discipline of asking narrower questions. The source material says identical analysis techniques apply across vehicles and drivers because the dynamics remain the same. That is encouraging, but it can also tempt you into trying to analyze everything. Do not. Your job after a session is usually not to understand the whole car. Your job is to leave with one better instruction for the next session.
Use this sequence every time. First, name the question. Second, choose the template that matches the question. Third, compare against a reference lap or another run if you have one. Fourth, use cursors, markers, distance location, and time difference to locate where the pattern begins. Fifth, translate the pattern into a driving decision. Sixth, write a session note so you know what you intended to test.
The question must be specific enough that the channels can answer it. Poor question: Why was I slow? Better question: Did I give away time from brake release to throttle pickup in Turns 5 and 6 compared with my best lap? Poor question: Is the car bad? Better question: In the corner where I complained about push, did steering angle keep increasing while speed and throttle showed I was asking the front tires to do more than the car accepted? Poor question: Did third gear feel better? Better question: On the exit straight, did the lap with third gear show a cleaner RPM rise, better speed gain, and no extra throttle delay compared with the lap where I shifted earlier?
Once the question is named, the channel group does most of the organizing work. Driver activity channels show what you did in the cockpit and what speed resulted. Gearing channels show whether the engine and gear choice supported acceleration. Understeer and oversteer channels connect driver demand, speed, throttle, lateral response, and balance. Vital functions tell you whether the car is healthy enough for the rest of the analysis to mean anything. Lambda and engine channels are for powertrain questions, not corner-entry coaching. Track data can also be extracted from logged data, but that is a different kind of question from driver technique.
A strong data view also uses consistent colors. The sources recommend assigning specific colors to specific channels and keeping the same channel color across templates. That sounds minor until you are tired between sessions. If throttle is green in one template, make it green everywhere. If brake is red in your driver activity view, keep it red. If signals related to one wheel share a color, keep that convention. The goal is to make recognition automatic so your attention goes to the relationship, not the legend.
Graph limits matter for the same reason. User-definable graph limits are listed as an important software feature because a badly scaled trace hides the useful shape. If the throttle trace fills the screen but brake is compressed into a thin line, you will overweight throttle and miss braking detail. If RPM is scaled so tightly that every shift looks dramatic, you may chase a gearing problem that is not important. Set limits so the changes you care about are visible without making normal variation look like a crisis.
Distance plots are usually your friend for driver questions because the track location matters. The source material lists plotting data versus time or distance as a key software feature. Time plots can be useful, but if two laps have different speeds, the same corner event appears at different times. A distance-based view makes it easier to compare the same piece of racetrack. When you are asking what happened at a corner, line the data up by location when the software allows it. Then use overlays, cursors, and markers to inspect where the trace starts to diverge.
Multilap overlays and time-difference plots are where channels become answers. A single lap can show what happened. A comparison shows whether the thing mattered. The source material says comparing data from different laps or runs reveals the effect of setup changes or driver performance. That is the central move. You compare your current lap against a known good lap, a previous session, or another driver in the same car when that is available. The overlay shows the behavior. The time difference shows where the behavior cost or gained time.
Do not treat the fastest lap as automatically perfect. It is a reference, not a sacred lap. A fastest lap may be better overall while still containing a weak corner. But it gives you something concrete. If the time-difference trace shows a gain from corner exit to the next braking zone, look at throttle, speed, RPM, and gear. If the loss begins before turn-in, look at brake, speed, and possibly steering. If the loss begins after steering is already applied, compare steering, throttle, and balance channels. The answer is in the timing of the divergence.
Here is the basic reading order for a driver activity display. Start with speed because it shows the result. Find where the speed trace separates between two laps. Then look backward in distance to find the first driver input that changed. Did brake begin earlier? Did brake stay on longer? Did throttle open later? Did steering rise sooner or more sharply? The speed difference is the symptom; the input traces are the likely causes. If you start with the input trace alone, you may mistake harmless style differences for performance problems.
Brake position is useful because it anchors the beginning of many corner events. If the slower lap brakes earlier and the speed trace is lower at turn-in, you probably gave away entry speed before the corner. If the slower lap brakes at the same place but carries brake longer, the issue may be release timing or confidence at the transition. If the slower lap releases earlier but still turns in slower, look at whether the brake pressure actually removed too much speed before release or whether the line required the slowdown. The channel does not tell you what to do by itself; it tells you where to ask the next question.
Throttle position is useful because it shows demand, not guaranteed acceleration. A driver can press the throttle and still fail to gain speed if the car is traction-limited, in the wrong gear, or still carrying too much steering. That is why throttle belongs beside speed, RPM, and sometimes steering. If throttle opens earlier and speed climbs sooner, you found a useful gain. If throttle opens earlier but speed does not improve, you may be asking for power before the car can use it. If throttle opens later and the time-difference trace worsens down the following straight, the next session target is probably earlier, cleaner throttle application.
Steering angle is useful because it shows demand at the front tires. In driver activity analysis, steering beside speed, brake, and throttle helps you see whether you are making the car work harder at the same location. In understeer and oversteer analysis, steering becomes more meaningful when it is compared with front and rear lateral g and understeer angle. A larger steering angle at the same speed is not automatically bad, but if the extra steering coincides with slower speed gain or a complaint that the car will not rotate, the trace gives you a place to investigate.
RPM and gear ratio are useful when the question is acceleration after the corner. The source grouping for gearing is vehicle speed, engine RPM, throttle position, and gear ratio. That group lets you separate a driver hesitation from a gear-choice issue. If throttle is fully open at the same place but speed gain is weaker and RPM behavior is poor, gearing may deserve attention. If RPM and gear are similar but throttle opens later, the problem is not gear selection. If a shift interrupts acceleration, the speed trace and time difference will show whether the interruption mattered.
Vital functions belong in the analysis workflow because bad vehicle health can corrupt your conclusions. Oil pressure, temperatures, battery voltage, RPM, and related channels do not teach you how to drive a corner, but they tell you whether the car was operating normally enough to trust the performance conversation. A lap with abnormal temperature, pressure, or voltage behavior is not a clean coaching reference. Check the basics before turning small trace differences into driving advice.
Session notes are not optional decoration. Software support for adding session notes is listed among the useful features because the data file needs context. The logger records what happened; you record what you were trying, what the car felt like, and what changed. The source material also emphasizes that logged data forms an objective measurement that can be used with the subjective comments of the driver. Your comments are part of the analysis when they are specific. Write the corner, the sensation, and the attempted change. Avoid vague notes like car felt weird. Better: Turn 7 entry, added brake release earlier, felt front push from turn-in to apex.
This objective-plus-subjective pairing is important. Data can show where a handling problem appears and help an engineer decide what setup changes might be made before the next session. But you are the person in the cockpit, and driver activity logging gives a detailed record of what was happening there. When the trace and the feeling agree, confidence increases. When they disagree, that is not failure. That is a useful investigation. Maybe the car felt loose because you released brake abruptly. Maybe it felt slow because you were on throttle but in a poor gear. Maybe you blamed the car for a timing difference in your hands or feet.
Mathematical channels are the next layer, but they should serve the question instead of showing off. The source material explains that math channels perform calculations on logged data so the results can be plotted and analyzed as separate channels. Supported operations include add and subtract, multiply and divide, trigonometric functions, differentiate and integrate, and average. For a driver, the important idea is not the math menu. It is that the software can transform raw logged data into a derived channel that answers a more direct question.
For example, a time-difference plot is a derived comparison that turns two speed histories into a simple gain-or-loss picture. An understeer angle channel turns multiple measurements into a balance-related signal. Averages and statistics can summarize a lap section when the raw trace is too busy. Differentiation and integration can support deeper analysis when you know what you are asking. The risk is creating math channels before you can explain what decision they support. If a derived channel does not change your next-session instruction, leave it out of the driver view.
Histograms, X-Y graphs, run charts, track maps, and statistical data per lap or section all have places in the toolset. The source material lists them because different graphical presentations put the data in different light. For this lesson, use them as secondary tools. Start with the channel group that matches the driving question. If the trace view answers the question, stop. If the trace view shows a pattern you need to summarize across many laps or sessions, then use statistics, histograms, or run charts. Do not begin with a complicated chart when a speed-throttle-brake-steering overlay would give a cleaner answer.
The workflow also protects you from a common trap: confusing available data with useful data. Modern systems make logging accessible and can collect a large amount of information. More information does not automatically create better interpretation. The source material says the team or driver who uses the data more efficiently gains the edge. Efficient use means you do not let every channel compete for attention. You choose the smallest set that can answer the question with enough confidence to act.
Here is the driver-side checklist for turning channels into answers. Name the corner or straight. Name the performance question. Select the matching template. Overlay the reference lap or run. Inspect speed first to find the result. Work backward through brake, throttle, steering, RPM, gear, balance, or vital channels depending on the template. Use time difference to decide whether the pattern mattered. Write one driving action for the next session. After the next run, compare again and decide whether the action improved the trace.
The action should be testable. Not drive better. Not be smoother. Not fix Turn 4. A testable action sounds like this: release the brake ten feet earlier and watch whether minimum speed and throttle pickup improve without extra steering. Or hold third gear on the exit and compare speed gain to the shift lap. Or avoid adding steering after initial turn-in and see whether throttle can open sooner. If you cannot describe what success will look like in the channels, your instruction is not ready.
Calibration is the way you know this skill is improving. The first cue is speed of analysis. You should be able to open the correct display without hunting. The second cue is reduced channel clutter. Your screen should show fewer traces, not more, because you know which signals belong together. The third cue is cleaner cause-and-effect language. Instead of saying the lap was slow, you can say the loss began when brake release extended past the reference lap and delayed throttle. The fourth cue is session-to-session learning. Your notes name a change, and the next overlay shows whether it worked.
A coach or engineer would hear the difference in your debrief. Early in learning data, drivers often report feelings only. The car pushed. I was slow. I think I braked too early. After practicing this lesson, your debrief pairs the feeling with evidence. The car felt like it pushed at mid-corner, and the understeer display showed more steering demand there while speed did not improve. I thought the later shift helped, but the gearing display showed the same throttle point and weaker speed gain. I felt better in the braking zone, and the driver activity overlay showed the brake trace moved later without losing minimum speed.
You are still allowed to ask why. In fact, the source material repeatedly points toward learning and asking why. The key is asking why after you have located what. What changed? Where did it change? Which channel group shows it? Did the time difference care? Only then should you ask why and decide whether the answer is technique, setup, powertrain, conditions, or measurement.
The most important boundary is honesty. The bonded material supports channel grouping, display preparation, graphical and statistical reduction, comparative analysis, driver activity analysis, vehicle performance analysis, mathematical channels, and notes. It does not support pretending that one trace can diagnose every driving problem. Use the data as evidence, not as a fortune teller. When the channel group cannot answer the question, either choose a better group, collect better data next time, or mark the question unresolved.
Worked example: braking and throttle pickup in one corner
Imagine you come in after a session and believe you lost time in a medium-speed corner. The question is not whether the whole lap was good. The question is whether your driver inputs created the loss from braking to exit. Open the driver activity template: speed, throttle position, steering angle, and brake pedal position.
Overlay your best lap from the session against the lap you want to understand. Use a distance plot if the software gives you that option, because you care about the same location on the track. Start with the speed trace and the time-difference plot. Find the first place where the slower lap begins losing time. If the loss begins before turn-in, look at brake timing and speed reduction. If the brake trace starts earlier on the slower lap and the speed trace is already lower before steering begins, the likely answer is simple: you created the time loss before the corner by braking too early or too much.
If both laps begin braking at about the same location, look at release and throttle. The slower lap may carry brake farther toward the apex, delay throttle pickup, or add steering while waiting to commit to throttle. In that case, the driving answer is not go faster. The answer is to test a cleaner release-to-throttle transition in that corner. On the next session, your success criterion is visible in the same display: similar or better minimum speed, no extra steering demand, earlier throttle opening, and a time-difference trace that stops worsening on exit.
This example uses the source grouping for driver activity and the source-supported comparison idea. The value comes from the relationship. Speed shows the result. Brake, throttle, and steering show the likely cause. The overlay and time difference show whether the difference mattered.
Worked example: exit acceleration and gear choice
Now imagine a driver says third gear felt stronger exiting a slower corner, but the stopwatch did not clearly agree. This is a gearing question, so do not begin with every channel. Open the gearing template: vehicle speed, engine RPM, throttle position, and gear ratio.
Compare a lap where the driver used the old gear choice against a lap where the driver tried the new one. Again, look at the speed trace and time difference first. If the new gear choice produces better speed gain from corner exit to the next braking zone, the evidence is useful. Then check throttle. If throttle pickup happened at the same place in both laps, the acceleration difference is more likely related to the gear and RPM behavior than to driver hesitation. If throttle opened later on the supposedly better gear lap, the comparison is contaminated because the driver changed two things at once.
RPM tells you whether the engine was operating differently through the exit. Gear ratio confirms which gear was actually used. Speed tells you the result. Throttle tells you whether the driver asked for acceleration at the same point. With those four channels together, you can separate a real gearing benefit from a driver-input difference.
The next-session instruction should be narrow. Run three laps using the current gear plan and three laps using the alternative, only when traffic allows comparable exits. Mark the laps or write clear session notes. If the same throttle point and cleaner RPM behavior produce better speed gain and a favorable time difference, keep the change. If the speed trace does not improve, the feeling was not enough evidence.
Worked example: separating balance from driver demand
A driver returns and says the car will not turn. That may be a vehicle balance problem, but it may also be a driver-demand problem. The source material separates vehicle performance analysis from driver performance analysis and also provides an understeer and oversteer channel group: speed, throttle position, front lateral g-force, rear lateral g-force, steering angle, and understeer angle.
Start with the complaint location. Use the track map, markers, cursor location, or lap section tools to find the corner. Then compare the problem lap with a better lap or a previous run. If the driver is adding more steering at similar speed and similar throttle, while the balance-related channels show understeer behavior, the complaint has support. If the steering trace is much busier on the problem lap or the driver enters with a different speed and throttle condition, the car may be responding to different demands rather than producing the same problem on its own.
The important lesson is not to use balance language too early. Steering angle alone does not prove the car is bad. Driver comments alone do not prove setup is wrong. Logged data can provide an objective measurement to combine with subjective comments. When both line up, the engineer or driver has a better basis for change. When they do not, the next test should isolate the variable: same entry speed, same throttle plan, same steering target, then compare the balance channels again.
Drill: the three-template post-session routine
Do this at your next event after each clean session. The drill takes 10 to 12 minutes and uses three prepared templates.
Before the event, build three displays. First, Driver Activity: speed, throttle position, steering angle, and brake pedal position. Second, Gearing: vehicle speed, engine RPM, throttle position, and gear ratio. Third, Understeer and Oversteer: speed, throttle position, front lateral g-force, rear lateral g-force, steering angle, and understeer angle. Use consistent colors across all templates. Set graph limits so each trace is readable. Add a place for session notes.
After session one, choose one corner and one straight. In the corner, use Driver Activity to compare your best lap against a representative slower lap. Write one sentence naming where the time difference began and which input changed first. On the straight, use Gearing to check whether throttle, RPM, gear, and speed support your gear choice. Write one sentence naming whether the data supported or challenged your feeling.
After session two, test only one change from those notes. Do not chase three fixes. When you return, reopen the same template and compare the same location. Success is not a perfect lap. Success is being able to say whether the intended change appeared in the trace and whether the time difference improved at that location.
After session three, add the balance template only if you have a handling complaint. Pair the subjective comment with the objective traces. Success is a short, evidence-based debrief: the corner, the feeling, the channel group, the observed pattern, and the next action. If you cannot produce that debrief, simplify the question and repeat the drill next event.
Common mistakes
The first mistake is opening every channel. The screen looks serious, but the analysis gets weaker because unrelated signals compete for attention. Good looks like choosing the smallest channel group that can answer the question.
The second mistake is using a template that does not match the question. A gearing problem needs speed, RPM, throttle, and gear ratio. A driver-input problem needs speed, throttle, steering, and brake. A balance complaint needs steering and balance-related channels, not just a lap-time table. Good looks like matching the display to the job before interpreting the trace.
The third mistake is analyzing without a reference. A single lap can show what happened, but comparison reveals whether a driver change or setup change mattered. Good looks like overlaying laps or runs and using the time-difference plot to locate meaningful gains and losses.
The fourth mistake is trusting feel alone or data alone. Driver comments are subjective, and logged data is objective measurement. The useful analysis combines them. Good looks like a note that says what you felt, where you felt it, what you tried, and what the channels showed.
The fifth mistake is changing too many things before the next session. If you alter brake point, gear choice, and line all at once, the next overlay cannot tell you which change mattered. Good looks like one testable next-session instruction and a clear success criterion in the data.
The sixth mistake is leaving software setup until you are already at the track. The sources emphasize preparation because display templates, colors, graph limits, and channel organization take time. Good looks like arriving with the core templates ready so post-session analysis is a repeatable routine, not a scramble.
When to use math channels and statistics
Use math channels when they make the answer clearer than the raw signals. The source material describes math channels as calculations performed on logged data so the results can be plotted and analyzed as separate channels. That can be powerful, but only if the new channel serves the question.
For a driver, the most useful derived information is often comparative: time difference between laps, section statistics, averages, or balance-related channels the software already supports. These reduce a large data set into a pattern you can reason about quickly. But a math channel is not automatically more advanced analysis. If you cannot explain what decision the channel supports, keep it out of the working display.
Statistics are similar. They are useful when you need to summarize repeated behavior across laps or sections. They are less useful when you have not yet located the event in the trace. Start with the graph. Find the location. Compare the channels. Then use statistics or run charts when you need to confirm that the pattern repeats.
Cross-references inside the course
This lesson sits between basic data trust and deeper coaching interpretation. If you are unsure whether a channel should be trusted for a specific question, cross-reference the sibling lesson about trusting each channel for the right question. If you are still building the base screen layout, cross-reference the lesson about building a useful data picture before analyzing the lap. If you already have a clean channel group and want to turn the trace into coaching language, cross-reference the lesson about turning telemetry into coaching evidence.
The boundary here is deliberate. This lesson teaches the operating habit: question, template, comparison, answer, next action. It does not try to teach every possible sensor, every vehicle-dynamics diagnosis, or every coaching conversation. Those are related skills. The skill here is making the software show the right relationship quickly enough that you can use it between sessions.
Author Review
No quiz questions are attached to this lesson.
Sources
| # | Document | Chunk | Pages | Score | Collection |
|---|---|---|---|---|---|
| 1 | Analysis Techniques for Racecar Data Acquisition | 9998c72b-304d-0767-6517-dc3b82cea9fe | 6 | 1 | uio_books_raw_v1 |
| 2 | Analysis Techniques for Racecar Data Acquisition | be2d8954-f3d6-95a0-e682-04b9cf37b698 | 6 | 1 | uio_books_raw_v1 |
| 3 | Analysis Techniques for Racecar Data Acquisition | e9455a82-2815-f3a9-fbe0-aedf29951909 | 6 | 1 | uio_books_raw_v1 |
| 4 | Analysis Techniques for Racecar Data Acquisition | 536b17e4-0195-75ee-8979-88ad603c0e04 | 6 | 1 | uio_books_raw_v1 |
| 5 | Analysis Techniques for Racecar Data Acquisition | e70d7a2a-94d7-b3ff-b6a8-0037d26ced7a | 6 | 1 | uio_books_raw_v1 |
| 6 | Analysis Techniques for Racecar Data Acquisition | 66088a66-7d06-8e55-03eb-967374239bec | 6 | 1 | uio_books_raw_v1 |
| 7 | Analysis Techniques for Racecar Data Acquisition | f2f9f82a-8a03-1e7d-6d85-1132b3f91b51 | 6 | 1 | uio_books_raw_v1 |
| 8 | Analysis Techniques for Racecar Data Acquisition | 52e7d5ab-412b-acc5-fb49-cb0e8d5511b1 | 6 | 1 | uio_books_raw_v1 |
| 9 | Analysis Techniques for Racecar Data Acquisition | 3a5fe220-f07b-4fb6-47a3-65c6e93ce3ac | 6 | 1 | uio_books_raw_v1 |
| 10 | Analysis Techniques for Racecar Data Acquisition | 336d6fcb-354a-b1a4-ebf0-8c4bbfffbb49 | 6 | 1 | uio_books_raw_v1 |
| 11 | Analysis Techniques for Racecar Data Acquisition | fe480844-bae5-7848-3b0e-8ffbd328ce32 | 6 | 1 | uio_books_raw_v1 |
| 12 | Analysis Techniques for Racecar Data Acquisition | ad559d04-3651-61c2-d02b-5455aba0d7cc | 7 | 1 | uio_books_raw_v1 |
| 13 | Analysis Techniques for Racecar Data Acquisition | 7ae7b884-5466-cf01-8e1a-333086305e85 | 5 | 1 | uio_books_raw_v1 |
| 14 | Analysis Techniques for Racecar Data Acquisition | 15474906-387d-234d-cb57-341d5efc4d3a | 5 | 1 | uio_books_raw_v1 |
| 15 | Analysis Techniques for Racecar Data Acquisition | c6840a75-c015-d97b-7b98-bd7b84b4cbab | 18 | 1 | uio_books_raw_v1 |
| 16 | Analysis Techniques for Racecar Data Acquisition | 5eeea298-6191-0fb2-1054-b10fe574a804 | 2 | 1 | uio_books_raw_v1 |
| 17 | Analysis Techniques for Racecar Data Acquisition | d0db9128-dc9a-aec3-14a8-5f101654753f | 3 | 1 | uio_books_raw_v1 |
| 18 | Data-for-Drivers-PRINT | b80dc634-a0a7-d6de-d470-353aed47e2a6 | 17 | 1 | uio_books_raw_v1 |
| 19 | Analysis Techniques for Racecar Data Acquisition | 9ee3c928-9190-4c5d-2314-158932244c31 | 22 | 1 | uio_books_raw_v1 |