Chapters

29 Sensor Fusion and Kalman Filtering

sensors
sensor
types

29.1 Start With the Measurement Story

Picture a strain sensor on a bridge. Its reading changes with load, but also with heat, age, mounting stress, and small random effects. A clean number on a screen can hide those very different causes.

Start with the physical event and a known test input. Record the expected direction, size, and response time. Repeat the test over time and temperature. Then hold the load steady, remove one sensor, and add a slow offset. Check whether the method mistakes drift for a real change.

Use averaging only after you know which kind of error is present. It can reduce fast random noise, but it cannot remove every slow change. Combining sensors can expose faults, yet it can also combine shared errors. An advanced method is useful only when its limit is visible.

Go deeper in two steps. The Practitioner material examines slow noise and sensor fusion. Under the Hood follows the physical sensing chain and the limits that appear before an action.

Use a four-part sensor record. First, name the physical event. Next, name the part that turns it into a signal. Then name each change made by the circuit and code. Last, name the action that uses the result.

Place a check at every part. Apply a known input. Hold it still. Repeat it. Change heat and time. Compare two units. Keep the raw result and the cleaned result. This makes a hidden slow shift easier to see.

Choose the method from the fault. Use a filter for the kind of noise it can reduce. Use a second sensor only when it adds a different clue. Keep a stop rule for disagreement. Review the whole chain after a new part, mount, case, sample rate, or field setting.

Advanced sensing begins when one reading is no longer enough. Start with the real claim - smoother position, better anomaly evidence, or more robust context - then decide whether filtering, fusion, or a Kalman model earns its complexity.

29.2 Field Sensors Fail Differently

Maria, an agricultural IoT engineer, was frustrated. Her soil moisture sensors worked perfectly in the lab---readings were stable, accurate, and repeatable. But three months after deploying them across a vineyard in Napa Valley, farmers started complaining: “The readings wander around even when it hasn’t rained in weeks!”

After days of debugging, Maria discovered something that surprises many engineers: averaging more samples doesn’t always help. Her sensors suffered from a phenomenon called 1/f noise, where longer measurement windows actually captured more low-frequency drift, not less. The solution wasn’t more averaging---it was smarter signal processing and combining multiple sensors together.

This chapter takes you on the journey from lab-perfect sensors to field-reliable systems. You’ll learn why some noise defies averaging, how combining sensors makes them stronger than any individual sensor, and what it takes to build sensing systems that work reliably for years in harsh real-world conditions.

29.3 Why This Matters

These aren’t just academic concepts---they’re the foundation of technology you use every day:

Start with Your smartphone’s GPS uses Kalman filtering to maintain position when walking through urban canyons. Then Fitness trackers fuse accelerometer + gyroscope + barometer for accurate step and floor counting. Next Self-driving cars combine 10+ sensor types using advanced fusion algorithms. Finally Industrial IoT saves millions in maintenance by detecting sensor drift before failures occur.

Understanding these principles separates hobbyist projects from production-ready systems.

29.4 In 60 Seconds

Advanced sensor topics include 1/f noise (which limits long-term averaging effectiveness), multi-sensor fusion (combining GPS, Wi-Fi, barometer, and IMU for better positioning), and Kalman filtering (optimally blending predictions with measurements). Production sensor systems need robust error handling, redundancy, watchdog timers, and traceable calibration.

The mathematical gist. Independent white noise shrinks as 1/N1/\sqrt{N}, so 10, 100, 1,000, and 10,000 samples ideally improve noise by 3.16×, 10.0×, 31.6×, and 100×. But an averaging window has bandwidth near 1/(2T)1/(2T). At the chapter’s 0.5 Hz 1/f corner, useful averaging is limited to about T=1.00T=1.00 s; beyond that the window enters the drift-dominated band.

Math Bridge · guided foundationsWhy does √N averaging stop helping?Let Phoebe connect sample cancellation, window bandwidth, and the chapter's 0.5 Hz corner.

29.5 Key Concepts

