Build the telemetry handoff another engineer can trust

Generated from content/lms/telemetry-systems-engineering/07-system-integration-and-troubleshooting/03-documentation-and-handoff.md; edit the source file, not this page.

Source path: content/lms/telemetry-systems-engineering/07-system-integration-and-troubleshooting/03-documentation-and-handoff.md

Course: Design and validate the telemetry system that feeds every decision

Module: Integrate the full pipeline and keep it running

Estimated duration: 55 minutes

Purpose: make the system survivable

A telemetry system is not handed off when the logger powers up. It is handed off when another engineer can take the car after a session, download the data, understand what the system records, know which traces are trusted enough to use, see what changed since the last run, and know what question the next session is supposed to answer. That is the skill in this lesson. You are not writing paperwork for decoration. You are building a takeover path.

The bonded material gives you a practical order for that takeover path. A starter chassis and driver system records engine RPM, wheel or vehicle speed, throttle position, steering angle, lateral acceleration, and longitudinal acceleration. It also records vital functions such as pressures, temperatures, and battery voltage, plus a beacon or lap marker so the data can be tied to laps. More advanced analysis adds suspension movement, brake pressure, tire temperatures, tire pressures, ride height, loads, yaw, torque, aerodynamic pressures, and other signals. The same source material also gives the working discipline: ask what you want to measure, download the logger every time the car comes in, begin with the vital channels, listen to the driver, observe what the car is doing before chasing why, analyze all laps rather than worshipping the fastest lap, look for the obvious first, and keep logs for later reference. Your documentation is those habits made permanent.

Keep the scope tight. The sibling lessons in this module cover running the whole chain before the out-lap and diagnosing telemetry faults before the next session. This lesson is the bridge between those actions. You are not learning how to fix every live fault here, and you are not building a pre-session checklist from scratch. You are learning how to leave evidence so the next engineer can run those checks and diagnoses without having to reconstruct your thinking from scattered files, half-remembered driver comments, and unlabeled traces.

Principle: document the question, the signal, and the next action

Good telemetry documentation has three jobs. First, it states what question the system is meant to answer. Second, it states which signals are available for that question and which signals are missing or limited. Third, it turns the latest evidence into a next action. If a handoff only lists hardware, it is incomplete. If it only stores data files, it is incomplete. If it only records conclusions, it is dangerous, because the next engineer cannot see whether the conclusion came from a vital-channel problem, a driver comment, a speed trace, a setup change, traffic, or an unsupported guess.

The question comes first because data acquisition expands without a natural stopping point. The corpus lists many possible channels, and then immediately warns that engineers should ask what they want to measure. That warning is the center of your handoff. When you document a system, do not treat every absent channel as a defect and every installed channel as self-explanatory. Tie each installed channel to a purpose. Tie each missing channel to a known limit. Tie each future channel to the question it would make answerable. That keeps the next engineer from confusing a rich trace list with a useful analysis system.

The signal comes second. At minimum, the next engineer needs to recognize the six basic traces and the vital channels. Those six traces are still the most used resources even when the car has a much larger logger package. That means your handoff should make the basics easy to find, not bury them under every advanced sensor the car happens to carry. A steering trace, a throttle trace, speed, RPM, lateral acceleration, longitudinal acceleration, pressures, temperatures, voltage, and lap sync are the first map of the car. Brake pressure, suspension movement, infrared tire temperature, tire pressure, ride height, loads, yaw, propshaft torque, aero pressure, and other channels are extensions around that map, not replacements for it.

The next action comes third. A handoff that ends with data exists is not a handoff. After every meaningful run, the next engineer should be able to see whether the car was healthy, what the driver reported, which laps were representative, where time was gained or lost on the speed trace, which setup change was being tested, which channels should have moved if the change worked, whether the evidence was consistent across laps, and what objective goes into the next session. That action line is where documentation becomes engineering instead of storage.

Layer one: the channel inventory

Start the handoff with a channel inventory that separates core, vital, lap-sync, diagnostic, and expansion channels. The core group is engine RPM, vehicle or wheel speed, throttle position, steering angle, lateral acceleration, and longitudinal acceleration. The vital group is temperatures, pressures, and battery voltage. The lap-sync group is the beacon or other lap-start and lap-end marker. The diagnostic group includes channels such as brake line pressure, suspension movement, tire temperature, tire pressure, ride height, suspension loads, yaw, and the engine-specific ECU channels used for performance analysis. The expansion group is not installed-yet fantasy. It is the list of channels the team has a reason to add next because a current question cannot be answered cleanly.

