Build distance laps you can trust
Generated from
content/lms/telemetry-systems-engineering/05-lap-stitching-time-alignment-and-overlay/01-distance-base-and-lap-stitching.md; edit the source file, not this page.
Source path: content/lms/telemetry-systems-engineering/05-lap-stitching-time-alignment-and-overlay/01-distance-base-and-lap-stitching.md
Course: Design and validate the telemetry system that feeds every decision
Module: Stitch laps and align traces so comparisons are fair
Estimated duration: 55 minutes
Core idea
A time log is a record of what happened in the order the logger saw it. A distance lap is a record of where it happened on the racetrack. The difference matters because telemetry analysis is usually comparative. You are rarely asking whether the throttle was 62 percent at 18.43 seconds into some lap. You are asking whether the throttle was different at the same place on the track, whether the brake release moved deeper into the same braking zone, whether one driver carried more speed through the same middle of the corner, or whether a time-loss peak lines up with a throttle lift, brake touch, steering correction, or line problem.
That is why this lesson sits before trace alignment and automated segmenting. If the lap is still only a time log, the system can put two squiggly lines on top of each other, but it cannot promise that the two samples represent the same physical part of the track. Once the first meaningful speed difference appears, the faster lap and slower lap begin to separate in space. At the same timestamp, the faster car is farther down the road. A time overlay then compares different track locations while making them look synchronized. That is the failure you are removing.
A trustworthy distance lap gives every logged channel a station measured from lap start. Speed, throttle, brake pressure, steering angle, rpm, lateral acceleration, longitudinal acceleration, and time-loss traces can then be reviewed against distance. In the corpus examples, the useful plots use distance in feet or yards as the horizontal axis. One illustration shows speed and throttle position over a lap of a little more than eleven thousand feet. Another shows GPS speed, throttle, front brake pressure, steering angle, rpm, lateral acceleration, and longitudinal acceleration all synchronized against distance. A third uses GPS speed and time lost against distance at Lime Rock Park. Those examples are not decoration. They show the product you are trying to build: every channel laid against the same track station so a driver or engineer can compare what happened at the same point on the course.
The principle is simple. Convert before you compare. Do not judge the driver from time-aligned traces when the question is location-based. First build the lap as distance, then overlay, then ask what changed.
What you are building
For this lesson, a distance lap has five parts.
First, it has a lap boundary. The system needs to know where this lap begins and ends, so station zero means the same start point for every lap in the comparison. The bonded material does not give a lap-trigger algorithm, so this lesson does not pretend there is one universal method. The engineering requirement is narrower and more important: whatever boundary you choose, it must be consistent enough that the same track features occur at the same station from lap to lap.
Second, it has a distance base. This is the cumulative track distance from the lap start to each point in the lap. The distance base is the new horizontal axis for the analysis. The logger may have recorded the channels in time order, but the analysis product must let the software and the human reviewer ask what the car was doing at this distance into the lap.
Third, it has channels attached to that distance base. Speed alone is often the first channel you inspect because it is the visible result of the car and driver package, but speed by itself rarely tells you the cause. Once a speed difference is found, the useful follow-up channels are the driver and vehicle signals that can explain it: throttle position, brake pressure, steering angle, rpm, and acceleration. The Data for Drivers examples show exactly that review pattern. Start with overlay and compare time. Find the difference. Then ask what generated it.
Fourth, it has segment structure. A segment is a track portion with a beginning and end on the distance axis. Segmenting is where a distance lap becomes useful for consistency work. The theoretical-fastest-lap idea depends on adding the fastest segment times from a session. That only makes sense if the segment boundaries refer to repeatable places on the track. A fastest sector pulled from a wandering or inconsistent station base is not a coaching insight. It is a math artifact.
Fifth, it has review notes. Data acquisition becomes valuable when the driver, engineer, or coach interprets it. Bentley's driver-record habit is relevant here: before and after each session, you should write objectives, conditions, changes, and results. Distance conversion does not replace that record. It gives the record a precise track-location spine.
The minimum workflow
Start by preserving the raw time log. Do not overwrite it and do not treat the generated distance lap as the only truth. Raw time order is still your audit trail. The distance lap is a derived analysis surface. If the derived surface looks wrong later, you need the raw log to rebuild it.
Next, choose the laps you are willing to analyze. A race session can include traffic, tire degradation, fuel weight changes, and driver condition changes. Those factors can change lap time and ultimate car-driver performance across a run. They do not make the data useless, but they should change how aggressively you compare laps. A clean qualifying-style lap and a traffic lap may both be real, but they are not equally clean inputs for calibrating a distance base or judging a technique change.
Then establish the lap boundary and reset the station at the start of each lap. This sounds administrative, but it is where many bad overlays begin. If lap one starts at one physical point and lap two starts even a little later, every corner station is shifted. The traces may look similar, but your system has introduced a location error before the driver has done anything wrong.
Build the distance base through the lap. The bonded corpus gives the analysis requirement, not a sensor-specific formula. It points to speed, time, and distance as related quantities and shows distance-axis plots as the useful review product. In a production telemetry system, the implementation can be hidden behind logger software, GPS-derived distance, wheel-speed-derived distance, or another supported source. The lesson for you is to verify the product, not assume the label Distance makes it trustworthy.
Attach each channel to the distance base. This is the step that turns isolated logged channels into a lap. A throttle value without a station is a moment in time. A throttle value at a repeatable station is a driving input at a place on the track. The same is true for brake pressure, steering angle, rpm, and acceleration. Once the channels are stationed, you can ask whether one lap braked earlier, whether a driver lifted in a fast sweeper, whether a steering correction came before a speed loss, or whether an rpm trace shows the same gear usage at the same part of the lap.
Check the end distance and the shape. A distance lap should finish at a plausible total lap distance and should carry the major speed features in the expected order. You do not need to solve every driving question during this check. You are only asking whether the lap can be trusted enough for comparison. The bottom graph in the Bentley data example shows speed and throttle over an eleven-thousand-foot lap with recognizable peaks and troughs. That is the kind of sanity check you want: not just a number at the end, but a lap-shaped trace.
Overlay two laps only after that. The first overlay should be speed against distance. Speed is the ultimate result channel, so it quickly tells you where performance differs. If the speed traces agree through a section, there may be less to learn there on this pass. If they separate, you have a track-location question to investigate.
Use delta or compare time to prioritize, not to conclude. The Data for Drivers material shows the right mindset: overlay two laps, look for differences, use delta or compare time to find the biggest differences, then identify the difference. The time-loss trace tells you where to look. It does not tell you why the loss happened. At Lime Rock Park, the example highlights a speed reduction on the red lap and a time lost peak near that location. The teaching question is not simply that the red lap was slower. The question is what led to the reduction: throttle, braking, steering, line, driver vision, mental image, confidence, or traffic. The data generates the question. The driver record and feedback help answer it.
Finally, extract metrics only from laps you trust. Run charts and lap metrics can make large datasets easier to interpret. They can also multiply errors if the input laps are poorly stationed. If the distance base is sound, metrics help you compare many laps efficiently. If the distance base is wrong, metrics give false confidence at scale.
How the system should feel when it is right
A good distance conversion makes the review calmer. You stop arguing about whether the traces visually line up and start asking useful coaching questions. The same braking zone appears at the same station. The same speed minimum appears in the same corner. Throttle application begins at a comparable place. Segment boundaries cut the same pieces of track. The time-loss trace rises where the speed trace shows a real difference. When you add brake, throttle, steering, and acceleration, they speak to the same event rather than a vague time window.
It also changes how you talk to the driver. Instead of saying the trace changed around 24 seconds, you can say the loss begins in the first half of that corner, or just before the throttle return, or near the braking release for that segment. That language matches how drivers remember the lap. Bentley is clear that data should help the driver, and that driver feedback remains central. A distance lap is a bridge between the logged channels and the driver's physical memory of the track.
The strongest calibration cue is repeatability. Take two clean laps from the same session and overlay speed against distance. You should see the major track features repeat in order with reasonable station agreement. Then add throttle and brake. If a throttle lift appears as a spike or dip that lines up with the same speed feature from lap to lap, your distance base is probably useful. If every channel seems to slide relative to the others, or the same corner appears to move around the lap, you are not ready to judge technique.
The second calibration cue is explainable time loss. In the Lime Rock example, the graph shows a time-lost peak near a speed dip. That is useful because it creates a focused investigation. You can look at brake pressure, throttle, steering, line, and driver context. If your distance lap produces time-loss peaks that do not correspond to any track feature or channel behavior, suspect the distance base or the lap selection before blaming the driver.
The third cue is segment usefulness. Theoretical fastest lap is valuable because it compares your best segment performances against your best whole lap. If your best lap is close to the theoretical fastest lap, the spread suggests consistency. If the gap is much larger, it points toward inconsistency, experimentation, lack of confidence, or errors. But this depends on reliable segment cuts. A distance lap that cannot place segment starts and ends repeatably cannot support a meaningful theoretical-fastest-lap report.
The fourth cue is driver agreement without driver obedience. Data acquisition systems can reveal something the driver did not notice, such as a small throttle ease in a sweeper. They can also confirm what the driver already felt. But the corpus warns that data does not give all the answers and that driver feedback cannot be replaced. If the trace says one thing and the driver perceives another, treat it as a diagnosis problem. Do not dismiss the driver and do not dismiss the data. Check the distance base, check the channel, check the lap context, and ask a better next-session question.
Sub-skills
Sub-skill one is lap-boundary discipline. Your distance lap is only as good as the repeatability of station zero. For an intermediate telemetry builder, this means you should treat lap detection as a data-quality step, not a clerical step. Before overlaying, inspect whether the lap start, lap end, and total distance behave consistently enough for the analysis you are about to perform.
Sub-skill two is channel stationing. Each channel must be reviewed as a track-position signal, not just a time-series signal. Speed, throttle, brake, steering, rpm, and acceleration become useful together because they are synchronized to a distance axis. The multi-channel Data for Drivers example is important here. It does not show speed in isolation. It shows the driver inputs and vehicle responses together, aligned by distance.
Sub-skill three is first-pass speed triage. Speed is often where you begin because it contains the result. A faster speed through the same station usually means less time spent there, and an increase in speed decreases lap time. But speed is an outcome channel. It points to the area of interest. It does not by itself prove the cause.
Sub-skill four is cause-channel interrogation. Once speed or compare time flags a location, you inspect throttle, brake pressure, steering angle, line context if available, and the driver's own explanation. The Data for Drivers prompt asks whether the speed reduction came from a throttle lift, braking, steering angle, line, brake pressure, vision, mental image, confidence, or traffic. That is the right sequence. The distance lap gives you the place. The cause channels and driver context give you the diagnosis.
Sub-skill five is segment hygiene. Segments must be tied to the distance base, and they must be reviewed before their numbers are trusted. This lesson deliberately stops before the sibling lesson on automating segments before trusting splits. The cross-reference matters: once your distance laps are reliable, segment automation becomes powerful. Before that, it is just an automated way to create misleading splits.
Sub-skill six is session-context filtering. Segers notes that lap times and car-driver performance can vary during a race because of tire degradation, fuel weight, and driver condition. That matters for lap stitching because a later lap can be slower for reasons that are not a distance-conversion failure and not a single technique error. You still can compare it, but your conclusion needs to name the context.
Sub-skill seven is record-backed interpretation. Bentley's driver records give a practical template. Before the session, write the objective and the technique plan. After the session, record conditions, car changes, and results. When the distance lap reveals a difference, you have something to compare it against. Without those notes, the trace may show what changed while leaving you guessing why.
Failure modes
The most common failure is judging from time alignment. It feels natural because the logger recorded time, but time is not the track. Two laps can be compared at the same timestamp while the cars are in different places. The faster lap has traveled farther. Any conclusion about braking point, throttle return, steering correction, or corner speed becomes suspect.
Another failure is trusting the plot label. A graph can say Distance and still be a poor distance lap for your purpose. The useful test is not whether the axis has the right word. The useful test is whether the same track events occur at repeatable stations and whether the distance product supports a coherent overlay.
A third failure is using speed as the whole diagnosis. Speed tells you where the lap was better or worse. It does not tell you whether the driver lifted, braked, used more steering, chose a worse line, hit traffic, or lacked confidence. If you stop at speed, you turn a useful location clue into an unsupported driving judgment.
A fourth failure is over-trusting theoretical fastest lap. A theoretical best made from segments can show consistency gaps, but it can also be unrealistic when there are enough laps to pick from. The lesson is not to reject the report. The lesson is to use it as a consistency diagnostic and keep the segment boundaries honest.
A fifth failure is ignoring driver feedback. Data acquisition can be an excellent coach, but it is not the whole coaching conversation. If the driver says the car felt different from what your interpretation suggests, the answer is not to win the argument with the screen. The answer is to check the measurement, check the distance base, check the session conditions, and plan the next test.
Cross-references in this module
This lesson gives you the distance-based lap product. The sibling lesson Align traces before you judge the driver comes next because even distance-based channels can still need careful alignment before you make a fine technique judgment. Do not use this lesson as permission to skip trace alignment. Use it to make trace alignment meaningful.
The sibling lesson Automate the segments before you trust the splits belongs after this because segment automation depends on the distance base. A segment is only useful if its start and end represent the same physical portion of track each time. Build the distance lap first, verify it, then automate the repeatable cuts.
What good looks like
A good conversion workflow ends with fewer but sharper questions. You are not trying to explain the entire lap from one overlay. You are trying to make the lap comparable by place, find the biggest differences, and decide what to inspect next. The strongest result is a review that sounds like a paddock conversation with evidence: here is the station where the lap begins to lose time, here is the speed difference at that station, here are the input channels at the same place, here is what the driver reported, and here is the one thing to test in the next session.
That is the working standard. Distance laps are not prettier time logs. They are the foundation that lets the rest of your telemetry system compare the same piece of track to the same piece of track.
Worked example: Nurburgring speed overlay as the first proof
The Segers example uses two overlaid speed traces around the Nurburgring to show why distance is the proper comparison axis. Treat that as your first proof case.
Imagine you have two laps from the same driver and car. One lap is the reference. The other is the candidate. If you put them against time, the early part of the lap may look usable, especially before the first meaningful speed difference. But as soon as one lap carries more speed or gets to throttle earlier, that lap travels farther by the same timestamp. A braking event at the same time on the two plots may no longer be the same braking zone. A speed minimum at the same time may no longer be the same corner. The overlay looks tidy while the physical comparison gets worse across the lap.
Now convert both laps to station from lap start. Plot only speed first. At this stage you are not diagnosing driver technique. You are checking whether the overlay compares the same road. The Nurburgring example matters because it is a long lap. A time-based error has more room to grow. A distance-based speed overlay lets you compare the vehicle and driver at the same point on the track, even when the laps have different elapsed times.
Once the speed trace is on distance, inspect the big features. The high-speed sections, braking valleys, and corner exits should appear in the same order. Where the traces differ, the question becomes specific. Did the candidate lap slow too much before the corner. Did it give away exit speed. Did it carry more speed into a section but lose it later. That is the start of analysis.
Only after that first proof should you add throttle, brake, steering, and acceleration channels. The reason is discipline. Speed is the outcome. If the outcome trace itself does not line up in a physically credible way, adding more channels only gives you more ways to be fooled. Distance first, speed proof second, cause channels third.
Worked example: Lime Rock Park time-loss peak at 1600 yards
The Data for Drivers Lime Rock Park example is a better coaching example because it shows what to do after the distance lap exists. The visible graph overlays two laps, red and blue, with GPS speed and time lost plotted against distance in yards. Near 1600 yards, the red lap has a speed dip and the time-lost trace rises to about 0.195 seconds.
The poor review is to say the red driver was slower there and move on. The better review is to use the distance lap to hold the question still. The loss is not somewhere in the lap and not around a vague timestamp. It is at a station. That lets you inspect the other channels at the same place.
Start with the simplest comparison. Was the red lap slower before the event, during the event, or only after it. If the time loss begins before the speed dip, the cause may be earlier than the obvious valley. If the red lap matches speed until a sudden reduction, look for a lift, a brake touch, or a steering correction. If speed is lower but throttle and brake do not explain it, line, confidence, traffic, or car state may be involved.
Then inspect brake pressure. A small brake application where the reference lap stayed off the brake changes the diagnosis. It may mean the driver saw the corner differently, lacked confidence, responded to traffic, or corrected an entry problem. Inspect throttle next. A lift in a place the driver remembers as flat is exactly the kind of thing data can reveal. Inspect steering angle. More steering at the same station can explain a speed reduction even without a brake event because the driver may have asked too much of the tire or used a tighter line.
Finally, ask the driver. The corpus is explicit that data does not give all the answers. At Lime Rock, the distance lap gives the exact location and the channels frame the likely mechanisms, but the driver may know there was traffic, a missed visual cue, a mental-image problem, or a confidence issue. The useful coaching output is one next-session test: repeat that section with a defined throttle, brake, or vision objective and see whether the time-loss peak changes at the same station.
Worked example: Berkeley-style full-lap channel stationing
The Bentley illustration describes a bottom graph with speed and throttle position over the course of a lap, plotted against distance in feet. The visible data notes show a lap distance a little over eleven thousand feet, with speed ranging from a low near the slowest corner to a high near the fastest section. Use that kind of plot to understand channel stationing.
A full-lap distance product is not just a speed trace. It is a container that lets every channel answer the same where question. At 3000 feet into the lap, what was speed. What was throttle. Was the brake released. Was the car accelerating or still slowing. At 8000 feet, did throttle return earlier on one lap. Did speed rise sooner. Did rpm show a different gear choice. Those are station questions, not timestamp questions.
The practical check is to pick three recognizable features: a major braking zone, a slowest-speed point, and a full-throttle acceleration section. On two clean laps from the same session, those features should sit at consistent stations. If the speed minimum for the same corner moves around while the lap boundary has not changed, the distance product needs attention. If the speed minimum lines up but throttle appears shifted, the channel synchronization or channel processing needs attention. If both speed and throttle line up, the lap is ready for more serious comparison.
This is also where you learn not to worship the fastest lap. The Data for Drivers material warns that only looking at fastest lap can hide important information. A slower lap may contain the best version of one section. A faster lap may still lose time in a place the driver can improve. Once the channels are stationed, you can combine whole-lap review with segment review and driver-record notes instead of reducing the session to one lap time.
Common mistakes
Mistake one is comparing timestamps and calling it a driver difference. The symptom is a review full of statements about earlier braking, later throttle, or higher midcorner speed based on traces that were only aligned by elapsed time. What good looks like is refusing to make a location-based judgment until the laps are plotted by distance and the same track features line up.
Mistake two is treating the distance axis as automatically correct. The symptom is a graph labeled Distance with corner features that drift from lap to lap or segment boundaries that cut different pieces of track. What good looks like is checking station zero, lap end, and recognizable speed features before trusting the overlay.
Mistake three is stopping at speed. The symptom is a diagnosis that says the driver was slower without identifying whether the cause was throttle, brake pressure, steering angle, line, traffic, confidence, or car behavior. What good looks like is using speed as the first flag, then inspecting input and response channels at the same station.
Mistake four is using delta time as a verdict. The symptom is treating the biggest time-loss peak as the answer. What good looks like is treating delta or compare time as a prioritizer. It tells you where the review should begin. The cause still has to be found from other channels and driver context.
Mistake five is building theoretical fastest conclusions on unverified segments. The symptom is a report that says the driver could have gone much faster, but the system is combining segment times from cuts that have not been proven repeatable. What good looks like is verifying the distance base and segment boundaries first, then using the theoretical-fastest gap as a consistency signal.
Mistake six is ignoring session drift. The symptom is comparing an early clean lap to a later race lap and blaming the driver for all speed differences. What good looks like is naming tire degradation, fuel weight, driver condition, and traffic as possible context before turning the trace into a technique prescription.
Mistake seven is letting data overrule the driver instead of coaching the driver. The symptom is a screen-based argument. What good looks like is using data as a witness, then checking it against driver feedback, records, and the next-session objective.
Drill: three-lap distance-base audit at your next event
Run this drill after one session, before you try to coach yourself from overlays. Use three laps: your best clean lap, one other clean lap within the same session, and one lap you are tempted to analyze but know may have traffic, a mistake, or a condition change. The drill takes about twenty minutes at the laptop.
Step one is the speed-only proof. Convert the two clean laps to distance and overlay speed against distance. Do not add throttle or brake yet. Mark three major track features: the highest-speed section, the deepest braking valley, and one corner exit where speed begins to climb. Success criterion: those features appear in the same order and at believable stations on both laps. If they do not, stop. You have a distance-base problem or a lap-selection problem.
Step two is the cause-channel pass. Add throttle and brake pressure. Find the largest speed difference between the two clean laps. At that station, write one sentence naming the visible input difference. It may be earlier throttle, longer braking, a lift, or no obvious input difference. Success criterion: your sentence refers to a station or track feature, not just elapsed time.
Step three is the compare-time pass. Add delta or compare time if your software provides it. Identify the largest time-loss rise and check whether it corresponds to a real speed or input difference. Success criterion: you can state whether the time-loss peak generated a specific question. If it does not, do not force an answer. Mark it as unresolved.
Step four is the dirty-lap guardrail. Overlay the questionable lap against the clean reference. Before judging the driver, write the known context: traffic, mistake, tire state, fuel state, or driver condition if known. Success criterion: your conclusion includes the context. If the questionable lap cannot support a fair technique comparison, you say so and exclude it from the coaching decision.
Step five is the record. In your driver log, write the session objective, the two stations reviewed, the biggest time-loss question, and the one thing to test next session. Success criterion: the next-session objective is specific enough that a later distance overlay can confirm or reject it.
When this principle needs guardrails
Distance-based laps are necessary for meaningful overlay, but they are not magic. They need guardrails.
The first guardrail is measurement correctness. Segers frames usable data as something that must be measured correctly. A broken or poorly configured source can still produce a plot. The existence of a graph is not proof that the graph is fit for a decision.
The second guardrail is changing performance across a run. Tire degradation, fuel weight, and driver endurance can change lap times and the car-driver limit. If the distance lap shows a difference late in a session, that difference may be real without being a technique error. Your notes should preserve that context.
The third guardrail is driver feedback. Bentley argues for data acquisition as a powerful tool, but also emphasizes that it cannot replace what the driver feels and reports. For lap stitching, that means a disagreement between trace and driver is a reason to investigate, not a reason to dismiss either side.
The fourth guardrail is scope. This lesson teaches the distance base needed before overlay and segment work. It does not replace the next trace-alignment lesson. If you need fine judgment about exactly when a brake release or throttle pickup moved, align the traces carefully before judging the driver. It also does not replace the segment-automation lesson. Distance laps make trustworthy segments possible, but segment rules still need their own checks.
Author Review
No quiz questions are attached to this lesson.
Sources
| # | Document | Chunk | Pages | Score | Collection |
|---|---|---|---|---|---|
| 1 | Analysis Techniques for Racecar Data Acquisition | 298d8370-448d-3f4a-4164-cc740c02801e | 7 | 1 | uio_books_raw_v1 |
| 2 | Data-for-Drivers-PRINT | c10154dc-b033-8e12-98ae-b40ab858909d | 11 | 1 | uio_books_raw_v1 |
| 3 | Data-for-Drivers-PRINT | 95d759bb-9d50-5ef8-90ea-2e92ab2c47b4 | 9 | 1 | uio_books_raw_v1 |
| 4 | Ultimate Speed Secrets - Ross Bentley | 3d142f9f-7c75-7fdb-3c25-0edaa29d9600 | 554 | 1 | uio_books_raw_v1 |
| 5 | Ultimate Speed Secrets - Ross Bentley | 48f39d4b-df22-6fb5-3f40-6c8a40d11e8e | 554 | 1 | uio_books_raw_v1 |
| 6 | Ultimate Speed Secrets - Ross Bentley | 7212e525-6587-a46d-1fab-5d027a6e940e | 553 | 1 | uio_books_raw_v1 |
| 7 | Ultimate Speed Secrets - Ross Bentley | 3adbc456-d2a5-b44d-52f6-6d5b5d941b78 | 564 | 1 | uio_books_raw_v1 |
| 8 | Ultimate Speed Secrets - Ross Bentley | c6a44a7b-a56b-ff04-249e-5c90bd975aea | 566 | 1 | uio_books_raw_v1 |
| 9 | Speed Secrets Professional Race Driving Techniques Ross Bentley | a009c9a4-cb8d-b3b5-063d-33e44ea0b5cb | 76 | 1 | uio_books_raw_v1 |
| 10 | Analysis Techniques for Racecar Data Acquisition | 5eeea298-6191-0fb2-1054-b10fe574a804 | 2 | 1 | uio_books_raw_v1 |
| 11 | Analysis Techniques for Racecar Data Acquisition | 41138569-fa56-a0a4-38c5-301475e4131a | 21 | 1 | uio_books_raw_v1 |
| 12 | Analysis Techniques for Racecar Data Acquisition | 1d32f116-9b81-52c6-919d-dba1c542c011 | 5 | 1 | uio_books_raw_v1 |
| 13 | Analysis Techniques for Racecar Data Acquisition | 15474906-387d-234d-cb57-341d5efc4d3a | 5 | 1 | uio_books_raw_v1 |
| 14 | Analysis Techniques for Racecar Data Acquisition | 39682334-bcf0-1be4-aea0-3c7df650fbac | 20 | 1 | uio_books_raw_v1 |
| 15 | Analysis Techniques for Racecar Data Acquisition | 10c55b71-044c-c477-4af7-6ba94652ee56 | 26 | 1 | uio_books_raw_v1 |
| 16 | Analysis Techniques for Racecar Data Acquisition | 9ee3c928-9190-4c5d-2314-158932244c31 | 22 | 1 | uio_books_raw_v1 |
| 17 | Analysis Techniques for Racecar Data Acquisition | d0db9128-dc9a-aec3-14a8-5f101654753f | 3 | 1 | uio_books_raw_v1 |
| 18 | Going Faster Mastering the Art of Race Driving - Carl Lopez | 4285b990-c3e7-880e-5596-99af145b469c | 300 | 1 | uio_books_raw_v1 |
| 19 | Going Faster Mastering the Art of Race Driving - Carl Lopez | fa01ec16-aace-9079-2afa-de127b8272a9 | 300 | 1 | uio_books_raw_v1 |