Start with MEMS Sensors: Micro-Electro-Mechanical Systems sensors fabricated using semiconductor processes; combine mechanical sensing elements with signal conditioning electronics on a single chip, enabling miniature low-cost accelerometers, gyroscopes, and pressure sensors. Then Piezoelectric Effect: The generation of electrical charge in a material when mechanical stress is applied; used in vibration sensors, ultrasonic transducers, and force sensors; also works in reverse (electrical voltage causes mechanical strain). Next Hall Effect Sensor: Produces a voltage proportional to a perpendicular magnetic field; used for contactless current sensing, position detection, and rotary encoders — immune to wear unlike mechanical contacts. After that Time-of-Flight (ToF) Sensor: Measures distance by timing the round-trip of a laser or ultrasonic pulse; lidar ToF sensors achieve millimeter resolution; more accurate than ultrasonic and unaffected by ambient sound levels. Continue by Capacitive Sensing: Measures changes in capacitance caused by proximity, touch, or dielectric variation; used in soil moisture sensors, proximity switches, touch screens, and liquid level detection without direct contact. Continue by Thermal Imaging Array: A grid of thermopile elements producing a 2D temperature map; the MLX90640 (32x24 pixel) provides room-scale thermal images for occupancy detection and predictive maintenance. Continue by Load Cell: A strain-gauge-based transducer converting mechanical force to electrical signal; requires Wheatstone bridge excitation and instrumentation amplification; typical resolution 0.01% of full scale. Finally Electrochemical Gas Sensor: Uses oxidation/reduction reactions at electrodes to produce current proportional to gas concentration; used for CO, NO2, and other toxic gases; requires periodic calibration and has limited operating lifetime.

Learning Objectives

After completing this chapter, you will be able to:

  • Identify 1/f noise in sensor data and explain why it limits long-term averaging effectiveness
  • Design multi-sensor fusion architectures that outperform individual sensors
  • Implement Kalman filtering algorithms for optimal state estimation
  • Construct robust sensing systems with error handling, redundancy, and watchdog recovery for production deployment

29.6 What Makes This Advanced

When you move beyond hobby projects to building real-world sensor systems, new challenges appear that textbooks often skip over. Here’s the key insight:

Lab sensors work. Field sensors fail. The difference isn’t the sensor---it’s understanding the hidden problems:

  1. Drift over time: Your temperature sensor slowly “forgets” its calibration, like a watch that loses minutes each day
  2. Noise that doesn’t average away: Some noise (called “1/f noise”) actually gets worse with longer measurements
  3. Single-sensor blindspots: GPS doesn’t work indoors; accelerometers drift; barometers shift with weather

The solution? Combine sensors intelligently (sensor fusion) and build systems that detect and recover from failures automatically.

Think of it like asking several witnesses to describe the same car accident. Each person saw it from a different angle and might have missed details---but by combining their accounts, you get a more complete and accurate picture than any single witness could provide. That’s sensor fusion.

29.7 Meet the Sensor Squad

Throughout this chapter, Temperature Terry, the microcontroller, the LED, and the battery will help explain these tricky concepts in fun ways! Look for their special boxes at the end of the chapter.

Sneak peek: Sammy discovers that the longer he averages his readings, the LESS it helps! Max explains it’s because of something called “1/f noise” (pronounced “one-over-f”). And the whole squad learns how working TOGETHER as a team (sensor fusion!) makes them stronger than any one friend alone.

Skip to the end to meet the full Sensor Squad story!

29.8 Prerequisites

Before diving in, make sure you’re comfortable with:

If terms like “low-pass filter” or “calibration offset” feel unfamiliar, review those chapters first---this chapter builds directly on those concepts.

29.9 Quick Prerequisite Check

Test your readiness for this chapter with these quick questions:

  1. What does a low-pass filter do? → Allows slow changes through, blocks rapid fluctuations (noise)
  2. Why do we calibrate sensors? → To correct systematic errors like offset and gain drift
  3. What is sensor noise? → Random variations in readings that don’t reflect the actual measured quantity

If you answered all three correctly, you’re ready! If not, consider reviewing the prerequisite chapters first.

29.9.1 Chapter Roadmap

This overview covers the two ideas every later technique depends on, then points to focused child chapters for implementation and production work.

PartTopicKey Question
Part 11/f NoiseWhy doesn’t more averaging always help?
Part 2Sensor FusionHow do we combine imperfect sensors?
Dig deeperKalman ImplementationHow does the prediction-update estimator work in code?
Dig deeperProduction ValidationHow do we make fusion reliable in the field?

Let’s begin with the mystery that stumped Maria.


29.10 Part 1: The 1/f Noise Problem

Let’s start with the mystery Maria encountered: why doesn’t more averaging always help?

29.10.1 When Averaging Fails on 1/f Noise

You’ve probably learned that averaging reduces noise. Take 100 readings, average them, and you get a result that’s 10× cleaner (√100 = 10). This works beautifully for “white noise”---the random fluctuations that are equally likely at any frequency.

