9  Mathematical Foundations for IoT

9.1 Learning Objectives

  • Calculate derivatives and integrals in IoT scenarios such as PID control, energy budgeting, and sensor drift compensation
  • Convert between linear and logarithmic scales (dB, dBm) and apply Shannon capacity to evaluate channel throughput
  • Construct state-prediction matrices for sensor fusion using Kalman filter equations
  • Analyse probability distributions (Gaussian noise model, 68-95-99.7 rule) to quantify sensor uncertainty
  • Justify how modular arithmetic underpins public-key cryptography and Diffie-Hellman key exchange
In 60 Seconds

IoT engineering uses a handful of mathematical tools repeatedly: calculus for measuring rates of change (PID control, sensor drift), logarithms for managing large signal ranges (decibels in RF, Shannon capacity), probability for quantifying sensor noise (Gaussian distributions, 68-95-99.7 rule), and linear algebra for fusing multiple sensor inputs (Kalman filter). You do not need to derive these from scratch – you need to recognize which tool applies to each IoT problem and understand the intuition behind it.

9.2 For Beginners: Mathematical Foundations for IoT

Think of mathematics as the “language” of IoT engineering. Just like you don’t need to be a poet to write clear emails, you don’t need to be a mathematician to build IoT systems. What you do need is to understand the basic “vocabulary” - knowing when to use calculus (for measuring change), logarithms (for dealing with huge ranges like signal strength), or probability (for handling sensor noise). This appendix teaches you to recognize which mathematical tool applies to each IoT problem and understand the intuition behind it, without requiring you to memorize complex proofs or derivations.

MVU: Mathematics for IoT Engineers

Core Concept: IoT engineering relies on a handful of mathematical tools - derivatives for measuring change, logarithms for managing large ranges, probability for handling uncertainty, and linear algebra for sensor fusion.

Why It Matters: Understanding these foundations lets you read datasheets, interpret signal measurements, configure PID controllers, and estimate battery life without guessing.

Key Takeaway: When you encounter a formula in IoT documentation, use this appendix to understand the intuition behind it and see practical examples before attempting implementation.

9.3 How It Works: Mathematics Powering IoT Systems

The Big Picture: Math as IoT’s Hidden Language

Mathematics provides the precise language for describing IoT behavior. When a datasheet says “sensor drift: 0.5%/°C,” that’s calculus (derivatives). When LoRa claims “10 km range,” that’s logarithms (path loss in dB). When a Kalman filter fuses GPS and accelerometer data, that’s linear algebra (matrices) and probability (Gaussian distributions).

The pattern: IoT engineers don’t derive formulas from scratch—we recognize which mathematical tool applies to each problem and understand the intuition behind it. This section builds that recognition and intuition.

9.4 A. Calculus Concepts for IoT

9.4.1 A.1 Rates of Change (Derivatives)

The Core Idea

A derivative measures how fast something is changing at any instant. In IoT, we constantly deal with changing quantities: temperature rising, battery depleting, signals fluctuating.

Notation: \(\frac{dx}{dt}\) means “the rate at which x changes with respect to time t”

IoT Applications:

Scenario What’s Changing Derivative Meaning
Temperature monitoring Temperature (T) \(\frac{dT}{dt}\) = heating/cooling rate (°C/second)
Battery drain Charge (Q) \(\frac{dQ}{dt}\) = current flow (Amperes)
Vehicle tracking Position (x) \(\frac{dx}{dt}\) = velocity (m/s)
Signal processing Voltage (V) \(\frac{dV}{dt}\) = rate of voltage change

Practical Example - PID Controller:

The PID formula uses derivatives: \[P(t) = K_p \cdot e(t) + K_i \cdot \int e(t)dt + K_d \cdot \frac{de(t)}{dt}\]

  • P term: Current error (how far off are we?)
  • D term (\(\frac{de}{dt}\)): How fast is the error changing? (prevents overshooting)
  • I term: Accumulated error over time (corrects persistent drift)

Intuition: The derivative term is like a driver who slows down when approaching a stop sign - you react to how fast you’re approaching, not just how far away you are.

9.4.2 A.2 Accumulation (Integrals)

The Core Idea

An integral adds up many small pieces to get a total. Think of it as “continuous summation.”

Notation: \(\int f(x)dx\) means “sum up all the tiny pieces of f(x)”

IoT Applications:

Scenario What We’re Summing Result
Energy consumption Power × time Total energy used (Joules)
Data transfer Bits per second × time Total data transferred (bytes)
Sensor noise Small random fluctuations Average reading (smoothing)
Battery capacity Current × time Charge used (mAh)

Practical Example - Energy Budget:

Total energy consumed by an IoT device: \[E_{total} = \int_0^T P(t) \, dt\]

If power varies during operation: - Active mode: \(P_{active} = 50mW\) for 10ms - Sleep mode: \(P_{sleep} = 0.01mW\) for 990ms

\[E_{cycle} = (50mW \times 10ms) + (0.01mW \times 990ms) = 0.5mJ + 0.0099mJ \approx 0.51mJ\]

Intuition: Integration is like measuring water in a tank by tracking how fast it fills over time, even if the flow rate changes.

9.4.3 A.3 The Derivative-Integral Relationship

