8  IoT Engineering Quick Reference

8.1 In 60 Seconds

This appendix is a quick-reference companion for IoT terminology, protocol comparisons, sensor specifications, ESP32 pin assignments, common unit conversions, engineering formulas, and standards links. Use it when you already understand the topic and need to recall a fact quickly. Return to the detailed chapters when you need design reasoning, implementation guidance, or troubleshooting context.

• Start with the section heading that matches the fact you need.
• Use the tables for quick comparison, not as a substitute for full design trade-off analysis.
• Check the formulas and calculators when you need a first-pass estimate.
• Follow standards links when exact protocol behavior or compliance language matters.
• Treat examples here as reference patterns that still need adaptation for your hardware and project constraints.

8.2 Start With The Evidence Note

Use the appendix like a bench card, not like an answer key. A table can remind you that a pin is input-only, a protocol uses a certain transport, or a battery formula needs current and time. The project still needs an evidence note that says where the value came from, which design decision depends on it, and what check would catch a wrong assumption.

For example, a range row becomes useful only after you attach band, antenna, enclosure, mounting, walls, interference, and field RSSI or SNR. A sensor row becomes useful only after you attach calibration, warm-up, mounting, airflow, supply voltage, and drift. A formula becomes useful only after you write the units and compare the estimate with a measurement.

Start every lookup with three short lines: reference, requirement, evidence. That habit keeps quick facts from turning into hidden design risks.

8.3 Learning Objectives

By using this appendix, you will be able to:

• Locate definitions for acronyms and technical terms used throughout the curriculum.
• Compare reference tables to assess trade-offs among different IoT technologies.
• Interpret common sensor parameters while justifying design decisions.
• Apply networking, electronics, and battery-life formulas to first-pass engineering estimates.
• Trace IEEE, IETF, and industry specifications when authoritative protocol documentation is needed.

8.4 References Are Not Requirements

The appendix is a bench reference, not a decision engine. A table can remind you that IEEE 802.11 normally gives higher throughput than IEEE 802.15.4, that MQTT uses publish/subscribe over TCP, that CoAP is specified by IETF RFC 7252, or that ESP32 GPIO 34-39 are input-only on common boards. Those facts are useful because they shorten recall. They are unsafe when they are copied into a design without the condition that made the fact true.

Use every lookup as the first line of an evidence note. A wireless range row needs frequency band, transmit power, antenna gain, enclosure, installation height, walls, interference, duty-cycle rules, and field RSSI or SNR. A sensor accuracy row needs operating range, calibration, mounting, airflow, self-heating, supply voltage, and drift. A protocol row needs the exact specification version, packet behavior, security profile, broker or server configuration, and failure mode that the project will tolerate.

The safest mental model is reference, requirement, evidence. The reference gives a value or definition. The requirement says how your project depends on it. The evidence proves the dependency with a datasheet revision, standard clause, packet capture, bench measurement, calculator input, or field test. Without all three, a lookup can sound precise while hiding the real engineering assumption.

Lookup Type	What It Can Tell You	What It Cannot Prove Alone	Evidence To Attach
Protocol row	Transport, message pattern, QoS, overhead, and common use	That the chosen device, broker, gateway, or network handles the failure case	Specification version, trace, retry test, authorization rule
Sensor row	Range, interface, nominal accuracy, and power class	That the reading is accurate inside the enclosure and duty cycle	Datasheet revision, calibration note, bench reading, warm-up test
Pin row	GPIO capability, default bus mapping, and boot restrictions	That the board revision and external circuit leave startup stable	Board schematic, boot test, pull-up/down review, firmware pin map
Formula row	A repeatable first-pass estimate with named variables	That the field environment, regulator, antenna, or battery matches the estimate	Inputs, units, assumptions, measured comparison, margin

Treat appendix values as entries in a reference ledger: fact, dependency, evidence, and the next check that would falsify the assumption.

8.5 Convert Lookup Into Evidence

When you use this appendix during a build, convert the lookup into a short evidence card before the value enters a capstone report, firmware constant, schematic, or dashboard. Start with the exact fact and its source location. Then name the project dependency: battery sizing, link margin, storage retention, sensor threshold, broker behavior, pin assignment, regulatory channel plan, or maintenance workflow. Finally, write the next check that would catch a wrong assumption.

For protocols, attach the specific standard or implementation behavior. MQTT may mean OASIS MQTT 3.1.1 or MQTT 5.0; QoS 1 still allows duplicates, so a telemetry pipeline needs message identifiers, timestamps, or idempotent writes. CoAP comes from RFC 7252, but retransmission timers, confirmable messages, DTLS, OSCORE, proxy behavior, and UDP loss still need project-level review. 6LoWPAN relies on adaptation over IEEE 802.15.4, so MTU, fragmentation, route repair, and border-router behavior belong next to the table row.

