Fundamentals Module Guide
1.1 Start With One Reading
A payload is the useful data in a message. A protocol is the shared set of rules used to exchange it. Picture a cold-room sensor that reports 23.6 degrees. The team must show how the event became a number, bytes, a packet, and a delivered record.
Carry that reading through this guide. Keep its units, scale, time, packet boundary, link evidence, and delivery need clear. When the received value is wrong, trace the same path backward until the proof locates the fault.
Your guide: Physics Phoebe
“A sensor obeys physics before it obeys your code — know the wave, the delay, and the noise floor first.”
1.2 Start With the Story
Start with a team trying to explain why a sensor reading, a packet, a radio link, and a protocol choice all belong in the same design review. The core idea in Fundamentals Module Guide is simple: fundamentals are the reusable moves that let an IoT engineer turn raw events into defensible system decisions. This page focuses that idea on Navigation for the Fundamentals part, routing learners through data representation, packet structure, sensor pipelines, signal processing. In everyday IoT, they stop teams from treating bytes, signals, packets, wireless links, and protocols as separate mysteries. Start simple: follow one reading from the physical world to its encoded payload, then use the chapter lanes when a detail needs proof.
Follow the team’s four review beats to see how one physical event becomes a decision the whole design group can defend.
-
Physics Phoebe: “Begin with the event: warm air changes one sensor reading.”
-
Data Dora and Packet Pete: “Encode the reading, then carry it in a bounded packet.”
-
Radio Remi: “A packet still needs a radio link with enough margin to arrive.”
-
The team: “Now defend the protocol against range, timing, power, and evidence.”
1.3 Core Building Blocks of IoT
Imagine a cold-room sensor reports a sudden rise in temperature. After this part, you will be able to trace that reading from the sensor, through its changing signal and stored data, into a packet, and across a chosen protocol. A packet is a bounded message; a protocol is the set of rules that carries it. You will know where to look when the value is wrong, the message is unclear, or the link cannot deliver it. These same five moves let you find the right chapter for any IoT problem and explain your design to a team. The chapters follow engineering tasks, not a single device family. Start with the task that matches the fault, then follow its links for deeper practice.
1.4 Learning Objectives
After working through this part, you will be able to:
- Decode byte-level values using number systems, signedness, byte order, and text encoding rules.
- Inspect packet fields, framing, and error-detection evidence.
- Explain how sensor readings move through conditioning, sampling, conversion, processing, and transmission.
- Reason about sampling, quantization, filtering, and signal limits.
- Estimate wireless link behavior from frequency, path loss, antennas, and link budget terms.
- Choose a protocol from constraints, evidence, and trade-offs instead of from habit.
- Raw readings need representation rules before they become trusted values.
- Sensor signals need sampling and conversion decisions before they become useful data.
- Packets need framing, addressing, and error checks before they can be interpreted safely.
- Wireless links need margins, not hope.
- Protocol choices should be explained with requirements and evidence.
1.5 Skill Map
The fundamentals lanes in Figure 1.1 connect the same end-to-end data journey from measurement to protocol decision. Follow one temperature event so that each lane hands a named artifact to the next instead of becoming an isolated topic.
Read Figure 1.1 as a chain of engineering questions. Sensor pipeline establishes what happened physically; signal processing decides whether the sample is trustworthy; data representation fixes the byte contract; packet structure protects its boundary; and wireless link supplies delivery evidence. Protocol choice is last because it must fit all five earlier constraints. If that final review fails, use the red return path to find the first unsupported hand-off rather than guessing at a new radio.
1.6 Evidence Flow
A fundamentals review in Figure 1.2 keeps the data path visible instead of treating each topic as isolated vocabulary. The worked temperature thread below shows exactly what evidence survives each transformation.
Read Figure 1.2 from the calibrated 23.6 °C observation to its 2417-count ADC evidence, then through the explicit uint16, big-endian, 0.1 °C byte contract. The packet keeps sequence, length, payload boundary, and error-check evidence; the link record keeps RSSI, sensitivity, retries, and the resulting 17 dB margin. Only then does the worked pilot apply its own release rule. The red debugging path runs in reverse because a wrong received value must be localized to the frame, representation, conversion, or physical measurement—not hidden by a protocol swap.
If a temperature reading looks wrong after transmission:
- Keep the raw packet bytes and packet timestamp.
- Decode the representation contract: width, signedness, byte order, scale, and units.
- Check packet framing and error-detection fields.
- Review the sensor conversion and calibration path.
- Check whether the link or protocol path could have dropped, delayed, or duplicated messages.
1.7 Choose A Route
1.7.1 I Need To Decode A Byte Dump
Start with Number Systems and Data Units, then continue to Bitwise Operations and Endianness.
1.7.2 I Need To Make Text Or IDs Safe
Start with Text Encoding for IoT, then continue to Data Formats for IoT.
1.7.3 I Need To Inspect A Packet
Start with Packet Anatomy, then continue to Packet Framing and Packet Error Detection.
1.7.4 I Need To Understand Sensor Readings
Start with Signal Processing Essentials, then trace the applied path through Sensor to Network Pipeline and Sensor Pipeline Overview.
1.7.5 I Need To Reason About Wireless Range
Start with Radio Wave Basics, then continue to Path Loss and Link Budget.
1.7.6 I Need To Choose A Protocol
Start with Protocol Selection Framework, then use Protocol Framework Scenarios for practice.
1.8 Review Checkpoints
Use these checkpoints to decide whether to move forward or revisit a lane.
1.9 Knowledge Check
1.10 Deep Dive: Keep The Endpoint Loop Visible
Strip any IoT endpoint down and you usually find the same loop: sense the physical world, process the reading, communicate the result, and sometimes actuate to change the world back. A soil probe, a smart lock, and a factory vibration monitor differ in details but not in that shape. Power sits underneath the loop because battery or harvested-energy endpoints survive by sleeping between short bursts of work.
| Loop block | Typical hardware | Job | Evidence to preserve |
|---|---|---|---|
| Sense | Sensor front end and ADC | Turn a physical quantity into a digital number | Calibration record, units, range, noise, timestamp |
| Process | Microcontroller or edge processor | Filter, threshold, format, decide | Algorithm version, thresholds, conversion contract |
| Communicate | BLE, IEEE 802.15.4, Wi-Fi, cellular, or wired interface | Move data to a gateway, peer, or cloud endpoint | Packet bytes, retry count, link margin, latency |
| Actuate | Relay, motor, valve, display, driver stage | Change the physical world | Command source, safety interlock, confirmation reading |
A smart thermostat shows the loop. A temperature sensor and ADC read 21.4 C; the microcontroller compares it to a 22 C setpoint and decides to call for heat; the device reports the reading and decision over Wi-Fi; then it closes a relay to the furnace. The room warms, the next sensor reading rises, and the loop repeats. Feedback from actuation back into sensing is what makes this a control loop rather than a one-way data pipe.
1.10.1 Radio Duty Cycle Shapes The Design
The radio often dominates the recurring energy budget in battery devices. A small packet can require a brief but high-current transmit or receive window, while the processor may complete local formatting or threshold logic cheaply. That does not mean the CPU is irrelevant; it means the design should avoid unnecessary radio wakeups, retries, and payload bytes.
The practical pattern is a duty-cycled endpoint loop: wake, sense, process, transmit briefly, and return to deep sleep. If a device reports once a minute and the radio is active for 10 ms, the radio-active fraction is about 10 ms / 60 s = 0.017% before counting retries and receive windows. That small active fraction is why packet size, retry behavior, and wake scheduling matter as much as the sensor choice.
A door sensor makes the trade visible. Streaming continuous status keeps the radio awake and drains the battery quickly. Sleeping until a door event or periodic heartbeat lets the same product send a few bytes, record enough evidence for troubleshooting, and return to low-power state. In the fundamentals lane, the question is not “Which component is important?” It is “Which part of the endpoint loop produced the evidence, changed the state, or spent the energy?”
1.11 Summary
The Fundamentals part is the technical base for the rest of the course:
- Data representation explains how raw bytes become values, strings, flags, and payloads.
- Packet structure explains how payloads are framed, addressed, and checked.
- Sensor pipelines explain how measurements become digital data.
- Signal processing explains sampling, conversion, filtering, and interpretation limits.
- Wireless propagation explains why links need margin and evidence.
- Protocol selection ties requirements to defensible communication choices.
1.12 What’s Next
1.12.1 Begin With Bytes
Data Representation Fundamentals is the best first stop if you are unsure where to begin.
1.12.2 Trace The Measurement
Sensor to Network Pipeline connects sensing, processing, and transmission.
1.12.3 Inspect Messages
Packet Anatomy explains how payloads are organized for delivery.
1.12.4 Decide A Protocol
Protocol Selection Framework turns constraints into a documented choice.
1.13 Key Takeaway
Fundamentals are the shared vocabulary for IoT design: devices, data representation, packets, protocols, signal processing, wireless behavior, and system tradeoffs. Later modules assume these ideas are usable together.