For each channel, write the practical meaning rather than only the name. A useful entry says what part of the car or driver the trace represents, why the team uses it, and what other trace it is commonly checked against. Speed is the broadest performance trace. Throttle, brake pressure when available, steering, lateral acceleration, longitudinal acceleration, and RPM show driver activity and vehicle response. Temperatures, pressures, and voltage are health traces. Suspension, strain, load, ride-height, and tire-temperature channels help explain why the car behaved the way the basic traces show it behaved. ECU channels such as RPM, throttle position, lambda, and air box pressure can be transferred and overlaid with lap timing when the engine logger communicates with the external acquisition unit, so the handoff must make clear which signals come from the ECU and which come from the chassis logger.

Do not let the inventory become a shopping list detached from the car. The source material says most teams start with the six basic channels and extend step by step as they gain experience. That step-by-step history belongs in the document. If brake pressure was added because throttle and speed traces could not separate coasting from real braking, write that. If suspension travel was added because the team needed to understand platform movement rather than only driver inputs, write that. If tire temperature was added because grip questions kept returning after sessions, write that. If a channel is planned but absent, write the current consequence: the team cannot answer that question from logged data yet.

Layer two: the health-first routine

The next engineer must know that performance analysis does not begin with lap time. It begins with vital channels. The source process is blunt: when the car enters, download the logger because even warm-ups and rollout laps can matter, then begin with engine and driveline temperatures, pressures, and battery voltage before addressing performance data. Your handoff should make that order impossible to miss.

A good session note therefore begins with health status. It records whether the logger was downloaded for this car entry, whether the vital channels looked normal or abnormal, and whether any strange behavior must be understood before comparing laps. It also records the driver comment, because listening to the driver makes it easier to know what to look for. The point is not to let the driver overrule the data or let the data dismiss the driver. The point is to put the driver comment next to the first health checks so the next engineer knows the starting hypothesis.

This matters most when the driver comes in excited, frustrated, or convinced the car is undrivable. The handoff standard should say: record the comment, check the vital channels, then look at what the car did. If the note skips directly to a handling conclusion while voltage, temperature, or pressure behavior is unknown, the next engineer inherits a weak conclusion. If the note records the health check first, the next engineer can decide whether the complaint belongs in a performance-analysis lane or a reliability lane.

Layer three: the session and run log

The run log is the spine of the handoff. It connects the physical car, the data file, the driver report, the setup condition, and the next objective. It does not need to be ornate, but it does need to be consistent. Every car entry earns an entry because warm-ups and rollout laps can contain relevant information. That rule prevents the common failure where the only documented file is the fastest session, while the early warning appeared during a warm-up or installation lap.

For each run, document the purpose before the result. Was this a baseline, a check after a repair, a comparison after a setup change, a driver-learning run, a rollout, or a simulation-validation run? Then document what changed. If nothing changed, say that the car is still on the baseline condition. If a setup change was made, identify the channels expected to show the effect. The source material gives a clear example: aerodynamic changes most likely show up in speed and wheel-load traces. The same discipline applies more broadly. If you cannot name the trace that should move, the change is not ready to be evaluated from data.

Then document the evidence. Do not only capture the best lap. Analyze all laps and note consistencies and inconsistencies, because traffic can strongly influence lap time. Statistics and run charts are useful because they widen the view beyond one lap. The next engineer needs to know which laps were clean enough to compare, which were compromised, which traces were consistent, and which traces created the next question. If your note only says fastest lap improved, it hides whether the car improved, the driver found a cleaner lap, traffic changed, or the comparison is too thin.

Layer four: the analysis trail

A handoff should preserve the order of analysis, not just the conclusion. The operating sequence from the corpus is simple and powerful. Start with vital channels. Listen to the driver. Observe what the car is doing through speed, acceleration, and driver activity. Then move toward why by looking at channels such as shock data and strain gages when available. Look for the obvious first. Use other channels to check the story. Compare if you can. Imagine what the better trace would look like. Set objectives for the next session.

