13 IoT Quick Reference: Conversions and Standards

capstone

appendix-conversions-formulas-standards

13.1 Start With the Situation

A design note now has the right component and protocol names, but its numbers still need consistent units and formulas. This route keeps the conversion, calculation, and standards checks together.

13.2 Overview

This reference route connects unit conversion and useful formulas to calculators and standards sources.

This is part 2 of 2. Review IoT Quick Reference: Terms and Hardware when you need the first route.

13.3 Learning Objectives

By the end of this chapter, you will be able to:

convert common IoT units
apply networking and electronics formulas
locate relevant standards and references

13.4 Chapter Roadmap

Follow the original sections below in order. They begin at the reviewed split boundary and keep every worked example, figure, check, and supporting banner with the section that owns it.

13.5 E. Unit Conversions

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

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

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

13.6 F. Useful Formulas

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

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

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

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

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

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

13.8 Visual Reference Gallery

IoT Protocol Ecosystem

Before choosing an application protocol, locate every layer that must carry its traffic. Read Figure 13.1 from physical and link technologies upward through networking and transport to the application contract.

Figure 13.1: IoT Protocol Stack

In Figure 13.1, the lower layers determine how bits cross the local medium, the network layer supplies addressing and routing, transport controls end-to-end delivery behavior, and MQTT or CoAP provides the application exchange. The stack shows why an application choice never removes MTU, routing, reliability, or radio constraints; those layers remain part of the capstone evidence path.

ESP32 Architecture Overview

An ESP32 design works only when compute, memory, radios, and peripherals share resources without violating timing or pin constraints. Use Figure 13.2 to trace those internal responsibilities before treating the board as one undifferentiated component.

Figure 13.2: ESP32 Architecture

In Figure 13.2, start at the processor and memory buses, then follow the connections to Wi-Fi and Bluetooth, GPIO, ADC/DAC, and serial interfaces. The diagram makes the integration trade-off visible: convenience comes from putting these blocks together, but firmware still must budget cores, memory, peripheral ownership, radio activity, and electrical limits. Those are the checks that turn a popular board into a defensible choice.

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)

Before changing code, inspect the actual sensor package in Figure 13.3 and connect the appendix address options to the SDO wiring on the breakout. The photograph is useful here because the debugging question is about a physical board configuration, not an abstract I2C rule.

A small BME280 breakout board with a square metal-capped sensor package and a row of pin headers. — Figure 13.3: A BME280 breakout like the one in this scenario; the appendix gives two possible addresses, selected by the SDO wiring.

In Figure 13.3, locate the metal-capped BME280 package first and then the header pins that carry power and the I2C bus. The board view reminds you that the selected address depends on how the breakout exposes and wires SDO; it cannot be inferred from the sensor name alone. That observation sends the investigation back to wiring, power, bus scan, and board documentation before firmware is rewritten.

Photo: SparkFun Electronics, CC BY 2.0.

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

Blueprint Bina crosses out an appendix used as the only bridge to a design choice in red; the same panel shows a full chapter providing context, with the appendix retained as a small recall card. — CP-0057 misconception buster: A learner tries to learn IoT exclusively from the appendix, using the glossary, pin references, and formulas without reading the detailed chapters.

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:

Read the detailed chapter (e.g., MQTT fundamentals)
Practice with examples
Use appendix as quick reference during design/coding
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

13.9 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

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

13.12 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

13.1 Start With the Situation

13.2 Overview

13.3 Learning Objectives

13.4 Chapter Roadmap

13.5 E. Unit Conversions

13.5.1 Data Rate

13.5.2 Signal Strength (dBm)

13.5.3 Power Consumption

13.6 F. Useful Formulas

13.6.1 Networking

13.6.2 Electronics

13.6.3 Battery Life

13.7 G. References and Further Reading

13.7.1 Standards Organizations

13.7.2 Key RFCs and Standards

13.8 Visual Reference Gallery

Common Pitfalls

13.9 Summary

13.10 Knowledge Check

13.11 Navigation

13.12 What’s Next