Skip to content
CampusPrep
EC-705 · IOT LAB/Quick Revision Short Notes

IOT LAB (EC-705) - Unit 1 Short Notes

UNIT 1: FOUNDATIONS OF IOT & ENABLING TECHNOLOGIES

1.1 Introduction to the Internet of Things (IoT)

  • Definition: A system of interrelated computing devices, mechanical and digital machines, objects, animals, or people that are provided with unique identifiers (UIDs) and the ability to transfer data over a network without requiring human-to-human or human-to-computer interaction.

  • Evolution: From Machine-to-Machine (M2M) (point-to-point communication) to IoT (networked, intelligent, scalable systems with cloud integration).

  • Key Characteristics:

    • Connectivity: Anything can be connected.

    • Heterogeneity: Diverse devices, OS, protocols.

    • Dynamic changes: Device state & context change.

    • Scale: Massive number of connected devices.

    • Interoperability: Ability to work across different systems.

  • IoT vs. Internet vs. Traditional Embedded Systems:

    • Traditional Embedded System: Standalone, dedicated function, limited/no connectivity.

    • Internet: Connects people & computers (human-centric).

    • IoT: Connects "things" (object-centric), often autonomous, data-driven.

  • Drivers of Growth:

    • Decreasing cost of sensors & hardware.

    • Ubiquitous connectivity (broadband, cellular, LPWAN).

    • Advancements in cloud computing & storage.

    • Sophisticated data analytics & AI.

  • Major Application Domains:

    • Smart Home, Smart Cities, Industrial IoT (IIoT), Healthcare (Telemedicine), Agriculture (Precision Farming), Retail (Smart Inventory).

[!TIP] Exam Focus: Be prepared to contrast IoT with M2M and traditional embedded systems. List at least 5 application domains with one example each.

1.2 IoT Architecture & Reference Models

  • Three-Layer Architecture:

    1. Perception Layer: Physical sensors/actuators for data acquisition & action.

    2. Network Layer: Connects devices to network; data transmission (wired/wireless).

    3. Application Layer: Delivers services to end-users; data interpretation & visualization.

    Simplest model, but lacks detail on processing and business logic.

  • Five-Layer Architecture:

    1. Perception Layer

    2. Transport Layer: Focuses on secure & reliable data transmission (gateways, networks).

    3. Processing Layer: Data storage, processing, analytics (edge/cloud).

    4. Application Layer

    5. Business Layer: Overall management, business models, user privacy.

    Adds crucial layers for data handling and business strategy.

  • IoT Reference Model (Detailed Functional View):

    | Layer | Key Components & Functions | |-------------------|------------------------------------------------------------------------------------------------| | Device Layer | Physical devices, sensors, actuators, hardware platforms. | | Communication Layer | Network protocols, gateways, data transport mechanisms. | | Information Layer | Data abstraction, formatting (JSON/XML), device management, security. | | Application Layer | End-user applications, dashboards, APIs, analytics engines. | | Business Layer | Business processes, policies, ROI analysis, device lifecycle management. |

  • IoT System Maturity Model (Levels):

    1. Level 1 - Device Connectivity: Basic data collection.

    2. Level 2 - Device Management: Remote monitoring & control.

    3. Level 3 - Insight & Action: Data analysis for alerts.

    4. Level 4 - Automation: Rule-based automated responses.

    5. Level 5 - Optimization: AI/ML-driven predictive & prescriptive analytics.

[!TIP] Common Pitfall: Don't confuse the Three-Layer and Five-Layer architectures. Remember the Five-Layer explicitly separates Transport (data movement) from Processing (data handling).

