Mount sensors so the data is trustworthy
Generated from
content/lms/telemetry-systems-engineering/01-sensor-selection-and-placement/02-mounting-for-signal-integrity.md; edit the source file, not this page.
Source path: content/lms/telemetry-systems-engineering/01-sensor-selection-and-placement/02-mounting-for-signal-integrity.md
Course: Design and validate the telemetry system that feeds every decision
Module: Choose the right sensor for every signal
Estimated duration: 55 minutes
The first mounting rule is simple: mount the sensor on the physical thing whose motion, load, pressure, temperature, or state you are trying to know. That sounds obvious until the car starts moving. On a real circuit, the car is a stack of moving bodies. The chassis moves. The wheel hubs move differently. The dampers move between those bodies. The rotating shaft is its own moving system. The air around the car changes with speed, ride height, brake cooling, and body motion. A channel is trustworthy only when the mounting choice makes the logged signal belong to the question you are trying to answer.
This lesson is not about choosing every channel on the car. The sibling lessons cover turning a measurement need into a sensor specification and building a channel budget. Here the skill is narrower and more practical: you decide where the sensor belongs, what the mount allows you to believe, what it does not allow you to believe, and how to prove that the channel is good enough before you let it guide a setup decision.
For an intermediate driver or club engineer, the temptation is to think of mounting as fabrication. You make a bracket, tie the wire back, and start logging. That is not enough. The corpus is clear that race-car data analysis starts with asking exactly what you want to measure, that logged data is limited by the available sensors and the logging capabilities, and that some crucial quantities are difficult or impossible to measure directly on track. Mounting is therefore part of the measurement design. The bracket is only the last physical expression of a chain of choices.
A trustworthy mounting decision has five parts. First, state the physical quantity, not just the channel name. Wheel speed, suspension movement, brake line pressure, ride height, tire pressure, brake disc temperature, yaw speed, propshaft torque, and aerodynamic pressure are not interchangeable channel labels. Each describes a different physical location and a different reference body. Second, decide whether you need the quantity directly or whether an inferred quantity is acceptable. Tire contact patch load is the classic problem: the on-track rolling tire does not offer a direct sensor for that load, so the engineer works with wheel position, wheel load, body acceleration, known masses, and dynamics equations. Third, choose the mounting body. A chassis accelerometer does not tell the same story as a sensor on the wheel upright. A suspension potentiometer does not tell the same story as hub acceleration. A ride-height sensor does not tell the same story as a damper sensor. Fourth, match the mounting and the logged rate to the frequency content you care about. When hub acceleration is calculated from body acceleration plus suspension movement acceleration derived from position sensors, high-frequency data is impaired by the low sampling rates and sensor resolution of the position sensors. Fifth, record the limits of the channel before the first interpretation session. If you do not write down what the channel cannot prove, you will eventually use it to prove too much.
The practical mindset is to treat every sensor as a witness with a viewpoint. A witness bolted to the chassis can describe chassis motion. A witness mounted on the wheel upright can describe hub motion. A witness coupled to the damper can describe relative suspension movement. A witness on a rotating shaft needs a way to move signal and power across a rotating boundary. A witness aimed at the road with a laser ride-height sensor can help you understand ride height and aerodynamic balance, but it is still measuring within its own mounting geometry and logging limits. The skill is not to collect more witnesses. The skill is to put the right witness in the right place and keep its testimony inside its competence.
Start with the minimum data set, then extend it deliberately. A starter logging package for chassis and driver performance analysis commonly includes engine RPM, wheel speed, throttle position, steering angle, lateral acceleration, and longitudinal acceleration, with vital car functions and a lap beacon added so the data can be placed in time. That starter set already creates a large analysis load. The next logical extensions often include brake pressure, suspension movement, and infrared tire temperature. More advanced systems may add wheel-speed channels for each wheel, front and rear axle lateral acceleration, vertical acceleration, tire pressure, ride height, suspension loads with strain gauges, brake disc temperatures, yaw speed, propshaft torque, aerodynamic pressures, and gear-lever force. The mounting lesson inside that list is that every extension adds a physical promise. If you add suspension movement, you are promising that the sensor is mounted across the motion you actually care about. If you add brake pressure, you are promising that the sensor is reading the hydraulic line relevant to the braking question. If you add ride height, you are promising that the sensor location represents the aerodynamic or platform question you will later ask of it.
Do not confuse a longer channel list with better evidence. The source material warns that specific needs require specific channels and that the system should be extended step by step as experience grows. That matters for mounting because each new channel affects wiring harness planning, available memory, and other hardware. A channel can be technically present and still be untrustworthy if the car cannot log it at the needed resolution, if the harness plan forces a compromised location, or if the analysis question needs a signal the installed sensor cannot physically see. The right question before adding a sensor is not whether the logger has a spare input. It is whether the mounted sensor will see the right physical event clearly enough to answer the decision you are about to make.
The cleanest mounting examples come from suspension work because the car gives you several related but different physical signals. Competition vehicles often have nonconstant and nonlinear characteristics, and suspension systems include unknown parameters and nonlinear elements that are difficult to model. That is why measurements must be taken under operating conditions. Many race cars use position and load sensors in key suspension elements. Some install accelerometers not only on the car body but also in the wheel hubs. Each mounting choice makes a different kind of analysis possible. A body accelerometer is useful for body movement. A wheel-hub or wheel-upright accelerometer gets closer to the unsprung side of the system. Position sensors describe suspension movement. Load sensors in the suspension give wheel load, not tire contact patch load. If you mount those sensors and then pretend they all describe the same thing, the data will look scientific while the conclusion is weak.
Suspension analysis also shows why raw data alone is not trust. The source example uses an actual race car sampled at 100 Hz and shows 20 seconds of average vertical load, average ride height, body vertical acceleration, and reference speed in the time domain. The important lesson is that raw time-domain data does not provide much meaningful information about actual car behavior by itself. The mounting may be mechanically sound and the logger may be recording, but the channel is not yet a setup answer. To infer actual tire load, the measurements of wheel movement and force must be related to body movement using relevant suspension parameters and dynamics equations. Mounting gives you the ingredients; it does not remove the need to understand the model that connects those ingredients.
This is where an intermediate engineer needs discipline. If the sensor is mounted to measure wheel position, call it wheel position. If it is mounted to measure wheel load, call it wheel load. If the analysis estimates tire load from those signals, call that an estimate and preserve the assumptions. The source material explicitly distinguishes wheel load from tire contact patch load and notes that rolling-tire contact patch load is not directly measurable on track. That boundary is not a paperwork detail. It determines whether you can safely say the tire was unloaded or only that the measured suspension load changed in a way that suggests a tire-load change after calculation. Trustworthy data keeps direct measurements and inferred channels separate.
A similar boundary appears with accelerometers. A single three-axis accelerometer on the chassis can provide useful vertical modal information, but it is limited for broader suspension-rig-on-track analysis. If you need hub acceleration, the source gives two options: mount a specific sensor on the wheel upright, or calculate hub acceleration from body acceleration and suspension movement acceleration derived from position sensors. The second method can impair high-frequency data because the position sensors have low sampling rates in time and space. That is a mounting lesson with teeth. If your question lives in high-frequency wheel motion, do not expect a slow or low-resolution derived channel to behave like a direct upright-mounted accelerometer. The mount and the sample path decide what frequencies survive.
Sampling rate is not separate from mounting. The competition logging excerpt points to rates such as 250 Hz and 500 Hz where the system allows it, while the suspension example cites 100 Hz data from an actual race car. The lesson is not that one rate is universally correct. The lesson is that the mount, sensor, logger, and analysis question must be chosen as a package. If a sensor is placed to observe a fast event but the system logs too slowly, the signal can be neat and still miss the event. If a derived acceleration channel depends on position sensors whose time and space resolution are too low, the calculation can be mathematically tidy and still lose the high-frequency behavior. When you mount a sensor, write down the frequency band you expect it to support and verify that the logger can actually capture it.
Track data has its own limits. Logged data depends on available sensors, logging resolution and frequency, lap, circuit, and weather. On-circuit tests are expensive, especially when those limitations are present. That does not make track mounting pointless. It means you must know what kind of truth track mounting can provide. The circuit is the real operating environment, and for many vehicle-dynamics questions it is the only place where the car, road, driver, aero state, tire state, and transient inputs interact. But the circuit does not hand you every hidden variable. Road actual position is difficult to measure accurately. Rolling-tire contact patch load cannot be directly sensed. Your on-car mounting plan must therefore separate direct observation from inference and keep environmental dependence attached to the data.
The four-post rig provides the opposite teaching case. On the rig, the vehicle sits on four actuators under the wheels. The generated road input is controlled and recorded, and the resulting data can be analyzed in frequency terms. Rig testing can provide sensors for contact patch load, tire deflection, and controlled road input without lap or circuit dependency. It can be cost-effective. But the same source warns that static tire behavior is different from rolling tire behavior, car balance assessment is unreliable, and aerodynamic load simulation requires extra actuators while still failing to reproduce the interaction of aerodynamic forces with the suspension. So even a perfectly mounted rig sensor has a domain. Rig mounting can tell you some things that track mounting cannot, and track mounting can tell you some things the rig cannot reproduce. Trustworthy sensor work means knowing which world the sensor lives in.
A useful way to judge mounting is to ask whether the channel can survive being used in a decision. For suspension setup, the source lists goals such as minimizing energy absorbed by the vehicle, minimizing energy absorbed in the dampers, maintaining body movement within acceptable limits, maintaining vehicle height within acceptable aerodynamic limits, and avoiding tire load fluctuation that can lead to contact breakaway. Those are not small decisions. They may lead you to change dampers, springs, ride height, aero platform, or operating limits. Before you make such a decision, the sensor mount must earn the right to influence it. A body accelerometer alone should not be used as though it captured all wheel behavior. A wheel-position sensor should not be treated as direct tire contact patch load. A ride-height sensor should not be interpreted without remembering where it was aimed and what aerodynamic question it was meant to support.
Ride-height and aerodynamic sensors make this concrete. The source material identifies ride-height sensors, aerodynamic pressures through pitot tubes, and brake cooling effects on disc temperatures and aerodynamic performance. It also notes the use of laser ride-height sensors for dynamically and directly logging ride height. If your question is aerodynamic balance, you mount sensors where the car platform and airflow question exists, not wherever the bracket is convenient. Ride-height data can help check aerodynamic balance because the car's platform under speed is part of the aero system. Brake disc temperature can help evaluate brake cooling changes, and those cooling changes can have aerodynamic consequences. But the mounting plan has to keep the chain intact: ride height is not itself downforce, brake disc temperature is not itself aero drag, and pressure readings are not themselves a full balance map. They are mounted observations that become useful when interpreted with the right context.
Rotating torque sensors teach another boundary: sometimes the main mounting problem is signal transfer. A torque sensor based on strain-gauge application can log shaft torque while the shaft is in use, but the signal and power have to cross from the rotating shaft to the measurement electronics. The source describes two solutions. Slip rings provide physical contact, but their wear and packaging issues make them less common in motor racing applications. Wireless transfer through telemetry or magneto-elastic polarized band technology avoids that contact path. For the mounting decision, this means a rotating sensor is not just a sensor stuck to a shaft. It is a complete moving measurement system with power, signal transfer, packaging, and durability constraints. If any one of those pieces fails, the channel is not trustworthy even if the strain gauge itself is correct.
Synchronization also belongs in signal trust. The source recommends a beacon channel to identify the beginning and end of a lap, and it describes communication between engine-specific logging and an external chassis data acquisition unit so engine signals can be overlaid with lap timing. That matters because a perfectly mounted sensor can become misleading if its timing reference is poor or if separate systems cannot be compared correctly. Mounting for signal integrity therefore includes planning how the sensor channel will align with the rest of the car. If brake pressure, throttle, steering, wheel speed, and acceleration are not time-aligned, a driver-performance conclusion can be wrong even though each individual sensor was mounted well.
Before editing a car, use a mounting trust map. Write the decision you want to make at the top of the page. Then list the direct physical signals needed, the sensors that will observe them, the body each sensor will be mounted to, the logging rate and resolution expectation, and the inference chain. For a damper question, this might include suspension movement, wheel load, body vertical acceleration, reference speed, and perhaps hub acceleration if high-frequency wheel behavior matters. For an aero-platform question, it might include ride height, aerodynamic pressures, reference speed, and relevant temperature or cooling channels. For a torque question, it might include the torque sensor, its rotating signal transfer method, and the synchronization path to engine and chassis data. The goal is to make every future graph accountable to a mounting choice.
When the sensor is installed, perform a credibility pass before interpreting performance. Look first for whether the channel behaves like the mounted physical quantity should behave. A ride-height channel should relate to the part of the car and motion it is aimed at. A suspension movement channel should show relative movement across the suspension element. A wheel-upright accelerometer should show a different viewpoint than the chassis accelerometer. A brake pressure channel should align in time with braking events and driver inputs. Then look for whether the data can support the intended frequency content. If the question is high-frequency hub acceleration and the channel is derived from position sensors with limited sampling and resolution, treat the high-frequency conclusion as suspect. Finally, check whether the data is being interpreted inside its environment. A circuit lap is lap-, circuit-, and weather-dependent. A four-post result is controlled and repeatable but misses parts of rolling-tire and aero interaction.
Good mounting also protects you from over-analysis. The source says analysis often provides as many answers as new questions. That is normal. The mistake is to treat every new question as proof that the last sensor was wrong or that more channels are automatically needed. Sometimes the correct next step is to extend the system. Sometimes it is to improve the mounting reference. Sometimes it is to add a direct sensor rather than derive the quantity. Sometimes it is to stop and admit that the desired quantity cannot be measured directly on track. Trustworthy data is not data that answers every question. It is data whose answer stays inside the capability of the mounted system.
Your working rule for this lesson is this: a sensor mount is good when the channel can be named without apology. If the trace says body vertical acceleration, it came from a body accelerometer and you use it as body vertical acceleration. If the trace says hub acceleration, it came from a direct hub or upright sensor, or the derived channel is clearly labeled with the sampling and resolution penalty. If the trace says wheel load, you do not call it tire contact patch load unless the analysis path has been stated. If the trace says ride height, you know where it was measured and why that location represents the question. If the trace says propshaft torque, the rotating signal and power transfer method has been chosen for the environment. That discipline is what lets a driver, engineer, or instructor trust the graph when the setup decision matters.
Worked example: suspension sensors as an on-track rig
Imagine you want to understand vertical suspension behavior on a real circuit, not on a controlled rig. The source material describes this exact style of work: use sensors on the car to perform a version of rig testing on track. The available direct signals can include wheel position, wheel load, body vertical acceleration, average ride height, and reference speed. The mounting choice is the whole lesson. Wheel position sensors belong where they measure the suspension motion you intend to analyze. Load sensors belong in the relevant suspension load path, but their channel remains wheel load rather than rolling tire contact patch load. The body accelerometer belongs to the body, and with a single three-axis chassis unit its most useful role in this analysis is vertical modal movement. If you need hub acceleration, the clean mounting choice is a specific sensor on the wheel upright.
Now compare two analysis paths. In the first, you mount an accelerometer on the wheel upright and log hub acceleration directly. In the second, you calculate hub acceleration from body acceleration plus suspension movement acceleration derived from the position sensors. The second path is tempting because it uses channels you may already have, but the source warns that this process impairs high-frequency data because of the low sampling rates in time and space, meaning sensor resolution, of the position sensors. The intermediate lesson is not that calculation is forbidden. It is that the derived channel has a narrower truth claim. If you later look at a sharp high-frequency feature and make a damper decision from it, the direct upright sensor has earned more confidence than the derived channel.
A disciplined workflow would log a short section at reference speed, display average vertical load, average ride height, body vertical acceleration, and speed, then resist the urge to diagnose the car from the raw time trace alone. The source example states that such raw data does not provide much meaningful information about actual car behavior. You use the raw trace first as a credibility check: are the channels present, synchronized, and behaving like their mounted bodies would behave. Only after that do you move toward frequency analysis, equations of dynamics, and setup decisions. The mount gets the data into the conversation; it does not replace the interpretation.
Worked example: ride height, brake cooling, and aerodynamic balance
Suppose the car is sensitive to aero platform, and you suspect a brake-cooling change affected straight-line speed or balance. The relevant mounted channels might include laser ride-height sensors, aerodynamic pressure sensors such as pitot tubes, brake disc temperature sensors, reference speed, and the standard driver and chassis channels. The corpus supports each part of that chain, but it also keeps the interpretation bounded. Ride height is useful because maintaining vehicle height within acceptable limits is part of the suspension and aero problem. Laser ride-height sensors can directly and dynamically log ride height. Aerodynamic pressure sensors can observe air-pressure behavior. Brake disc temperatures can show the thermal effect of brake cooling changes, and brake cooling can also have a significant aerodynamic effect.
The mounting mistake would be to install one sensor and let it stand in for the whole system. A ride-height sensor mounted at one location tells you about that location's distance to the reference surface. It does not by itself tell you total downforce. A brake disc temperature channel tells you what happened thermally at the disc. It does not by itself tell you the aerodynamic cost of the cooling configuration. A pitot or air-pressure sensor gives you a pressure observation from its mounting location. It does not by itself define the car's full aero map. The trustworthy version is a chain of mounted observations: platform position, pressure behavior, brake temperature response, and reference speed, interpreted together and compared within the same circuit and weather context.
This is also where channel-budget thinking and mounting thinking meet. If you know you may later add ride height, brake disc temperature, or aerodynamic pressure channels, the source says future expansion affects the wiring harness, available memory, and other hardware. Planning those channels late can force compromised mounting, and compromised mounting weakens the later setup conclusion. For an intermediate engineer, the practical answer is to reserve the physical and logging capacity before the aero question becomes urgent.
Worked example: propshaft torque on a rotating system
A propshaft torque channel is different from a static pressure or position channel because the measured part is rotating. The source identifies torque sensors as a specialized strain-gauge application and describes a drive-shaft torque sensor where the sensor signal and power must be transferred to the measurement electronics. That one sentence changes the mounting problem. You are not only attaching a sensor to the measured part. You are designing a rotating measurement path.
One option is slip rings. They give physical contact between the axle and measurement electronics, providing power and retrieving the signal. The source also gives the risk: susceptibility to wear and packaging issues, which is why this solution is used less often in motor racing applications. Another option is wireless transfer by telemetry or magneto-elastic polarized band technology. The trustworthy mounting decision therefore includes the transfer method, not just the sensing element. A shaft-mounted sensor with an unreliable transfer path is not a trustworthy channel. A transfer method that cannot survive the packaging and operating environment turns a valid sensor into questionable data.
The analysis boundary is also clear. A propshaft torque channel can be valuable because it measures while the shaft is in use, but it still needs synchronization with engine RPM, throttle, gear, wheel speed, and lap timing before it becomes useful for performance analysis. If the torque trace cannot be aligned with the rest of the car, the mount may be mechanically impressive while the engineering conclusion remains weak.
Common mistakes
Mistake one is mounting a channel before naming the physical question. The source repeatedly returns to the idea that engineers should ask what exactly they want to measure. A vague channel request produces a vague mount. Good looks like writing the decision first, then the physical quantity, then the sensor location.
Mistake two is treating the chassis as the whole car. A chassis accelerometer is valuable, especially for body movement, but the source notes that a single three-axis chassis accelerometer is primarily useful for vertical modal movements in this suspension context. Good looks like adding wheel-hub or wheel-upright sensing when the question is actually about the unsprung side or hub acceleration.
Mistake three is calling inferred data direct data. Wheel load, wheel position, and body acceleration can help infer tire load through dynamics equations and relevant masses, but rolling tire contact patch load is not directly measurable on track in the source material. Good looks like labeling the direct channels and the inferred channel separately.
Mistake four is ignoring sampling and resolution when the mount is meant to capture fast motion. The source warns that deriving hub acceleration from position sensors can impair high-frequency data because of low sampling rates and sensor resolution. Good looks like using a direct upright-mounted sensor for high-frequency hub behavior or limiting the conclusion when the channel is derived.
Mistake five is trusting raw traces too early. The example 100-Hz race-car data over 20 seconds is included to show that raw data does not provide much meaningful information about actual car behavior. Good looks like using the raw trace for sanity checks first, then applying the analysis method that matches the mounted sensors.
Mistake six is treating rig and track data as interchangeable. Four-post testing provides controlled inputs, contact patch load sensing, and frequency-based analysis, but the source notes limitations around static tire behavior, balance assessment, and aerodynamic load interaction. Track data is real operating data, but it is limited by available sensors, logging capability, lap, circuit, and weather. Good looks like using each environment for the truth it can actually support.
Mistake seven is adding channels without protecting future mounting and logging capacity. The source explicitly connects future signal expansion to the wiring harness, memory, and hardware. Good looks like reserving space, inputs, and logging rate for the next decision rather than forcing the next sensor into a compromised location.
Drill: the mounting trust map and 20-second audit
Do this at your next event with one target system only. Pick suspension, aero platform, braking, or rotating torque. Do not pick the whole car. Before the first session, spend 20 minutes writing a mounting trust map. The map has five lines for each channel: the decision the channel supports, the physical quantity, the mounted body or location, the logging rate or resolution concern, and the limit you will not exceed in analysis.
Run three short checks across the day. In session one, collect a baseline and mark a 20-second segment with steady reference speed or a repeatable track condition. For a suspension exercise, mirror the source example by reviewing average vertical load, average ride height, body vertical acceleration, and reference speed if those channels are available. Your success criterion after session one is not a setup change. It is that every trace can be named as the physical quantity its mount actually measures.
Before session two, choose one questionable channel and write what would make it untrustworthy. Maybe the channel is derived from low-resolution position data. Maybe the sensor is on the chassis but the question is about wheel-hub behavior. Maybe the ride-height location does not represent the aero question. Run the same check again. Your success criterion after session two is that you can state whether the channel is direct, inferred, or only contextual.
After session three, make one interpretation and one refusal. The interpretation is a conclusion the mounted data can support. The refusal is a conclusion you will not make from this mounting package. For example, you may say the body vertical acceleration trace and ride-height channel show the platform behavior in that section, but you will not claim direct rolling tire contact patch load. Or you may say the derived hub acceleration is useful for a broad trend, but you will not use it for a high-frequency damper decision. The drill is successful when the refusal is as clear as the interpretation.
Cross-references to related skills
Use the sibling lesson on turning the measurement into the sensor specification before this lesson when the question itself is still vague. That lesson should decide what physical quantity, range, resolution, and logging need exist. Use this lesson when you are deciding where the sensor belongs and what the mounted channel can honestly claim. Then use the channel-budget lesson before expanding the system, because the corpus connects future channels to wiring harness capacity, memory, and hardware. The order matters: define the question, mount the sensor so it observes the right physical body, then budget the channel so the logger captures the needed information.
Author Review
No quiz questions are attached to this lesson.
Sources
| # | Document | Chunk | Pages | Score | Collection |
|---|---|---|---|---|---|
| 1 | Analysis Techniques for Racecar Data Acquisition | 51508775-0624-f564-4d00-979c5cc55a4e | 16 | 1 | uio_books_raw_v1 |
| 2 | Analysis Techniques for Racecar Data Acquisition | f725bafe-8b10-b36a-5b91-3395a519319d | 16 | 1 | uio_books_raw_v1 |
| 3 | Analysis Techniques for Racecar Data Acquisition | d18c0afe-a337-709c-36e1-a544a81e704e | 16 | 1 | uio_books_raw_v1 |
| 4 | Analysis Techniques for Racecar Data Acquisition | f6dc9cae-392f-1151-15c6-df8acd9a8ec5 | 5 | 1 | uio_books_raw_v1 |
| 5 | Analysis Techniques for Racecar Data Acquisition | 9b41b678-4787-363c-042e-2986a1b9565e | 5 | 1 | uio_books_raw_v1 |
| 6 | Document | 2ca9f4a7-eee0-2379-2b90-a722752e524c | 59 | 1 | uio_books_raw_v1 |
| 7 | Analysis Techniques for Racecar Data Acquisition | 2ec2c11f-d0d5-1c58-a22d-6a7b9bae589a | 23 | 1 | uio_books_raw_v1 |
| 8 | Analysis Techniques for Racecar Data Acquisition | b7da1ef7-f9f8-c734-bdb6-c1aa09e017fe | 5 | 1 | uio_books_raw_v1 |