Derivatives and integrals are inverses: - Derivative: Tells you the rate of change - Integral: Tells you the accumulated total

Flowchart showing the fundamental calculus relationships between position, velocity, and acceleration. Integration moves from acceleration to velocity to position (right to left), while differentiation moves from position to velocity to acceleration (left to right). Position is measured in meters, velocity in meters per second, and acceleration in meters per second squared.
Figure 9.1: Diagram illustrating calculus relationship

In sensor fusion, we often: - Integrate accelerometer data to get velocity - Integrate velocity to get position - Differentiate position to get velocity

9.5 B. Exponential and Logarithmic Functions

9.5.1 B.1 Exponential Growth and Decay

The Core Idea

Exponential functions describe processes where change is proportional to the current value. Things grow (or decay) faster when there’s more of them.

The exponential function: \(y = e^x\) where \(e \approx 2.718\)

IoT Applications:

Phenomenon Formula Description
Capacitor discharge \(V(t) = V_0 \cdot e^{-t/\tau}\) Voltage decays exponentially
Signal attenuation \(P = P_0 \cdot e^{-\alpha d}\) Power decreases with distance
Sensor warm-up \(T(t) = T_{final}(1 - e^{-t/\tau})\) Approaches target exponentially
Battery self-discharge \(Q(t) = Q_0 \cdot e^{-\lambda t}\) Charge slowly leaks away

Time Constant (τ):

  • After \(1\tau\): Value drops to 37% of initial (\(e^{-1} \approx 0.37\))
  • After \(3\tau\): Value drops to 5% of initial
  • After \(5\tau\): Value drops to 0.7% (essentially zero for practical purposes)

Practical Example - RC Time Constant:

A sensor with a 100Ω resistor and 10µF capacitor: \[\tau = R \times C = 100\Omega \times 10\mu F = 1ms\]

This sensor can respond to signals changing up to ~1000 Hz.

9.5.2 B.2 Logarithms

The Core Idea

A logarithm asks: “What power do I raise the base to, to get this number?” Logarithms compress large ranges into manageable scales.

Definition: If \(b^x = y\), then \(\log_b(y) = x\)

Common bases:

  • \(\log_{10}\) (common log) - used in dB calculations
  • \(\ln\) or \(\log_e\) (natural log) - used in signal processing
  • \(\log_2\) (binary log) - used in information theory (bits)

IoT Applications:

1. Decibels (dB) - Compress power ratios: \[dB = 10 \log_{10}\left(\frac{P_{out}}{P_{in}}\right)\]

Power Ratio dB Value
1× (no change) 0 dB
2× (double) +3 dB
10× +10 dB
100× +20 dB
0.5× (half) -3 dB
0.1× -10 dB

2. Shannon Capacity - Maximum data rate: \[C = B \log_2(1 + SNR)\]

Where: - \(C\) = channel capacity (bits/second) - \(B\) = bandwidth (Hz) - \(SNR\) = signal-to-noise ratio

Why logarithm? Doubling SNR doesn’t double capacity - you get diminishing returns.

3. dBm (Power in milliwatts): \[dBm = 10 \log_{10}(P_{mW})\]

Power dBm
1 mW 0 dBm
10 mW 10 dBm
100 mW 20 dBm
0.001 mW (1 µW) -30 dBm

9.6 C. Linear Algebra Basics

9.6.1 C.1 Vectors

The Core Idea

A vector is an ordered list of numbers representing multiple related quantities. In IoT, sensors often produce vector outputs (e.g., 3-axis accelerometer gives [x, y, z]).

Notation: \(\vec{v} = \begin{bmatrix} x \\ y \\ z \end{bmatrix}\) or simply \([x, y, z]\)

IoT Applications:

Data Type Vector Representation
3-axis accelerometer \([a_x, a_y, a_z]\) in g-force
GPS position \([latitude, longitude, altitude]\)
RGB color \([red, green, blue]\) values 0-255
IMU (9-axis) \([a_x, a_y, a_z, g_x, g_y, g_z, m_x, m_y, m_z]\)

Vector Operations:

Magnitude (Length): How “big” is the vector? \[|\vec{v}| = \sqrt{x^2 + y^2 + z^2}\]

Example: Accelerometer reads \([0.5, 0.3, 0.8]g\) \[|\vec{a}| = \sqrt{0.5^2 + 0.3^2 + 0.8^2} = \sqrt{0.98} \approx 0.99g\]

This tells us the total acceleration magnitude (useful for fall detection).

9.6.2 C.2 Matrices

The Core Idea

A matrix is a 2D array of numbers. Matrices transform vectors - rotate them, scale them, or combine multiple measurements.

Notation: \[M = \begin{bmatrix} a & b \\ c & d \end{bmatrix}\]

IoT Applications:

1. Coordinate Transformation:

Rotating sensor data to align with a reference frame: \[ \begin{aligned} x' &= x\cos\theta - y\sin\theta \\ y' &= x\sin\theta + y\cos\theta \end{aligned} \]

2. Kalman Filter State:

State vector might be \([position, velocity, acceleration]\): \[\vec{x} = \begin{bmatrix} p \\ v \\ a \end{bmatrix}\]

State transition predicts next state: \[\vec{x}_{k+1} = F \cdot \vec{x}_k\]

