Evaluate smart sensors and CAN-FD before you rewire
Generated from
content/lms/telemetry-systems-engineering/08-emerging-technologies-and-future-trends/01-smart-sensors-and-can-fd.md; edit the source file, not this page.
Source path: content/lms/telemetry-systems-engineering/08-emerging-technologies-and-future-trends/01-smart-sensors-and-can-fd.md
Course: Design and validate the telemetry system that feeds every decision
Module: Look ahead to the next generation of telemetry
Estimated duration: 55 minutes
The skill in this lesson is not buying the newest sensor or the fastest bus. The skill is knowing when a telemetry system has outgrown its old measurement architecture, and then redesigning it without losing reliability, diagnosis, or interpretability. You are comparing three layers at the same time: the sensor, the network, and the logger software that turns all of it into usable evidence.
Start with the baseline. A conventional data acquisition system begins with a physical parameter: pressure, temperature, speed, force, position, acceleration, or another quantity you care about. A sensor converts that physical quantity into an electrical signal that the logging unit can understand. The logger stores the measured parameter in electronic memory, and an external computer communicates with the logger to download data and configure the system. That architecture is still the mental model you should carry, even when the hardware becomes more modern. The question is always the same: what physical quantity is being measured, where is it converted into data, where is it calibrated, where is it diagnosed, and how does it reach the log file?
Traditional analog sensors keep a lot of that burden outside the sensor. The sensor produces an electrical output, often proportional to the measured quantity. You provide the correct supply voltage when the sensor needs it, check the output with a meter or oscilloscope, and let the logger or ECU convert the signal into a digital value. That makes analog sensors transparent and serviceable. You can back-probe a terminal, check supply and ground, view a waveform, and decide whether the sensor or circuit is plausible. It also means the system depends on the quality of the analog wiring, the logger input, the calibration curve, and the diagnostic procedure you apply at the track.
A smart sensor moves part of that responsibility toward the measurement point. The corpus describes CAN data bus and smart gauges as a trend in which many data streams are multiplexed on simpler few-wire harnesses, with processing power at remote locations, either at distant nodes or at every individual sensor. In practical telemetry terms, the sensor is no longer only a variable resistor, voltage source, inductive pickup, or raw transducer. It may contain conditioning electronics, calibration data, a microcontroller, local diagnostics, a digital output, or multiple sensing elements in one package. That can make the system cleaner, lighter, and easier to expand, but it also means the logger and software must understand the device, the protocol, the scaling, the status fields, and the failure reporting.
The principle is this: upgrade when moving intelligence closer to the sensor or increasing bus capability solves a real measurement problem better than adding more analog channels and more wiring. Do not upgrade because digital sounds modern. Upgrade because your existing system is suffering from drift, wiring bulk, connector count, channel expansion limits, download and configuration friction, bus occupancy, or poor diagnostic visibility. The sources are clear that data systems have evolved around three pressures: memory for increasing numbers of sensors, the number of possible sensor inputs, and the speed at which data moves to and from the system. Smart sensors and CAN-FD both respond to those pressures, but at different points in the chain.
Smart sensors attack the measurement and wiring problem. MEMS technology allows miniature mechanical and electro-mechanical elements to be built with integrated circuits on a common silicon substrate. That permits multiple miniature sensors to be grouped in one measurement device, such as combined three-dimensional acceleration and gyroscope measurement. Surface acoustic wave sensor technology extends the idea further: a sensor can respond to temperature, pressure, displacement, acceleration, torque, or chemical composition, and some SAW sensors can be interrogated wirelessly and can operate without batteries. In a race telemetry design, that changes your architecture. A single inertial package may replace several separate channels. A wireless tire pressure system may avoid rotating wiring. A smart gauge or sensor node may output a scaled, digital value instead of forcing the logger to interpret a raw voltage.
CAN and CAN-FD attack the communication problem. Classical CAN is already a major step beyond point-to-point analog wiring because it lets ECUs, sensors, actuators, dashboards, input modules, and loggers share structured messages on a bus. It is a serial bus suited for networking intelligent devices as well as sensors and actuators. It has multi-master capability, so nodes can request use of the bus, and messages are prioritized by identifier rather than addressed like a normal computer network. All nodes may hear a broadcast message, but each node decides whether to process it based on the identifier. That message identifier defines content and priority, so urgent data wins access when two devices try to transmit at once.
Classical CAN also has hard practical boundaries. The bonded chunks state a maximum transmission rate of 1 Mbit/s and a message payload of 0 to 8 bytes of user information. Longer messages require segmentation, meaning the message is sliced into smaller parts. That is acceptable when the message set is modest, sample rates are appropriate, and the bus has margin. It becomes a design constraint when you are adding many channels, combining devices, carrying status and diagnostic fields, or trying to keep latency low. The lesson concept identifies CAN-FD as the redesign option with higher data rates and larger payloads compared with classical CAN. Because the bonded corpus does not include a CAN-FD standards section, you should not attach unsupported numeric CAN-FD limits here. The engineering decision is still clear: CAN-FD is relevant when the current CAN-family architecture is sound, but classical CAN message size or effective throughput has become the bottleneck.
The old analog answer to expansion is to add logger inputs, expansion boxes, and wiring. That can work. In many club systems, it is still the right answer. The more channels you add, though, the more you inherit every analog problem: supply checks, ground offsets, connector failures, induced noise, channel-by-channel calibration, and physical harness weight. Denton notes that many vehicles contain over a kilometre of wiring, and multiplexing reduces wiring, multi-plugs, and connectors while allowing existing systems to be upgraded or added without modifying the original system. Racecar data acquisition texts make the same practical point from the logger side: CAN communication links became popular replacements for serial or parallel links because of speed and easier addition of devices to the system.
The smart-sensor answer is to ask whether the sensor can deliver a better measurement package than the logger can create from raw analog. For a temperature channel on a short harness, maybe not. For a three-axis inertial measurement unit, tire pressure on a rotating wheel, combustion sensing, or a sensor that must report its own health, the answer may be yes. The corpus gives examples where direct measurement changes the quality of the control or diagnostic information. Ion sensing and cylinder pressure sensing are useful because they provide information about the actual combustion process, not merely an indirect symptom. Future systems are described as moving toward more direct measurement of exhaust gas composition and more sophisticated feedback to the ECU. The lesson for telemetry is not that every race car needs those specific sensors. The lesson is that better sensing often comes from measuring the physical process more directly and carrying the information digitally with enough context to trust it.
The trade-off is that smart sensors are not simpler in the absolute sense. They simplify the harness and the analog channel count, but they make the system more dependent on device firmware, protocol definitions, configuration tools, and logger support. Van Valkenburgh describes smart sensors and gauges as requiring processing power at remote locations and more sophisticated hardware and software, even if the system may be less expensive in the long run. That is the trade you must explain to a driver, team owner, or crew chief: fewer wires and richer data do not remove engineering work. They move the work from soldering, shielding, and analog calibration into network design, device configuration, software support, and diagnostic discipline.
You should evaluate the upgrade in five passes.
First, classify the channel. Ask what the channel is for. Is it a slow health channel, a driver display channel, a setup-analysis channel, a control input, or a post-incident channel? Convenience and body functions can live on slower networks in production vehicles, while real-time engine functions use faster networks. That split matters in a race system too. Oil temperature and fuel level do not need the same treatment as crank speed, brake pressure, steering angle, wheel speed, suspension displacement, yaw rate, or a crash-triggered high-g event. If a signal affects control, safety, or high-speed analysis, you give it more bandwidth, cleaner timing, and better diagnostics.
Second, decide where calibration should live. In an analog system, calibration often lives in the logger channel setup or ECU scaling. You still must verify the sensor against known standards and confirm the output signal. A smart sensor may carry calibration internally or output an already scaled digital value. That can reduce drift and setup error, but only if the logger applies the right protocol and units. You are not done when numbers appear on the dash. You are done when you can prove that the value, units, update rate, status bits, and failure behavior are correct.
Third, design the diagnostic path before the failure. Modern vehicle systems do self-diagnostic checks on sensors and actuators, storing fault codes when a component or circuit fault occurs. Component monitors can detect circuit faults and perform rationality tests against expected values. That is the mindset you want in telemetry. A channel should not only show a number. It should help you know whether the number deserves belief. A smart sensor may report internal status. A CAN node may disappear from the bus. A circuit may be open, shorted, out of range, or implausible. A good upgrade makes those states easier to detect and easier to explain.
Fourth, budget the bus. Classical CAN is not a magic pipe. Only one signal can be sent on the bus at one time, and message priority decides who wins arbitration. A low-priority stream can be delayed if higher-priority messages dominate. A large value set can consume repeated 8-byte frames. A longer message can require segmentation. CAN-FD is attractive when higher data rates and larger payloads reduce those pressures, but you still need a message plan. Decide which messages are high priority, which can be slower, which belong on another bus, and which should stay analog or local to a logger. You are designing a traffic pattern, not just selecting a wire.
Fifth, verify the hardware and software together. Race data systems are field equipment. Van Valkenburgh points out that general data recording equipment may not be adequate for vibration, noise, heat, cost, portability, and size restrictions, which is why dedicated race systems exist. A smart sensor that looks excellent on a bench can be a poor track choice if the connector is fragile, the logger cannot decode it, the software cannot display status, or the team cannot troubleshoot it between sessions. A CAN-FD-capable sensor is not useful if your logger, dash, wiring, termination, analysis software, and rule environment remain classical CAN only.
A good smart-sensor upgrade has a specific feel in the shop and at the track. In the shop, the channel list is shorter and cleaner because one device may provide several related measurements. The harness has fewer long analog runs and fewer connector pairs. Configuration is more deliberate: device address or identifier, scaling, update rate, status fields, logger decode, and display mapping are all written down. At the track, the driver and engineer see stable values, useful fault states, and fewer intermittent problems from vibration or connector movement. In the data, you see synchronized channels with no unexplained gaps, no obvious aliasing from a channel that was sampled too slowly for its job, and no suspicious step changes that look like scaling or status interpretation errors.
A poor upgrade looks modern but behaves vague. The dash shows numbers, but no one can say where the calibration lives. A status byte exists, but the analysis template hides it. A sensor reports digital values, but the team never checked them against a known reference. A CAN bus was expanded, but no one checked message priority or bus load. A CAN-FD device was added, but the logger records only a subset of its data. A traditional analog problem has simply been replaced by a digital interpretation problem.
Use the following technique when you plan a redesign.
Begin with an inventory table. For each existing channel, record the physical parameter, current sensor type, wiring route, logger input, sample rate, calibration location, known failure history, and who uses the value. Do the same for proposed channels. Mark each channel as keep analog, move to smart sensor, move to CAN-family device, or remove. Be strict. If a channel is not used for driver feedback, setup decisions, reliability decisions, diagnosis, or compliance, it should not drive the architecture.
Then identify clusters. Inertial channels belong together. Wheel and tire channels belong together. Engine health channels belong together. Suspension displacement, damper position, and tire-sidewall camera references may belong in a synchronized analysis workflow. A cluster is a candidate for a smart node or digital device because the values are related and timing matters between them. Grouping values at the device can reduce wiring and protect relationships between channels.
Next, map timing. Write down which channels must be available with low latency, which need high sample rate for analysis, which can be logged slowly, and which are event-triggered. A crash recorder reacting to a high-g trigger is a different design problem from a water temperature channel. A driver display fuel remaining estimate is different from a post-session suspension analysis trace. Timing decisions are what keep the bus from becoming a dumping ground.
After timing, map diagnostics. For every channel, decide what failed, disconnected, implausible, out-of-range, and degraded should look like. The OBD examples in the corpus are useful because they do not merely detect a number; they store a DTC, preserve operating context, and may use a safe substitute value for a short time. Race telemetry does not always need automotive OBD behavior, but it needs the same discipline. If an oil pressure sensor fails, the team should not need to guess whether the engine has lost pressure or the sensor has lost power. If a yaw sensor stops transmitting, the data should show that as a sensor or network fault, not as a magically steady car.
Only after that should you choose the bus. Classical CAN remains appropriate when the channel set fits within its rate, payload, and latency limits, and when the ecosystem of existing ECUs, dashboards, and loggers already supports it. CAN-FD becomes worth considering when the design remains message-based and distributed, but you need more payload per message or more throughput than classical CAN provides. If you cannot explain the current bottleneck in those terms, you are probably not ready to redesign the bus.
Finally, write a validation plan that uses both digital and physical evidence. For CAN, Denton describes checking signal integrity on CAN-high and CAN-low with a dual-channel scope, where one line should be a coincident mirror image of the other. That matters because a network problem is not always a software problem. For sensors, basic diagnosis still matters: verify supply where needed, verify output, compare against known standards, and use a scope when the waveform matters. For smart sensors, add protocol checks: correct identifiers, expected update rates, valid status, correct scaling, sensible units, and expected behavior when a sensor is unplugged or forced out of range.
You improve at this skill when your upgrades become boring in the right way. The first session after a redesign should not be a scavenger hunt. You should know which values are critical, which are advisory, which devices can fail gracefully, and how the logger will show that failure. You should see fewer harness-related intermittents, fewer calibration mysteries, and fewer post-session arguments about whether a trace is real. If a channel is wrong, the system should give you a path to diagnose it: physical layer, power and ground, sensor status, bus presence, message decode, scaling, and analysis template.
The main failure mode is over-centralized confidence. Digital data feels authoritative because it arrives as a clean number. Do not let that trick you. A raw analog voltage can be wrong, but a smart digital value can also be wrong if the sensor is misconfigured, the wrong decode is loaded, the wrong units are assumed, or the device is outside its operating environment. You still need physical checks and reference conditions. A pressure sensor should be checked against known pressure. A temperature sensor should be compared at known ambient and operating points. An inertial package should show expected static axes before you trust it on track.
The second failure mode is bus optimism. A network that worked with a dash and ECU may not be healthy after you add input modules, smart sensors, and high-rate channels. Classical CAN prioritizes messages, so the system may continue working while lower-priority data becomes late, sparse, or inconsistent. CAN-FD can give you more room, but it does not remove the need to classify messages and test the actual system. If the logger cannot record the new payloads or the analysis software cannot decode them, the extra bus capability has not helped the driver.
The third failure mode is forgetting the human workflow. A trackside system is used by people under time pressure. A smart sensor that requires a laptop, proprietary utility, undocumented address change, and fragile connector may be harder to live with than a simple analog sensor that can be checked with a meter. The right upgrade reduces total operational risk, not just schematic complexity.
Keep analog when it is the clearest truth path. A simple, accessible sensor with a stable output and known calibration may be easier to verify than a smart device whose internal behavior you cannot inspect. Keep classical CAN when the current bus has capacity, the messages fit, and the logger ecosystem is stable. Move to smart sensors when local processing, integrated calibration, self-diagnostics, multiple axes, or wireless measurement solve a real problem. Move to CAN-FD when a distributed digital architecture is still right, but classical CAN payload and throughput are the limiting constraints and the whole stack can support the change.
This lesson stops at smart sensors and CAN-FD as engineering choices. The next lesson on AI and machine learning should use the data after it is reliable. The rulebook lesson should decide whether higher bus speeds, wireless sensors, or certain sensor classes are legal in your series. Do not let future analysis or legality questions blur the present task. Your job here is to design a measurement system that produces trustworthy, diagnosable, adequately timed data with the least unnecessary wiring and the least operational confusion.
Worked example: replacing analog expansion with a CAN-family logger network
Imagine a club-race car that began with a dash, a logger, and a handful of analog inputs: RPM, water temperature, oil temperature, oil pressure, fuel pressure, speed, lateral acceleration, and a lap beacon. That layout is close to the example in the corpus where a display system measures several values but does not store them, then transfers measured signals over CAN to a recording module. More inputs can be added by placing input modules on the network.
The old way to grow this system is to keep adding analog wiring to the logger. That works until the harness becomes awkward, the logger input count becomes tight, or the team spends too much time chasing connector and calibration problems. The better intermediate step is not automatically CAN-FD. First you decide whether classical CAN can still carry the message set. If each new input module sends modest messages at sensible rates, classical CAN may be enough. You gain easier device addition, cleaner wiring, and better modularity without changing the whole stack.
Now suppose the team adds a smart inertial unit, four tire pressure sensors, damper channels, steering angle, brake pressure, throttle, lambda, and multiple status messages from the ECU. The design problem changes. You now have more devices, more message identifiers, more timing sensitivity, and more payload pressure. Classical CAN still sends only one message at a time, with priority controlled by identifiers, and each message carries only 0 to 8 bytes of user information. If the useful data now requires many segmented or frequent messages, the bus plan becomes the limiting factor. That is the moment to evaluate CAN-FD, provided the logger, dash, devices, wiring practice, and software all support it.
The success criterion is not that the car has a newer network. The success criterion is that the team can add channels without adding a mess, can diagnose a missing node quickly, can preserve timing for high-value channels, and can still explain every number in the analysis software.
Worked example: smart inertial and tire sensors without overtrusting them
A modern inertial package is a good candidate for smart sensing because MEMS technology can combine multiple miniature sensors and integrated circuits on a common substrate. The corpus gives the example of three-dimensional acceleration and gyroscope measurements in a single sensor. That is attractive in a race car because yaw, acceleration, and driver-line analysis depend on relationships between axes. Keeping those measurements together can help preserve timing and reduce wiring.
A tire pressure monitoring system based on SAW technology shows a different advantage. The corpus describes SAW sensors as sensitive, reliable, suitable for many applications, and able in some cases to be interrogated wirelessly and operate without batteries. For wheel-mounted measurements, that matters because rotating wiring is undesirable. A wireless, batteryless pressure sensor can solve a physical installation problem that a traditional analog channel cannot solve cleanly.
The trap is to treat smart output as automatically true. Before you use the inertial data for setup decisions, check the static axes, update rate, units, mounting orientation, and logger decode. Before you use wireless pressure data to make tire calls, check cold pressures against a known gauge, confirm the identifier for each wheel, and verify what the system reports when a sensor is absent or implausible. A smart sensor may reduce analog drift and wiring complexity, but it still needs a reference check and a failure check.
Common mistakes
The first mistake is upgrading the bus before diagnosing the measurement problem. If the real issue is a poor ground, bad connector, wrong calibration curve, or logger scaling error, CAN-FD will not fix it. Good looks like proving the existing failure mode first, then choosing the upgrade that removes that failure mode.
The second mistake is treating all channels as equal. A slow temperature value, a driver display value, a control-related value, and a high-rate analysis channel do not deserve the same sample rate, priority, or diagnostic behavior. Good looks like classifying every channel by use, timing, and consequence before you assign it to analog, smart sensor, classical CAN, or CAN-FD.
The third mistake is hiding diagnostics. A smart sensor that reports status is only useful if the logger records that status and the analysis template exposes it. Good looks like recording the value and the health information together, then testing unplugged, out-of-range, and implausible cases before the car leaves the shop.
The fourth mistake is assuming less wiring means less engineering. Multiplexing and smart sensors can reduce harness size and connector count, but the work moves into identifiers, configuration, decoding, update rates, and software support. Good looks like a written message map, device list, scaling table, and validation procedure.
The fifth mistake is ignoring physical-layer verification. CAN is digital, but it still lives on wires. Denton describes checking CAN-high and CAN-low as differential mirror-image signals on a scope. Good looks like checking the network electrically when there are bus faults, not only changing software settings.
The sixth mistake is buying isolated capability. A CAN-FD sensor or smart gauge is not an upgrade if the logger cannot record it, the dash cannot display it, or the analysis software cannot decode it. Good looks like verifying the whole chain: sensor, connector, power, bus, logger, display, download, analysis, and trackside diagnostic method.
Drill: the 90-minute smart-sensor and CAN-FD readiness audit
Do this drill before your next system redesign. It takes one focused work session in the shop and one verification pass at the next event.
For 30 minutes, build a channel inventory. Write every logged channel in a table with five fields: physical quantity, current sensor or source, wiring or bus path, calibration location, and who uses the data. Mark each channel as driver display, reliability, setup analysis, control support, compliance, or unused. Success means every channel has an owner and a reason to exist.
For the next 30 minutes, mark the failure behavior. For each channel, write what open circuit, short circuit, missing node, out-of-range, implausible, and wrong scaling would look like. If you cannot answer for a channel, that channel is not ready for a smart-sensor upgrade. Success means you know how the logger or dash will show a bad value before the value fails on track.
For the final 30 minutes, sketch the bus plan. Group related sensors, identify high-rate channels, identify low-rate health channels, and list any messages that may exceed classical CAN comfort because of payload size, update rate, or segmentation. Success means you can explain why each proposed smart sensor belongs on the network, why classical CAN is enough or not enough, and what hardware and software must change if CAN-FD is adopted.
At the next event, run one session as a validation session rather than a setup session. Confirm that all upgraded channels appear, update, and record. Check at least one known reference value, such as ambient temperature or cold tire pressure, and confirm that no high-value channels are missing from the log. Success means the data engineer can diagnose the system from the log and configuration notes without guessing.
When this principle breaks down
The smart-sensor and CAN-FD principle breaks down when the system around the upgrade is not ready. If the series rules do not allow the sensor class, wireless device, or bus speed, the correct engineering answer is to stay within the rulebook and cross-reference the rulebook lesson. If the logger hardware cannot receive CAN-FD, the software cannot decode it, or the team cannot support it trackside, the capability is theoretical.
It also breaks down when analog transparency is more valuable than digital integration. A simple sensor that can be checked with a meter and scoped directly may be the better choice for a low-rate, low-risk, easy-to-wire measurement. Smart sensing is strongest when it solves a real problem: multiple axes in one package, local calibration, better self-diagnosis, reduced rotating wiring, reduced harness mass, or a more direct measurement of the physical process.
Finally, it breaks down when you try to use better data transport to compensate for unclear data purpose. More payload and higher data rate do not make unused channels useful. A redesign should make the measurement system more truthful and more serviceable, not merely larger.
Author Review
No quiz questions are attached to this lesson.
Sources
| # | Document | Chunk | Pages | Score | Collection |
|---|---|---|---|---|---|
| 1 | Analysis Techniques for Racecar Data Acquisition (Jorge Sergers) | 0f48c3f3a33993585815267ec13a2181 | 4 | 1 | uio_books_raw_v1 |
| 2 | Analysis Techniques for Racecar Data Acquisition | 7f97400e-d711-1096-5734-8ace0078e432 | 23 | 1 | uio_books_raw_v1 |
| 3 | Race Car Engineering Mechanics Paul Van Valkenburgh | 71f57a54-2aaa-0836-1deb-cdccabb2b28e | 154 | 1 | uio_books_raw_v1 |
| 4 | Advanced Automotive Fault Diagnosis. Automotive Technology. Vehicle Maintenance and Repair Tom Denton | 93d01029-7de3-19c9-522e-230dd3833d98 | 267 | 1 | uio_books_raw_v1 |
| 5 | Advanced Automotive Fault Diagnosis. Automotive Technology. Vehicle Maintenance and Repair Tom Denton | 207c1692-51fc-b996-af3b-6638e15a047b | 270 | 1 | uio_books_raw_v1 |
| 6 | Advanced Automotive Fault Diagnosis. Automotive Technology. Vehicle Maintenance and Repair Tom Denton | 48522f33-6dce-3ab8-7617-27ad22dc6e06 | 268 | 1 | uio_books_raw_v1 |
| 7 | Advanced Automotive Fault Diagnosis. Automotive Technology. Vehicle Maintenance and Repair (Tom Denton) | 03c368556e6aa0486ea14718ab37d788 | 268 | 1 | uio_books_raw_v1 |
| 8 | Advanced Automotive Fault Diagnosis. Automotive Technology. Vehicle Maintenance and Repair Tom Denton | 6002b10d-c2d6-8aa4-3cdc-265951cf607b | 75 | 1 | uio_books_raw_v1 |
| 9 | Advanced Automotive Fault Diagnosis. Automotive Technology. Vehicle Maintenance and Repair Tom Denton | 468b0de6-ebef-c66a-e1dd-214ad999bb41 | 123 | 1 | uio_books_raw_v1 |
| 10 | Advanced Automotive Fault Diagnosis. Automotive Technology. Vehicle Maintenance and Repair Tom Denton | 6bb28e97-93ee-0b2e-2dcb-fb32f4b05a22 | 120 | 1 | uio_books_raw_v1 |
| 11 | Advanced Automotive Fault Diagnosis. Automotive Technology. Vehicle Maintenance and Repair Tom Denton | d2561923-2e22-85a0-a535-aced1902a77a | 273 | 1 | uio_books_raw_v1 |
| 12 | Analysis Techniques for Racecar Data Acquisition | 09b767d2-53d9-2fcf-cd5d-4ea326fc7e93 | 5 | 1 | uio_books_raw_v1 |
| 13 | Advanced Automotive Fault Diagnosis. Automotive Technology. Vehicle Maintenance and Repair Tom Denton | 35f80cef-a9c7-f887-6421-c065b0f9eef8 | 133 | 1 | uio_books_raw_v1 |
| 14 | Advanced Automotive Fault Diagnosis. Automotive Technology. Vehicle Maintenance and Repair Tom Denton | f5f4e2bf-0cf0-a6e4-6e58-0be3c3b4debb | 140 | 1 | uio_books_raw_v1 |
| 15 | Advanced Automotive Fault Diagnosis. Automotive Technology. Vehicle Maintenance and Repair Tom Denton | afc58169-87c0-f607-050d-48a53268a358 | 133 | 1 | uio_books_raw_v1 |
| 16 | Race Car Engineering Mechanics Paul Van Valkenburgh | 67c1f7f2-fefc-dfc7-2a97-14691fd14735 | 149 | 1 | uio_books_raw_v1 |