Turn the measurement into the sensor spec
Generated from
content/lms/telemetry-systems-engineering/01-sensor-selection-and-placement/01-from-measurand-to-spec.md; edit the source file, not this page.
Source path: content/lms/telemetry-systems-engineering/01-sensor-selection-and-placement/01-from-measurand-to-spec.md
Course: Design and validate the telemetry system that feeds every decision
Module: Choose the right sensor for every signal
Estimated duration: 55 minutes
A useful telemetry channel does not start with a sensor catalog. It starts with the measurand: the physical thing you need to know. You are not buying a brake pressure sensor because brake pressure is an interesting number. You are choosing a sensor because you need to answer a question about driver input, chassis behavior, reliability, safety, vehicle modeling, or setup development. The channel is successful only if the data logger records the right physical parameter, over the right interval, in the real environment of the car, with enough accuracy for the analysis you intend to perform.
The core skill in this lesson is turning that need into a specification before you choose hardware. You will learn to write a practical sensor spec from five decisions: what physical quantity you are measuring, what interval the sensor must cover, what environment it must survive, what accuracy is actually useful, and what the budget should buy. Those questions come directly from the sensor-selection method in the data acquisition text: first determine the requirements of the measurement, then evaluate the sensor data sheet. That order matters. If you reverse it, you start defending a part number before you have defined what the channel must prove.
For an intermediate telemetry builder, this is the difference between a channel list and an engineering system. A beginner says the car needs brake pressure, suspension movement, and tire temperature. A competent builder says the brake pressure channel must identify driver braking behavior, correlate to longitudinal acceleration, and survive the hydraulic environment; the suspension channel must capture operating motion on track, because the whole suspension contains nonlinear behavior that cannot be fully described by laboratory component tests alone; the tire temperature channel must support tire operating questions, while recognizing that some things at the contact patch are still not directly measurable on a rolling tire.
Start with purpose. The data acquisition book divides logged information into several useful categories: vital functions of the car, driver activity, vehicle development, reliability and safety, determining vehicle parameters, and running logs. That classification is not paperwork. It tells you what kind of decision the channel must support. A channel used for driver coaching has a different success test from a channel used to prevent engine damage. A channel used to feed a simulation model has a different standard from a channel used as a running log for component life. If you cannot say which job the channel performs, you cannot sensibly specify the sensor.
For example, engine oil pressure and temperature, water temperature, fuel pressure, gearbox and differential temperature, battery voltage, and engine RPM belong to the vital-function family. They tell you whether the car is healthy enough to continue and whether damage may be developing. Throttle position, steering angle, brake pressure, and related channels belong to driver activity because the driver directly commands them. Wheel speed, acceleration, suspension movement, ride height, suspension loads, yaw speed, tire pressure, and tire temperature can support vehicle dynamics, development, and diagnosis. The same physical sensor may serve more than one category, but you should choose the primary purpose before specifying it.
A clean sensor spec reads like a chain. The analysis question leads to the measurand. The measurand leads to the physical category: temperature, pressure, flow, displacement or position, velocity, acceleration, or force. The expected values lead to the range. The car environment leads to survival requirements, mounting constraints, and contamination protection. The intended comparison or decision leads to accuracy, resolution, sampling, and logger compatibility. Future expansion needs lead to wiring, memory, and hardware headroom. Budget comes last, because budget should buy only the performance that the measurement can use.
The first sub-skill is naming the measurand exactly. Do not write suspension data if you mean damper shaft displacement. Do not write brake data if you mean hydraulic line pressure at a selected circuit. Do not write tire data if you mean infrared surface temperature, tire pressure, or vertical load estimate. The book lists measurement categories, and those categories help you separate physical quantities that often get mixed together in conversation. Temperature is not pressure. Position is not force. Acceleration is not velocity. A sensor transforms one physical phenomenon into an electrical signal proportional to that phenomenon, so the specification has to name the phenomenon, not the general area of interest.
This is where many first telemetry systems become vague. A driver says the car feels unstable under braking, so the team adds more channels. More channels can help, but only if each one measures a defined part of the problem. Brake line pressure can show driver brake input. Longitudinal acceleration can show the car response. Wheel speed can show individual wheel behavior, especially if ABS or traction control already requires wheel speed sensors. Suspension movement can show pitch and heave response. Steering angle can show what the driver asked the front tires to do. Tire temperatures and pressures can support tire operating questions. Each channel earns its place by measuring a different part of the mechanism.
The second sub-skill is defining the expected measurement interval. A sensor range that is too small clips the event you care about. A range that is wildly too large may give away useful detail because the logged signal uses only a small part of the available scale. The data acquisition text calls this the sensor range question: what is the expected measurement interval? You answer it from the event, not from wishful thinking. For brake pressure, the interval must cover the real pressures the hydraulic system produces in the intended use. For suspension travel, it must cover the operating motion of the damper or suspension member without hitting the sensor limit. For ride height, it must include the car state in the pit lane and on circuit. For acceleration, it must include the expected longitudinal, lateral, or vertical accelerations in the vehicle and mounting location.
The range decision also depends on where the measurement will be used. A pit-lane sensor check may compare a reading to an expected value and alarm on an offset. An on-track channel may need to capture peaks, rates, and transient behavior. The book gives an example of comparing sensor readings to expected values during a pit-lane phase, using externally calculated references and offsets. That example is important because it shows that range is not only about the biggest number. The channel must also be useful around the reference value where you inspect drift, offset, or setup-dependent changes.
The third sub-skill is specifying the environment. A race car is not a lab bench. Temperature, pressure, and vibration can influence a sensor output. Mounting and contamination by fluid, dirt, and similar material can affect the sensor. That means the spec must say where the sensor lives and what it will experience. A pressure sensor in a hydraulic brake circuit has a different environment from an infrared tire temperature sensor looking at a tire surface. A suspension position sensor near moving arms and debris has a different exposure from a logger input inside the cockpit. A wheel-hub accelerometer has a different vibration and mounting problem from a body accelerometer.
The mounting statement is part of the sensor spec, not a later installation chore. If the mounting changes the physical quantity being measured, the sensor may be accurate and still produce bad data. The text is explicit that mounting and contamination can affect output. It also notes that accelerometers may be installed on the car body and, in some cases, in the wheel hubs. Those two locations do not ask the same question. A body accelerometer helps describe the sprung mass response. A wheel-hub accelerometer gets closer to unsprung response and road input, but it lives in a harsher environment. The specification has to say which response you need and which location can produce it.
The fourth sub-skill is choosing useful accuracy, not maximum accuracy. The data acquisition text makes a practical point: everyone wants the highest possible accuracy, but cost matters, and a sensor with more accuracy than the logger can record is not necessary. Signal conditioning and analog-to-digital conversion can add inaccuracy to a highly accurate sensor signal. In other words, a sensor is only one part of the measurement chain. The logged value is created by the sensor, conditioning, conversion, wiring, logger configuration, and analysis workflow. Paying for accuracy that disappears in the rest of the chain is not engineering. It is uncontrolled spending.
Use the decision you need to make as the accuracy test. If the channel is a vital-function alarm, the useful question may be whether the value is inside or outside a safe range. If the channel is a setup-development tool, the useful question may be whether a setup change created a meaningful offset, peak, or behavior change. If the channel is a model-parameter input, the useful question may be whether the value is accurate enough to support the simulation model. If the channel is driver-coaching data, the useful question may be whether the trace clearly distinguishes one braking, steering, or throttle behavior from another. In each case, accuracy is tied to a decision, not to a catalog superlative.
The fifth sub-skill is matching the sensor to the logger and system architecture. A physical parameter is captured by a sensor, transformed into an electronic signal, and stored by the data logging unit. The logger may communicate with a computer for download and configuration. A dashboard may display values but not store them. Engine ECUs may transfer engine-related sensor signals to an external logger. Additional input modules may be added over a network such as CAN. These architecture details shape the spec because the best physical sensor is not useful if the system cannot read it, store it, synchronize it, or expand around it.
This is why sensor selection cannot be separated from channel planning. The starter chassis and driver-performance system in the book records engine RPM, wheel speed, throttle position, steering angle, lateral acceleration, and longitudinal acceleration. Vital functions such as fluid pressures and temperatures and battery voltage should also be logged, and a beacon channel should identify lap beginning and end. Those six basic signals already give a large amount of data to analyze. The text then recommends extending toward suspension movement, brake line pressure, infrared tire temperatures, clutch pressure, gear position, each wheel speed, axle accelerations, vertical acceleration, tire pressures, ride height, suspension loads, brake disc temperatures, yaw speed, propshaft torque, aerodynamic pressures, gear lever force, and related channels as the questions become more sophisticated.
The lesson here is sequencing. You do not win by specifying the most elaborate sensor package on day one. The book says teams commonly start with the six basic channels and then extend the system step by step as they gain more experience in analysis. That is a design principle. A channel should be added when the current data creates a new question that the current sensor set cannot answer. Brake pressure, suspension movement, and infrared tire temperature are described as the next logical step after the basics. Future expansion also affects wiring harness, available memory, and other hardware, so a good sensor spec should include whether the channel is part of an immediate build or part of planned expansion.
A practical spec template has eight fields. First, write the analysis question. Second, write the measurand and physical category. Third, write the expected interval or range. Fourth, write the location and mounting concept. Fifth, write the environment: temperature, pressure, vibration, contamination, and motion exposure. Sixth, write the required accuracy in relation to the logger and decision. Seventh, write the electrical and system interface: logger input, signal conditioning, analog-to-digital conversion, CAN or module path, storage, and synchronization needs. Eighth, write the budget and expansion note. This template keeps you from confusing the sensor with the goal.
Now apply it to a channel: brake line pressure for driver and chassis analysis. The analysis question might be whether the driver is applying, releasing, and modulating the brake in a way that matches the car response. The measurand is hydraulic brake line pressure, a pressure measurement. The range must cover the expected braking interval for the car. The environment is the brake hydraulic system and nearby heat, vibration, fluid exposure, and mounting loads. The useful accuracy must be good enough to distinguish braking technique changes and correlate pressure to longitudinal acceleration and wheel speed behavior, without specifying more precision than the logger and conversion can preserve. The system interface must place the signal into the logger with lap timing so the trace can be compared across corners and laps.
Notice what is not in that spec: a vague desire for better brake data. The sensor is justified because it connects a driver activity channel to the vehicle response. If the car already logs longitudinal acceleration and wheel speed, brake pressure completes an important part of the story. If the car also logs steering angle and throttle position, you can see the transition from braking to turning to power. The book identifies brake pressure as a common next step after the basic six channels because it adds direct insight into driver input and chassis behavior.
Apply the template again to suspension movement. The analysis question might be whether the suspension is controlling load transfer and road input in a way that avoids unwanted fluctuations and supports grip. The measurand is displacement or position, typically shock absorber movement or suspension travel. The range must cover the expected movement without bottoming or topping the sensor. The environment includes vibration, suspension motion, contamination, and mounting constraints. The accuracy must be useful for comparing motion traces, setup effects, and operating behavior. The system interface must sample and record fast enough for the suspension events being studied, while recognizing the logger limitations mentioned in the book.
Suspension movement is a strong example because the book explains why operating-condition measurement matters. Spring rates and damper rates can be characterized in the lab, but the entire suspension system includes unknown parameters and nonlinear elements that can become too complex. Competition vehicles have nonconstant and nonlinear characteristics that are difficult to model, and a real circuit is the only place to record data for optimizing suspension settings. That does not mean every suspension answer is available from a sensor. Tire contact patch load on a rolling tire is described as impossible to measure because there is no sensor for it, and road actual position is difficult to measure accurately. Your sensor spec must respect both sides: measure what you can, and do not pretend the logged channel is the unmeasurable thing itself.
This is the measurement-chain mindset. A suspension position sensor does not measure grip. It measures movement. A suspension load strain gauge does not directly measure tire contact patch load. It measures strain in a selected element, which may support a load estimate if the system is understood and calibrated. An infrared tire temperature sensor does not measure the complete thermal state of the tire. It records surface temperature in its target area. Tire pressure monitoring supports safety and tire behavior analysis, but pressure is not vertical load. Each sensor gives a trace of a physical phenomenon; analysis turns related traces into a conclusion.
A good spec therefore includes the claim boundary. For brake pressure, you can claim driver brake input at the measured circuit. You cannot claim total tire force from that channel alone. For steering angle, you can claim steering input. You cannot claim front tire slip angle unless other assumptions and measurements support it. For longitudinal acceleration, you can claim vehicle acceleration at the sensor location and axis. You cannot claim brake balance without supporting channels. For suspension movement, you can claim the measured travel at the sensor installation. You cannot claim exact contact patch load. This boundary prevents overinterpreting clean-looking traces.
Calibration and verification should be part of the spec from the beginning. The data acquisition text describes comparing sensor readings to expected values during the pit-lane phase, calculating offsets as the average difference between the sensor reading and the reference value, and using alarms to spot readings outside the desired range. The example includes ride height, suspension movement, and tire load offsets, with setup-dependent constants that must be kept up to date after setup changes. That is a practical model for your own channels: define what the sensor should read in a known condition, define the tolerance, and decide what you will do if the offset is outside the range.
The pit-lane check also teaches a subtle point: expected values may change with setup and operating condition. If you compare ride height or suspension movement to old reference values after a setup change, you may flag a sensor that is actually correct. The text says reference constants are setup dependent and need to be current at every setup change. It also notes that checking readings on the in-lap may require tire information because tire stiffness properties are affected by temperature and pressure changes during the outing. Your spec should therefore say when and how the channel is checked. Out-lap and in-lap checks may not mean the same thing.
The calibration cue for a well-specified channel is not that the trace looks smooth. Smooth bad data is still bad data. The cue is that the channel behaves plausibly in known conditions, stays within expected offsets, captures the event without clipping, and changes in the direction the mechanism predicts when the driver or setup changes. Brake pressure should rise when the brake is applied and should align with longitudinal deceleration behavior. Steering angle should move with driver input. Suspension movement should respond to braking, cornering, acceleration, bumps, and setup changes. Ride height should compare sensibly to known references in the pit-lane condition. Tire pressure and temperature data should be interpreted with awareness that tire stiffness and thermal state change over a run.
A second calibration cue is analysis usefulness. The book warns that analysis often provides as many answers as new questions. That is normal. A useful channel should either answer the original question or expose the next specific measurement requirement. If a brake pressure trace shows that driver input differs between laps, you may next need wheel speed or brake temperature to separate driver behavior from hardware behavior. If suspension movement shows unexpected behavior, you may need additional position sensors, accelerometers, or load measurements. If tire temperature data does not explain a balance issue, you may need pressure, suspension, and driver-input context. The next channel should grow out of a specific gap.
There are four common failure modes in turning a measurand into a spec. The first is catalog-first selection. You choose a sensor because it is available, popular, or expensive, then retrofit a purpose around it. The cost is that you may record a precise version of the wrong thing. The correction is to write the analysis question and physical category before looking at part numbers.
The second failure mode is over-accuracy. You buy a sensor whose precision exceeds what the logger, signal conditioning, and analog-to-digital conversion can preserve. The cost is budget with no usable information gain. The correction is to specify useful accuracy at the logged-data level, not just the sensor-data-sheet level.
The third failure mode is range neglect. The sensor clips during the event or uses too little of its range in normal operation. The cost is lost detail exactly where the trace matters. The correction is to define the expected measurement interval from the actual use case and include both event peaks and reference-condition checks.
The fourth failure mode is environment blindness. The sensor is theoretically appropriate but mounted where vibration, temperature, pressure, dirt, fluid, or mechanical motion corrupts the output. The cost is data that cannot be trusted even though the sensor itself is not defective. The correction is to specify exposure and mounting as first-class requirements.
The fifth failure mode is analysis overreach. You treat an available channel as if it measures a more valuable hidden quantity. Suspension travel becomes grip. Brake pressure becomes tire force. Tire surface temperature becomes complete tire state. The cost is false confidence. The correction is to state the claim boundary in the spec and combine channels only when the mechanism supports the conclusion.
The sixth failure mode is expansion blindness. You choose a sensor and logger arrangement that works for the first build but leaves no clean path for the next question. The book warns that future signal count affects wiring harness, memory, and other hardware. The correction is to record whether a channel is part of the basic system, the next logical expansion, or a later development package, and to choose architecture with that path in mind.
The skill also has a stopping rule. If the measurand cannot be measured directly, do not pretend otherwise. The data acquisition text is clear that some crucial data, such as tire contact patch load on a rolling tire, is impossible to measure because no sensor exists for it, and other inputs, such as actual road position, are difficult to measure accurately. In those cases, you specify proxy channels and write down what they can and cannot prove. You might measure suspension movement, suspension loads, wheel speed, tire pressure, tire temperature, acceleration, and ride height to study behavior around the tire, but you should not label any one of those channels as direct rolling contact patch load.
The final product of this lesson is a one-page sensor specification. It should be readable by the person buying the sensor, the person wiring it, the person mounting it, and the person analyzing the logged data. If those people would choose different hardware after reading your spec, the spec is incomplete. A good spec narrows the choices before the catalog opens. It says what physical parameter matters, why it matters, what interval it must cover, what environment it must survive, what accuracy is useful, what the logger can record, how it will be checked, and what decision it supports.
Use the following working rule at the car: no channel earns a connector until it earns a sentence. The sentence is: We need to measure this physical quantity, over this interval, at this location, in this environment, to answer this question, with this level of useful accuracy. If you cannot fill that sentence, you are not ready to choose the sensor. If you can fill it, the data sheet becomes a tool instead of a trap.
Worked example: specifying brake line pressure after the basic six channels
Assume the car already logs engine RPM, wheel speed, throttle position, steering angle, lateral acceleration, and longitudinal acceleration. That is the basic chassis and driver-performance set described in the data acquisition text, and it already gives a large amount of information. After several events, the next question is braking consistency. The driver reports that the car feels different at corner entry from lap to lap, but the existing channels cannot separate driver brake input from vehicle response.
The analysis question is: how does the driver apply and release the brake, and how does that input relate to longitudinal acceleration and wheel speed behavior? The measurand is brake line pressure. The physical category is pressure. The range must cover the expected hydraulic pressure interval in the measured line without clipping. The environment is a brake hydraulic circuit and nearby race-car heat, vibration, fluid exposure, and mounting stress. The useful accuracy is the accuracy needed to distinguish application, peak, release, and modulation patterns in the logged trace, while recognizing that signal conditioning and analog-to-digital conversion may limit the recorded result. The interface requirement is that the channel must be synchronized with lap timing, wheel speed, throttle, steering, and acceleration traces.
The first calibration check is a known-condition check. In the pit or pit-lane phase, the channel should show a plausible low value with no pedal force and a repeatable increase under a controlled pedal application. During analysis, the channel should align with the driver event: pressure rises when the driver brakes, longitudinal acceleration responds, and wheel speed behavior gives context. If the pressure trace shows clipping at peak braking, the range is wrong. If the trace is noisy or offset in a known condition, inspect mounting, wiring, conditioning, and reference values before using it to coach the driver.
This channel is justified because it adds driver-command information that the basic system lacks. It does not, by itself, measure tire force or brake balance. It tells you what pressure existed at the measured line. The useful conclusion comes from overlaying that trace with longitudinal acceleration, wheel speed, steering angle, throttle position, and lap timing.
Worked example: specifying suspension movement for setup development
Now assume the question is no longer driver braking input. The team is developing setup and wants to understand how the car moves under racing conditions. The data acquisition text explains that spring and damper rates can be measured in the laboratory, but the full suspension system includes unknown parameters and nonlinear elements. It also says a real circuit is the only place to record data for optimizing suspension settings. That is enough to justify suspension movement channels when the setup question is specific.
The analysis question is: how much does the suspension move in the operating conditions that matter, and how does that movement change with setup? The measurand is shock absorber or suspension movement. The physical category is displacement or position. The range must cover expected bump, rebound, heave, pitch, and roll-related movement without the sensor reaching its limit. The mounting must track the intended suspension motion without binding, flexing, or being contaminated by dirt and fluid. The environment includes vibration, road input, temperature, moving parts, and debris. The useful accuracy must support comparison between runs and setup changes, while the logger must have adequate resolution and frequency for the events being studied.
The calibration plan should include a reference check. The book describes comparing sensor readings against expected values in pit-lane conditions and calculating offsets. For suspension movement and ride height, those references are setup dependent. That means the spec should require updated reference constants after setup changes. If the car comes back in after laps, tire temperature and pressure may affect tire stiffness and therefore the interpretation of ride-height-related checks. The spec should distinguish an out-lap check from an in-lap check.
The claim boundary is critical. Suspension movement data can show measured travel and can support setup analysis. It does not directly measure tire contact patch load. The text states that crucial data such as tire contact patch load on a rolling tire is impossible to measure because there is no sensor for it. If you need to reason about the tire, suspension movement is one input among others, not the hidden truth itself.
Drill: write three sensor specs before the next event
Before your next event, choose three candidate channels: one driver-activity channel, one vehicle-development channel, and one vital-function or safety channel. Use brake line pressure, suspension movement, and battery voltage or tire pressure if those fit your car. Spend 20 minutes per channel and write the eight fields: analysis question, measurand and category, expected interval, location and mounting concept, environment, useful accuracy, electrical and logger interface, and budget or expansion note.
At the event, do not judge the drill by whether the sensor is installed. Judge it by whether the spec changes your buying or mounting decision. A successful first session produces three sentences in this form: We need to measure this physical quantity, over this interval, at this location, in this environment, to answer this question, with this level of useful accuracy. A successful second session adds a known-condition check for each channel. A successful third session identifies one claim boundary for each channel, such as brake pressure not being tire force or suspension movement not being rolling contact patch load.
The pass standard is practical. Another competent person should be able to read each spec and understand what sensor family to consider, what logger compatibility matters, where the sensor would live, how it would be checked, and what analysis decision it supports. If they still have to ask what you are really trying to measure, the measurand is not specific enough.
Common mistakes
Catalog-first selection is the mistake of choosing hardware before defining the measurement. Good looks like a written analysis question and measurand before part numbers appear.
Range guessing is the mistake of selecting a sensor interval without thinking through the expected operating event. Good looks like a range that captures the event and still gives useful detail around the reference values you will check.
Accuracy shopping is the mistake of buying more sensor accuracy than the logger and signal chain can preserve. Good looks like useful accuracy defined at the logged-data level, with signal conditioning and analog-to-digital conversion included in the thinking.
Mounting afterthought is the mistake of treating installation as separate from specification. Good looks like a sensor location and mounting concept written into the spec, with temperature, pressure, vibration, fluid, dirt, and motion exposure considered.
Proxy confusion is the mistake of naming a channel after the thing you wish it measured instead of the physical phenomenon it actually measures. Good looks like clear claim boundaries: pressure is pressure, displacement is displacement, acceleration is acceleration, and inferred conclusions require supporting channels.
Expansion blindness is the mistake of designing the first channel without considering wiring, memory, and future hardware. Good looks like a staged plan: basic channels first, then logical additions such as brake pressure, suspension movement, and infrared tire temperature when the analysis need is real.
Cross-references to related lessons
This lesson feeds directly into sensor mounting. Once the measurand and environment are defined, the mounting lesson should decide how to install the sensor so the logged signal still represents the intended physical parameter. It also feeds the channel-budget lesson. Once the sensor spec defines purpose, range, accuracy, logger interface, memory needs, and future expansion, the channel budget can decide whether the whole acquisition system answers the question without exceeding hardware limits.
Keep the scopes separate. This lesson decides what the channel must measure and why. The mounting lesson decides how to physically preserve that measurement. The channel-budget lesson decides whether the logger, inputs, memory, frequency, and expansion path support the full set of channels.
Author Review
No quiz questions are attached to this lesson.
Sources
| # | Document | Chunk | Pages | Score | Collection |
|---|---|---|---|---|---|
| 1 | Analysis Techniques for Racecar Data Acquisition | 0d7a69c2-87d1-3729-2d89-48e20e0b7ffe | 23 | 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 | Analysis Techniques for Racecar Data Acquisition (Jorge Sergers) | a8a47256bff4e7cb8f6984f220ae7701 | 4 | 1 | uio_books_raw_v1 |
| 5 | Analysis Techniques for Racecar Data Acquisition | 99fdf750-f23e-0611-c169-ea0a4763a55c | 5 | 1 | uio_books_raw_v1 |
| 6 | Analysis Techniques for Racecar Data Acquisition | f725bafe-8b10-b36a-5b91-3395a519319d | 16 | 1 | uio_books_raw_v1 |
| 7 | Analysis Techniques for Racecar Data Acquisition | 8813a25c-567e-26cc-7633-6e4ed19d1882 | 7 | 1 | uio_books_raw_v1 |
| 8 | Analysis Techniques for Racecar Data Acquisition | 1bce2031-76a1-b6db-c919-403af4bc66fc | 5 | 1 | uio_books_raw_v1 |