For hardware, attach the exact device and board context. ESP32 pin references are only safe after the board schematic, boot strapping pins, input-only pins, ADC limitations, I2C pull-ups, and peripheral conflicts are checked. A BME280 or SHT31 row should lead to interface wiring, address setting, enclosure airflow, sampling interval, self-heating, and calibration expectations. A PMS5003 particulate sensor row should lead to airflow, warm-up, cleaning, and replacement planning rather than a single accuracy claim.

For formulas, keep inputs and units visible. A link-budget estimate should name transmit power, antenna gain, receiver sensitivity, path-loss model, installation height, cable loss, regional limit, and field RSSI/SNR target. A battery estimate should include active current, sleep current, wake interval, radio burst length, regulator quiescent current, battery chemistry, temperature, self-discharge, and end-of-life margin. The formula is the traceable arithmetic; the evidence card is the engineering argument.

A good appendix note is short enough to write during lab work: “Reference fact, project dependency, source revision, measured or calculated proof, unresolved risk, owner, date.” That format lets another teammate repeat the lookup and challenge the design without rereading the whole module.

8.6 Specifications Leave Implementation Gaps

Under the hood, many appendix facts come from standards or datasheets that deliberately stop at an interface boundary. IEEE 802.11 and IEEE 802.15.4 define radio and MAC behavior, but they do not decide antenna placement, enclosure losses, channel congestion, power policy, or application recovery. IETF RFCs such as RFC 7252 for CoAP, RFC 6550 for RPL, RFC 4944 and RFC 6282 for 6LoWPAN define protocol mechanisms, but a product still chooses timers, buffer sizes, routing policy, security credentials, and observability.

Datasheets draw similar boundaries. A microcontroller technical reference manual can describe ADC resolution, touch channels, UARTs, SPI controllers, I2C controllers, boot pins, and absolute maximum ratings. It cannot prove that a particular dev board exposes the pin safely, that a sensor cable has enough pull-up strength, that a relay module will not drag a boot strap pin, or that Wi-Fi activity will not disturb an analog measurement. A sensor datasheet may quote accuracy under controlled calibration conditions while your enclosure creates heat, dust, condensation, vibration, or airflow constraints.

Formula references also leave gaps. Free-space path loss assumes a simplified propagation model; indoor multipath, body absorption, metal cabinets, antenna orientation, and duty-cycle restrictions change the result. Ohm’s law and voltage dividers are exact circuit relationships, but resistor tolerance, ADC input impedance, noise, leakage, and temperature drift determine whether the measurement is usable. Battery-life math is arithmetic; chemistry, temperature, peak current, regulator efficiency, self-discharge, and aging determine whether the deployed device lasts.

The deep skill is to write down where the reference guarantee stops. A standard may guarantee packet structure but not deployment reliability. A datasheet may guarantee a limit under specified conditions but not your enclosure. A table may compare protocols but not choose one for your threat model or power budget. A formula may be correct while the inputs are fantasy. The appendix becomes dependable when every lookup carries that stop sign and a plan to close the gap with measurement, source revision, or a design review.

How To Use This Appendix

Use this page like a bench reference during project work. It is best for lookup, comparison, and recall; it is not the primary place to learn a new concept from scratch.

8.7 Deep Dive: Reference Facts Need Engineering Context

A quick reference helps when you already know the concept and need a fast lookup. It should not turn a table value into a design decision by itself. A LoRaWAN range figure, ESP32 pin note, DHT22 accuracy value, MQTT QoS label, or battery-life formula becomes useful only after the project context is named.

Figure 8.1: A reference value is useful only when the project phase and decision boundary are clear.

Use each reference item as a starting point for a short check: what unit is used, what condition makes it true, what assumption your project is making, and what source would settle an exact requirement. A protocol table can narrow choices, but the final design may need the IEEE 802.15.4 specification, IETF RFC, LoRa Alliance documentation, ESP32 datasheet, sensor datasheet, or vendor errata.

The figure shows the habit to use throughout this appendix. During feasibility, overview claims and key specifications may be enough to reject an unsuitable part. During component selection, electrical limits, range, accuracy, and power modes matter. During schematic, PCB, firmware, and production work, the same part needs pin diagrams, timing limits, package dimensions, register maps, initialization sequences, ordering codes, and reliability notes. A table row is therefore not a permanent truth; it is a cue to ask which decision is being made now.

Keep that boundary explicit when you use the protocol, sensor, ESP32, unit-conversion, and formula sections below. A BLE range row may support a first shortlist, but it cannot replace an on-site RSSI check. A BME280 current value may start a battery estimate, but it must be combined with sampling interval, regulator quiescent current, radio transmit current, and sleep leakage. A formula result should keep its units, assumptions, and rounding visible so another teammate can repeat it.

Boundary	Use It For
Lookup	Recall, comparison, and first-pass estimates.
Design	Full chapter, datasheet, standard, or bench measurement review when the value controls cost, safety, power, range, or compatibility.
Project	Unit, tolerance, operating condition, and failure consequence record before a value is reused.

8.7.1 Convert a Table Entry Into a Checkable Assumption