1.3 Enabling Technologies - Hardware & Sensing

  • Sensors & Actuators:

    • Sensors: Convert physical parameter to electrical signal (e.g., Temperature (DS18B20), Humidity (DHT11), Motion (PIR), Proximity (Ultrasonic)).

    • Actuators: Convert electrical signal to physical action (e.g., Relay, Motor, Servo, LED).

    • Interfacing Basics: Analog (ADC required) vs. Digital (GPIO, I2C, SPI, UART).

  • MCU vs. MPU:

    | Feature | Microcontroller (MCU) | Microprocessor (MPU) | |-------------------|----------------------------------------------------|----------------------------------------------| | Core | CPU + RAM + Flash + Peripherals on single chip. | CPU only; requires external RAM/Flash. | | OS | Bare-metal, RTOS (FreeRTOS). | Full OS (Linux, Windows). | | Power | Low power, often battery-operated. | Higher power, mains-powered. | | Use Case | Dedicated, real-time control tasks (Arduino). | Complex processing, multimedia (Raspberry Pi).| | Examples | Arduino (ATmega328), ESP32, STM32. | Raspberry Pi (Broadcom SoC), BeagleBone. |

  • Key Development Boards:

    • Arduino (Uno/Nano):

      • Architecture: 8-bit AVR (ATmega328P).

      • GPIO: Digital I/O, Analog Input (ADC), PWM, Serial (UART), I2C, SPI.

      • Shields: Plug-in expansion boards.

      • IDE: Simple Arduino IDE (C++ based).

    • Raspberry Pi:

      • Architecture: ARM-based System-on-Chip (SoC).

      • OS: Runs full Linux (Raspbian/Raspberry Pi OS).

      • GPIO: 40-pin header (3.3V logic), supports I2C, SPI, UART, PWM.

      • Capabilities: Multimedia, USB, Ethernet, Wi-Fi/Bluetooth.

    • ESP32/ESP8266:

      • Key Feature: Integrated Wi-Fi (802.11 b/g/n) & Bluetooth (ESP32: BLE & Classic).

      • Low Power: Deep sleep modes for battery IoT nodes.

      • Programming: Arduino IDE, MicroPython, Espressif IDF.

      • Use Case: Wi-Fi-enabled IoT endpoints, gateways.

    • Others: BeagleBone (more I/O, Linux), STM32 Nucleo (professional ARM Cortex-M).

[!TIP] Lab Relevance: For a beginner, Arduino is best for sensor interfacing & real-time control. Raspberry Pi is best for complex processing, vision, or acting as a gateway. ESP32 is ideal for battery-powered, Wi-Fi-connected sensors.

1.4 Enabling Technologies - Connectivity & Communication

  • Short-Range Wireless (Personal Area Networks):

    • Bluetooth Classic: High data rate, higher power, audio streaming.

    • Bluetooth Low Energy (BLE): Ultra-low power, intermittent data, beacons.

    • Zigbee (IEEE 802.15.4): Low power, mesh networking, high node count (Smart Home).

    • Z-Wave: Proprietary, low-power mesh, high reliability (Home Automation).

    • NFC (Near Field Communication): 4 cm range, secure, for payments/access.

    • RFID: Passive/Active tags for identification (supply chain).

  • Long-Range Wireless (LPWAN - Low Power Wide Area Network):

    | Technology | Range | Data Rate | Power | Cost | Key Use | |----------------|---------------|---------------|-------------|-------------|--------------------------------| | LoRaWAN | 2-15 km (rural) | 0.3-50 kbps | Very Low | Low (modem) | Private/public networks, agriculture | | NB-IoT | ~10 km | ~250 kbps | Low | Medium (SIM)| Cellular-based, operator-deployed | | Sigfox | 30-50 km (rural)| 100 bps | Very Low | Subscription| Ultra-narrowband, simple telemetry |

  • Cellular Technologies for IoT:

    • 4G/LTE: High bandwidth, mobile broadband (video, vehicles).

    • 5G for IoT:

      • URLLC (Ultra-Reliable Low-Latency Comm): Factory automation, remote surgery.

      • mMTC (Massive Machine-Type Comm): Billions of sensors (smart cities).

  • Wired & IP-based:

    • Ethernet: Reliable, high-speed, fixed installations (factories, buildings).

    • MQTT over TCP/IP: Standard for reliable IP-based messaging.

  • Selection Criteria Checklist:

    Range? (cm vs km) → Power? (battery vs mains) → Data Rate? (bps vs Mbps) → Cost? (device & network) → Scalability? (nodes) → Topology? (star, mesh, point-to-point).