But here’s what the textbooks often skip: not all noise is white noise.

1/f noise (also called “pink noise” or “flicker noise”) behaves differently. Its power increases at lower frequencies, which means slow, wandering drift dominates over long time periods. And here’s the frustrating part: when you average over longer windows, you’re actually capturing more of this low-frequency drift, not averaging it away.

29.10.2 How 1/f Noise Affects Your Sensors

The impact is counterintuitive: short-term averaging works exactly as expected (10 samples gives you ~3× improvement), but long-term averaging hits a wall. At some point, taking more samples stops helping---and can even make things worse as you capture slow baseline drift.

Let’s put numbers to this. Imagine you’re averaging temperature readings:

Averaging WindowWhite Noise ResultWith 1/f Noise
10 readings3.2× cleaner3.0× cleaner
100 readings10× cleaner5× cleaner
1000 readings31.6× cleaner6× cleaner (barely improved!)
10000 readings100× cleaner6× cleaner (no more improvement!)

See the pattern? With strong 1/f noise, you hit diminishing returns much sooner than expected.

29.10.3 1/f Corner Frequency

Every sensor has a “1/f corner frequency”---the frequency where 1/f noise equals the white noise floor. Below this frequency, 1/f noise dominates and averaging becomes ineffective.

Sensor TypeTypical 1/f CornerWhat This Means
MEMS accelerometer1-10 HzCheck datasheet; avoid averaging below your sensor’s corner frequency
Thermistor0.1-1 Hz1-5 second averages are optimal (check your device’s corner)
Photodiode100-1000 HzMust sample at 2× the corner frequency or higher (200 Hz to 2 kHz depending on device)
Gas sensor0.01 HzLong-term drift is expected and unavoidable

The practical rule: Stop averaging at roughly 2× the corner frequency. For a sensor with a 0.5 Hz corner, 2× the corner = 1.0 Hz, so averaging for more than ~1 second (1/1.0 Hz) provides no additional benefit.

29.10.4 Fighting Back: Mitigation Strategies

So what can you do? Here are four proven techniques, ordered from simplest to most sophisticated:

1. Know when to stop averaging. Check your sensor’s datasheet for the 1/f corner frequency. If it’s not listed, measure it experimentally by computing the Allan variance at different averaging times.

2. Use high-pass filtering. Remove DC and very-low-frequency components before your measurement. This cuts out the 1/f-dominated frequencies.

29.11 Optional High-Pass Filter Pattern

# Simple high-pass filter to remove DC drift
alpha = 0.99  # Cutoff tuning parameter
filtered = 0.0
previous_reading = sensor.read()

while True:
    new_reading = sensor.read()
    filtered = alpha * (filtered + new_reading - previous_reading)
    previous_reading = new_reading

3. Apply chopping/modulation. Periodically reverse the sensor’s polarity or bias, then subtract alternate readings. This moves your signal above the 1/f corner frequency where noise is well-behaved.

4. Use correlated double sampling. Take two measurements under different conditions (e.g., with and without excitation), then subtract. The 1/f noise, being correlated between samples, largely cancels out.

To decide whether averaging can improve a slow sensor, inspect Figure 29.1 in the frequency domain first. The plot separates frequency-independent white noise from the low-frequency rise associated with flicker noise.

A noise spectrum plots 1/f, white and total noise against log frequency. The corner separates a low-frequency drift zone from a safe averaging zone.
Figure 29.1: 1/f Noise Spectrum: The frequency domain view shows white noise (flat) and 1/f noise (rising at low frequencies) intersecting at the corner frequency. Below the corner, averaging becomes ineffective.

Read Figure 29.1, begin in the flat white-noise region, move toward lower frequency, and locate the corner where the rising 1/f contribution takes over. Longer averaging suppresses independent noise but eventually encounters drift-like low-frequency behaviour, connecting the spectrum to the need for calibration or high-pass treatment.

29.12 Explore 1/f Noise and Averaging

Use this simulation to see how averaging window size affects noise reduction. Drag the sliders and watch how 1/f noise limits long-term averaging!


29.13 When One Sensor Is Not Enough

Now that you understand why individual sensors have inherent limitations (noise that doesn’t average away, drift over time, blind spots in certain conditions), let’s explore a powerful solution: combining multiple sensors to create something stronger than any individual sensor.

This is called sensor fusion, and it’s the secret behind everything from smartphone navigation to self-driving cars.