3. Covariance Matrix:

Describes uncertainty in measurements: \[P = \begin{bmatrix} \sigma_x^2 & \sigma_{xy} \\ \sigma_{xy} & \sigma_y^2 \end{bmatrix}\]

Diagonal elements: Variance (uncertainty) in each variable Off-diagonal: How variables correlate (change together)

9.6.3 C.3 Matrix Multiplication

Quick Rule

To multiply matrix A (m×n) by matrix B (n×p), the inner dimensions must match. Result is (m×p).

Example: Transforming a 3D point \[\begin{bmatrix} 2 & 0 & 0 \\ 0 & 2 & 0 \\ 0 & 0 & 2 \end{bmatrix} \begin{bmatrix} 1 \\ 2 \\ 3 \end{bmatrix} = \begin{bmatrix} 2 \\ 4 \\ 6 \end{bmatrix}\]

This scales the vector by 2 in all directions.

9.7 D. Probability and Statistics

9.7.1 D.1 Basic Probability

The Core Idea

Probability quantifies uncertainty. In IoT, sensor readings are never perfect - probability helps us reason about noise, errors, and reliability.

Key Concepts:

Term Definition IoT Example
Probability P(A) Chance of event A (0 to 1) P(packet loss) = 0.02
Expected Value E[X] Average outcome Average sensor reading
Variance Var(X) Spread around average Noise level
Standard Deviation σ √Variance ±σ covers 68% of readings

Practical Example - Sensor Reliability:

If a sensor has 99.9% uptime: - P(working) = 0.999 - P(failure) = 0.001

For 100 sensors, expected failures = 100 × 0.001 = 0.1 per unit time

9.7.2 D.2 Gaussian (Normal) Distribution

The Core Idea

The Gaussian distribution (bell curve) describes random noise in most physical systems. It’s characterized by mean (μ) and standard deviation (σ).

\[p(x) = \frac{1}{\sigma\sqrt{2\pi}} e^{-\frac{(x-\mu)^2}{2\sigma^2}}\]

Properties:

  • 68% of values within μ ± 1σ
  • 95% of values within μ ± 2σ
  • 99.7% of values within μ ± 3σ

IoT Application - Sensor Noise:

A temperature sensor with: - Mean reading: μ = 25.0°C - Noise: σ = 0.5°C

95% of readings will be between 24.0°C and 26.0°C.

9.7.3 D.3 Sensor Fusion: Combining Measurements

When you have two noisy measurements of the same thing, the optimal combination is:

\[x_{combined} = \frac{\sigma_2^2 \cdot x_1 + \sigma_1^2 \cdot x_2}{\sigma_1^2 + \sigma_2^2}\]

Intuition: Weight each measurement inversely by its uncertainty. Trust the more precise sensor more.

Example:

  • GPS says position is 100m (σ = 10m)
  • Accelerometer integration says 95m (σ = 5m)

\[x_{combined} = \frac{25 \times 100 + 100 \times 95}{100 + 25} = \frac{2500 + 9500}{125} = 96m\]

The combined estimate is closer to the accelerometer (more precise).

9.8 E. Modular Arithmetic for Cryptography

9.8.1 E.1 The Modulo Operation

The Core Idea

Modular arithmetic is “clock arithmetic.” After reaching a maximum value, numbers wrap around to zero.

Notation: \(a \mod n\) = remainder when a is divided by n

Examples:

  • \(7 \mod 5 = 2\) (7 = 1×5 + 2)
  • \(25 \mod 7 = 4\) (25 = 3×7 + 4)
  • \(12 \mod 12 = 0\) (clock wraps at midnight)

9.8.2 E.2 Why Modular Arithmetic for Cryptography?

Key Property: Easy to compute forward, hard to reverse.

Example - Discrete Logarithm:

Given: \(g = 5\), \(p = 23\)

Forward (easy): Calculate \(5^7 \mod 23\) \[5^7 = 78125 \mod 23 = 17\]

Reverse (hard): Given 17, find x where \(5^x \mod 23 = 17\)

This “trapdoor” property enables public-key cryptography.

9.8.3 E.3 Diffie-Hellman Key Exchange

Two IoT devices can agree on a shared secret over an insecure channel:

Diffie-Hellman key exchange sequence diagram showing two IoT devices agreeing on shared public parameters, each generating a private key, computing public values via modular exponentiation, exchanging public values, and deriving the same shared secret independently

Diffie-Hellman key exchange sequence
Figure 9.2: Diffie-Hellman key exchange between two IoT devices
Analogy-based explanation of Diffie-Hellman using color mixing. Public shared starting color is Yellow (known to everyone including eavesdropper). Device A mixes with secret Red to get Orange, sends Orange publicly. Device B mixes with secret Blue to get Green, sends Green publicly. Device A takes Green (from B) and adds its secret Red to get Brown. Device B takes Orange (from A) and adds its secret Blue to get same Brown. Eavesdropper sees Yellow, Orange, Green but cannot unmix to find Red or Blue, so cannot compute Brown. The shared secret Brown is known only to A and B. This paint mixing analogy illustrates why DH is secure: mixing is easy, unmixing is computationally hard.
Figure 9.3: Alternative View: Paint Mixing Analogy - This diagram explains Diffie-Hellman using a color mixing analogy. Both devices start with shared public Yellow. Device A mixes with secret Red to create Orange. Device B mixes with secret Blue to create Green. They exchange Orange and Green publicly. A then adds Red to Green, B adds Blue to Orange - both get the same Brown (shared secret). The eavesdropper sees Yellow, Orange, and Green but cannot “unmix” colors to find the secrets. In math terms: mixing colors is easy (modular exponentiation), but unmixing is computationally hard (discrete logarithm). This is why Diffie-Hellman works for IoT key exchange.