Write your analysis note in that order. First, state the health finding. Second, state the driver comment. Third, state the observed behavior: where the speed trace lost or gained time, where throttle was delayed or lifted, where steering activity changed, where acceleration traces changed, or where brake pressure shape mattered if that channel is installed. Fourth, state the explanatory evidence: suspension movement, tire temperature, pressure trend, load, ride-height, or other available channels. Fifth, state the uncertainty. Sixth, state the next objective.

The speed trace deserves special treatment in the handoff because it tells where time is gained or lost. That does not mean speed explains everything. It means speed anchors the performance question before you dive into cause. If a new engineer opens your note and sees a cause before seeing where the speed trace changed, the note is backwards. If the note says where the speed changed, then shows what the driver inputs and chassis channels did around that change, the next engineer can follow the logic.

Layer five: the change record and simulation log

Changes need their own trail. A setup change without a recorded expected trace is hard to evaluate. A simulation run without a log of inputs and results is hard to use later. The corpus explicitly says a good log of simulation runs and results should be kept for later reference. Put the same idea into physical test work. The next engineer should be able to see what was changed, why it was changed, which channels should reveal the effect, what result appeared, and whether the evidence was strong enough to keep, reverse, or retest the change.

This is especially important when simulations or off-car analysis motivate significant alterations. The source material describes using simulation to test outside the physically available adjustment range and then using results to motivate real vehicle decisions. That is useful only if the later engineer can see the chain from simulated condition to real decision. If the handoff only says a change was recommended, the next engineer cannot tell whether the recommendation came from a validated model, an unvalidated assumption, an aero-map update, a tire-model change, or a track bump-profile recheck.

Keep the change record modest and disciplined. Record the baseline, the change, the expected channel response, the actual channel response, the driver comment, whether the comparison was clean, and the next action. If the evidence is inconclusive because the lap was traffic affected or the weather changed, write that. The limitations of logged data include lap, circuit, and weather dependence. Treat those limits as part of the record, not as excuses added later.

Layer six: failure readiness and spares

The handoff should also make the system repairable. The corpus points out that critical sensors should be within reach in case of failure, and so should cables, connectors, and other spare equipment. It also says backup solutions are better when budget allows. Documentation turns that physical preparedness into usable preparedness. The next engineer needs to know which channels are critical, which physical parts protect those channels, and what backup path exists if a sensor or cable fails.

Keep this part grounded in the installed system. Do not write a generic spare-parts catalog. Write the critical telemetry spares that matter for this car and this analysis plan. If the beacon or lap marker fails, lap segmentation is affected. If battery voltage is unreliable, health interpretation becomes weaker. If a brake pressure sensor fails, brake-shape analysis is gone. If a suspension potentiometer fails, platform explanation is reduced to indirect evidence. If the ECU link fails, engine-specific signals cannot be overlaid cleanly with lap timing. The handoff does not need to solve every repair. It needs to tell the next engineer what capability is lost and what backup evidence remains.

Layer seven: limitations and confidence

The final layer is the confidence boundary. Telemetry can feel authoritative because it creates graphs, but the corpus is clear that logged data is limited by available sensors, by logging resolution and frequency, and by lap, circuit, and weather dependence. It also notes that some crucial items, such as tire contact patch load on a rolling tire, are impossible to measure directly. That belongs in the handoff because the next engineer must know where the data stops.

Mark channels and conclusions with confidence. A high-confidence conclusion is supported by the relevant installed channels and repeated across comparable laps. A medium-confidence conclusion is supported by some evidence but has a missing channel, traffic complication, weather difference, or inconsistent lap pattern. A low-confidence conclusion is a hypothesis for the next run, not an instruction to change the car. This confidence language is not extra bureaucracy. It prevents the next engineer from treating every note as equally proven.

Sub-skill: signal triage

Signal triage is the ability to sort channels by purpose before you analyze them. Put core driver and vehicle traces first, vital channels before performance claims, lap sync where the files can be segmented, and advanced channels next to the questions they answer. When you inherit data, do the same thing in reverse. Ask which core traces exist, whether the vital traces are healthy, whether lap segmentation is reliable, and which advanced traces can explain the behavior.

The practical cue is simple: if you cannot explain why a channel exists, it is not yet part of the handoff. It may still be installed, and it may still be useful later, but the documentation should not pretend it has a current engineering role. Conversely, if the team keeps asking a question that no installed channel can answer, the handoff should say so. That is how the system grows step by step instead of by impulse.

Sub-skill: evidence ordering