29.13.1 Single-Sensor Problem

Let’s be honest about what individual sensors can’t do:

SensorWhat It’s Good AtWhere It Fails
GPSAbsolute position outdoorsDoesn’t work indoors; multipath in urban canyons
Wi-Fi RSSIWorks indoors±5-8m accuracy; affected by people moving
BarometerAltitude/floor detectionDrifts with weather; no horizontal info
AccelerometerDetecting motionDrifts over time; can’t tell position
GyroscopeSmooth rotation trackingDrifts; no absolute reference
MagnetometerCompass headingDistorted by metal, electronics

Notice a pattern? Each sensor has complementary weaknesses. GPS drifts indoors where Wi-Fi works. Accelerometers drift over time where GPS provides corrections. Barometers give altitude that GPS struggles with in urban environments.

The insight: Instead of trying to build a perfect single sensor (impossible), combine imperfect sensors that fail in different ways.

29.13.2 Sensor Fusion: The Core Idea

Remember the witness analogy from the introduction? Each witness sees a different angle of the same event. No single witness is complete, but by weighing each account based on what they could reliably observe, you reconstruct reality more accurately than any individual could. Sensor fusion applies this same principle to electronic measurements:

29.13.3 What Sensor Fusion Actually Means

The engineering literature is not always careful with these words: sensor fusion, data fusion, information fusion, multisensor data fusion, and multi-sensor integration all get used almost interchangeably. A widely cited definition (Hall and Llinas, 1997) frames the goal plainly: combine data from multiple sensors, and related information from associated databases, to achieve improved accuracy and more specific inferences than any single sensor could achieve alone.

Durrant-Whyte (1988) draws a finer line between two of those terms. Sensor fusion happens when a dedicated fusion stage — voting, averaging, or something more elaborate — actually combines the sensor streams into one shared internal representation of the environment before that representation reaches the control application. Multisensor integration skips the shared stage: each sensor’s raw stream is wired straight to the control application, which is left to reconcile them itself. The witness analogy above is sensor fusion only if someone actually merges the accounts into one story; if every witness testifies separately and the jury does the merging inside its own head, that is integration, not fusion — and the quality of the outcome depends entirely on how well the jury (your control code) happens to do that job.

29.13.4 Classifying Fusion by Data Level: The Dasarathy Hierarchy

Competitive, complementary, and cooperative fusion (covered with production examples in the fusion strategy guide) classify a fusion system by how the sensors relate to each other. A second, independent question is at what stage of processing the combining happens. Dasarathy (1997) organizes that into five levels, from raw signals up to final decisions:

Start with Data-in/data-out (DAI-DAO): the lowest, most elementary level. Raw sensor data goes in, processed raw data comes out, run immediately after acquisition — a Gaussian, median, or edge-preserving filter cleaning up a noisy image is DAI-DAO fusion: still an image afterward, just a better one. Then Data-in/feature-out (DAI-FEO): raw data goes in, but the output is an extracted feature, such as a shape pulled out of an image. Next Feature-in/feature-out (FEI-FEO): both input and output are features — commonly called feature fusion. It matters most when sensors have genuinely different data structures whose features cannot be derived from one another: an ultrasonic ranger contributes range, a camera contributes shape, and combining the two features yields a volumetric size estimate that neither sensor could produce alone. After that Feature-in/decision-out (FEI-DEO): perhaps the most common pattern in practice. A feature vector built from several sensors gets classified against prior training to reach a decision — a convolutional network turning several channels of motion-sensor data into an activity label (a push-up versus a kettlebell thruster, say) is FEI-DEO fusion. Finally Decision-in/decision-out (DEI-DEO): the top of the hierarchy, also called decision fusion. Each sensor or hub reaches its own local decision first, and only those decisions travel onward — the pattern a smart-home hub uses when a door sensor, a switch, and a humidity sensor each report status independently and the hub reconciles the decisions, rather than every raw reading being centrally fused.

The two taxonomies are independent and both can apply to the same system at once: a Kalman filter blending accelerometer and gyroscope readings (the running example throughout the Kalman filtering chapter) is complementary fusion by relationship, running at roughly the feature level by data type, since each sensor’s raw signal has already been converted into an angle estimate before the filter combines them.

29.14 Fusion Rule of Thumb

Best estimate = weighted combination of GPS, Wi-Fi, barometer, accelerometer, gyroscope, and magnetometer readings.

Before adding sensor fusion, inspect Figure 29.2 to identify what independent information each sensor contributes and where uncertainty is combined.