An eavesdropper sees only 8 and 19 - computing the shared secret requires solving the discrete logarithm problem (computationally infeasible for large numbers).

9.9 F. Complex Numbers for Signal Processing

9.9.1 F.1 What Are Complex Numbers?

The Core Idea

Complex numbers extend real numbers to include \(i = \sqrt{-1}\). They’re essential for representing signals that have both amplitude and phase.

Form: \(z = a + bi\) - \(a\) = real part - \(b\) = imaginary part

Alternative (Polar) Form: \(z = r \cdot e^{i\theta}\) - \(r\) = magnitude (amplitude) - \(\theta\) = phase angle

9.9.2 F.2 Why Complex Numbers in IoT?

1. Representing Sinusoidal Signals:

A sensor reading: \(v(t) = A \cos(\omega t + \phi)\)

Using Euler’s formula: \(e^{i\theta} = \cos\theta + i\sin\theta\)

We can write: \(v(t) = \text{Re}[A \cdot e^{i(\omega t + \phi)}]\)

2. Fourier Transform:

Converts time-domain signals to frequency-domain: \[X(f) = \int_{-\infty}^{\infty} x(t) \cdot e^{-i2\pi ft} \, dt\]

The result is complex: - Magnitude \(|X(f)|\) tells you “how much” of each frequency - Phase \(\angle X(f)\) tells you “when” each frequency component peaks

3. I/Q Signals in Radio:

LoRa and other radios use I/Q (In-phase/Quadrature) representation: - I = real part of signal - Q = imaginary part of signal

This allows representing any modulation scheme.

9.9.3 F.3 Complex Number Operations

Operation Formula Signal Processing Meaning
Addition \((a+bi) + (c+di) = (a+c) + (b+d)i\) Superimposing signals
Magnitude \(|a+bi| = \sqrt{a^2+b^2}\) Signal amplitude
Phase \(\angle(a+bi) = \arctan(b/a)\) Signal timing
Multiplication Magnitudes multiply, phases add Mixing/modulation

9.10 G. Information Theory Basics

9.10.1 G.1 Bits and Entropy

The Core Idea

Entropy measures information content or uncertainty. More unpredictable data requires more bits to represent.

Entropy formula: \[H = -\sum_i p_i \log_2(p_i)\]

Where \(p_i\) is the probability of each outcome.

Example - Sensor Alarm:

  • Alarm triggers 1% of the time
  • \(H = -(0.01 \log_2 0.01 + 0.99 \log_2 0.99)\)
  • \(H = -(0.01 \times -6.64 + 0.99 \times -0.014) = 0.08\) bits

The alarm provides only 0.08 bits of information per reading (very predictable).

9.10.2 G.2 Shannon Capacity

The maximum rate at which information can be reliably transmitted:

\[C = B \log_2(1 + SNR)\]

Practical Implications:

SNR Capacity (per Hz of bandwidth)
1 (0 dB) 1 bit/s/Hz
3 (5 dB) 2 bit/s/Hz
7 (8.5 dB) 3 bit/s/Hz
15 (12 dB) 4 bit/s/Hz
31 (15 dB) 5 bit/s/Hz

Key Insight: To double capacity, you need to roughly quadruple SNR. This explains why LoRa trades data rate for range (lower SNR = lower rate but still works).

9.11 H. Quick Reference Card

9.11.1 Essential Formulas for IoT

9.11.1.1 Signal Processing

Formula Expression
Nyquist Rate \(f_{sample} \geq 2 \times f_{max}\)
Shannon Capacity \(C = B \times \log_2(1 + SNR)\)
dB conversion \(dB = 10 \times \log_{10}(P_2/P_1)\)
dBm from mW \(dBm = 10 \times \log_{10}(P_{mW})\)

9.11.1.2 Wireless

Formula Expression
Free Space Loss \(FSPL = 20\log_{10}(d) + 20\log_{10}(f) + 20\log_{10}(4\pi/c)\)
Link Budget \(P_{rx} = P_{tx} + G_{tx} + G_{rx} - L_{path}\)
Path Loss (approx) \(L \propto d^n\) (n = 2 free space, 3-4 urban)

9.11.1.3 Electronics

Formula Expression
Ohm’s Law \(V = I \times R\)
Power \(P = V \times I = I^2R = V^2/R\)
RC Time Constant \(\tau = R \times C\)
Capacitor Voltage \(V(t) = V_0 \times e^{-t/\tau}\)

9.11.1.4 Battery Life

Formula Expression
Average Current \(I_{avg} = (I_{active} \times D) + (I_{sleep} \times (1-D))\)
Battery Life \(Hours = mAh / mA_{average}\)

9.11.1.5 Sensor Fusion

