9 Mathematical Foundations for IoT
capstone
mathematical
foundations
9.1 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 Start With The Decision The Number Supports
A formula is useful only when it changes an engineering decision. Before calculating, say what the number will decide: gateway spacing, battery size, sample rate, alert threshold, filter cutoff, storage retention, or key length. Then write the units and assumptions beside the equation so the result can be challenged later.
That turns math into a reviewable capstone artifact. A link budget is not just dBm arithmetic; it is a claim about range under named antenna, path-loss, receiver-sensitivity, and fade-margin assumptions. A battery estimate is not just milliamp-hours divided by current; it is a claim about active time, sleep current, warm-up, retries, regulator loss, temperature, and replacement interval. A probability threshold is not just a percentage; it is a claim about false alarms, missed events, and sensor noise.
Start with the decision, then carry the units, then record the assumption that would make the answer unsafe. The later sections give the tools, but this habit decides whether the tool is being used honestly.
Phoebe’s Field Notes: Where the Capstone Formulas Come From
9.2.1 Phoebe’s Why
The formulas in a capstone are compact physics statements, not magic spreadsheet entries. A radio link budget starts with power spreading over a sphere. A sampling rule starts with copied spectra not overlapping. An ADC SNR limit starts with the unavoidable rounding error of a finite code. An RC filter starts with charge stored on a capacitor. A battery estimate starts with charge being removed over time. When the derivation stays visible, the team can see which assumption would break the result in the field.
9.2.2 The Derivation
Free-space radio begins with transmit power \(P_t\) spread over area \(4\pi d^2\):
\[S = \frac{P_tG_t}{4\pi d^2}\]
An antenna collects with effective aperture:
\[A_e = \frac{G_r\lambda^2}{4\pi}\]
So Friis is:
\[P_r = P_tG_tG_r\left(\frac{\lambda}{4\pi d}\right)^2\]
and free-space path loss is:
\[\mathrm{FSPL} = \left(\frac{4\pi d}{\lambda}\right)^2\]
Because \(\lambda = c/f\):
\[\mathrm{FSPL}_{dB} = 20\log_{10}(d) + 20\log_{10}(f) + 20\log_{10}\left(\frac{4\pi}{c}\right)\]
Decibels come from power ratios:
\[L_{dB} = 10\log_{10}\left(\frac{P_2}{P_1}\right)\]
so multiplied gains and losses become addition:
\[P_{rx,dBm} = P_{tx,dBm} + G_{tx,dB} + G_{rx,dB} - L_{path,dB}\]
Sampling repeats a spectrum every \(f_s\) hertz:
\[X_s(f) = \sum_{k=-\infty}^{\infty}X(f-kf_s)\]
Non-overlap requires:
\[f_{max} \leq f_s - f_{max}\]
therefore:
\[f_s \geq 2f_{max}\]
Quantization step size is:
\[q = \frac{V_{FS}}{2^N}\]
Uniform rounding noise has mean-square value:
\[\overline{e^2} = \frac{q^2}{12}\]
For a full-scale sine wave:
\[\mathrm{SNR}_{dB} = 10\log_{10}\left(1.5 \times 2^{2N}\right)\]
\[\mathrm{SNR}_{dB} \approx 6.02N + 1.76\]
For an RC low-pass filter, the capacitor law \(i = C\,dV/dt\) and Ohm’s law give exponential settling with:
\[\tau = RC\]
and cutoff:
\[f_c = \frac{1}{2\pi RC}\]
Battery runtime is charge divided by average current:
\[I_{avg} = \frac{\sum I_i t_i}{\sum t_i}\]
\[t_{hours} = \frac{\mathrm{capacity}_{mAh}}{I_{avg,mA}}\]
9.2.3 Worked Numbers: This Chapter’s Calculation Records
- Shannon ceiling: \(C = B\log_2(1+\mathrm{SNR}) = 125000\log_2(11) = 432429\) bit/s \(\approx 432\) kbit/s
- Link budget: \(P_{rx} = 14 - 120 = -106\) dBm, and margin \(= -106 - (-137) = 31.0\) dB, or \(10^{31/10} = 1.26\times10^3\) times the minimum receiver power
- Sampling: the chapter’s \(360\) Hz vibration content needs \(f_s \geq 2(360) = 720\) Hz; a \(2\) kHz choice gives \(2000/720 = 2.78\times\) the minimum and a \(1000\) Hz Nyquist frequency
- Sixteen-bit data stream: ideal quantization SNR \(= 6.02(16) + 1.76 = 98.1\) dB, while the data rate at \(2\) kHz is \(2000 \times 16 = 32000\) bit/s
- RC anti-alias filter: for \(f_c = 400\) Hz, \(RC = 1/(2\pi 400) = 398\) us; with \(R = 10\) kohm, \(C = 398\) us\(/10000 = 39.8\) nF
- Battery record: \(I_{avg} = 160(2/60) + 0.8(58/60) = 5.33 + 0.773 = 6.11\) mA, so \(2000/6.11 = 328\) h \(= 13.7\) days
Each answer is only as strong as the assumption beside it: free-space geometry for FSPL, band-limited input before sampling, uniform quantization error, a first-order RC model, and usable battery capacity at the stated current and temperature.
Chapter Roadmap
This is a long reference chapter, so use it as a guided toolkit:
- First anchor every formula to the decision, evidence term, and unsafe assumption it supports.
- Then review calculus, exponentials, and logarithms for change, accumulation, ratios, dB, and Shannon capacity.
- Next use vectors, matrices, probability, and covariance to reason about sensor fusion and uncertainty.
- After that connect modular arithmetic, complex numbers, and information theory to security, radio, and signal processing.
- Finally use the quick reference, worked examples, quizzes, and hands-on exercise to turn the ideas into capstone checks.
Checkpoints recap the tools you have already met, and collapsed callouts can be treated as deep dives on a first pass.
9.3 Deep Dive: Math Turns IoT Guesswork into Bounds
IoT math is useful when it turns an engineering question into a bounded decision. A derivative can say whether temperature is rising fast enough to trigger an alert. An integral can estimate whether a battery survives the duty cycle. A logarithm can compare received power and link margin. A probability model can decide whether a noisy sensor reading is reliable enough to act on.
The goal is not symbolic elegance. The goal is to know which tool belongs to the problem, which units must be carried through the calculation, and which assumption would make the answer unsafe. The link-budget figure shows a common pattern: a design claim becomes stronger only when each term in the chain is named. Transmit power, antenna gain, cable loss, path loss, receiver sensitivity, and fade margin are not decorative variables; each one can be measured, specified, or challenged in a review.
The same pattern applies outside radio work. A battery estimate is weak until active current, sleep current, wake time, sensor warm-up, regulator loss, and temperature derating are visible. A PID controller is weak until sample time, actuator limits, overshoot, accumulated error, and noise filtering are visible. A Kalman filter is weak until process noise, measurement noise, timestamp alignment, and coordinate frame are visible. Mathematical foundations help a capstone team replace “it should work” with a bounded claim that someone else can test.
| Question Type | Useful Tools | IoT Decisions They Support |
|---|---|---|
| Rate | Derivatives, differences, filters | Drift, acceleration, PID control, change detection, event thresholds |
| Total | Integrals, sums, duty-cycle averages | Energy, data volume, airtime, cost, exposure over time |
| Uncertainty | Probability, covariance, confidence intervals | Noise filtering, false alarms, sensor fusion, reliability claims |
| Range and ratio | Logarithms, dB, dBm, Shannon capacity | Link budgets, SNR, path loss, throughput limits |
Every practical IoT calculation should preserve units. RSSI in dBm, transmit power in dBm, antenna gain in dBi, path loss in dB, current in milliamps, charge in mAh, energy in joules or watt-hours, sample interval in seconds, and payload size in bytes cannot be mixed casually. Most field mistakes come from a correct-looking formula applied to incompatible units or an unrealistic time window.
Start with the decision the calculation is meant to support. If the decision is gateway spacing, write a link budget in dBm/dBi/dB and include antenna orientation, mounting height, indoor attenuation, regional transmit limit, receiver sensitivity at the selected data rate, and fade margin. If the decision is sample rate, write the highest signal frequency, anti-aliasing filter behavior, ADC resolution, storage budget, and event latency. If the decision is battery size, write the current profile for boot, sensing, compute, radio join, transmit, receive window, retry, sleep, and worst-case temperature.
Then keep the calculation tied to evidence. A spreadsheet row, bench log, packet capture, datasheet value, spectrum reading, calibration curve, or field-trial measurement should back the terms that matter. When an assumption is borrowed from a datasheet or standard, record the boundary: temperature range, supply voltage, antenna gain condition, packet size, spreading factor, duty cycle, or sensor accuracy class. That record turns math into an engineering argument rather than a polished but unverifiable number.
- Name the decision. Example: alert threshold, gateway spacing, battery size, sample rate, filter cutoff, or key length.
- Write the equation with units. Keep dB/dBm, mA/mAh, seconds/hours, bits/bytes, and variance/standard deviation distinct.
- State the assumption. Include noise distribution, independence, sampling rate, radio model, clock stability, or component tolerance.
- Check the consequence. Decide whether the answer changes a design choice, safety margin, test plan, or field measurement.
Mathematical models are compact state machines. A PID loop stores current error, accumulated error, and rate of error change. A Kalman filter stores a state vector, covariance matrix, process noise, measurement noise, and update equations. A link budget stores transmit power, gains, losses, path model, receiver sensitivity, and required margin. A cryptographic exchange stores group parameters, private values, public values, and modular operations.
Those states explain why measurement quality matters. A GPS reading with 10 m uncertainty and an IMU estimate with drifting bias should not be averaged blindly. A LoRaWAN link with a positive margin in free-space math can still fail under indoor attenuation, gateway duty-cycle limits, antenna orientation, and interference. A Diffie-Hellman exchange is useful only when parameters, authentication, random generation, and key handling are correct.
| Model State | What Must Stay Visible |
|---|---|
| Control | Error, accumulated error, derivative estimate, saturation, sample time, and actuator limit |
| Fusion | Position, velocity, covariance, process noise, measurement noise, timestamp, and sensor frame |
| Wireless | Frequency, bandwidth, transmit power, antenna gain, path loss, noise floor, SNR, capacity, and margin |
| Security | Freshness, nonce, key lifetime, authentication state, and accepted parameters |
Checkpoint: Bounded Claims
You now know:
- Useful calculations start with a decision such as gateway spacing, battery size, sample rate, alert threshold, filter cutoff, storage retention, or key length.
- Units have to travel with the equation: dB/dBm, mA/mAh, seconds/hours, bits/bytes, and variance/standard deviation are not interchangeable labels.
- A calculation becomes defensible only when its evidence term and unsafe assumption are visible beside the numeric result.
9.4 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
- Analyze 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
The opening sections gave you the review habit: name the decision, carry the units, and keep assumptions visible. The rest of the chapter now walks through the mathematical tools that make those review records precise.
9.5 Math Makes IoT Claims Bounded
Mathematics in IoT is useful when it puts a boundary around a claim. It tells a team how far a radio link can degrade before packets fail, how long a battery can support a duty cycle, how noisy a sensor can be before an alert becomes untrustworthy, and how much delay a control loop can tolerate. The formula is not the final answer. The final answer is a design claim with units, assumptions, evidence, and margin.
Read this chapter as a map from engineering question to tool. Calculus handles change and accumulation: drift, velocity, current over time, energy, and PID error terms. Logarithms handle large ratios: dB, dBm, SNR, path loss, and Shannon capacity. Probability handles uncertainty: sensor noise, packet loss, confidence ranges, false alarms, and fleet reliability. Linear algebra handles state: accelerometer axes, GPS position, Kalman filter vectors, covariance, and coordinate transforms. Number theory and modular arithmetic support cryptographic operations such as Diffie-Hellman style key agreement. Complex numbers and information theory support radio, filtering, Fourier analysis, entropy, and channel limits.
The Shannon-Weaver model is the operating picture behind those information-theory terms: an information source creates a message, a transmitter or encoder turns it into a signal, a channel carries it while a noise source can corrupt it, and a receiver or decoder reconstructs a message for the destination. In an IoT link, the source might be a sensor event, the encoder might be firmware plus packet format, the channel might be a noisy radio or cable, and the destination might be a gateway rule or cloud application. Entropy, redundancy, noise, and channel capacity are not abstract labels in that chain; they decide how much uncertainty the message carries, how much protection the design adds, and what reliable rate the channel can support.
The core habit is to write down what the calculation can and cannot prove. A link budget can prove a margin under the path-loss and receiver-sensitivity assumptions you used; it cannot prove antenna installation quality. A Kalman update can combine prediction and measurement uncertainty; it cannot prove that timestamps and frames are aligned. A Shannon capacity estimate bounds throughput for a bandwidth and SNR; it cannot promise application latency through a congested gateway.
| Question | Math Tool | Evidence Term | Design Claim |
|---|---|---|---|
| Will the link close? | Logarithms, dB, path loss, SNR | RSSI/SNR, receiver sensitivity, antenna gain, fade margin | Gateway spacing has stated margin under measured conditions |
| Will the node last? | Integrals, sums, duty-cycle averages | Current profile, wake time, retry rate, regulator loss, temperature | Battery estimate includes operating modes and end-of-life margin |
| Can the sensor be trusted? | Probability, variance, covariance, filtering | Calibration data, noise model, outlier rule, timestamp source | Alert thresholds reflect uncertainty and false-positive cost |
| Can state be fused? | Vectors, matrices, Kalman update | State vector, covariance, process noise, measurement noise | Prediction and correction are repeatable across sample intervals |
9.6 Build A Calculation Record
For project work, turn every important formula into a calculation record. Begin with the decision: gateway spacing, sample rate, filter cutoff, alert threshold, battery capacity, storage volume, key size, or fusion model. Then write the equation with named units before entering numbers. Current in milliamps, charge in milliamp-hours, energy in joules, transmit power in dBm, gain in dBi, loss in dB, bandwidth in hertz, payload size in bytes, variance in squared units, and standard deviation in original units must not be treated as interchangeable labels.
Attach evidence to the terms that matter. A link-budget record should include transmit power, antenna gain, cable loss, receiver sensitivity for the selected data rate, path-loss model, regional limit, installation height, measured RSSI/SNR, and fade margin. A battery record should include boot current, sensor warm-up, MCU active current, radio join, transmit, receive windows, retry behavior, sleep leakage, regulator quiescent current, temperature derating, and battery chemistry. A sampling-rate record should include the highest signal frequency, Nyquist margin, anti-alias filter cutoff, ADC resolution, data volume, and event-latency requirement.
Use probability records when action depends on noisy data. Name the source of uncertainty, not just the symbol. For a temperature sensor, separate datasheet accuracy, calibration offset, self-heating, ADC noise, enclosure lag, and environmental variation. For a fleet tracker, separate GPS error, accelerometer bias, clock drift, and map-matching assumptions. A Gaussian model is helpful only after outliers, saturation, missing data, and systematic drift have been checked. If those dominate, use robust statistics, thresholds, or explicit fault states rather than pretending a bell curve explains everything.
Write the result in an auditable sentence: “With a 125 kHz channel, measured SNR of 10, and the Shannon bound as a ceiling, capacity is about 432 kbps before protocol overhead; the application budget must stay below that and be verified in a packet trace.” That sentence carries the input, method, limit, and next verification step.
9.7 Models Fail At Their Assumptions
Under the hood, mathematical models fail less often because the algebra is wrong and more often because the assumptions are invisible. Free-space path loss assumes a clean propagation model, while indoor deployments add wall loss, multipath, antenna orientation, human bodies, metal racks, humidity, and channel interference. Shannon capacity is an upper bound for a channel with bandwidth and SNR; it does not include MAC overhead, duty-cycle rules, retransmissions, encryption overhead, buffering, or application latency.
Control and sampling models have similar boundaries. A derivative of a noisy signal amplifies noise unless filtering and sample time are chosen carefully. An integral of error can wind up against actuator limits unless the PID controller has anti-windup behavior. Nyquist sampling prevents aliasing only when the signal is band-limited or an anti-alias filter removes high-frequency content before the ADC. An FFT peak is meaningful only when windowing, sampling rate, leakage, and calibration are understood.
Sensor fusion models hide state assumptions. A Kalman filter needs a state vector, transition model, process noise, measurement model, measurement noise, timestamp alignment, and coordinate frame. If the GPS fix is one second old and the accelerometer frame is rotated, the matrix equations can still run while the result is physically wrong. Covariance is a promise about uncertainty; it must be updated when sensors saturate, drift, drop packets, or enter a different environment.
Cryptographic math has its own boundary. Modular exponentiation and Diffie-Hellman style exchange depend on secure parameters, randomness, authentication, freshness, key derivation, and key storage. The hard discrete-log problem does not stop a man-in-the-middle attacker unless the exchange is authenticated. Record the protocol version and library behavior when the math supports a security claim. The lesson is the same across the chapter: a formula gives leverage only when its assumptions, operating range, and validation evidence travel with the result.
9.8 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.
Math Toolkit Map
- Calculus describes rates of change and accumulated energy.
- Logarithms make signal strength, path loss, and capacity easier to compare.
- Probability explains noisy measurements and confidence ranges.
- Linear algebra organizes multi-sensor state estimates.
- Number theory supports public-key cryptography.
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.9 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% per degree 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.
The first tool family handles change over time. That is why calculus appears in PID control, energy budgets, sensor drift, and sample-rate reasoning before the chapter moves into ratios and uncertainty.
9.10 A. Calculus Concepts for IoT
9.10.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 (degrees 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.10.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 x time | Total energy used (Joules) |
| Data transfer | Bits per second x time | Total data transferred (bytes) |
| Sensor noise | Small random fluctuations | Average reading (smoothing) |
| Battery capacity | Current x 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.10.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
In sensor fusion, we often: - Integrate accelerometer data to get velocity - Integrate velocity to get position - Differentiate position to get velocity
Checkpoint: Change and Accumulation
You now know:
- A derivative describes a rate of change, such as temperature in degrees C/second, charge flow in Amperes, or velocity in m/s.
- An integral adds small pieces into a total, such as power over time, bits per second over time, or current over time.
- The energy-budget example combines 50 mW for 10 ms with 0.01 mW for 990 ms to get about 0.51 mJ per cycle.
9.11 B. Exponential and Logarithmic Functions
9.11.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 (tau):
- 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 ohm resistor and 10 uF capacitor: \[\tau = R \times C = 100\Omega \times 10\mu F = 1ms\]
This sensor can respond to signals changing up to ~1000 Hz.
9.11.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 |
|---|---|
| 1x (no change) | 0 dB |
| 2x (double) | +3 dB |
| 10x | +10 dB |
| 100x | +20 dB |
| 0.5x (half) | -3 dB |
| 0.1x | -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.
Interactive Calculator: Shannon Channel Capacity
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 uW) | -30 dBm |
Interactive Calculator: dB and dBm Conversions
Logarithms compress huge ratios into values engineers can compare in a review. Next, linear algebra gives the matching language for multi-axis state: positions, velocities, covariance, and coordinate transforms.
9.12 C. Linear Algebra Basics
9.12.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).
Interactive Calculator: 3D Vector Magnitude
9.12.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.12.3 C.3 Matrix Multiplication
Quick Rule
To multiply matrix A (m by n) by matrix B (n by p), the inner dimensions must match. Result is m by 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.13 D. Probability and Statistics
9.13.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 sigma | sqrt(variance) | +/- 1 sigma 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 x 0.001 = 0.1 per unit time
9.13.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 (mu) and standard deviation (sigma).
\[p(x) = \frac{1}{\sigma\sqrt{2\pi}} e^{-\frac{(x-\mu)^2}{2\sigma^2}}\]
Properties:
- 68% of values within mu +/- 1 sigma
- 95% of values within mu +/- 2 sigma
- 99.7% of values within mu +/- 3 sigma
IoT Application - Sensor Noise:
A temperature sensor with: - Mean reading: mu = 25.0 C - Noise: sigma = 0.5 C
95% of readings will be between 24.0 C and 26.0 C.
9.13.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 (sigma = 10m)
- Accelerometer integration says 95m (sigma = 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).
Interactive Calculator: Sensor Fusion
Try It: Write a Sensor Uncertainty Assumption Check
Before using a fused sensor estimate in a capstone decision, write one short assumption check:
- Decision: what action will use the estimate, such as triggering an alert, logging a location, or changing actuator output.
- Inputs: each sensor value, its stated or measured \(\sigma\), and the time window used to collect samples.
- Assumption: why a Gaussian model is reasonable here, or which evidence shows that outliers, drift, or saturation need a different model.
- Rule: the numeric threshold that separates accept, warn, and reject states, including units.
- Recalculation condition: the condition that forces a new estimate, such as a new enclosure, different sample rate, firmware filter change, or field noise pattern.
Accept the estimate only when the decision, units, uncertainty source, and recalculation condition are all explicit.
Checkpoint: State and Uncertainty
You now know:
- A vector can hold a multi-axis sensor reading such as [0.5, 0.3, 0.8]g, whose magnitude is about 0.99g.
- A matrix can rotate, scale, or update state vectors, including Kalman filter state such as position, velocity, and acceleration.
- Probability makes fusion reviewable: a 10m GPS estimate and a 5m accelerometer estimate should not be averaged blindly; the more precise estimate carries more weight.
9.14 E. Modular Arithmetic for Cryptography
9.14.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 = 1x5 + 2)
- \(25 \mod 7 = 4\) (25 = 3x7 + 4)
- \(12 \mod 12 = 0\) (clock wraps at midnight)
9.14.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.14.3 E.3 Diffie-Hellman Key Exchange
Two IoT devices can agree on a shared secret over an insecure channel:
An eavesdropper sees only 8 and 19 - computing the shared secret requires solving the discrete logarithm problem (computationally infeasible for large numbers).
9.15 F. Complex Numbers for Signal Processing
9.15.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.15.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.15.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.16 G. Information Theory Basics
9.16.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.16.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).
Checkpoint: Security and Signals
You now know:
- Modular arithmetic wraps values around a modulus, as in 7 mod 5 = 2 and 25 mod 7 = 4.
- Diffie-Hellman relies on forward calculations such as 5^7 mod 23 = 17 being easy while the reverse problem is hard.
- Complex numbers track amplitude and phase, while information theory connects entropy, SNR, bandwidth, and Shannon capacity.
9.17 H. Quick Reference Card
9.17.1 Essential Formulas for IoT
9.17.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.17.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.17.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.17.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.17.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.17.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))\) |
9.18 Visual Reference Gallery
Kalman Filter Visualization
The Kalman filter optimally combines predictions with noisy measurements, essential for sensor fusion in navigation and tracking applications.
Signal Processing Pipeline
Signal processing transforms raw sensor data into meaningful information through filtering, sampling, and mathematical transformations.
Common Pitfalls
1. Skipping the units when applying IoT formulas
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. The battery life formula puts battery capacity (mAh) in the numerator and average current (mA) in the denominator; reversing those terms or confusing mA with uA gives an answer that is wildly wrong. Always write out units in intermediate steps and verify unit cancellation before trusting a numeric result.
2. Confusing linear and logarithmic scales for signal measurements
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.
3. Applying normal distribution assumptions to real IoT sensor noise
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.19 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 |
Worked Example: Designing a Kalman Filter for GPS-Accelerometer Fusion
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 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.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 covarianceMath concepts used: Vectors (C.1), matrices (C.2), matrix multiplication (C.3), Gaussian distribution (D.2), sensor fusion (D.3), integrals (A.2).
Decision Framework: Choosing Sampling Rates Using Nyquist Theorem
Use this framework to determine the minimum ADC sampling rate for your sensor based on signal frequency content.
9.19.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.19.2 Step-by-Step Decision Process
| Signal Type | Frequency Estimation Method | Example Calculation | Recommended Sampling Rate |
|---|---|---|---|
| Temperature (slow) | Physical time constant | Thermocouple: tau = 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 (2x 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.5x Nyquist for margin) |
| Voltage ripple | Power supply frequency | AC mains: 60 Hz + harmonics -> 300 Hz | 1 kHz (capture up to 5th harmonic) |
9.19.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 x 30 Hz = 120 Hz
- Harmonics: Up to 3x fundamental for imbalance detection = 120 x 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.5x 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.19.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.19.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.8x data volume |
| 10 kHz (over-sampled) | 160,000 bits/sec | Digital filtering, noise averaging | 14x data volume, unnecessary |
Energy Impact (from Section A.2, Energy Budget):
ADC power: 5 mW active, conversion time: 10 us
- 720 Hz: Duty cycle = 720 x 10 us = 0.72%, average power = 5 mW x 0.0072 = 36 uW
- 2 kHz: Duty cycle = 2000 x 10 us = 2%, average power = 100 uW
- 10 kHz: Duty cycle = 10%, average power = 500 uW
Battery life impact (2000 mAh at 3.3V):
- 2 kHz: 100 uW -> 30 uA -> 2000/0.03 = 66,667 hours = 7.6 years
- 10 kHz: 500 uW -> 150 uA -> 13,333 hours = 1.5 years
Decision: 2 kHz sampling provides a 2.8x margin over the Nyquist minimum while preserving 7+ year battery life. 10 kHz over-sampling wastes 80% of battery life with no signal quality benefit.
9.19.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.5x 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)\) | 10x power = 10 dB |
| Voltage ratio | \(dB = 20\log_{10}(V_2/V_1)\) | 10x 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 2x in linear terms).
9.19.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})\) | 2x 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.01x power -> -20 dB |
| Amplifier gain (voltage) | \(dB = 20\log_{10}(V_{out}/V_{in})\) | 10x voltage -> 20 dB |
| SNR (power ratio) | \(dB = 10\log_{10}(S/N)\) | 100:1 -> 20 dB SNR |
9.19.8 Quick Lookup Table (Section B.2)
| Linear Ratio | Power dB (10 log) | Voltage dB (20 log) |
|---|---|---|
| 0.5x (half) | -3 dB | -6 dB |
| 2x (double) | +3 dB | +6 dB |
| 10x | +10 dB | +20 dB |
| 100x | +20 dB | +40 dB |
| 1000x | +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.19.9 Practical IoT Example: Link Budget Calculation
Given: LoRa transmitter outputs 14 dBm (25 mW), path loss is 120 dB, receiver sensitivity is -137 dBm.
Correct calculation:
\[P_{rx} = P_{tx} + G_{ant} - L_{path}\] \[P_{rx} = 14 \text{ dBm} + 0 \text{ dB} - 120 \text{ dB} = -106 \text{ dBm}\]
Receiver needs -137 dBm minimum, received signal is -106 dBm:
\[\text{Margin} = -106 - (-137) = 31 \text{ dB}\]
Link has 31 dB margin (1,259x power above minimum) - link will work reliably.
Common mistake: Student adds voltage gain (in dBV) to power budget (in dBm) - units must match!
9.19.10 Rule Summary
- Power quantities (W, mW, dBm): Use \(10\log_{10}\)
- Voltage quantities (V, dBV): Use \(20\log_{10}\)
- Always label units (dBm, dBV, dB relative to reference)
- 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.20 Knowledge Check
9.21 Try It Yourself
Hands-On Exercise: Calculate Battery Life with Real Power Measurements
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 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 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).
9.22 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.23 See Also
Related Resources
Within This Module:
- Glossary A-F - Definitions for technical terms (dB, Shannon Capacity, Kalman Filter)
- Reference Appendix - Visual conventions and quick-reference material for mathematical diagrams
Applied Mathematics (Cross-Module):
- Signal Processing Essentials - Fourier transforms, filtering, Nyquist theorem in practice
- Kalman Filtering for Sensor Fusion - Step-by-step implementation of matrix-based sensor fusion
- Cryptography Fundamentals - Modular arithmetic in RSA, Diffie-Hellman, elliptic curves
- Energy-Aware Design - Battery life calculations using integrals and exponentials
Interactive Tools:
- Power Budget Calculator - Interactive tool applying the integral-based battery life formulas from this chapter
- dB Conversion Tool - Practice logarithmic conversions between mW and dBm
- Kalman Filter Visualizer - See matrix operations in real-time sensor fusion
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.24 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 |