8  Appendix

Putting Numbers to It

Reference usability can be estimated by lookup coverage:

\[ U = \frac{N_{\text{resolved-lookups}}}{N_{\text{total-lookups}}} \]

Worked example: If learners perform 220 glossary lookups and 198 are resolved without leaving the section, usability is \(198/220 = 0.90 = 90\\%\). Improving cross-references and examples should push this ratio higher.

Key Takeaway

In one sentence: This appendix is your quick-reference companion for IoT terminology, protocol comparisons, sensor specifications, and essential engineering formulas.

Remember this rule: Use this appendix to refresh your memory during design decisions or study sessions, but return to the detailed chapters for deeper explanations and context.

8.1 Learning Objectives

By using this appendix, you will be able to:

• Retrieve IoT terminology: Locate definitions for acronyms and technical terms used throughout the curriculum
• Evaluate protocols: Contrast reference tables to assess trade-offs among different IoT technologies
• Interpret sensor specifications: Analyse common sensor parameters to justify design decisions
• Calculate using engineering formulas: Solve networking, electronics, and battery life problems with provided equations
• Trace standards references: Navigate links to IEEE, IETF, and industry specifications for authoritative documentation

In 60 Seconds

The appendix provides supplementary reference material that supports but does not replace the main course chapters: mathematical derivations, extended code examples, hardware specifications, and additional worked problems. Use it as a lookup resource when a chapter references a formula or technique that needs more depth. The appendix is designed for active reference – search for specific topics using the section headings rather than reading linearly.

8.2 Key Concepts

• Reference Architecture: A pre-defined, validated system design template that documents component relationships, data flows, and technology choices for a specific IoT deployment pattern, reducing design time from months to weeks
• Bill of Materials (BOM): A structured list of all hardware components, quantities, and estimated costs for an IoT project, used for procurement planning and project budgeting before physical construction begins
• Protocol Comparison Matrix: A side-by-side tabular comparison of IoT communication protocols (MQTT, CoAP, HTTP, LoRaWAN, BLE) across key dimensions (bandwidth, latency, power, range, cost), enabling rational selection
• Worked Example: A fully solved problem showing inputs, methodology, intermediate steps, and final answer – more valuable for learning than exercise problems without solutions because the reasoning process is visible
• Quick Reference Card: A condensed single-page summary of the most commonly needed facts (port numbers, frequency bands, power consumption values) formatted for rapid lookup without consulting full documentation
• Errata: A documented list of known corrections to earlier versions of content, ensuring learners who reference printed or cached material can apply fixes to maintain accuracy
• Standards Reference: A compilation of IEEE, IETF, and vendor standards relevant to IoT system design, with brief summaries and document identifiers enabling engineers to locate primary source documents
• Index: An alphabetically organized cross-reference mapping technical terms to the chapters and sections where they are introduced and applied, critical for navigating large reference material

8.3 For Beginners: Appendix

An appendix is like a reference guide at the back of a textbook - it contains quick lookups for terms, formulas, and specifications you need while working on projects. Think of it as a cheat sheet: you wouldn’t read it cover-to-cover, but you’ll flip to it when you need to remember “What’s the I2C address of that temperature sensor?” or “What’s the formula for battery life?” It saves you from hunting through chapters when you just need a quick fact.

8.4 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.5 B. Protocol Comparison Tables

8.5.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.5.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.5.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.6 C. Common Sensor Specifications

8.6.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.6.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.6.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.7 D. ESP32 Pin Reference

8.7.1 GPIO Capabilities

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

8.7.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.7.3 Mid-Section Knowledge Check

8.8 E. Unit Conversions

8.8.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.8.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.8.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.9 F. Useful Formulas

8.9.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 ? '✅ Excellent signal' :
  link_budget.rx_power > -85 ? '✅ Good signal' :
  link_budget.rx_power > -100 ? '⚠️ Weak signal' :
  '❌ Very weak signal - may not work'}
