Sample fast enough to trust the signal

Generated from content/lms/telemetry-systems-engineering/02-sampling-and-anti-aliasing/01-nyquist-in-practice.md; edit the source file, not this page.

Source path: content/lms/telemetry-systems-engineering/02-sampling-and-anti-aliasing/01-nyquist-in-practice.md

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

Module: Sample fast enough without drowning in data

Estimated duration: 45 minutes

A logged channel is not automatically a usable signal. It is a series of stored numbers, and even a modest sampling rate turns one lap into a long list of numbers. Your job is not to collect the longest list. Your job is to collect numbers that still represent what the car and driver actually did, so the later analysis can support a decision instead of laundering a mistake through a graph.

That is the practical meaning of Nyquist in a track telemetry system. If a real signal changes faster than your logger is sampling it, the logger can produce a false lower-frequency shape. The data still looks like data. It may even look smooth and convincing. But it is not the event you meant to measure. The result is aliasing: a false representation created by sampling too slowly. In the race car data acquisition text, the example is a sine wave where the sampling frequency is lower than the frequency of the original wave. The logger produces another sine wave at a lower frequency, and that lower-frequency wave is the alias. The important lesson is not merely mathematical. The important lesson is that a wrong sampling choice can create a trace that looks interpretable while pointing you toward the wrong conclusion.

The clean rule is this: the sampling frequency must be greater than twice the highest frequency present in the signal you care about. If the signal contains a 20 Hz sine wave, the sample rate must be more than 40 Hz to digitize that sine wave without aliasing under the theorem. Greater than twice is the minimum principle in the bonded corpus. It is not a complete design recipe for every sensor installation, and this lesson will not pretend that it is. The sibling lesson on anti-aliasing filters and decimation chains is where the full signal-conditioning chain belongs. Here, your skill is narrower and earlier: before you trust a channel, you decide whether the channel was sampled fast enough for the question you are asking.

That decision starts with the analysis question, not with a menu in the logger software. A logging system for driver and chassis analysis commonly starts with engine RPM, wheel speed, throttle position, steering angle, lateral acceleration, and longitudinal acceleration. Those six basic signals already give the engineer a large amount of information. More advanced systems add brake pressure, damper position, ride height, tire temperatures and pressures, suspension loads, strain gages, and other channels. The temptation is to treat all of these as equal because they all arrive in the same file. They are not equal. A speed trace used to compare two laps around a track, a steering trace used to study input shape, a brake pressure trace used to inspect release timing, and a damper trace used to validate a suspension model are different measurement jobs. Each job has its own fastest meaningful feature, and the sample rate has to be chosen for that feature.

Use this working sequence. First, name the decision the channel must support. If you are analyzing gearing, the relevant set may include vehicle speed, engine RPM, throttle position, and gear ratio. If you are analyzing understeer or oversteer, the relevant set may include speed, throttle, front and rear lateral g, steering angle, and understeer angle. If you are analyzing wheel load, the relevant set may include speed plus lateral and longitudinal weight transfer. If you are building or validating a simulation model, the channel may be helping identify vehicle parameters under racing conditions rather than on the static car. The sampling-rate decision is tied to the decision path. A channel that is adequate for a broad lap summary may be inadequate for a fine-grained dynamic question.

Second, identify the fastest feature of the signal that matters to that decision. Do not ask only how often the channel changes in an average sense. Ask what part of the channel you are going to interpret. Are you looking for the shape of a driver input, the timing relationship between a driver input and vehicle response, the difference between two laps at the same point on the track, or a vehicle-dynamics feature that will feed a model? Nyquist is about the highest frequency encountered in the signal, not the average pace of the lap. If the part you care about is a fast transition, then the transition governs the minimum sampling choice.

Third, choose a sampling frequency greater than twice that highest meaningful frequency before you arrive at the track. The bonded corpus is explicit that before arriving at the track, sensors should be calibrated, the dashboard should be programmed, and the correct sampling frequencies should be set. Suspension potentiometers, strain gages, steering angle sensors, accelerometers, and brake pressure sensors should be zeroed when the car is on the setup pad. That instruction matters because sampling is not a paddock panic task. If you wait until the first download to discover that an important channel was sampled too slowly, the session may still be useful for driving notes, but that channel is compromised for the analysis question that needed the faster content.