Formula Expression
Weighted Average \(x = (\sigma_2^2 \times x_1 + \sigma_1^2 \times x_2) / (\sigma_1^2 + \sigma_2^2)\)
Combined Variance \(\sigma^2 = (\sigma_1^2 \times \sigma_2^2) / (\sigma_1^2 + \sigma_2^2)\)

9.11.1.6 Probability

Formula Expression
Gaussian 68-95-99 \(\mu \pm 1\sigma\) (68%), \(\mu \pm 2\sigma\) (95%), \(\mu \pm 3\sigma\) (99.7%)
Expected Value \(E[X] = \sum(x \times P(x))\)

Common Pitfalls

Every IoT calculation has units that must be tracked: mA for current, mAh for battery capacity, dBm for signal power, Hz for frequency, seconds for time. Applying the battery life formula with mA in the numerator and mAh in the denominator gives hours correctly; confusing mA with uA gives an answer 1000x too large. Always write out units in intermediate steps and verify unit cancellation before trusting a numeric result.

RF engineers universally use dB (decibels) for signal strength because path loss spans 6 orders of magnitude (0.001 mW to 1000 mW). A 3 dB increase means double the power, not a 3% increase. Students who add dB values arithmetically (10 dBm + 10 dBm = 20 dBm, assuming 20 mW) make 100x errors. Remember: add dB values for gains/losses in a chain, but convert to linear scale first when adding powers from independent sources.

The Gaussian noise model works well for electronic noise (thermal noise, quantization noise) but fails for systematic errors (calibration drift, EMI interference, sensor saturation). Before applying the 68-95-99.7 rule to your sensor’s error budget, verify that actual error samples look bell-shaped by plotting a histogram. Outlier-prone sensors need robust statistics (median, IQR) rather than mean and standard deviation.

9.13 Summary

This appendix covered the mathematical foundations used throughout the IoT textbook:

Topic Key Concept Primary Use
Calculus Rates & accumulation PID control, energy budgets
Exponentials Growth/decay Signal attenuation, battery life
Logarithms Compression dB scales, Shannon capacity
Linear Algebra Vectors, matrices Sensor fusion, Kalman filter
Probability Uncertainty Noise modeling, reliability
Modular Arithmetic Wraparound math Cryptography
Complex Numbers Amplitude + phase Signal processing, radio
Information Theory Bits, entropy Channel capacity, compression

You’re building a fleet tracking system using GPS (±10m accuracy) and an accelerometer-based dead reckoning system. Here’s how to apply the mathematical foundations to implement sensor fusion.

Step 1: Model the System State

From Section C.2 (Matrices), define state vector as position and velocity:

\[\vec{x} = \begin{bmatrix} p_x \\ p_y \\ v_x \\ v_y \end{bmatrix}\]

Where: - \(p_x, p_y\) = position (meters) - \(v_x, v_y\) = velocity (meters/second)

Step 2: State Transition (Prediction)

From Section A.1 (Derivatives) and A.2 (Integrals), position changes via velocity integration:

\[p_{new} = p_{old} + v \cdot \Delta t\]

In matrix form (Section C.3):

\[\vec{x}_{k+1} = F \cdot \vec{x}_k + \vec{w}_k\]

\[F = \begin{bmatrix} 1 & 0 & \Delta t & 0 \\ 0 & 1 & 0 & \Delta t \\ 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 1 \end{bmatrix}\]

Example: Current state is position (100m, 200m), velocity (15 m/s, 0 m/s), \(\Delta t = 0.1s\)

\[\begin{bmatrix} p_x \\ p_y \\ v_x \\ v_y \end{bmatrix}_{new} = \begin{bmatrix} 1 & 0 & 0.1 & 0 \\ 0 & 1 & 0 & 0.1 \\ 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 1 \end{bmatrix} \begin{bmatrix} 100 \\ 200 \\ 15 \\ 0 \end{bmatrix} = \begin{bmatrix} 101.5 \\ 200 \\ 15 \\ 0 \end{bmatrix}\]

Predicted position: (101.5m, 200m) after 0.1 seconds.

Step 3: Measurement Update (GPS Reading)

GPS reports position (103m, 201m) with σ = 10m uncertainty.

From Section D.2 (Gaussian Distribution), GPS measurement has: - Mean: μ = (103, 201) - Covariance: \(\sigma^2 = 100\) (since σ = 10m)

From Section D.3 (Sensor Fusion), combine prediction with measurement:

\[p_{fused} = \frac{\sigma_{GPS}^2 \cdot p_{pred} + \sigma_{pred}^2 \cdot p_{GPS}}{\sigma_{pred}^2 + \sigma_{GPS}^2}\]

Assume prediction uncertainty \(\sigma_{pred} = 5m\) (accelerometer integration), GPS uncertainty \(\sigma_{GPS} = 10m\):

X-coordinate: \[p_x = \frac{100 \cdot 101.5 + 25 \cdot 103}{25 + 100} = \frac{10150 + 2575}{125} = \frac{12725}{125} = 101.8m\]

Y-coordinate: \[p_y = \frac{100 \cdot 200 + 25 \cdot 201}{125} = \frac{20000 + 5025}{125} = 200.2m\]

Fused estimate: (101.8m, 200.2m)

