IoT Lab (IT-705) - Unit 2 Short Notes

UNIT 2: IoT Technologies and Protocols (Lab-Focused Notes)

2.1 Core IoT Hardware & Component Interfacing

2.1.1 Sensors & Transducers

• Definition: A sensor converts a physical parameter (temperature, light) into an electrical signal. A transducer often includes signal conditioning.

• Types:

  • Analog: Output a continuous voltage/current (e.g., LM35 temperature, photoresistor). Requires ADC (Analog-to-Digital Conversion) for digital reading.

  • Digital: Output discrete digital signals (e.g., DHT11 humidity/temperature, PIR motion). Communicates via protocols like I2C, SPI, UART (serial).

• Interfacing Fundamentals:

  • GPIO (General Purpose Input/Output): Pins on MCUs/SoCs to read digital states (HIGH/LOW) or control outputs.

  • ADC: Converts analog voltage to a digital number. Key parameters: Resolution (bits, e.g., 10-bit = 1024 levels), Reference Voltage ($$\displaystyle V_{ref} $$). Formula:

$$Digital\ Value = \frac{V_{in}}{V_{ref}} \times (2^{Resolution} - 1)$$

*   **Calibration:** Essential for accuracy. Involves mapping sensor output to known reference values and applying correction factors in software.

• > [!TIP] Always check a sensor's datasheet for its output type (analog/digital), supply voltage, and communication protocol before interfacing.

2.1.2 Actuators

• Definition: Devices that convert electrical signals into physical action.

• Types & Control:

  • Relays: Electromechanical switches for high-power AC/DC loads. Controlled via digital GPIO.

  • Motors:

    • DC: Simple on/off or speed control via PWM (Pulse Width Modulation). Duty cycle (%) determines average power.

    • Stepper: Precise angular movement. Requires driver (e.g., ULN2003) and sequence pulses.

    • Servo: Position control (0-180°). Controlled by PWM signal with specific pulse width (typically 1-2ms).

  • Solenoids: Linear actuators (push/pull) for valves, locks.

  • Indicators: LEDs (with current-limiting resistor), Buzzers (tone generation via PWM).

• PWM Control: Frequency is fixed; duty cycle (percentage of ON time in a period) controls effective voltage.

$$V_{avg} = Duty\ Cycle \times V_{supply}$$

2.1.3 Microcontroller/SoC Platforms for Prototyping

> [!TIP] MCU (Arduino/ESP): Best for real-time, low-power, cost-sensitive end-devices. SBC (RPi): Best for edge gateways needing OS, file system, or heavy computation (e.g., video analytics).

2.2 Wireless Communication Technologies for IoT

2.2.1 Short-Range / Personal Area Networks (PAN)

> [!TIP] BLE GATT: Data organized as Services (collections of characteristics). A Characteristic holds the actual sensor value (e.g., temperature). Use a smartphone app (nRF Connect) to explore GATT profiles.

2.2.2 Local / Wide Area Networks (LAN/WAN)

• Wi-Fi (IEEE 802.11):

  • Modes: Infrastructure (AP) vs. Ad-hoc (peer-to-peer).

  • Security: WPA2 (AES) is standard; WPA3 is newer/stronger.

  • IoT Consideration: High power consumption; use deep sleep strategies. Good for mains-powered devices.

• Cellular (4G/LTE, 5G, NB-IoT, Cat-M1):

  • NB-IoT (Narrowband IoT): Very low bandwidth, deep coverage (+20dB), low power. Ideal for static, infrequent small packets (smart meters).

  • Cat-M1 (LTE-M): Higher bandwidth than NB-IoT, supports mobility & voice. For more demanding IoT (trackers, medical).

  • 5G: Ultra-low latency, massive IoT (mMTC), critical for real-time control/AR.

2.2.3 Low-Power Wide-Area Networks (LPWAN)

> [!TIP] LoRaWAN Regional Parameters: Different frequency bands (EU868, US915, AS923). Check your region's plan for duty cycle limits and available channels.

2.3 IoT Application Layer Protocols & Messaging

2.3.1 Publish-Subscribe Model: MQTT

• Architecture: Broker (central server) mediates between Clients (publishers & subscribers).

• Topic: Hierarchical string (e.g., home/livingroom/temp). Uses / as separator.

• Wildcards:

  • + : Single-level wildcard (home/+/temp)

  • # : Multi-level wildcard (home/#)

• QoS (Quality of Service) Levels:

  • QoS 0: "At most once." Fire-and-forget. Fastest, least reliable.

  • QoS 1: "At least once." Guaranteed delivery, possible duplicates. Requires PUBACK.

  • QoS 2: "Exactly once." Guaranteed, no duplicates. 4-step handshake (PUBLISH, PUBREC, PUBREL, PUBCOMP). Slowest, most overhead.

• LWT (Last Will & Testament): Message/client tells broker what to publish if it disconnects unexpectedly (e.g., home/livingroom/status = "offline").

• Common Brokers: Mosquitto (lightweight), EMQX (scalable), HiveMQ (enterprise).

• > [!TIP] MQTT vs. HTTP: MQTT is asynchronous, low-overhead, ideal for constrained networks. HTTP is request-response, stateless, higher overhead.