Evidence ordering keeps you from chasing the interesting trace before checking the important one. In the handoff, the order is health, driver, observed behavior, explanation, comparison, objective. Health is temperatures, pressures, voltage, and any other vital signal. Driver is the comment that gives you a search direction. Observed behavior is speed, acceleration, throttle, steering, braking if available, and RPM. Explanation is suspension, load, tire, ride-height, strain, or other deeper channels. Comparison is all-lap consistency, run charts, statistics, and traffic awareness. Objective is what the next run is meant to learn.

When this order becomes habit, the documentation reads like an engineering thought process. When it is missing, the document becomes a pile of traces and opinions. The next engineer should be able to follow your note and see why you looked where you looked. That is the difference between a conclusion and a handoff.

Sub-skill: change traceability

Change traceability means every setup or system change has an expected signature. If an aerodynamic change is made, the source material says speed and wheel-load traces are likely places to see the effect. If brake pressure is added as a channel, the expected use is to read pressure shape, consistency, trail, and hard-short versus light-long behavior. If suspension movement is added, the expected use is to help explain vehicle response and platform behavior. If infrared tire temperature is added, the expected use is to support grip and tire-behavior questions.

The handoff entry for a change should therefore include the question, the change, the expected trace, the result, and the next action. Without the expected trace, the next engineer can only admire the data after the fact. With it, the next engineer can judge whether the test answered its question.

Sub-skill: limits literacy

Limits literacy is knowing what not to claim. Logged data depends on available sensors and logger capability. On-circuit tests are expensive and affected by lap, circuit, and weather. Some important physical quantities are not directly measured. Simulation results need logs and later validation. These facts should not make you timid. They should make you precise.

Write the limit next to the conclusion. If tire contact patch load was not measured, do not write as though it was. If weather changed between runs, say the comparison is weaker. If the brake pressure channel is absent, do not diagnose brake release shape from imagination. If suspension movement is not installed, do not pretend the speed trace alone proves the damper story. The next engineer can work with honest uncertainty. They cannot work safely with false certainty.

Calibration cues: what better documentation looks like

You know the handoff is improving when the next engineer asks fewer reconstruction questions and better engineering questions. Instead of asking which file goes with which run, they ask why lap three and lap five diverged. Instead of asking whether the car was healthy, they ask why voltage dipped in one run. Instead of asking what changed, they ask whether the expected channel moved enough to keep the change. That shift tells you the document is carrying the basics.

You also know it is improving when the analysis starts from the same place every time. The first review checks vital channels. The driver comment is captured before the trace hunt begins. The speed trace anchors the performance question. All laps are reviewed for consistency and traffic effects. Other channels are used to check the story. The note ends with a next-session objective. If those steps appear without you prompting them, the handoff is doing its job.

The telemetry itself gives calibration cues too. A mature handoff makes file-to-run matching clean, lap segmentation obvious, core traces easy to locate, missing channels explicit, and setup-change comparisons narrower. The speed trace, throttle trace, steering trace, brake pressure trace when installed, RPM, gear when installed, GPS line when available, segment reports, theoretical best, g-sum, total steer, and throttle histogram are not all mandatory for every car. But when any of them are used, the handoff should say why they were used and what question they served.

Failure modes and recovery

The first failure mode is the data dump. This looks productive because there are many files, screenshots, and traces. It fails because the next engineer cannot tell what question each file answers. Recover by adding a run log and a channel-purpose inventory before doing more analysis.

The second failure mode is fastest-lap tunnel vision. It feels efficient because it starts with the best lap, but it hides traffic effects, inconsistent laps, warm-up information, and reliability clues. Recover by reviewing all laps, marking consistency and inconsistency, and using statistics or run charts where they widen the view.

The third failure mode is performance before health. It feels urgent because the driver is standing nearby and the car may feel awful. It costs time because a pressure, temperature, or voltage issue can invalidate the performance story. Recover by documenting the vital-channel check at the top of every session note.

The fourth failure mode is unsupported precision. It shows up when the note states a detailed cause that the installed sensors cannot prove. Recover by writing the actual evidence and the missing channel. Turn the unsupported claim into a next-session objective or a future sensor need.

The fifth failure mode is channel creep. It starts with a reasonable desire for more data and becomes a system that strains wiring, memory, hardware, and attention without answering sharper questions. Recover by tying every proposed channel to a specific measurement need and by documenting future expansion as step-by-step capability growth.