Fourth, review the first data with a trust gate before you start drawing conclusions. Race data software can make logged numbers easier to reason about. It can show time plots, distance plots, X-Y graphs, histograms, and run charts. It can overlay laps, stretch the y-axis so small variations are easier to detect, and summarize large data sets into statistics. Those tools are powerful, but they cannot turn an aliased signal back into the real event. A cleaner-looking trace is not proof of a correct measurement. A graph axis that makes variation easier to see is a viewing choice, not a sampling fix. A statistic calculated from a bad representation is still a statistic of the bad representation.

The most practical place this shows up is comparative analysis. Most race car data analysis is comparative. You compare laps or runs to understand a setup change, a driver change, or a different condition. The book is clear that overlaying two traces as a function of distance is the useful way to compare the vehicle and driver at the same point on the track, while overlaying by time can mislead because events at the same time may occur at different locations. But distance overlay only solves the alignment problem. It does not solve the sampling problem. If the channel you are overlaying is aliased, you have accurately aligned a false trace. You can then make a very organized wrong decision.

So the skill is not just knowing the theorem. The skill is running a small engineering discipline around every channel you intend to trust. You decide what the channel is for. You choose a sampling rate that can represent the fastest part of that use. You set and zero the system before the event. You inspect the first traces with the suspicion that smoothness can be false. Then you use the software tools only after the signal earns your trust.

For an intermediate driver-engineer, this is a shift in mindset. In a novice workflow, you might download a session, open speed and throttle, and look for where the faster lap carries more speed. That is useful, and speed is often the first channel to compare because it contains the result that matters: more speed in the right place reduces lap time. But in a systems-engineering workflow, you add one question before the comparison: is this channel sampled fast enough for the event I am interpreting? If yes, proceed. If no, stop using that channel for that specific claim.

The difference between recorded and trustworthy matters because the basic six channels are often used together. Suppose throttle position is sampled adequately but lateral acceleration is not. You might see a clean throttle trace and a delayed or softened lateral-g response, then invent a chassis explanation for a relationship that was partly created by measurement. Suppose steering angle is under-sampled relative to the input detail you care about. You might accuse the driver of making a slower or smoother steering input than they actually made. Suppose brake pressure is sampled too slowly for the release shape you intend to study. You may miss the pressure contour that would have explained a longitudinal-g trace. The specific sensor examples come from the standard channel set, and the broader point comes from the aliasing mechanism: a false lower-frequency signal can masquerade as the thing you wanted to analyze.

A good sampling decision also respects the difference between trackside usefulness and later engineering use. The data acquisition text emphasizes that the engineer has limited time and must provide clear answers quickly. It also emphasizes that large data sets need to be reduced into something that makes sense through graphics or statistics. That does not mean you should collect shallow data because you need fast answers. It means you should decide the sampling plan early enough that fast analysis later is based on solid measurement. Trackside pressure makes a bad signal more dangerous, not less, because everyone wants an answer while the car is still hot.

There are four calibration cues that tell you the sampling discipline is improving. The first cue is pre-event completeness. Before the car rolls, you can point to each important channel and say what conclusion it supports and what sampling setting was chosen for that use. The second cue is setup-pad hygiene. The channels that need zeroing are zeroed before the track session, so you are not mixing sampling uncertainty with calibration uncertainty. The third cue is first-session skepticism. You examine whether important traces have plausible shape before using them in overlays, run charts, or setup decisions. The fourth cue is analysis restraint. When a channel is not trustworthy for a question, you refuse to use it for that question even if the graph would make a tidy story.

Failure looks different from a broken sensor. A broken sensor may be obvious. An aliased channel may be persuasive. It may produce a lower-frequency shape that looks stable. It may overlay neatly. It may generate repeatable statistics. The cost is that your conclusion becomes detached from the real car. You may tune a suspension model against a signal that did not capture the dynamic behavior. You may compare two laps and attribute a difference to the driver when the channel could not represent the timing detail. You may think a driver input is smoother than it was, or a chassis response slower than it was, because the logger has already converted the fast content into a slower false representation.

When you suspect this has happened, your recovery is to narrow the claim. Do not throw away the whole session automatically. Use channels only for the level of interpretation they can support. A suspect high-detail steering trace may still coexist with a useful speed comparison. A brake pressure channel that cannot support release-shape analysis may still tell you broad pedal application timing if its sample rate is adequate for that broader question. But do not use a compromised channel to justify a precise conclusion. The honest sentence is: this channel was recorded, but it was not sampled fast enough for that claim.

The final habit is documentation. A good log of simulation runs and results is recommended for later reference, and the same discipline applies to sampling choices. Record which channels were used for which conclusions, which sampling choices were set, and which traces were excluded from precise interpretation. This makes later analysis faster and protects the team from repeating the same mistake. The purpose of data acquisition is to reduce guesswork, not to give guesswork a more professional display.