2.3.2 Request-Response Model: CoAP

• Design: RESTful protocol for constrained devices. UDP-based (low overhead, no connection).

• Methods: GET, POST, PUT, DELETE (like HTTP).

• Observe Pattern: Client subscribes to a resource; server sends new representations when resource changes (like a lightweight MQTT).

• Message Formats: Confirmable (CON) messages require ACK. Non-Confirmable (NON) are fire-and-forget.

• Security: Typically uses DTLS (Datagram TLS) for encryption.

• > [!TIP] CoAP vs. HTTP: CoAP uses binary header (compact), UDP, and has built-in observe. HTTP uses text header (larger), TCP, and requires polling/push tech (e.g., WebSockets).

2.3.3 Other Protocols

• AMQP: Enterprise-grade, reliable, queuing features. More complex/overhead than MQTT.

• XMPP: XML-based, presence/chat oriented. Good for human-to-machine or presence-based IoT.

2.3.4 Protocol Selection Criteria

2.4 Data Management, Cloud Integration & Edge Computing

2.4.1 Edge vs. Cloud Computing

2.4.2 Cloud IoT Platforms (AWS, Azure, GCP)

• Common Core Services:

  1. Device Registry/Management: Register devices, track metadata, manage credentials (certificates/keys).

  2. Data Ingestion: Secure endpoint (MQTT/HTTP) for devices to send telemetry.

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

  4. Storage: Time-series DB, object storage, NoSQL.

  5. Visualization: Dashboards (Grafana, CloudWatch, IoT Central).

• Conceptual Flow:

  Device (MQTT/HTTPS) → Cloud IoT Endpoint → Rules Engine → Storage/Analytics/Visualization

2.4.3 Data Processing & Storage

• Time-Series Databases (TSDB): Optimized for timestamped sensor data (InfluxDB, TimescaleDB). High write/query performance for time-based queries.

• Stream Processing: Process data in-motion (e.g., AWS Kinesis, Azure Stream Analytics). Used for real-time aggregation, anomaly detection.

• Visualization: Tools like Grafana (excellent for TSDB), Node-RED (flow-based integration), or cloud-native dashboards.

2.5 IoT Security Fundamentals & Challenges

2.5.1 The IoT Threat Landscape

• Attack Surfaces:

  1. Device: Physical tampering, firmware exploits, weak/default passwords.

  2. Communication: Eavesdropping, packet injection, replay attacks.

  3. Cloud/App: Insecure APIs, weak authentication, data breaches.

• Common Threats: Botnets (Mirai - DDoS via hijacked devices), data theft, ransomware, device hijacking.

2.5.2 Security Mechanisms & Best Practices

2.5.3 Privacy Considerations

• Data Minimization: Collect only what is necessary.

• Anonymization/Pseudonymization: Remove or mask personally identifiable information (PII).

• User Consent: Clear opt-in for data collection, especially for sensitive data.

• Regulations: GDPR (EU) - right to erasure, data portability. CCPA (California). Design for compliance.

2.6 Practical Implementation, Testing & Deployment

2.6.1 Prototyping & Development Workflow

1. Define: Sensing/actuation requirement.

2. Select: Sensor/actuator + MCU/SoC (consider connectivity, power, cost).

3. Interface: Wire hardware, write firmware to read sensor/control actuator.

4. Connect: Implement protocol (MQTT/CoAP) to send data to broker/cloud.

5. Integrate: Configure cloud rules, set up database, build dashboard.

6. Test: End-to-end data flow.

2.6.2 Testing & Debugging Tools

• Serial Monitor: (Arduino IDE, PuTTY) - View Serial.println() debug output.

• MQTT Clients: MQTT.fx, MQTT Explorer - Subscribe/publish to topics, test broker.

• CoAP Clients: CoAPthon, Postman (with CoAP plugin).

• Network Analyzers: Wireshark - Capture and inspect MQTT/CoAP packets (filter mqtt or coap).

• Logic Analyzer/O-Scope: Debug timing issues, PWM signals, communication buses (I2C/SPI).

2.6.3 Deployment Challenges

• Power Management:

  • Use deep sleep modes (ESP32: esp_sleep_enable_timer_wakeup()).

  • Optimize transmission power/duration.

  • Consider energy harvesting (solar, vibration) for maintenance-free operation.

• Scalability:

  • Broker Clustering: Use Mosquitto bridge or EMQX cluster for thousands of devices.

  • Cloud Scaling: Serverless functions (AWS Lambda) for per-device logic; avoid monolithic apps.

• Interoperability:

  • Use standard data formats (JSON for readability, CBOR for binary efficiency).

  • Adhere to standard semantic models (e.g., W3C Web of Things).

  • Beware of vendor lock-in (proprietary cloud APIs).

• Physical Deployment:

  • Enclosure: Weatherproof (IP rating), thermal management.

  • Antenna Placement: Avoid metal enclosures, test signal strength on-site.

  • Environmental Factors: Temperature/humidity extremes, vibration, EMI.

> [!TIP] Lab Exam Checklist: Be ready to wire a sensor (analog/digital) to an Arduino/ESP32, read data, publish via MQTT to a local broker (Mosquitto), and view it in a client. Know how to use Wireshark to filter and read an MQTT PUBLISH packet.