Notice the fused position is closer to the prediction (101.5, 200) than the GPS (103, 201) because prediction is 2× more accurate (\(\sigma=5\) vs \(\sigma=10\)).

Step 4: Uncertainty Reduction

From Section D.3, combined variance:

\[\sigma_{fused}^2 = \frac{\sigma_{pred}^2 \cdot \sigma_{GPS}^2}{\sigma_{pred}^2 + \sigma_{GPS}^2} = \frac{25 \cdot 100}{25 + 100} = \frac{2500}{125} = 20\]

\[\sigma_{fused} = \sqrt{20} = 4.47m\]

Interpretation: Fusing 5m-accurate prediction with 10m-accurate GPS yields 4.47m accuracy - better than either sensor alone!

Step 5: Real-World Performance Calculation

For a delivery truck moving at 60 km/h (16.67 m/s):

  • GPS update rate: 1 Hz (once per second)
  • Dead reckoning uncertainty growth: 2% per second (from accelerometer bias)

Between GPS updates (1 second):

  • Distance traveled: 16.67 meters
  • Dead reckoning error: 16.67 × 0.02 = 0.33m (grows linearly)
  • Fused uncertainty after 1 sec: \(\sigma = \sqrt{4.47^2 + 0.33^2} = 4.48m\)

After GPS update:

  • Pre-update: σ = 4.48m
  • Post-fusion: σ = 4.47m (Kalman correction brings accuracy back)

Key Insight: Kalman filter prevents dead reckoning drift by periodically re-anchoring position with GPS, while smoothing GPS noise with prediction.

Implementation Pseudocode:

# Initialize state
state = [position_x, position_y, velocity_x, velocity_y]
P = [[25, 0, 0, 0],    # Position covariance matrix (5m uncertainty)
     [0, 25, 0, 0],
     [0, 0, 4, 0],     # Velocity covariance (2 m/s uncertainty)
     [0, 0, 0, 4]]

# Prediction step (every 0.1 seconds)
state_predicted = F @ state  # Matrix multiplication from Section C.3
P_predicted = F @ P @ F.T + Q  # Add process noise Q

# Measurement step (GPS reading every 1 second)
innovation = gps_reading - H @ state_predicted  # H extracts position
S = H @ P_predicted @ H.T + R  # Innovation covariance (R = GPS noise)
K = P_predicted @ H.T @ inv(S)  # Kalman gain (optimal weighting)
state = state_predicted + K @ innovation  # Update state
P = (I - K @ H) @ P_predicted  # Update covariance

Math concepts used: Vectors (C.1), matrices (C.2), matrix multiplication (C.3), Gaussian distribution (D.2), sensor fusion (D.3), integrals (A.2).

Use this framework to determine the minimum ADC sampling rate for your sensor based on signal frequency content.

9.13.1 The Nyquist Rule (Section A.1 + Quick Reference)

\[f_{sample} \geq 2 \times f_{max}\]

Where \(f_{max}\) is the highest frequency component in your signal. But how do you find \(f_{max}\)?

9.13.2 Step-by-Step Decision Process

Signal Type Frequency Estimation Method Example Calculation Recommended Sampling Rate
Temperature (slow) Physical time constant Thermocouple: τ = 1s → \(f_{max} = 1/(2\pi\tau) = 0.16\) Hz 0.5 Hz (2 samples/sec)
Vibration Mechanical resonance Motor bearing: \(f_{max}\) = 120 Hz (2× rotation speed) 250 Hz (Nyquist) + anti-alias filter
Audio Human hearing range Speech: 20 Hz - 8 kHz 16 kHz (telephone quality)
Accelerometer Expected motion Hand gesture: 0-10 Hz 25 Hz (2.5× Nyquist for margin)
Voltage ripple Power supply frequency AC mains: 60 Hz + harmonics → 300 Hz 1 kHz (capture up to 5th harmonic)

9.13.3 Worked Example: Vibration Monitoring on Industrial Motor

Background: 1800 RPM motor (30 Hz rotation), 4-blade fan

Step 1: Identify Frequency Components

From Section B.1 (Exponential Functions) and mechanical theory:

  • Fundamental: Motor rotation = 30 Hz
  • Blade pass frequency: 4 blades × 30 Hz = 120 Hz
  • Harmonics: Up to 3× fundamental for imbalance detection = 120 × 3 = 360 Hz

Step 2: Apply Nyquist Theorem

\[f_{sample} \geq 2 \times 360 = 720 \text{ Hz}\]

Step 3: Add Safety Margin

Industry standard: 2.5× Nyquist to account for filter roll-off

\[f_{sample} = 2.5 \times 720 = 1800 \text{ Hz}\]

Step 4: Select Standard ADC Rate

Common options: 1 kHz, 2 kHz, 5 kHz, 10 kHz

Decision: 2 kHz (exceeds requirement, standard IC availability)

9.13.4 Anti-Aliasing Filter Design

From Section A.2 (RC Time Constant):

Goal: Attenuate frequencies above 360 Hz before sampling at 2 kHz

Filter cutoff frequency: \(f_c = 400\) Hz (between signal and Nyquist/2)

\[f_c = \frac{1}{2\pi RC}\]

\[RC = \frac{1}{2\pi \times 400} = 398 \mu s\]

