Vehicle data logging sounds straightforward until you are knee-deep in it. Then you realize the hard part is not capturing numbers, it is capturing the right numbers, at the right time resolution, with enough context to make those numbers mean something later. The logs you collect today are the evidence you will rely on tomorrow, whether you are diagnosing a drivability issue, validating a software change, or proving that a safety behavior worked the way it was designed to.
I have seen teams win and teams flail, and the difference is usually the same: they start by logging “everything,” and then discover that the data is either too noisy to trust, too sparse to diagnose, or too unstructured to use. Good logging starts with intent. What decision are you trying to make, and what measurements would allow you to make that decision without guesswork?
Below is a practical way to think about trackable vehicle data, what to measure, why it matters, and how to avoid common traps.
Start with the question behind the log
Before choosing signals, decide what you will do with the log. A log for warranty debugging has different priorities than a log for endurance testing. The measurements that help you decide “what changed” are not always the same as the measurements that help you decide “what will fail.”
Here are a few examples of real-world questions teams run into:
A steering controller update causes occasional oscillation at highway speeds. You need enough detail to correlate driver inputs, vehicle response, and control outputs.
A fleet vehicle shows high fuel consumption on certain routes. You need energy-related metrics, not just speed traces, and you need road and traffic context if you want to separate driver behavior from system behavior.
A new safety feature triggers too often in the field. You need event-based signals, timestamps, and the logic inputs that caused the event.
When you map your logging to the decision, the signal list becomes clearer. You are no longer trying to “record the world,” you are gathering evidence.
Think in layers: telemetry, context, and interpretation
A useful vehicle log has three layers.
Telemetry is the raw state and sensor data, like speed, brake pressure, wheel speeds, accelerations, battery voltage, temperatures, and actuator commands.
Context is the metadata and environment that explain why those signals look the way they do, like gear selection mode, drive mode, software version, route identifier, ambient conditions, and quality flags.
Interpretation is what you derive or compute so the data becomes actionable. Examples include delta between commanded and measured torque, slip ratio, event classification, or energy per distance.
If you only log telemetry, you will often have to reconstruct context later, which is rarely possible. If you only log context without telemetry, you will have no proof. If you log everything without interpretation, you will drown in data and spend days writing scripts instead of solving problems.
A simple rule that saves time: log what you can measure reliably, and log the inputs to your interpretations. That way your derived metrics can be audited.
The “always include” signals for most tracking
Every vehicle project has exceptions, but there is a core set of signals that usually earns its place in almost any logging plan. The key is to cover the basics of motion, control intent, and system health. Missing one of these can turn a diagnostic session into a guessing game.
Here is a compact set of what I consider “always include” for trackable logging on most road vehicles.
- Vehicle speed (and if possible, multiple references like wheel speed and GPS speed) Throttle and brake demand or pedal position, plus brake pressure if available Gear state, drive mode, and propulsion mode (for example, EV, hybrid, or blended) Actuator command signals relevant to the system under test (torque request, steering angle command, shift command) Basic health signals: system voltage, major temperatures, and fault or warning indicators
Even if your project is focused on one subsystem, these signals help you normalize behavior. If speed is wrong, many conclusions collapse. If faults are not visible, you will waste time analyzing a system while it is actively degraded.
Motion and kinematics: the foundation of correlation
Most issues in vehicle control trace back to “the system did not respond like we expected.” The fastest way to confirm or refute that is by capturing kinematics with enough fidelity.
Speed and its cousins
Vehicle speed is more complex than it sounds. Many platforms expose at least two useful speed references: wheel-derived speed and GPS speed. Wheel speed is often more stable indoors and at low speed, while GPS speed can capture changes independent of wheel slip. If your use case involves low traction, off-road, or aggressive maneuvers, slip can make wheel speed misleading.
A practical approach is to log both wheel speed and GPS speed when you can, then record a “reference selection” rule in the log metadata. If you do not choose a reference, your post-processing will choose one inconsistently.
Acceleration and jerk
Longitudinal and lateral acceleration are where you start seeing the physical outcome of control decisions. If you are debugging traction control or stability behavior, you need acceleration at a high enough rate to capture transients. Many teams log acceleration at rates that are too low, and the result looks smoothed and unhelpful. You do not need lab-grade data acquisition for every project, but you do need to resolve the time scale of the behavior.
Jerk can also be valuable. High jerk often indicates abrupt actuation or control oscillation, and jerk can help distinguish “soft response” problems from “sharp transition” problems.
Steering angles and yaw
If your vehicle dynamics are in scope, steering angle alone is not always enough. Yaw rate (yaw gyro) is often the best “truth” signal for how the vehicle actually rotates. Steering input, yaw rate response, and lateral acceleration together let you evaluate whether a control strategy is tracking, overshooting, or lagging.
Log steering angle measurement quality flags if your system provides them. When the signal is noisy or saturated, it will distort any derived “response metrics” you compute later.
Inputs versus commands versus feedback
One of the biggest logging mistakes is failing to separate driver intent, controller demand, and measured response.
A driver presses the accelerator. That is an input. The powertrain controller turns it into a torque request. That is a command. Then the engine, motor, or hydraulic system produces an actual torque. That is feedback.
When a control issue occurs, the fix depends on which link is wrong.
- If input looks wrong, you might have a pedal calibration or driver behavior issue. If command looks wrong, you might have a logic or tuning issue in the controller. If feedback looks wrong, you might have an actuator limitation, sensor fault, or mechanical degradation.
To avoid ambiguity, log all three where possible: pedal or demand signals, actuator command signals, and the measured states those commands are supposed to influence.
Subsystem-specific measurements that pay off
Once you have a baseline, the most valuable measurements depend on what you are tracking. Below are common subsystem categories and the signals that tend to reveal the story.
Drivetrain and torque management
If your work touches propulsion, torque management deserves careful logging.
What typically matters:
Torque request versus torque output, especially around transients when delays show up.
Wheel speed and slip indicators. Slip ratio is very informative for traction control. It is also very sensitive to how you define and filter the speeds, so log wheel speeds and your computation inputs.
Clutch or shift-related states for transmissions. If you are analyzing shift quality, the “gear” state is not enough. Log shift command, clutch pressure if applicable, and relevant solenoid or actuator commands.
Thermal states. Propulsion torque limits often correlate with temperature in ways that look random unless you capture temperatures close to the limiting components.
Brakes and stability control
Brake logging is where many teams discover they either did not log the right hydraulic signals or logged them at too low a rate.
For braking, capture brake pedal input and brake pressure (or brake command, depending on what your system provides). Then include wheel speed and at least one stability indicator, such as yaw rate or lateral acceleration. For ABS or traction interventions, log the intervention flags and the relevant control commands, like brake modulation signals or traction control torque adjustments.
Stability issues often appear as mismatches between commanded yaw behavior and actual yaw response. Logging both controller outputs and physical response makes pattern recognition much faster.
Steering and path tracking
For steering control problems, log measured steering angle, steering wheel angle if it exists, steering actuator states, and any intermediate controller outputs. Yaw rate and lateral acceleration help you separate “controller fault” from “vehicle response limitation.”
If your vehicle includes an advanced driver assistance or automated steering feature, log the mode transitions. Many failures happen during the first second after mode change, when gains and filters change.
Battery and energy flow (EV and hybrids)
For electrified vehicles, energy accounting is often the goal, but energy metrics can only be trusted if you understand the signal chain.
Capture:
Battery voltage and current at sufficient sampling rate to resolve current transients.
Motor torque commands and motor speed.
Inverter temperature or power electronics temperature if available.
State of charge or equivalent estimation outputs.
Also log power limits and thermal derating flags. Otherwise, later you will wonder why commanded power tracking a vehicle looks high while actual power is capped. The derating state explains that mismatch.
If you only log battery state of charge and skip current, you can still estimate long-term trends, but you cannot diagnose why a specific event happened.
Sampling rate and time alignment: where “more data” becomes “less useful”
Logging does not fail only because of missing signals. It also fails due to timing issues.
Two common timing pitfalls are:
Signals sampled at different rates and then aligned incorrectly, creating fake phase shifts.
Event timestamps recorded late or derived from the wrong clock domain.
A vehicle often has multiple clock sources, especially when mixing controller logs with sensor streams. The remedy is not just “sync clocks,” it is to ensure each log frame carries enough information to align streams later.
In practice, I look for these properties:
Every sample has a timestamp in a common time base, or the log includes conversion metadata.
Event markers reference the same time base as the signals.
If resampling is done during logging, the method is documented in the metadata.
Rate selection by behavior time scale
Sampling rate should match the fastest behavior you care about.
If you are diagnosing slow thermal limiting, high sampling rate does not buy much. If you are diagnosing brake modulation, control oscillation, or traction intervention, low sampling rate can hide the key transition.
A useful judgment approach is to think in terms of time windows you will analyze later. If you know you will zoom into a 200 ms window around an event, you need enough samples across that 200 ms window to see the shape of signals. If you sample too slowly, the signal shape becomes a set of points with no real dynamics.
Derived metrics: log inputs, not just outputs
Derived metrics are what make logs useful. But derived metrics can also become a trap. If you derive from filtered or reconstructed signals you do not archive properly, you can lose auditability.
A good example is slip ratio. You can compute it from wheel speed sensors. If you log wheel speeds and your wheel radius assumptions, you can reproduce the calculation later. If you only log “slip ratio” after it has been filtered with unknown parameters, you will not be able to adjust filters when you discover the wrong wheel radius or a bad quality flag.
The same applies to more complex metrics like:
track vehicles softwareTraction utilization, defined from torque and normal load proxies
Energy per distance estimates
Cumulative brake energy or regen efficiency
So, log the raw inputs and the key intermediate values you use. Then it is possible to recompute derived metrics when your assumptions evolve.
Events and annotations: the hidden multiplier
A raw stream is rarely enough. You need events.
An event is not just “something happened.” It is “something happened, and we know where in time it belongs, and we know why we care.” Events can be automatic, from fault detection, from mode changes, or from controller intervention flags. Events can also be manual, based on operator notes, track segments, or test phases.
If you can, record:
Mode transitions and feature enable states
Fault and warning indicators, including the moment they first appear
Intervention flags for traction, ABS, stability, or torque limiting
Test phase markers, such as “launch,” “constant speed,” “braking zone,” “cooldown”
I recommend treating event logging as a first-class feature, not a nice-to-have. In post-analysis, the fastest path to insight is often jumping from event to event, not scanning entire logs.
Data quality flags: don’t treat them like clutter
Some sensor values are intermittently invalid, saturated, delayed, or reconstructed. If you ignore quality flags, you risk drawing conclusions from a signal that is technically present but not trustworthy.
Common quality issues include:
IMU saturation during aggressive maneuvers
GPS dropouts during tunnels or underpasses
Temperature sensor lag during step changes
Wheel speed sensor dropouts at very low speed
When you log, store quality flags alongside the signal. If a wheel speed is invalid for 0.5 seconds, your slip ratio computation should reflect that and your interpretation should avoid using that interval.
This is one of those places where “more data” can be worse than “clean data.” A log with reliable flags and clear invalid intervals is easier to use than a log with no flags and a lot of quiet corruption.
Avoid the “log everything” trap with a pragmatic capture plan
Every team eventually faces a storage and bandwidth constraint. If you log at maximum rate for all sensors, you will either hit limits or accept compression that harms diagnostic resolution.
A pragmatic approach is to plan capture modes, such as:
Continuous logging at moderate rate for a limited signal set
Higher-rate burst logging triggered by specific events
Continuous low-rate logging for background health metrics, with event-based captures for fast dynamics
This does not have to be complex. Even a simple trigger for “intervention occurred” or “fault code set” can turn huge logs into manageable files.
If your system supports it, also track whether signals are present in the log for a given event. Missing data at the moment you need it is effectively worse than having no log at all.
Calibration, configuration, and versions: the part nobody wants to fix later
A log without configuration is like a photo without the camera settings. Software versions, parameter sets, and calibration data matter because behavior changes with them.
At minimum, include:
Software version identifiers for relevant controllers
Vehicle configuration fields like tire size, wheel radius, gear ratios, and mass model parameters if your computations depend on them
Drive mode and feature toggles
If your project involves repeated testing across days, include a test run identifier and operator identity if that is feasible. It sounds administrative, but it saves hours when someone asks, “Was this log from the car after the sensor replacement?”
A short checklist for validating a logging setup
Before a field test, do a quick sanity pass on your logging setup. This is not about perfection, it is about avoiding obvious traps that create weeks of rework.
- Verify timestamps and event markers align across streams by checking a known trigger, like brake pedal press Confirm every required signal is present during the intervals you care about, including around faults or interventions Check units and scaling, especially for torque, pressure, and temperature Inspect a sample log for quality flags and confirm invalid segments are handled in your derived metrics Make sure derived metrics can be reproduced using logged raw inputs and documented assumptions
I have never regretted spending an hour here. I have regretted skipping it more times than I can count.
What to measure when the goal is root-cause diagnosis
Root-cause diagnosis has a specific measurement pattern: you want enough redundancy to distinguish possibilities.
For many control problems, you need at least one signal that represents intent, one that represents actuator command, and one that represents physical response. If you only log intent and physical response, you cannot tell whether the controller computed something incorrectly or whether the actuator failed to follow the controller.
If your log includes actuator commands but not physical feedback, you might still diagnose command computation errors, but actuator failures become harder to prove. The same logic applies in reverse.
This redundancy is why I prefer logging actuator commands whenever feasible. They often act like the missing link between “what the driver asked for” and “what happened.”
Common edge cases that break interpretation
Even well-planned logging can fail in predictable ways.
One edge case is “mode coupling.” Many vehicles change control gains based on mode, like traction control levels, steering assist states, or transmission shift strategies. If you do not log those mode states, you may mistakenly treat different behavior as anomalies rather than normal mode-dependent behavior.
Another edge case is “limiter dominance.” When torque limits or thermal derating kick in, many control loops stop behaving like you expect. Logging the limit state explains why commanded signals diverge from achieved behavior. Without it, you will chase the wrong subsystem.
A third edge case is “sensor latency.” Some sensors or computed values are delayed. If you compare them naively, you can infer incorrect causality. Quality and timestamp metadata help you spot latency effects, and for some signals you may need to explicitly account for delay in derived metrics.
How to use logs without becoming dependent on tooling
The best logs survive beyond the first analysis toolchain. Tooling changes. Scripts break. Engineers move on.
To keep logs reusable:
Use clear signal naming and consistent units.
Store metadata that tells you what the data means, like scaling factors and sensor definitions.
Keep the mapping between raw signals and derived metrics.
A log folder with files that can be understood a year later is worth more than a log that only one person can parse. The cost of structured logging is small compared to the cost of losing context.
Choosing between high fidelity and operational practicality
There is a trade-off between the resolution you want and the operational overhead you accept.
High sampling rate and many sensors can be expensive. It increases bandwidth, storage, and sometimes even wiring complexity. Meanwhile, operational testing often needs logging that is quick to start, stable in the field, and tolerant of sensor dropout.
If you are running a track day test plan, the operational constraints are real. People forget to secure SD cards. Temperature changes affect electronics. Vibration loosens connectors. That is why I favor logging strategies that are robust, event-driven, and tolerant of missing optional signals.
High fidelity helps when diagnosing fast dynamics, but operational reliability helps you actually capture the evidence when it matters.
A better mental model: measure decisions, not just systems
The most useful logging is not a shopping list of sensors. It is evidence that supports the decisions you care about: “Did the controller do what it should?” “Did the actuator follow commands?” “Was the physical response within expectation?” “Was a safety or thermal limiter involved?”
When you log with that mindset, you naturally pick signals that connect the chain of causality, you preserve enough context to interpret them, and you avoid drowning in unusable data.
Track vehicle data logging is part engineering, part discipline. The technical choices, signal-by-signal, determine whether your next investigation starts with clarity or confusion. Spend time on the choices upfront, log what you can trust, and make sure the timeline is coherent. That is where the real value lives.