Diagram showing four sensor boxes on the left: GPS labeled absolute position but fails indoors; IMU labeled motion and orientation but drifts over time; Barometer labeled altitude and floor but weather drift; WiFi RSSI labeled works indoors but low accuracy. Arrows flow from all sensors to a central teal box labeled Fusion Engine containing Kalman Filter with steps: predict next state, compute Kalman gain K, update with sensors, output best estimate. An arrow leads to a yellow output box labeled Best Estimate showing Position, Velocity, Orientation with accuracy plus minus 0.5 to 1.5 meters.
Figure 29.2: Sensor Fusion Architecture: Multiple sensors with complementary strengths feed into a Kalman filter fusion engine, producing a best estimate more accurate than any individual sensor.

Read Figure 29.2 from the complementary sensor inputs through preprocessing and the fusion engine to the state estimate. The route connects redundancy to improved observability while preserving the need to reject correlated faults and biased inputs.

The key is figuring out the right weights---how much to trust each sensor at each moment. That’s where the Kalman filter comes in.



29.15 Continue: Kalman Filtering

The Kalman material is now a focused child chapter instead of a second mini-chapter inside this page.

Start by Kalman filtering and position fusion: prediction-update steps, MicroPython and Arduino examples, tuning tools, GPS plus IMU fusion, and Kalman gain practice.

29.16 Continue: Production Sensor Systems

Production validation is now a focused child chapter so field reliability, validation simulators, complementary-filter tuning, and deployment failure modes can be read without expanding this overview.

29.17 MEMS Sensor Implementation Chain

Miniaturisation does not remove the measurement chain; it packs the chain into fewer packages and makes power-domain timing more important. Follow one sample from physics to radio rather than treating a MEMS part as a single magic block.

BlockJobImplementation evidenceAwake for a sampled transmission?
Sensing elementTurns acceleration, pressure, temperature, gas concentration, or another measurand into resistance, charge, capacitance, current, or voltageRange, cross-axis response, resonance, bias, temperature coefficientUsually only while measuring; some wake detectors remain biased
Bias or bridgeExcites a resistive bridge, charges capacitive plates, biases a photodiode, or drives an electrochemical cellExcitation stability, warm-up, settling, leakageYes before and during acquisition
Analog front endAmplifies, level-shifts, demodulates, and filters the small transducer signalGain, input range, input-referred noise, bandwidth, saturation recoveryYes, with settling time allowed
ADCSamples and quantises the conditioned signalReference, code width, acquisition time, ENOB, conversion-complete flagYes for acquisition and conversion
MCU or sensor DSPApplies calibration, compensation, quality checks, timestamping, and packet formationFirmware and coefficient version, arithmetic limits, invalid-data flagsYes for processing; then sleep
RadioFrames, transmits, receives acknowledgement, and retries if policy permitsChannel, output power, airtime, retry count, acknowledgementOnly for the communication window
Power managementSequences rails, clocks, retention memory, and wake sourcesRail ramp, brownout threshold, wake cause, sleep currentAlways supervising; most switched rails off in sleep

The wake sequence is causal. First the power controller enables the sensing and analog domains. Next it waits for bias, reference, amplifier, and filter settling. Then the ADC acquires the signal and the MCU applies calibration. Only after a valid record exists should the radio wake, transmit, and wait for an acknowledgement. Finally firmware stores retry and quality state before switching domains off. Skipping the settling interval saves apparent time but turns yesterday’s charge, reference ramp, or filter transient into today’s reading.

For a simple 1 ms active, 1 s sleep schedule, use charge rather than averaging currents by eye. If IaI_a is active current, IsI_s is sleep current, ta=1 mst_a=1\ \text{ms}, and ts=1 st_s=1\ \text{s}, then

Iavg=Iata+Iststa+ts.I_{\text{avg}}=\frac{I_at_a+I_st_s}{t_a+t_s}.

At Ia=24 mAI_a=24\ \text{mA} and Is=8 μAI_s=8\ \mu\text{A},

Iavg=(24 mA)(0.001 s)+(0.008 mA)(1 s)1.001 s32 μA.I_{\text{avg}} =\frac{(24\ \text{mA})(0.001\ \text{s})+(0.008\ \text{mA})(1\ \text{s})}{1.001\ \text{s}} \approx32\ \mu\text{A}.