For project work, write the reference fact as an assumption that another teammate could verify. “BLE range is 10-100 m” is too broad. “This indoor beacon prototype assumes BLE advertisement packets remain readable at 8 m through one drywall wall, measured with RSSI above the app threshold on the chosen phone” is checkable. The reference table suggested the technology; the project assumption names the environment, device, metric, and test.

The same pattern applies across the appendix. ESP32 GPIO 34-39 are input-only, so a wiring plan should mark them as sensor inputs rather than relay outputs. A BME280 current value belongs in a duty-cycle calculation with sensor warm-up and sleep current. MQTT QoS 1 belongs with idempotent command handling because duplicates can occur. A link-budget formula belongs with antenna gain, receiver sensitivity, path loss model, installation height, and measured RSSI/SNR.

Use a compact assumption record before the value enters the capstone report: fact, source, unit or valid range, dependency, next check, owner, and review date. For an ESP32 pin choice, that record may say GPIO 34 is input-only and therefore can read an analog sensor but cannot drive a relay; GPIO 0, 2, 12, and 15 need boot-strap review before external circuits pull them. For an SHT31, DS18B20, or PMS5003 selection, it may record accuracy, interface, warm-up, airflow, enclosure, and replacement risk. For an SX1276 or RFM95 LoRa design, it may record regional channel plan, antenna gain, spreading factor, duty-cycle limit, RSSI/SNR target, and the field test that will validate the link budget.

The point is not to slow down every lookup. The point is to stop unreviewed reference facts from becoming hidden design commitments. A quick table value can be copied into the notebook in seconds, but the project should mark whether it is a rough estimate, a datasheet limit, a standard requirement, a library default, or a measured result from the actual build.

1. Copy the exact fact. Include the unit, row label, and section that supplied it.
2. Name the dependency. Explain which hardware, firmware, protocol, power, or user requirement depends on it.
3. Name the next check. Use a datasheet lookup, bench test, packet capture, calculator, or field measurement before treating the assumption as stable.

8.7.2 Reference Tables Compress Many Conditions

Compact tables hide the conditions that make a value true. Wireless range depends on frequency, transmit power, antenna gain, receiver sensitivity, path loss, walls, interference, installation height, and duty-cycle limits. Sensor accuracy depends on calibration, temperature range, supply voltage, self-heating, drift, sampling interval, and mounting. Current draw depends on active state, sleep state, radio burst length, regulator quiescent current, and firmware timing.

Standards links and datasheets matter because they define exact behavior. MQTT QoS uses packet exchanges such as PUBLISH, PUBACK, PUBREC, PUBREL, and PUBCOMP. CoAP confirmable messages use ACK and retransmission timers over UDP. I2C depends on pull-up resistors, bus capacitance, address conflicts, and clock speed. ESP32 boot pins can affect startup if external circuitry pulls them to the wrong state.

Every compressed value also has a revision problem. Vendor breakout boards may differ from the underlying chip datasheet because of regulator choice, level shifting, pull-up values, address jumpers, or board-layout limits. Library defaults may differ from a protocol specification because a driver chooses a timeout, retry count, payload size, keep-alive interval, or power mode. Regional rules may change what looks like a simple wireless comparison: LoRaWAN channel plans, transmit power, dwell time, and duty-cycle behavior are not the same in every region.

For that reason, a final capstone evidence packet should cite the exact reference revision and the observed project value when a number matters. Good records distinguish IEEE or IETF normative behavior from a vendor application note, a forum example, a library default, and a measurement from the team’s device. They also preserve the packet trace, oscilloscope capture, current profile, field RSSI/SNR reading, or calculator inputs that made the reference fact safe to reuse. That separation lets a future maintainer update one layer without guessing which assumptions were inherited from a table.

State	What Must Stay Visible
Specification	Protocol fields, timing, electrical limits, operating ranges, and conformance language.
Implementation	Library defaults, board revision, pin mapping, firmware configuration, and peripheral conflicts.
Validation	The measured value, observed packet trace, or repeatable calculation that confirms the reference fact in the project context.

8.7.3 Try It: Check One Reference Fact

Before copying a value from a table into a capstone design, write one quick reference check:

• Fact reused: the exact protocol limit, sensor range, formula, pin assignment, or conversion you plan to use.
• Source location: the appendix section and, when exact behavior matters, the external standard or data sheet you will verify against.
• Units and boundary: the unit, valid range, rounding rule, and any condition that changes the value.
• Project assumption: the way your project depends on the value, such as battery sizing, enclosure choice, alert threshold, or network capacity.
• Acceptance test: the bench test, calculation, or review step that proves the value is safe to use in your design.

Accept the reference only when the units, boundary conditions, and project dependency are explicit enough for another team member to repeat the check.

8.8 Key Concepts