The sixth failure mode is a repairable system with no repair handoff. The team may have sensors, cables, connectors, and spare equipment in the pit area, but the next engineer does not know which failure each spare solves or what analysis capability is lost when a channel dies. Recover by adding a critical-channel spare map.

The seventh failure mode is simulation amnesia. A model run influences setup, but the inputs, result, and later validation questions are not recorded. Recover by keeping a log of simulation runs and results for later reference, and by writing what track data should revalidate or fine-tune.

Cross-references inside the module

Use this lesson before and after the sibling lessons, not instead of them. Before running the whole chain before the out-lap, the handoff tells the engineer which channels and spares matter. After diagnosing telemetry faults before the next session, the handoff captures what failed, what evidence proved it, what backup was used, and what capability remains degraded. In both directions, documentation keeps the system from depending on one person's memory.

The operating standard

A complete handoff is not long because it is verbose. It is complete because it lets another engineer make the next correct move. It names the measurement question. It lists the installed and missing signals. It checks health before performance. It captures the driver comment. It reviews all laps and traffic context. It anchors time gain or loss on the speed trace. It uses deeper channels to explain rather than guess. It records setup and simulation changes with expected traces. It marks limits and confidence. It identifies critical spares and backup paths. It ends with the next objective.

If your document does those things, the next engineer does not need your memory to keep the telemetry program moving. They can take the car, open the files, trust the order of work, and make the next session cleaner than the last one.

Worked example: the six-channel HPDE logger after a rollout

The car comes in after a rollout, and the driver says the car feels strange. The weak handoff starts by hunting for a handling answer. The strong handoff starts by downloading the logger because even the rollout can contain relevant information. It marks the run as a rollout, lists the six basic channels as available, confirms lap sync, and checks temperatures, pressures, and battery voltage before comparing performance traces.

Once the health check is recorded, the note captures the driver comment and then observes what the car did. Speed, longitudinal acceleration, lateral acceleration, throttle, steering, and RPM describe the run well enough to decide whether the complaint belongs to basic vehicle behavior, driver input, driveline response, or a health concern. If the handoff says only car felt strange, the next engineer has to restart the whole investigation. If it says health normal, driver reported instability on rollout, speed trace shows no meaningful push run, steering input oscillated in the same section on both laps, and next run should verify after pressure recheck, the next engineer has a path.

The important point is not that the six-channel system solves every problem. It does not. The point is that the documentation makes the six-channel system honest. It shows what was checked, what was observed, and what remains unknown because deeper channels such as brake pressure or suspension movement are not installed.

Worked example: expanding to brake pressure, suspension movement, and infrared tire temperature

A team has outgrown the starter package. The basic traces keep raising questions that cannot be answered cleanly. The driver may be coasting, braking lightly for too long, or releasing brake pressure differently from lap to lap, so brake pressure becomes the next useful channel. The car may show speed-trace loss that needs a platform explanation, so suspension movement becomes useful. Grip questions keep returning after the tires heat, so infrared tire temperature becomes useful.

The handoff should not simply say new sensors installed. It should say which question each added channel is meant to answer, what comparison it supports, and what future cost it creates. The source material warns that expansion affects the wiring harness, memory, and other hardware. That belongs in the documentation because the next engineer has to know whether the system still has capacity and where a failure is likely to matter.

After the first run with the new channels, the handoff should record whether the traces are usable, how they changed the analysis order, and what they did not solve. Brake pressure may clarify pressure shape and consistency. Suspension movement may help explain why the basic traces look the way they do. Tire temperature may support tire behavior questions. But the document should still mark limits. Logged data remains limited by sensors, resolution, frequency, lap, circuit, and weather. The new channels reduce uncertainty; they do not remove it.

Worked example: simulation result becoming a real test item

A simulation suggests that a setup direction is worth testing outside the team's usual adjustment range. That is exactly the kind of result that can become confusing two sessions later if it is not documented. The handoff should record the simulation run, the result, the real-world decision it motivated, and the validation question for the track.

The corpus points toward later reference and revalidation. Aero performance, aeromap optimization, track bump profile, and tire-model tuning can all require reexamination after real data arrives. In the handoff, that means the simulation entry should not be treated as a verdict. It is a prediction with a follow-up. The next engineer needs to know what track data would support it, what data would challenge it, and whether the real run was clean enough to compare.