[!TIP] Exam Formula: For LPWAN, remember the trade-off triangle: Range ↔ Data Rate ↔ Power Consumption. You can't maximize all three simultaneously.

1.5 IoT Protocols & Data Communication

  • Application Layer Protocols:

    • MQTT (Message Queuing Telemetry Transport):

      • Model: Publish/Subscribe (asynchronous).

      • Components: Client (device/app), Broker (server), Topic (message category).

      • QoS Levels:

        • QoS 0: "At most once" (fire-and-forget).

        • QoS 1: "At least once" (acknowledged).

        • QoS 2: "Exactly once" (handshake, highest overhead).

      • Lightweight: Minimal header (2 bytes). Ideal for constrained networks.

      • Broker Example: Mosquitto, EMQX.

      Diagram Idea:

      DiagramSEARCH: MQTT publish-subscribe architecture diagram

    • CoAP (Constrained Application Protocol):

      • Model: RESTful (Request/Response) like HTTP.

      • Transport: UDP-based (low overhead), with optional reliability.

      • Use Case: Very constrained devices (6LoWPAN nodes).

      • Methods: GET, POST, PUT, DELETE.

    • HTTP/HTTPS: RESTful APIs. Heavy for constrained devices but universal. Used for cloud-to-cloud or less constrained devices.

    • AMQP: Enterprise-grade, message-oriented, complex (used in banking/finance).

  • Device/Network Layer Protocols:

    • 6LoWPAN: IPv6 over Low-Power Wireless Personal Area Networks (enables IP on Zigbee-like networks).

    • IPv6 over LPWAN: Compressed headers for LoRaWAN/NB-IoT.

    • Bluetooth Profiles: GATT (Generic Attribute Profile) for BLE data exchange.

  • Data Formats:

    • JSON: Human-readable, verbose. Common in web APIs.

    • XML: Verbose, legacy.

    • CBOR (Concise Binary Object Representation): Binary, compact. Ideal for constrained devices.

[!TIP] Rule of Thumb: Use MQTT for many-to-many, asynchronous, low-bandwidth telemetry. Use CoAP for request/response with very constrained nodes. Use HTTP when interacting with standard web services.

1.6 IoT Platforms & Cloud Integration

  • Role of Cloud in IoT:

    • Data Storage & Management: Scalable databases (Time-Series, NoSQL).

    • Processing & Analytics: Stream processing (Spark, Flink), ML/AI services.

    • Device Management: Onboarding, monitoring, firmware updates (OTA).

    • Visualization: Dashboards, alerts.

  • Platform-as-a-Service (PaaS) for IoT:

    | Platform | Key Service | Protocol Support | Best For | |--------------------|----------------------|---------------------------|---------------------------------------| | AWS IoT Core | Device Shadow, Rules Engine | MQTT, HTTP, LoRaWAN | Scalable, enterprise, AWS ecosystem. | | Azure IoT Hub | Device Twins, Endpoints | MQTT, AMQP, HTTP | Microsoft ecosystem, enterprise. | | Google Cloud IoT Core | Device Manager, Pub/Sub | MQTT, HTTP | GCP ecosystem, data analytics. | | ThingsBoard | Open-source, rule chains | MQTT, CoAP, HTTP | On-premise, customization. | | Kaa IoT Platform| Open-source, multi-tenant | Custom, HTTP, MQTT | Large-scale deployments. |

  • Core Platform Functions:

    1. Device Registry & Management: Secure identity (certificates/keys), metadata.

    2. Data Ingestion: High-throughput message broker.

    3. Rules Engine: Trigger actions based on data (e.g., "if temp>30°C, send alert").

    4. Dashboards & Visualization: Real-time charts, maps.

    5. Analytics & Storage: Process & store historical data.

  • Connecting a Device to a Cloud Platform (Generic Steps):

    1. Provision Device: Register device ID & credentials (X.509 cert, token) on platform.

    2. Configure Device: Install SDK/libraries, set Wi-Fi/network credentials, load cloud certs.

    3. Publish Telemetry: Send sensor data to platform's specific MQTT topic/HTTP endpoint.

    4. Subscribe to Commands: Listen for downstream messages/commands from platform.

    5. Visualize: Data appears in platform dashboard.