• Reference architecture: A validated system design template that documents components, data flows, and technology choices for an IoT deployment pattern.
• Bill of materials (BOM): A structured list of hardware components, quantities, and costs used for procurement planning and project budgeting.
• Protocol comparison matrix: A side-by-side comparison of communication protocols across range, data rate, power, topology, and typical use cases.
• Worked example: A solved problem that shows inputs, method, intermediate steps, and final answer so the reasoning is visible.
• Quick reference card: A compact summary of commonly needed facts such as pin assignments, units, ranges, and formulas.
• Standards reference: A pointer to IEEE, IETF, alliance, or vendor documents that should be checked for exact protocol requirements.
• Index: An organized cross-reference that maps terms to the chapters and sections where they are introduced and applied.

8.9 For Beginners: Appendix

An appendix is like a reference guide at the back of a textbook. You do not need to read it cover-to-cover. Use it when you need to remember a term, formula, sensor interface, pin assignment, or standards document while working on a project.

8.10 A. Glossary of IoT Terms

Term	Definition
6LoWPAN	IPv6 over Low-Power Wireless Personal Area Networks - Adaptation layer enabling IPv6 on IEEE 802.15.4 networks
ADC	Analog-to-Digital Converter - Hardware that converts continuous analog signals to discrete digital values
AMQP	Advanced Message Queuing Protocol - Message-oriented middleware protocol for reliable messaging
BLE	Bluetooth Low Energy - Low-power variant of Bluetooth designed for IoT applications
CoAP	Constrained Application Protocol - Lightweight protocol for resource-constrained IoT devices
DTLS	Datagram Transport Layer Security - Security protocol for UDP-based communications
Edge Computing	Processing data near the source rather than in a centralized cloud
Fog Computing	Distributed computing layer between edge devices and cloud
Gateway	Device that bridges different network protocols or technologies
GPIO	General Purpose Input/Output - Configurable pins on microcontrollers
I²C	Inter-Integrated Circuit - Two-wire serial communication protocol
IoT	Internet of Things - Network of physical devices connected to the internet
LoRa	Long Range - Proprietary spread spectrum modulation technique for LPWAN
LoRaWAN	LoRa Wide Area Network - MAC layer protocol built on LoRa
LPWAN	Low-Power Wide-Area Network - Network designed for long range, low power IoT
M2M	Machine-to-Machine - Direct communication between devices
MAC	Media Access Control - Protocol layer managing access to shared medium
MCU	Microcontroller Unit - Integrated circuit containing processor, memory, and I/O
MQTT	Message Queuing Telemetry Transport - Lightweight publish/subscribe protocol
NB-IoT	Narrowband IoT - Cellular LPWAN technology using licensed spectrum
NFC	Near Field Communication - Short-range wireless technology (~10cm)
OTA	Over-The-Air - Wireless delivery of updates or configuration
PHY	Physical Layer - Lowest layer of the OSI model handling raw bit transmission
PWM	Pulse Width Modulation - Technique for controlling power to devices
QoS	Quality of Service - Mechanism for prioritizing network traffic
REST	Representational State Transfer - Architectural style for web services
RFID	Radio-Frequency Identification - Wireless identification using radio waves
RPL	Routing Protocol for Low-Power and Lossy Networks
RSSI	Received Signal Strength Indicator - Measure of signal power
RTT	Round-Trip Time - Time for a signal to travel to destination and back
SDN	Software-Defined Networking - Network architecture with centralized control
Sigfox	Proprietary LPWAN technology using ultra-narrow band
SPI	Serial Peripheral Interface - Synchronous serial communication protocol
TLS	Transport Layer Security - Cryptographic protocol for secure communication
UART	Universal Asynchronous Receiver/Transmitter - Serial communication hardware
UDP	User Datagram Protocol - Connectionless transport protocol
WSN	Wireless Sensor Network - Network of distributed sensor nodes
Zigbee	IEEE 802.15.4-based specification for low-power mesh networks
Z-Wave	Proprietary wireless protocol for home automation

8.11 B. Protocol Comparison Tables

8.11.1 Short-Range Wireless Protocols

Protocol	Range	Data Rate	Power	Topology	Use Cases
Wi-Fi	50-100m	1-1000+ Mbps	High	Star	High-bandwidth applications
Bluetooth	10-100m	1-3 Mbps	Medium	Point-to-point	Audio, data transfer
BLE	10-100m	1-2 Mbps	Low	Star, Mesh	Wearables, beacons
Zigbee	10-100m	250 kbps	Very Low	Mesh	Home automation
Z-Wave	30-100m	100 kbps	Very Low	Mesh	Home automation
Thread	10-30m	250 kbps	Very Low	Mesh	Smart home
NFC	<10cm	424 kbps	Very Low	Point-to-point	Payments, access

8.11.2 LPWAN Technologies

Technology	Range	Data Rate	Spectrum	Topology	Battery Life
LoRaWAN	2-15 km	0.3-50 kbps	Unlicensed	Star	10+ years
Sigfox	10-50 km	100-600 bps	Unlicensed	Star	10+ years
NB-IoT	1-10 km	20-250 kbps	Licensed	Star	10+ years
LTE-M	1-10 km	1 Mbps	Licensed	Star	10+ years
Weightless	5-10 km	0.1-10 Mbps	Varies	Star	10+ years