This example also shows why documentation is not just clerical work. Without the log, a later engineer may see only the physical change and assume it was a paddock hunch. With the log, they can trace the decision from model to real test to next validation step.

Common mistakes

Mistake one is writing hardware inventory without analysis purpose. Good looks like a channel inventory where each trace is tied to a measurement question and grouped as core, vital, sync, diagnostic, or expansion.

Mistake two is documenting only the fastest lap. Good looks like a session note that reviews all laps, marks traffic effects, and records consistency or inconsistency before drawing a conclusion.

Mistake three is chasing performance while health is unknown. Good looks like every run note beginning with pressures, temperatures, voltage, and any strange vital-channel behavior before the performance story begins.

Mistake four is trusting the driver's comment or dismissing it too quickly. Good looks like recording the comment, using it to guide the search, and then checking it against speed, acceleration, driver activity, and deeper channels when available.

Mistake five is adding channels without a future plan. Good looks like step-by-step expansion where brake pressure, suspension movement, tire temperature, or other channels are added because a specific recurring question requires them, and where wiring, memory, and hardware implications are visible.

Mistake six is hiding uncertainty. Good looks like labeling the conclusion as high, medium, or low confidence based on installed sensors, lap comparability, traffic, weather, and trace consistency.

Drill: three-session telemetry handoff relay

At your next event, run this drill across three sessions. After each session, give yourself twelve minutes to write a handoff note before you do any deeper analysis. The note must include the run purpose, downloaded data status, vital-channel status, driver comment, representative laps, compromised laps, main speed-trace observation, supporting channel evidence, missing or questionable channels, and the next objective.

After session one, write the note for yourself and then reopen it thirty minutes later. Success means you can reconstruct the run without relying on memory. After session two, hand the note to another driver, coach, or engineer and ask them to tell you what they would check first. Success means they start with the vital channels and the stated objective rather than guessing. After session three, compare all three notes and mark one improvement to the channel inventory, one improvement to the run log, and one improvement to the next-session objective.

The count is three sessions. The time box is twelve minutes per handoff note plus a short review after each. The success criterion is not beautiful formatting. The success criterion is that another person can identify what was measured, whether the car looked healthy, which laps matter, what the evidence suggests, what is uncertain, and what the next run should test.

When this principle breaks down

This principle breaks down when the corpus-supported evidence does not exist. If the installed system lacks a channel, the handoff cannot pretend that channel answered the question. If the logger's resolution or frequency is not adequate for the event being studied, the conclusion must be marked weak. If the comparison spans different weather, a different circuit condition, traffic, or a changed driver approach, the note must say so. If a model result has not been checked against track data, the document should treat it as a prediction waiting for validation.

It also breaks down when the team tries to document every possible thing instead of the next useful thing. The source material says the list of channels can go on, but specific needs require specific channels. A handoff that grows without a measurement question becomes another source of noise. A better handoff stays narrow enough that the next engineer can act, then expands only when a real question demands another signal.

Author Review

No quiz questions are attached to this lesson.

Sources

#	Document	Chunk	Pages	Score	Collection
1	Analysis Techniques for Racecar Data Acquisition	48d56105-c3c5-81ff-d649-243a1cd43c35	6	1	uio_books_raw_v1
2	Analysis Techniques for Racecar Data Acquisition	9b41b678-4787-363c-042e-2986a1b9565e	5	1	uio_books_raw_v1
3	Analysis Techniques for Racecar Data Acquisition	f6dc9cae-392f-1151-15c6-df8acd9a8ec5	5	1	uio_books_raw_v1
4	Data for Drivers	cabda699642b26311b0a7ef998da2c71	15	1	uio_books_raw_v1
5	Analysis Techniques for Racecar Data Acquisition	4669aec5-620e-051b-7b5d-a0a0380b73b0	7	1	uio_books_raw_v1
6	Analysis Techniques for Racecar Data Acquisition	2c2b79d6-8481-a249-415e-c9cfb1be1d8c	19	1	uio_books_raw_v1
7	Analysis Techniques for Racecar Data Acquisition	f725bafe-8b10-b36a-5b91-3395a519319d	16	1	uio_books_raw_v1
8	Analysis Techniques for Racecar Data Acquisition	d0db9128-dc9a-aec3-14a8-5f101654753f	3	1	uio_books_raw_v1