[!TIP] Lab Critical: The Device Shadow/Digital Twin concept (e.g., AWS Device Shadow, Azure Device Twin) is vital. It's a JSON document that stores the desired and reported state of a device, allowing apps to interact with the device even if it's offline.

1.7 IoT Security & Privacy Fundamentals

  • Security Challenges:

    • Device heterogeneity & resource constraints (can't run heavy crypto).

    • Large attack surface (billions of endpoints).

    • Physical accessibility of devices.

    • Insecure network communication.

  • Core Security Concepts (CIA Triad +):

    • Confidentiality: Data secrecy (encryption).

    • Integrity: Data not altered (hashes, signatures).

    • Availability: System accessible (DDoS resistance).

    • Authentication: Verifying identity (certificates, tokens).

    • Authorization: Permission control (policies).

    • Non-repudiation: Proof of action (digital signatures).

  • Security by Layer:

    | Layer | Mechanisms | |--------------------|-------------------------------------------------------------------------------| | Device/Edge | Secure boot, Hardware Security Module (HSM)/TEE, TPM, signed firmware, OTA updates. | | Communication | TLS/DTLS (for TCP/UDP), VPNs, link-layer encryption (AES-CCM in 802.15.4). | | Cloud/App | Identity & Access Management (IAM), API keys/OAuth, data encryption at rest, WAF. |

  • Privacy Considerations:

    • Data Minimization: Collect only what's necessary.

    • User Consent: Explicit opt-in for data collection.

    • Anonymization/Pseudonymization: Remove or mask personal identifiers.

    • Right to be Forgotten: Ability to delete user data.

[!TIP] Golden Rule: "Security must be built-in, not bolted-on." Start with hardware security (secure elements) and use TLS for all communication. Never send plaintext credentials.

1.8 Introduction to IoT Development & Tools

  • Programming Languages:

    • C/C++: Arduino, ESP-IDF (for ESP32), STM32 (bare-metal/RTOS). Low-level, fast, resource-efficient.

    • Python: Raspberry Pi, MicroPython (ESP32, Raspberry Pi Pico). High-level, rapid prototyping, rich libraries.

    • JavaScript/Node.js: Raspberry Pi, edge gateways (for web-centric apps).

    • Go/Rust: Emerging for high-performance, secure cloud/edge services.

  • Essential Tools:

    | Tool Category | Examples | Purpose | |---------------------|---------------------------------------|-------------------------------------------------| | IDE | Arduino IDE, PlatformIO, VS Code | Code writing, compiling, uploading. | | Serial Monitor | Arduino Serial Monitor, PuTTY, minicom| Debugging, viewing sensor data logs. | | Protocol Testing| MQTT.fx, MQTT Explorer, Wireshark | Test MQTT connections, inspect packets. | | Hardware Tools | Breadboard, jumper wires, multimeter | Prototyping circuits, measuring voltage/current.|

  • Basic IoT Project Workflow:

    1. Sensor Interfacing: Connect sensor to board (GPIO, I2C, SPI). Write code to read raw data.

    2. Data Acquisition & Processing: Calibrate sensor, filter noise (e.g., moving average), convert units.

    3. Local Processing/Display: Process data locally (e.g., detect threshold), display on OLED/LCD or LED.

    4. Communication Protocol Implementation: Connect to Wi-Fi, set up MQTT client, publish data to topic.

    5. Cloud Integration: Configure device credentials, connect to AWS/Azure IoT Hub, publish telemetry.

    6. Visualization & Control: Create dashboard (Grafana, cloud dashboard), subscribe to command topics to control actuator.

[!TIP] Lab Pro-Tip: Always print debug statements (Serial.println) at each step of your code. Use MQTT Explorer to subscribe to your device's topic and verify data is being sent correctly before setting up cloud rules.

Go to where you left off?

Quick Add to Notes

Save questions, your own notes and screenshots into notes filed by unit. It takes a free account.

Create free account

Have an account? Log in