8.11.3 Application Layer Protocols

Protocol	Transport	Message Pattern	QoS	Overhead	Best For
MQTT	TCP	Pub/Sub	0,1,2	Low	Real-time telemetry
CoAP	UDP	Request/Response	Confirmable	Very Low	Constrained devices
HTTP/REST	TCP	Request/Response	N/A	High	Web integration
AMQP	TCP	Queue-based	Yes	Medium	Enterprise messaging
XMPP	TCP	Pub/Sub	N/A	High	Presence, messaging

8.12 C. Common Sensor Specifications

8.12.1 Temperature Sensors

Sensor	Range	Accuracy	Interface	Power
DHT22	-40 to 80°C	±0.5°C	Digital	1.5mA
DS18B20	-55 to 125°C	±0.5°C	1-Wire	1.5mA
BME280	-40 to 85°C	±1°C	I²C/SPI	3.6µA
LM35	-55 to 150°C	±0.5°C	Analog	60µA
TMP117	-55 to 150°C	±0.1°C	I²C	3.5µA

8.12.2 Motion/Orientation Sensors

Sensor	Type	Range	Interface	Features
MPU6050	6-axis IMU	±16g, ±2000°/s	I²C	Gyro + Accel
MPU9250	9-axis IMU	±16g, ±2000°/s	I²C/SPI	+ Magnetometer
ADXL345	Accelerometer	±16g	I²C/SPI	Low power
HC-SR501	PIR Motion	3-7m	Digital	Adjustable

8.12.3 Distance/Proximity Sensors

Sensor	Technology	Range	Accuracy	Interface
HC-SR04	Ultrasonic	2-400cm	±3mm	GPIO
VL53L0X	ToF Laser	0-200cm	±3%	I²C
Sharp GP2Y0A21	IR	10-80cm	±5%	Analog

8.13 D. ESP32 Pin Reference

8.13.1 GPIO Capabilities

GPIO	Input	Output	ADC	DAC	Touch	Notes
0	Yes	Yes	Yes	No	Yes	Boot mode (pull-up)
1	No	Yes	No	No	No	TX0
2	Yes	Yes	Yes	No	Yes	On-board LED
3	Yes	No	No	No	No	RX0
4	Yes	Yes	Yes	No	Yes	General purpose
5	Yes	Yes	No	No	No	VSPI CS
12-15	Yes	Yes	Yes	No	Yes	HSPI
16-17	Yes	Yes	No	No	No	UART2
18-19	Yes	Yes	No	No	No	VSPI
21-22	Yes	Yes	No	No	No	I²C
23	Yes	Yes	No	No	No	VSPI MOSI
25-26	Yes	Yes	Yes	Yes	No	DAC capable
27	Yes	Yes	Yes	No	Yes	General purpose
32-39	Yes	Limited	Yes	No	Limited	ADC1; GPIO 34-39 are input only

8.13.2 Common Pin Assignments

Default I²C:  SDA = GPIO 21, SCL = GPIO 22
Default SPI:  MOSI = GPIO 23, MISO = GPIO 19, SCK = GPIO 18, CS = GPIO 5
UART0:        TX = GPIO 1, RX = GPIO 3 (USB Serial)
UART2:        TX = GPIO 17, RX = GPIO 16

8.13.3 Mid-Section Knowledge Check

8.14 E. Unit Conversions

8.14.1 Data Rate

Unit	Equivalent
1 bps	1 bit/second
1 kbps	1,000 bps
1 Mbps	1,000,000 bps
1 Gbps	1,000,000,000 bps
1 Byte/s	8 bps

8.14.2 Signal Strength (dBm)

dBm	mW	Typical Use
30	1000	Max Wi-Fi (US)
20	100	Typical router
10	10	-
0	1	-
-10	0.1	Good Wi-Fi signal
-50	0.00001	Excellent Wi-Fi
-70	0.0000001	Good Wi-Fi
-90	0.000000001	Weak Wi-Fi
-120	-	LoRa sensitivity

8.14.3 Power Consumption

Current	@ 3.3V	Battery Life (2000mAh)
1 mA	3.3 mW	2000 hours (83.3 days)
100 µA	330 µW	20,000 hours (833 days / 2.3 years)
10 µA	33 µW	200,000 hours (22.8 years)
1 µA	3.3 µW	2,000,000 hours (228 years)

8.15 F. Useful Formulas

8.15.1 Networking

Free Space Path Loss (dB): \[FSPL = 20 \log_{10}(d) + 20 \log_{10}(f) + 20 \log_{10}\left(\frac{4\pi}{c}\right)\]

Link Budget: \[P_{rx} = P_{tx} + G_{tx} + G_{rx} - L_{path} - L_{other}\]

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

Interactive Link Budget Calculator

