12 IoT Quick Reference: Terms and Hardware
12.1 Overview
This first reference route covers vocabulary, protocols, sensors, and pin-level hardware facts.
This is part 1 of 2. Continue with IoT Quick Reference: Conversions and Standards for the second focused route.
12.2 In 60 Seconds
Prove a Quick Lookup Supports the Decision
Picture a builder who copies a range from a table and orders hardware before checking the band or site. A fast answer can create a slow failure when its limits are missing.
A protocol means an agreed set of rules for exchanging information. Record its version, role, source, date, and design consequence beside any value taken from this appendix.
Choose one lookup and test it against the cited source and the real design condition. Keep the question, value, units, source, assumption, check, and result so another person can verify the choice.
This check validates one use of a reference, not the whole design. The detailed chapters explain trade-offs, implementation, safety, and troubleshooting.
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.
12.3 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.
12.4 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.
12.5 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.
12.6 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.
12.7 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.
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.
Before applying the specification, inspect the real bme280 temperature-humidity-pressure sensor below: its package, terminals, scale, and installation context are part of the engineering evidence.
Carry those visible constraints into the surrounding analysis; the abstract symbol or capability name does not capture mounting, wiring, protection, or service access.
12.8 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. Read Figure 12.1 from feasibility toward production to see how the required evidence becomes more specific.
Read Figure 12.1 from feasibility toward production, noticing how overview claims give way to electrical limits, pin and timing detail, register behavior, and ordering evidence. 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.
Read Figure 12.1 from feasibility onward: broad capability and key limits come first, component selection narrows the electrical and performance evidence, and implementation work moves into pin, timing, package, register, and ordering detail. The visual progression is the habit to use throughout this appendix: a table row is not a permanent truth but 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. |
12.8.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.
- Copy the exact fact. Include the unit, row label, and section that supplied it.
- Name the dependency. Explain which hardware, firmware, protocol, power, or user requirement depends on it.
- Name the next check. Use a datasheet lookup, bench test, packet capture, calculator, or field measurement before treating the assumption as stable.
12.8.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. |
12.8.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.
12.9 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.
12.10 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.
12.11 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 |
12.12 B. Protocol Comparison Tables
12.12.1 Short-Range Wireless Protocols
↔ Scroll the protocol table horizontally to review topology and use cases.
| 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 |
12.12.2 LPWAN Technologies
↔ Scroll the LPWAN table horizontally to review topology and battery life.
| 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 |
12.12.3 Application Layer Protocols
↔ Scroll the application-protocol table horizontally to review overhead and best-fit uses.
| 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 |
12.13 C. Common Sensor Specifications
12.13.1 Temperature Sensors
↔ Scroll the temperature-sensor table horizontally to review interface and power.
| 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 |
12.13.2 Motion/Orientation Sensors
↔ Scroll the motion-sensor table horizontally to review interface and features.
| 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 |
12.13.3 Distance/Proximity Sensors
↔ Scroll the distance-sensor table horizontally to review accuracy and interface.
| 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 |
12.14 D. ESP32 Pin Reference
12.14.1 GPIO Capabilities
↔ Scroll the ESP32 pin table horizontally to review touch support and pin notes.
| 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 |
12.14.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 1612.14.3 Mid-Section Knowledge Check
12.15 Continue to Part 2
Continue with IoT Quick Reference: Conversions and Standards.