Choose: \(R = 10k\Omega\), then \(C = 398 \mu s / 10k\Omega = 39.8 nF\) → Use standard 39 nF capacitor

9.13.5 Real-World Tradeoffs

Sampling Rate Data Rate (16-bit samples) Pros Cons
720 Hz (minimum Nyquist) 11,520 bits/sec Low power, minimal storage No margin, aliasing risk
2 kHz (recommended) 32,000 bits/sec Safe margin, standard ADCs 2.8× data volume
10 kHz (over-sampled) 160,000 bits/sec Digital filtering, noise averaging 14× data volume, unnecessary

Energy Impact (from Section A.2, Energy Budget):

ADC power: 5 mW active, conversion time: 10 µs

  • 720 Hz: Duty cycle = 720 × 10µs = 0.72%, average power = 5mW × 0.0072 = 36 µW
  • 2 kHz: Duty cycle = 2000 × 10µs = 2%, average power = 100 µW
  • 10 kHz: Duty cycle = 10%, average power = 500 µW

Battery life impact (2000 mAh at 3.3V):

  • 2 kHz: 100 µW → 30 µA → 2000/0.03 = 66,667 hours = 7.6 years
  • 10 kHz: 500 µW → 150 µA → 13,333 hours = 1.5 years

Decision: 2 kHz sampling provides 5× safety margin while preserving 7+ year battery life. 10 kHz over-sampling wastes 80% of battery life with no signal quality benefit.

9.13.6 Common Mistake: Under-Sampling

Example: Student samples 60 Hz mains voltage at 100 Hz

\[f_{sample} = 100 \text{ Hz}, \quad f_{signal} = 60 \text{ Hz}\]

Nyquist requires \(f_{sample} > 120\) Hz, so 100 Hz causes aliasing.

What happens: 60 Hz signal appears as 40 Hz after aliasing (\(|100 - 60| = 40\) Hz)

Fix: Sample at ≥150 Hz (2.5× Nyquist) → use 250 Hz for standard ADC compatibility

Common Mistake: Misapplying dB Calculations to Voltage vs. Power

The Problem: Students often use the power formula \(dB = 10\log_{10}(P_2/P_1)\) when comparing voltages, leading to 6 dB errors.

Real Example from Student Report:

“Our amplifier increased signal voltage from 0.1V to 1.0V, a gain of 10 dB.”

What’s wrong?

From Section B.2 (Logarithms), dB formulas differ for power vs. voltage:

Quantity Formula Correct Calculation
Power ratio \(dB = 10\log_{10}(P_2/P_1)\) 10× power = 10 dB
Voltage ratio \(dB = 20\log_{10}(V_2/V_1)\) 10× voltage = 20 dB

Why the factor of 20 for voltage?

From basic electronics (Section A.2, Power formula):

\[P = \frac{V^2}{R}\]

If voltage doubles, power quadruples (voltage squared relationship).

\[dB = 10\log_{10}\left(\frac{P_2}{P_1}\right) = 10\log_{10}\left(\frac{V_2^2/R}{V_1^2/R}\right) = 10\log_{10}\left(\frac{V_2^2}{V_1^2}\right)\]

\[= 10\log_{10}\left[\left(\frac{V_2}{V_1}\right)^2\right] = 10 \times 2 \times \log_{10}\left(\frac{V_2}{V_1}\right) = 20\log_{10}\left(\frac{V_2}{V_1}\right)\]

Corrected Calculation:

Voltage gain from 0.1V → 1.0V:

\[dB = 20\log_{10}\left(\frac{1.0}{0.1}\right) = 20\log_{10}(10) = 20 \times 1 = 20 \text{ dB}\]

The student’s 10 dB answer is off by 6 dB (a factor of 2× in linear terms).

9.13.7 Decision Matrix: Power vs. Voltage dB

Measurement Type Use This Formula Example
Transmit power (mW) \(dBm = 10\log_{10}(P_{mW})\) 100 mW → 20 dBm
Antenna gain (power ratio) \(dB = 10\log_{10}(P_{out}/P_{in})\) 2× power → 3 dB
Signal voltage (ADC reading) \(dBV = 20\log_{10}(V)\) 1.0 V → 0 dBV
Path loss (power reduction) \(dB = 10\log_{10}(P_{rx}/P_{tx})\) 0.01× power → -20 dB
Amplifier gain (voltage) \(dB = 20\log_{10}(V_{out}/V_{in})\) 10× voltage → 20 dB
SNR (power ratio) \(dB = 10\log_{10}(S/N)\) 100:1 → 20 dB SNR

9.13.8 Quick Lookup Table (Section B.2)

Linear Ratio Power dB (10 log) Voltage dB (20 log)
0.5× (half) -3 dB -6 dB
2× (double) +3 dB +6 dB
10× +10 dB +20 dB
100× +20 dB +40 dB
1000× +30 dB +60 dB

Memory trick: Voltage uses 20 log because power depends on voltage SQUARED (the 2 becomes a multiplier in the log).

9.13.10 Rule Summary

  1. Power quantities (W, mW, dBm): Use \(10\log_{10}\)
  2. Voltage quantities (V, dBV): Use \(20\log_{10}\)
  3. Always label units (dBm, dBV, dB relative to reference)
  4. Never mix voltage dB with power dB in same calculation