Worked example: the 20 Hz sine-wave trap

Start with the cleanest possible example because it exposes the whole failure mode. The real signal is a sine wave at 20 Hz. The theorem says the sampling frequency must be greater than twice the highest frequency in the signal, so the sampling frequency must be more than 40 Hz. If you sample below the frequency content you need, the logger does not merely give you a rough-looking version of the same wave. It can produce a lower-frequency sine wave that was not the original signal. That lower-frequency trace is the alias.

Now translate that to a car. The exact waveform in the book is a sine wave, not a brake trace or a damper trace, so do not over-claim the example. The transferable lesson is the mechanism. If a channel contains faster content than the sample plan can represent, the stored channel may contain a false slower pattern. On the screen, that false slower pattern may look calm and usable. Your first defense is to know the fastest feature you care about before you accept the trace as evidence.

Worked example: speed overlay around the Nurburgring

The data acquisition text uses two overlaid laps around the Nurburgring to show why speed is often the first comparison channel. Speed contains the result, and an increase in speed in the right place reduces lap time. The same passage also makes the alignment rule clear: overlay laps by distance when you want to compare the vehicle and driver at the same point on the track. Overlaying by time can put different physical locations on top of one another as the laps diverge.

The sampling lesson is the trust gate before that comparison. You can do the distance overlay correctly and still be wrong if the speed channel was not sampled fast enough for the part of the trace you are interpreting. If your claim is broad, such as where one lap is generally faster along a section, the channel may support it. If your claim is fine, such as the exact shape of a short acceleration or deceleration event, you need to know that the sampling plan can represent that feature. The overlay answers where the cars are being compared. Nyquist discipline answers whether the signal being compared deserves belief.

Worked example: suspension development and simulation validation

The corpus describes a team developing a semi-active hydraulic suspension system and measuring vehicle dynamic parameters to compare with a conventional suspension. It also describes using data acquisition to help build a virtual model of the race car, where some parameters are measured on the static vehicle and others should be measured under racing conditions. That is a high-consequence sampling problem because the logged data is not just for a pretty post-session chart. It can influence a model that will later be used to test setups outside the physically available adjustment range.

In that situation, a damper position, ride height, load, or acceleration channel needs a sampling plan matched to the dynamics being studied. If the channel aliases, the model-validation process can absorb a false behavior. The dangerous part is that the simulation workflow may still look disciplined: logged data, graphics, statistics, comparison, and a saved run log. The discipline is incomplete if the measurement chain cannot represent the real dynamic content. For suspension and model work, sampling trust is part of model trust.

Common mistakes

Mistake one is treating a recorded channel as a truthful channel. A data logger stores numbers. That is all. The meaning comes from correct measurement, correct sampling, and disciplined interpretation. Good looks like asking whether the stored numbers can represent the physical event before you use them for a decision.

Mistake two is treating twice the frequency as a comfortable target. The theorem stated in the corpus requires a sampling frequency greater than twice the highest frequency encountered in the signal. Good looks like remembering that the 20 Hz example needs more than 40 Hz, not a casual less-than-or-equal shortcut.

Mistake three is setting sampling frequencies at the track after the problem appears. The corpus says the correct sampling frequencies should be set before arriving at the track, along with sensor calibration and dashboard programming. Good looks like a pre-event channel plan, then zeroing the relevant sensors on the setup pad before the car runs.

Mistake four is believing display tools can rescue bad sampling. Stretching a graph axis can make signal variations easier to detect, and overlays can make comparisons easier, but neither recreates signal content that was never sampled correctly. Good looks like using display tools after the channel passes the sampling trust gate.

Mistake five is confusing alignment with validity. Distance overlay is the right way to compare laps at the same point on the track, and time overlay can mislead because events at the same time may happen at different locations. But distance overlay does not prove the sampled signal is valid. Good looks like handling both problems: align by distance, and trust only channels that were sampled fast enough for the claim.

Mistake six is letting the analysis question drift. If a channel was selected for broad trend analysis, do not quietly promote it to fine event-shape evidence just because the trace looks interesting. Good looks like matching the claim to the sampling plan and narrowing the conclusion when the plan does not support precision.

Drill: the three-session sampling trust audit

Run this at your next event with one car and one logger. The count is three on-track sessions plus the setup-pad check. The total analysis time is about 15 minutes before the first session, 10 minutes after session one, and 10 minutes after session two.