That attractive number survives only if start-up, sensor warm-up, retries, leakage through GPIOs, and regulator quiescent current fit the model. A 20 ms warm-up at the same active current would dominate the 1 ms radio burst. Build the schedule from oscilloscope or power-profiler phases, not just the radio datasheet.

The timed component chain in Figure 29.3 connects the 1 ms communication window to every block that must settle before a valid packet exists.

Signal-flow cards run from transducer through bias and bridge, amplifier and filter, ADC, MCU, and radio; a power timeline shows one second asleep and one millisecond active.
Figure 29.3: A miniature sensor node converts a transducer signal through bias, analog conditioning, ADC, MCU, and radio under a one-second sleep and one-millisecond active schedule.

In Figure 29.3, Transducer precedes Bias / bridge, Amp + filter, and ADC before MCU can form a packet. The ACTIVE · 1 ms overlay is credible only if reference settling, sensor warm-up, radio startup, acknowledgement, and retry work fit inside it; otherwise the apparent sleep ratio hides real energy.

29.18 Miniaturisation Limits Before Actuation

Smaller force sensors gain integration and may gain resonant frequency, but the signal and every noise mechanism do not scale together. Start with thermal equilibrium. A spring mode stores mean energy on the order of kBTk_BT, giving an RMS displacement

xrms=kBTk.x_{\text{rms}}=\sqrt{\frac{k_BT}{k}}.

For a viscously damped mode, the one-sided thermal force-noise density is

SF1/2=4kBTbN/Hz.S_F^{1/2}=\sqrt{4k_BT b}\quad\text{N}/\sqrt{\text{Hz}}.

The mechanical transfer function turns that force into displacement, and the readout adds roughly size-independent amplifier, reference, and quantisation noise. Consequently, shrinking geometry does not guarantee a quieter force estimate. Under common families of similarly tuned structures, the acceleration-equivalent or thermomechanical error often worsens approximately with 1/m1/\sqrt{m} as proof mass falls. Treat that as a scaling rule to verify for the actual kk, bb, bandwidth, and temperature, not as a universal substitute for the noise model.

Surface effects also become harder to ignore. If a characteristic length is LL, volume and mass scale approximately as L3L^3, while exposed area scales as L2L^2; therefore surface-to-volume ratio scales as 1/L1/L. Surface charge traps, adsorption, contamination, package stress, and contact-related 1/f processes can occupy more of the error budget as the structure shrinks. Electrical noise may stay almost fixed while the mechanical signal falls, so the interface circuit can set the resolution even when fabrication improves.

This is the handoff to an actuator, not a reason to abandon miniaturisation. The sensor estimates a state and attaches uncertainty; control logic decides whether action is allowed; a driver converts the low-energy command into voltage or current; and the actuator converts supplied electrical, pneumatic, hydraulic, thermal, or mechanical energy into motion or force. Keep command energy separate from actuator energy: a GPIO can request motion, but the power stage and supply deliver it. At microscale, write both the sensing noise budget and the actuator force, travel, heating, and saturation budget before closing the loop.

The scale comparison in Figure 29.4 carries miniaturisation uncertainty all the way into a physical-output proof.

A 10 milligram and 0.1 milligram proof-mass force sensor comparison shows larger thermomechanical displacement and surface-to-volume effects at small scale while electronics noise stays 5 microvolts; sensing then flows through control and a 24 volt driver to a valve.
Figure 29.4: Large and small force sensors compare thermal displacement, surface effects, and fixed electronics noise before a measured command drives an actuator.

In Figure 29.4, 10 mg force sensor and 0.1 mg force sensor keep electronics noise: 5 µV fixed while thermal displacement and surface risk rise. The lower chain carries force = 2.4 mN through command = 65% and 24 V power stage to valve moves 12 mm, keeping sensing uncertainty separate from actuation energy and feedback.

29.19 Summary

Key advanced sensor takeaways:

Start with 1/f noise limits long-term averaging - Know the corner frequency before choosing an averaging window. Then Sensor fusion beats single sensors - Combine complementary measurements rather than trusting one noisy or drifting channel. Next Kalman filtering is the next implementation step - Use the child chapter when you need prediction-update code and gain tuning. Finally Production systems need validation - Use the production child chapter when a sensor result can drive action, alerts, or maintenance.

29.20 You Might Also Like

If you enjoyed…Explore…Why
1/f NoiseSignal Processing EssentialsLearn frequency-domain thinking
Sensor FusionKalman filtering and position fusionImplement the estimator path
Production SystemsProduction sensor fusion and validationValidate real deployments