When in doubt: Check if your measurement is voltage (from ADC, oscilloscope) → 20 log. If it’s power (from spectrum analyzer, RF meter) → 10 log.

9.14 Knowledge Check

9.15 Try It Yourself

Objective: Apply integrals (energy budgeting) and exponentials (battery discharge curves) to estimate how long an ESP32 sensor will run on 2× AA batteries.

Given Data:

  • Battery capacity: 2× AA alkaline = 2,000 mAh at 3V (6,000 mWh total energy)
  • ESP32 power states:
    • Active (WiFi transmit): 160 mA for 2 seconds
    • Light sleep: 0.8 mA for 58 seconds
    • Measurement interval: Every 60 seconds

Step 1: Calculate Average Current (from Section A.2, Integrals)

Using the duty cycle formula from Quick Reference:

\[I_{avg} = (I_{active} \times D_{active}) + (I_{sleep} \times D_{sleep})\]

Where D = duty cycle (fraction of time): - \(D_{active} = 2s / 60s = 0.0333\) (3.3% of time) - \(D_{sleep} = 58s / 60s = 0.9667\) (96.7% of time)

\[I_{avg} = (160mA \times 0.0333) + (0.8mA \times 0.9667)\] \[I_{avg} = 5.33mA + 0.77mA = 6.1mA\]

Step 2: Calculate Battery Life

\[Hours = \frac{Battery\ Capacity\ (mAh)}{Average\ Current\ (mA)} = \frac{2000mAh}{6.1mA} = 328\ hours\]

\[Days = 328 \div 24 = 13.7\ days\]

Step 3: Account for Battery Discharge Curve (Section B.1, Exponentials)

Alkaline batteries don’t provide constant voltage—they follow exponential decay. Usable capacity is ~80% at 1.1V cutoff:

\[Days_{actual} = 13.7 \times 0.80 = 11\ days\]

Challenge Extension:

  • What if you reduce transmit time to 1 second (faster WiFi)? Recalculate \(I_{avg}\).
  • What if you switch to lithium AA (2,500 mAh, flatter discharge curve = 90% usable)? New battery life?
  • Use Section B.1 RC time constant: If ESP32 has 100µF decoupling cap, how long to charge from sleep voltage?

Answer: With 1s transmit, \(I_{avg}\) drops to 3.44 mA → 19.3 days (alkaline) or 27 days (lithium).

Why This Matters: Battery life estimation is the #1 requirement for field-deployed IoT. This exercise applies integrals (averaging), exponentials (discharge curves), and real-world engineering judgment (efficiency factors).

9.16 Concept Relationships

How Math Concepts Connect in IoT Systems

Calculus → Signal Processing:

  • Derivatives detect rapid changes (anomaly detection: sudden temperature spike)
  • Integrals smooth noisy data (moving average filter = discrete integral)
  • Fourier Transform (Section F.2) decomposes signals into frequency components for filtering

Exponentials + Logarithms → Wireless Communication:

  • Exponential decay models signal attenuation: \(P = P_0 e^{-\alpha d}\)
  • Logarithms (dB scale) compress 100,000:1 power ranges into manageable numbers
  • Shannon Capacity links SNR (exponential in linear scale) to data rate via logarithm

Linear Algebra → Sensor Fusion:

  • Vectors represent multi-axis sensor data (accelerometer: \([a_x, a_y, a_z]\))
  • Matrices transform coordinate frames (rotate sensor orientation)
  • Kalman Filter (Section C.2) uses matrix multiplication to fuse GPS + IMU

Probability → Reliability & Quality:

  • Gaussian distribution models sensor noise (Section D.2)
  • Expected value predicts component failure rates
  • Sensor fusion weights measurements by inverse variance (trust precise sensors more)

Modular Arithmetic → Security:

  • Diffie-Hellman key exchange (Section E.3) uses “easy forward, hard reverse” property
  • Public-key cryptography relies on discrete logarithm difficulty
  • Hash functions (checksums, message authentication) use modular arithmetic

The Integration: A GPS-IMU tracker uses ALL these: calculus (integrate acceleration → velocity → position), logarithms (dB for signal strength), linear algebra (Kalman filter matrices), probability (sensor noise models), and modular arithmetic (encrypted data transmission).

9.17 See Also

Related Resources

Within This Module:

  • Glossary - Definitions for technical terms (dB, Shannon Capacity, Kalman Filter)
  • Visual Style Guide - IEEE color palette used in mathematical diagrams

Applied Mathematics (Cross-Module):

Interactive Tools:

Reference Materials:

  • Quick Reference Card (Section H) - Copy-paste formulas for IoT calculations
  • Worked Example: Kalman Filter (Section D.3) - Full GPS-accelerometer fusion walkthrough
  • Decision Framework: Sampling Rates (Section A.1) - Nyquist theorem application guide

9.18 What’s Next

If you want to… Read this
Apply calculus concepts to PID control system design Process Control and PID
Use probability theory in sensor fusion and Kalman filtering Sensor Fusion Fundamentals
Apply logarithms (dB) to wireless signal budget calculations Wireless Sensor Network Fundamentals
Apply statistical analysis to time-series IoT data Time-Series Queries
Access reference materials and supplementary content Appendix