29 Sensor Fusion and Kalman Filtering
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
The mathematical gist. Independent white noise shrinks as , 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 . At the chapter’s 0.5 Hz 1/f corner, useful averaging is limited to about s; beyond that the window enters the drift-dominated band.
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:
- Drift over time: Your temperature sensor slowly “forgets” its calibration, like a watch that loses minutes each day
- Noise that doesn’t average away: Some noise (called “1/f noise”) actually gets worse with longer measurements
- 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:
- Signal Processing Fundamentals: Filtering techniques and noise characteristics
- Calibration Techniques: Error sources and correction methods
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:
- What does a low-pass filter do? → Allows slow changes through, blocks rapid fluctuations (noise)
- Why do we calibrate sensors? → To correct systematic errors like offset and gain drift
- 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.
| Part | Topic | Key Question |
|---|---|---|
| Part 1 | 1/f Noise | Why doesn’t more averaging always help? |
| Part 2 | Sensor Fusion | How do we combine imperfect sensors? |
| Dig deeper | Kalman Implementation | How does the prediction-update estimator work in code? |
| Dig deeper | Production Validation | How 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 Window | White Noise Result | With 1/f Noise |
|---|---|---|
| 10 readings | 3.2× cleaner | 3.0× cleaner |
| 100 readings | 10× cleaner | 5× cleaner |
| 1000 readings | 31.6× cleaner | 6× cleaner (barely improved!) |
| 10000 readings | 100× cleaner | 6× 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 Type | Typical 1/f Corner | What This Means |
|---|---|---|
| MEMS accelerometer | 1-10 Hz | Check datasheet; avoid averaging below your sensor’s corner frequency |
| Thermistor | 0.1-1 Hz | 1-5 second averages are optimal (check your device’s corner) |
| Photodiode | 100-1000 Hz | Must sample at 2× the corner frequency or higher (200 Hz to 2 kHz depending on device) |
| Gas sensor | 0.01 Hz | Long-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.
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:
| Sensor | What It’s Good At | Where It Fails |
|---|---|---|
| GPS | Absolute position outdoors | Doesn’t work indoors; multipath in urban canyons |
| Wi-Fi RSSI | Works indoors | ±5-8m accuracy; affected by people moving |
| Barometer | Altitude/floor detection | Drifts with weather; no horizontal info |
| Accelerometer | Detecting motion | Drifts over time; can’t tell position |
| Gyroscope | Smooth rotation tracking | Drifts; no absolute reference |
| Magnetometer | Compass heading | Distorted 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.
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.
- Production sensor fusion and validation: lab-to-field degradation, validation rules, strategy selection, complementary filters, production pitfalls, and practice activities.
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.
| Block | Job | Implementation evidence | Awake for a sampled transmission? |
|---|---|---|---|
| Sensing element | Turns acceleration, pressure, temperature, gas concentration, or another measurand into resistance, charge, capacitance, current, or voltage | Range, cross-axis response, resonance, bias, temperature coefficient | Usually only while measuring; some wake detectors remain biased |
| Bias or bridge | Excites a resistive bridge, charges capacitive plates, biases a photodiode, or drives an electrochemical cell | Excitation stability, warm-up, settling, leakage | Yes before and during acquisition |
| Analog front end | Amplifies, level-shifts, demodulates, and filters the small transducer signal | Gain, input range, input-referred noise, bandwidth, saturation recovery | Yes, with settling time allowed |
| ADC | Samples and quantises the conditioned signal | Reference, code width, acquisition time, ENOB, conversion-complete flag | Yes for acquisition and conversion |
| MCU or sensor DSP | Applies calibration, compensation, quality checks, timestamping, and packet formation | Firmware and coefficient version, arithmetic limits, invalid-data flags | Yes for processing; then sleep |
| Radio | Frames, transmits, receives acknowledgement, and retries if policy permits | Channel, output power, airtime, retry count, acknowledgement | Only for the communication window |
| Power management | Sequences rails, clocks, retention memory, and wake sources | Rail ramp, brownout threshold, wake cause, sleep current | Always 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 is active current, is sleep current, , and , then
At and ,
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.
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 , giving an RMS displacement
For a viscously damped mode, the one-sided thermal force-noise density is
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 as proof mass falls. Treat that as a scaling rule to verify for the actual , , bandwidth, and temperature, not as a universal substitute for the noise model.
Surface effects also become harder to ignore. If a characteristic length is , volume and mass scale approximately as , while exposed area scales as ; therefore surface-to-volume ratio scales as . 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.
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 Noise | Signal Processing Essentials | Learn frequency-domain thinking |
| Sensor Fusion | Kalman filtering and position fusion | Implement the estimator path |
| Production Systems | Production sensor fusion and validation | Validate real deployments |