viewof tx_power = Inputs.range([-10, 30], {value: 20, step: 1, label: "TX Power (dBm)"})
viewof tx_gain = Inputs.range([0, 20], {value: 2, step: 0.5, label: "TX Antenna Gain (dBi)"})
viewof rx_gain = Inputs.range([0, 20], {value: 2, step: 0.5, label: "RX Antenna Gain (dBi)"})
viewof distance = Inputs.range([1, 10000], {value: 100, step: 10, label: "Distance (m)"})
viewof frequency = Inputs.range([100, 6000], {value: 2400, step: 100, label: "Frequency (MHz)"})
viewof other_loss = Inputs.range([0, 30], {value: 5, step: 1, label: "Other Losses (dB)"})

link_budget = {
  const c = 299792458; // speed of light in m/s
  const f_hz = frequency * 1e6;
  const d_m = distance;
  const fspl = 20 * Math.log10(d_m) + 20 * Math.log10(f_hz) + 20 * Math.log10(4 * Math.PI / c);
  const rx_power = tx_power + tx_gain + rx_gain - fspl - other_loss;
  return {fspl, rx_power};
}

html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #E67E22; margin-top: 0.5rem;">
<p><strong>Free Space Path Loss:</strong> ${link_budget.fspl.toFixed(2)} dB</p>
<p><strong>Received Power:</strong> ${link_budget.rx_power.toFixed(2)} dBm</p>
<p style="margin-top:0.5rem; font-size:0.9em; color:#666;">
${link_budget.rx_power > -70 ? 'Status: excellent signal' :
  link_budget.rx_power > -85 ? 'Status: good signal' :
  link_budget.rx_power > -100 ? 'Status: weak signal' :
  'Status: very weak signal - may not work'}
</p>
</div>`

8.15.2 Electronics

Ohm’s Law: \[V = I \times R\]

Power: \[P = V \times I = I^2 \times R = \frac{V^2}{R}\]

Voltage Divider: \[V_{out} = V_{in} \times \frac{R_2}{R_1 + R_2}\]

RC Time Constant: \[\tau = R \times C\]

Cutoff Frequency (RC Filter): \[f_c = \frac{1}{2\pi RC}\]

Interactive Voltage Divider Calculator

viewof v_in = Inputs.range([1, 24], {value: 5, step: 0.1, label: "Input Voltage (V)"})
viewof r1 = Inputs.range([100, 1000000], {value: 10000, step: 100, label: "R1 - Top Resistor (Ω)"})
viewof r2 = Inputs.range([100, 1000000], {value: 10000, step: 100, label: "R2 - Bottom Resistor (Ω)"})

voltage_divider = {
  const v_out = v_in * (r2 / (r1 + r2));
  const current = v_in / (r1 + r2);
  const power_total = v_in * current;
  const power_r1 = current * current * r1;
  const power_r2 = current * current * r2;
  return {v_out, current: current * 1000, power_total: power_total * 1000, power_r1: power_r1 * 1000, power_r2: power_r2 * 1000};
}

html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #3498DB; margin-top: 0.5rem;">
<p><strong>Output Voltage:</strong> ${voltage_divider.v_out.toFixed(3)} V</p>
<p><strong>Current Draw:</strong> ${voltage_divider.current.toFixed(3)} mA</p>
<p><strong>Total Power:</strong> ${voltage_divider.power_total.toFixed(2)} mW</p>
<p style="margin-top:0.5rem; font-size:0.9em; color:#666;">R1 dissipates ${voltage_divider.power_r1.toFixed(2)} mW, R2 dissipates ${voltage_divider.power_r2.toFixed(2)} mW</p>
</div>`

8.15.3 Battery Life

Battery Life (hours): \[Life = \frac{Battery_{mAh}}{I_{average_{mA}}}\]

Duty Cycle Average Current: \[I_{avg} = (I_{active} \times D) + (I_{sleep} \times (1-D))\]

Where D = duty cycle (0-1)

Interactive Battery Life Calculator

viewof battery_capacity = Inputs.range([100, 10000], {value: 2000, step: 100, label: "Battery Capacity (mAh)"})
viewof active_current = Inputs.range([0.1, 500], {value: 50, step: 0.1, label: "Active Current (mA)"})
viewof sleep_current = Inputs.range([0.001, 10], {value: 0.05, step: 0.001, label: "Sleep Current (mA)"})
viewof duty_cycle = Inputs.range([0, 1], {value: 0.01, step: 0.001, label: "Duty Cycle (0-1)"})

battery_calc = {
  const avg_current = (active_current * duty_cycle) + (sleep_current * (1 - duty_cycle));
  const life_hours = battery_capacity / avg_current;
  const life_days = life_hours / 24;
  const life_years = life_days / 365;
  return {avg_current, life_hours, life_days, life_years};
}

