16 IoT Mathematics: Fusion and Sampling Decisions

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$

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

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

Step 3: Measurement Update (GPS Reading)

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

From Section D.2 (Gaussian Distribution), GPS measurement has:

• Mean: mu = (103, 201)
• Covariance: $\sigma^2 = 100$ (since sigma = 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 2x 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 x 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: sigma = 4.48m
• Post-fusion: sigma ≈ 4.09m (the new GPS update reduces uncertainty below its pre-update value)

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).

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

Given Data:

• Battery capacity: two AA alkaline = 2,000 mAh at 3V (6,000 mWh total energy)
• ESP32 power states:
  • Active (Wi-Fi 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 terminal voltage changes during discharge; its usable capacity depends on load, temperature, and the device cutoff voltage. Assume usable capacity is ~80% at a 1.1V cutoff:

$Days_{actual} = 13.7 \times 0.80 = 11\ days$

Challenge Extension:

• What if you reduce transmit time to 1 second (faster Wi-Fi)? 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 100uF 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).