</p>
</div>`

8.9.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.9.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.10 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.10.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
• Zigbee Alliance: csa-iot.org - Zigbee, Matter standards
• Bluetooth SIG: bluetooth.com - Bluetooth specifications

8.10.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.11 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 I2C Address Conflict

Scenario: Your capstone project has a BME280 (temp/humidity/pressure) and BH1750 (light sensor), both using I2C. After wiring, only one sensor responds. You consult the appendix.

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: Both sensors have address 0x77 (BME280) and 0x23 (BH1750). Wait, those are different addresses - conflict elsewhere.

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 (WRONG! That’s SPI MISO)

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

Key Insight: The appendix’s pin reference and sensor specifications prevented hours of debugging. Quick lookups save time during prototyping.

Decision Framework: When to Use Appendix vs. Detailed Chapters

Situation	Use Appendix	Use Detailed Chapter
“What’s the I2C address of BME280?”	✅ Appendix (quick lookup)	Chapter (for I2C protocol details)
“How do I implement MQTT reconnection?”	Chapter (algorithm needed)	❌ Appendix (too detailed)
“What’s the formula for link budget?”	✅ Appendix (quick reference)	Chapter (for RF propagation theory)
“Should I use CoAP or MQTT?”	Chapter (decision guidance)	❌ Appendix (no recommendations)
“What’s the MTU for 6LoWPAN?”	✅ Appendix (protocol specs)	Chapter (for fragmentation details)

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 “cheat sheet” during hands-on work. Return to chapters for understanding why and how things work.

Common Mistake: Using Appendix as Primary Learning Resource

The Mistake: Student tries to learn IoT exclusively from the appendix (glossary, pin references, formulas) without reading the detailed chapters. Result: knows definitions but can’t make 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. Maps help navigate once you know the terrain; they don’t teach you how to hike.

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.12 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.13 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 (Module 3 Networking), MQTT (Module 3 Application Protocols), BME280 specs (Module 2 Sensors), ESP32 GPIO (Module 9 Prototyping). The appendix doesn’t introduce new concepts; it consolidates them for quick reference.

Standards organizations map to technology layers: IEEE owns physical/MAC layers (802.11, 802.15.4), IETF owns IP-based protocols (CoAP, 6LoWPAN, RPL), and industry alliances (LoRa Alliance, Zigbee Alliance) own application-layer ecosystems. Understanding this mapping helps you find authoritative documentation.

Protocol comparison tables reveal design trade-offs: The short-range table shows inverse relationship between data rate and power (Wi-Fi = high rate/high power, Zigbee = low rate/low power). The LPWAN table shows licensed vs. unlicensed spectrum trade-offs (NB-IoT = licensed/higher cost/better QoS, LoRaWAN = unlicensed/lower cost/variable performance). These tables don’t make design decisions for you — they help you ask the right questions before consulting detailed chapters.

Formulas connect hardware to behavior: Link budget formula ties transmit power (Module 4 Wireless) to receiver sensitivity (Module 2 Sensors) through path loss (physics). Battery life formula connects current consumption (Module 9 Energy) to duty cycle (Module 3 Networking protocols). The appendix doesn’t teach when to apply these formulas — it assumes you’ve already learned the underlying principles.

Pin reference prevents hardware mistakes: ESP32 GPIO table shows which pins have ADC/DAC/Touch capabilities (Module 2 Electronics), default I2C/SPI assignments (Module 2 Sensors), and boot-mode restrictions (Module 9 Prototyping). This reference doesn’t teach you how I2C works — it helps you avoid wiring mistakes after you’ve 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.14 Navigation

Previous	Current	Next
Design Strategies & Prototyping	Appendix	Capstone Projects

8.15 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
Review mathematical foundations used in IoT systems	Mathematical Foundations
Apply consistent visual standards from the style guide	Visual Style Guide
Return to any module for deeper topic exploration	Data Storage