Before session one, choose six channels from the basic driver and chassis set: engine RPM, vehicle speed, throttle position, steering angle, lateral acceleration, and longitudinal acceleration. If your logger also has brake pressure or damper position, pick one of those as a seventh channel only if it supports a specific question. For each selected channel, write one sentence stating the decision it is supposed to support. Then confirm that the sampling frequency has been set before the car goes out and that any relevant sensors have been zeroed on the setup pad.

After session one, do not start with lap-time storytelling. Open the channels and inspect whether the traces are plausible for the questions you wrote. Use graph scaling to make variations easier to see, but treat scaling as a viewing aid only. Mark each channel green, yellow, or red. Green means usable for the stated claim. Yellow means usable only for a broader claim. Red means recorded but not trusted for that claim.

After session two, overlay two laps by distance and compare speed first, then inspect the supporting channels. The success criterion is not that every channel passes. The success criterion is that you can clearly state which conclusions are supported by the sampled data and which conclusions are being withheld. A strong result is a short written note that says, for example, speed comparison by distance is usable, throttle timing is usable, but a precise claim about a fast steering feature is withheld until the channel is sampled appropriately.

Cross-references and boundary of this lesson

This lesson stops at the sampling-rate trust decision. The next lesson on anti-aliasing filters and decimation chains belongs after this because filtering and decimation are part of preserving usable signals through the logging and processing chain. The sibling lesson on triggers belongs to a different problem: capturing the moments that matter. Triggers help decide when to record or mark events. Nyquist discipline helps decide whether the recorded samples can represent the event once you have it.

Keep those skills separate in your head. A trigger can capture the right moment with the wrong sampling rate. A filter chain can be well designed around a poor analysis question. A beautiful distance overlay can compare a false trace at the correct location. Reliable telemetry comes from stacking the disciplines in the right order: define the decision, sample fast enough to represent the signal, condition and process it correctly, then analyze it with graphics, statistics, and comparisons.

Author Review

No quiz questions are attached to this lesson.

Sources

#	Document	Chunk	Pages	Score	Collection
1	Analysis Techniques for Racecar Data Acquisition	b4008001-9c15-558e-68ee-a25ac1b520b9	23	1	uio_books_raw_v1
2	Analysis Techniques for Racecar Data Acquisition	ee1febf0-3036-dccb-706e-d9571ddc21f3	6	1	uio_books_raw_v1
3	Analysis Techniques for Racecar Data Acquisition	9998c72b-304d-0767-6517-dc3b82cea9fe	6	1	uio_books_raw_v1
4	Analysis Techniques for Racecar Data Acquisition	c98ed282-a588-c960-b906-3fddfbe88d4b	6	1	uio_books_raw_v1
5	Analysis Techniques for Racecar Data Acquisition	9b41b678-4787-363c-042e-2986a1b9565e	5	1	uio_books_raw_v1
6	Analysis Techniques for Racecar Data Acquisition	4669aec5-620e-051b-7b5d-a0a0380b73b0	7	1	uio_books_raw_v1
7	Analysis Techniques for Racecar Data Acquisition	298d8370-448d-3f4a-4164-cc740c02801e	7	1	uio_books_raw_v1
8	Analysis Techniques for Racecar Data Acquisition	fd0ef1e1-6820-b5e2-5654-97647e5ade5c	6	1	uio_books_raw_v1
9	Analysis Techniques for Racecar Data Acquisition	ad559d04-3651-61c2-d02b-5455aba0d7cc	7	1	uio_books_raw_v1
10	Analysis Techniques for Racecar Data Acquisition	41138569-fa56-a0a4-38c5-301475e4131a	21	1	uio_books_raw_v1
11	Analysis Techniques for Racecar Data Acquisition	1bce2031-76a1-b6db-c919-403af4bc66fc	5	1	uio_books_raw_v1
12	Analysis Techniques for Racecar Data Acquisition	c7269e48-7f37-7a57-0ca5-2c9a37a8f0bd	5	1	uio_books_raw_v1
13	Analysis Techniques for Racecar Data Acquisition	52e7d5ab-412b-acc5-fb49-cb0e8d5511b1	6	1	uio_books_raw_v1
14	Analysis Techniques for Racecar Data Acquisition	f2f9f82a-8a03-1e7d-6d85-1132b3f91b51	6	1	uio_books_raw_v1
15	Analysis Techniques for Racecar Data Acquisition	543dbdb3-ecd1-1086-a3db-1aac06db61ec	6	1	uio_books_raw_v1
16	Analysis Techniques for Racecar Data Acquisition	1d32f116-9b81-52c6-919d-dba1c542c011	5	1	uio_books_raw_v1