html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #16A085; margin-top: 0.5rem;">
<p><strong>Average Current:</strong> ${battery_calc.avg_current.toFixed(3)} mA</p>
<p><strong>Battery Life:</strong> ${battery_calc.life_hours.toFixed(1)} hours (${battery_calc.life_days.toFixed(1)} days)</p>
${battery_calc.life_years >= 1 ? `<p><strong>Or:</strong> ${battery_calc.life_years.toFixed(2)} years</p>` : ''}
<p style="margin-top:0.5rem; font-size:0.9em; color:#666;">Example: A 2000mAh battery powering a device that draws 50mA when active and 0.05mA when sleeping, with 1% duty cycle (99% sleep time), will last approximately ${battery_calc.life_days.toFixed(0)} days.</p>
</div>`

8.16 G. References and Further Reading

MVU: IoT Standards Landscape

Core Concept: IoT standards come from different organizations - IEEE for physical/MAC layers (802.11, 802.15.4), IETF for internet protocols (CoAP, 6LoWPAN, RPL), and industry alliances for application-specific specs (LoRaWAN, Zigbee, Matter).

Why It Matters: Knowing which organization owns a standard tells you where to find official documentation, certification requirements, and future roadmaps for the technology you are using.

Key Takeaway: When researching a protocol, start with the standards body that owns it - IEEE for wireless PHY/MAC, IETF for IP-based protocols, and alliance websites for ecosystem-specific features.

8.16.1 Standards Organizations

• IEEE: ieee.org - 802.11, 802.15.4 standards
• IETF: ietf.org - CoAP, 6LoWPAN, RPL RFCs
• LoRa Alliance: lora-alliance.org - LoRaWAN specification
• Connectivity Standards Alliance (CSA): csa-iot.org - Zigbee and Matter standards
• Bluetooth SIG: bluetooth.com - Bluetooth specifications

8.16.2 Key RFCs and Standards

Document	Title
RFC 7252	CoAP - Constrained Application Protocol
RFC 6550	RPL - Routing Protocol for LLNs
RFC 4944	IPv6 over 802.15.4 (6LoWPAN)
RFC 6282	6LoWPAN Header Compression
IEEE 802.15.4	Low-Rate Wireless PANs
IEEE 802.11	Wireless LAN (Wi-Fi)

8.17 Visual Reference Gallery

IoT Protocol Ecosystem

IoT Protocol Stack

The IoT protocol ecosystem spans multiple layers, each with specialized protocols optimized for constrained devices and networks.

ESP32 Architecture Overview

ESP32 Architecture

The ESP32 combines dual-core processing with integrated wireless connectivity, making it a popular choice for IoT prototyping and production.

Worked Example: Using the Appendix to Resolve a Missing I2C Device

Scenario: Your capstone project has a BME280 temperature, humidity, and pressure sensor plus a BH1750 light sensor, both using I2C. After wiring, only one sensor responds. You consult the appendix before rewriting code.

Appendix lookup (Section C: Common Sensor Specifications): - BME280: I2C address 0x76 or 0x77 (configurable via SDO pin) - BH1750: I2C address 0x23 or 0x5C (configurable via ADDR pin)

Problem identified: The possible addresses are different, so an address conflict is unlikely. The next check is wiring and bus assignment.

I2C debug:

$ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- 76 --

Only one device (0x76) appears. BH1750 missing.

Solution: Check Section D (ESP32 Pin Reference): - Default I2C: SDA=GPIO 21, SCL=GPIO 22 - Verify wiring: BH1750 SDA connected to GPIO 19, which is SPI MISO rather than the default I2C SDA pin.

Fix: Move BH1750 SDA to GPIO 21. Both sensors now work.

Key insight: The appendix helped separate an addressing theory from a wiring fault. Quick lookups save time during prototyping when they are used with a clear diagnostic sequence.

Decision Framework: When to Use Appendix vs. Detailed Chapters

Situation	Best First Stop	Why
“What is the I2C address of BME280?”	Appendix	Quick lookup for a specific hardware fact
“How do I implement MQTT reconnection?”	Detailed chapter	Requires an algorithm, state handling, and error strategy
“What is the formula for link budget?”	Appendix	Quick formula reference
“Should I use CoAP or MQTT?”	Detailed chapter	Requires decision guidance and project context
“What is the MTU for 6LoWPAN?”	Appendix	Quick protocol specification lookup

Appendix strengths:

• Pin assignments during wiring
• Unit conversions during calculations
• Protocol quick comparison
• Formula lookups

Appendix limitations:

• No design guidance (go to chapters)
• No tutorials (go to chapters)
• No troubleshooting (go to chapters)

Key insight: Use the appendix as a quick reference during hands-on work. Return to chapters for understanding why and how things work.

Common Mistake: Using Appendix as Primary Learning Resource

The mistake: A learner tries to learn IoT exclusively from the appendix, using the glossary, pin references, and formulas without reading the detailed chapters. The result is memorized definitions without enough context for design decisions.

Why It Happens: Appendix is concise and feels efficient. “I can learn IoT in 20 pages!”

Example of insufficient understanding:

• Appendix: “MQTT is publish/subscribe, CoAP is request/response”
• Missing context: When to use each? QoS implications? Power consumption differences?
• Result: Chooses MQTT for battery device because “it’s popular” (wrong - CoAP would be better)

The Fix: Use the appendix for recall, not learning:

1. Read the detailed chapter (e.g., MQTT fundamentals)
2. Practice with examples
3. Use appendix as quick reference during design/coding
4. Return to chapter when deeper understanding is needed

Key insight: The appendix is a map, not a guidebook. It helps you navigate once you know the terrain; it does not teach the underlying engineering by itself.

Match the Protocol to Its Layer

Order the IoT Data Path

Common Pitfalls

1. Treating the appendix as primary learning material

The appendix is reference material, not a structured learning path. Reading it linearly without the conceptual grounding from main chapters produces memorization without understanding. Use appendix sections as deep-dives after the relevant main chapter concepts are understood, not as standalone introductions.

2. Not cross-referencing appendix material with main chapters

Appendix content is only valuable when connected to the problems it solves. When using a formula from the appendix, trace it back to the chapter where it was applied in context. The mathematical derivation alone without the application context rarely produces actionable understanding.

3. Copying appendix code examples without adapting to your hardware

Code examples in reference appendices are illustrative, not deployment-ready. They typically use placeholder device IDs, hardcoded credentials, and simplified error handling. Always adapt examples to your specific hardware, add proper error handling, and validate against your target environment before relying on them in production.

Label the Diagram

Code Challenge

8.18 Summary

This appendix serves as a quick reference companion to the main textbook:

• Glossary: 45+ IoT terms with concise definitions
• Protocol Comparisons: Side-by-side tables for wireless, LPWAN, and application protocols
• Sensor Specifications: Common temperature, motion, and distance sensors with specs
• ESP32 Pin Reference: GPIO capabilities and common pin assignments
• Engineering Formulas: Essential calculations for link budgets, battery life, and electronics

8.19 Knowledge Check

Auto-Gradable Quick Check

Concept Relationships

Appendix serves as the connective tissue between modules: Each table, formula, or pin reference draws from concepts explained in detail elsewhere: 6LoWPAN in networking, MQTT in application protocols, BME280 specifications in sensors, and ESP32 GPIO in prototyping. The appendix does not introduce new concepts; it consolidates them for quick reference.

Standards organizations map to technology layers: IEEE owns physical/MAC layers such as 802.11 and 802.15.4, IETF owns IP-based protocols such as CoAP, 6LoWPAN, and RPL, and industry alliances such as the LoRa Alliance and CSA own ecosystem specifications. Understanding this mapping helps you find authoritative documentation.

Protocol comparison tables reveal design trade-offs: The short-range table shows the relationship between data rate and power, such as Wi-Fi being higher rate and higher power while Zigbee is lower rate and lower power. The LPWAN table shows licensed vs. unlicensed spectrum trade-offs, such as NB-IoT using licensed spectrum and LoRaWAN using unlicensed spectrum. These tables do not make design decisions for you; they help you ask the right questions before consulting detailed chapters.

Formulas connect hardware to behavior: Link budget calculations tie transmit power to receiver sensitivity through path loss. Battery-life calculations connect current consumption to duty cycle. The appendix does not teach when to apply these formulas; it assumes you have already learned the underlying principles.

Pin reference prevents hardware mistakes: ESP32 GPIO tables show which pins have ADC, DAC, and touch capabilities, default I2C/SPI assignments, and boot-mode restrictions. This reference does not teach you how I2C works; it helps you avoid wiring mistakes after you have learned the protocol.

See Also

Within This Module (Engineering & Capstone):

• Capstone Projects - Apply appendix references in real projects
• Glossary A-F - Extended glossary (A-F terms)
• Glossary G-P - Extended glossary (G-P terms)

Related Concepts in Other Modules:

• IoT Protocol Stack - Detailed explanation of protocol layers
• Sensor Interfacing - I2C/SPI/UART protocols in depth
• ESP32 Development - ESP32 GPIO usage and examples
• MQTT Fundamentals - MQTT protocol details
• CoAP Fundamentals - CoAP protocol details
• LoRaWAN Architecture - LoRaWAN specification details
• Link Budget Calculations - RF link budget explained
• Battery Life Optimization - Battery life formulas and strategies

External Resources:

• IEEE Standards - Official IEEE 802.11, 802.15.4 specifications
• IETF RFCs - CoAP, 6LoWPAN, RPL specifications
• LoRa Alliance - LoRaWAN specification downloads
• ESP32 Technical Reference Manual - Complete ESP32 GPIO and peripheral documentation

8.20 Navigation

Previous	Current	Next
IoT Glossary: Q-Z	Appendix	Mathematical Foundations

8.21 What’s Next

If you want to…	Read this
Build a complete IoT system with capstone projects	Capstone Projects
Look up technical term definitions from across the course	IoT Glossary A-F
Continue to the next appendix topic	Mathematical Foundations
Apply consistent visual standards from the style guide	Reference Appendix
Return to any module for deeper topic exploration	Data Storage