IOT Lab (CE-705) - Unit 2 Short Notes

UNIT 2: IoT System Implementation & Integration

2.1 Sensor & Actuator Interfacing & Calibration

Core Concept: Bridging the physical world (analog signals) to the digital domain (microcontroller) and back.

2.1.1 Analog vs. Digital Sensor Integration

• Analog Sensors: Output a continuous voltage/current proportional to the measured quantity (e.g., temperature, light).

  • Key Interface: Analog-to-Digital Converter (ADC). Microcontrollers have built-in ADCs.

  • ADC Resolution: Determines precision. For an n-bit ADC:

$$V_{digital} = \frac{V_{in}}{V_{ref}} \times (2^n - 1)$$

    \boxed{\text{Step Size (Resolution)} = \frac{V_{ref}}{2^n}}

*   **Example:** 10-bit ADC with 3.3V ref → 3.3mV/step.

*   **Voltage Divider:** Used to scale a sensor's output voltage into the ADC's acceptable range (0-Vref). For resistors R1 (to Vcc) and R2 (to GND):

$$V_{out} = V_{in} \times \frac{R2}{R1 + R2}$$

• Digital Sensors: Output discrete digital signals (I2C, SPI, 1-Wire, UART). Contain internal ADC/processing.

  • Advantage: Less susceptible to noise, longer cables, often provide calibrated outputs.

  • Interface: Use dedicated communication protocol libraries.

2.1.2 Actuator Control

• Relays: Electromechanical switches. Used to control high-voltage/current devices (lights, fans) from a low-power MCU.

  • Drive: MCU pin → Driver transistor (e.g., BC547) → Relay coil. Always use a flyback diode across coil.

• DC Motors: Require H-Bridge (e.g., L293D) for direction control. PWM (Pulse Width Modulation) for speed control.

  • PWM Principle: Average voltage = $$\displaystyle V_{cc} \times \frac{t_{on}}{T} $$ (Duty Cycle).

• Servo Motors: Position-controlled. Input is PWM signal with specific pulse width (e.g., 1-2ms for 0-180°).

• Stepper Motors: Precise angular movement. Requires driver (e.g., A4988) and sequential coil energizing.

2.1.3 Calibration Techniques & Error Handling

• Purpose: Map raw sensor output (ADC value/voltage) to accurate real-world units.

• Two-Point Calibration: Use two known reference points (e.g., ice water at 0°C, boiling water at 100°C). Derive linear equation:

$$Real\ Value = m \times (Raw\ Reading) + c$$

• Error Handling:

  • Out-of-Range: Check if reading exceeds sensor's min/max spec.

  • Stuck/No Reading: Implement timeout for I2C/SPI communication.

  • Noise: Apply software filtering (Moving Average, Median Filter).

  • Drift: Periodic recalibration schedule.

2.1.4 Common Lab Sensors

[!TIP] Lab Tip: For DHT sensors, use a dedicated library (e.g., DHT sensor library by Adafruit) to handle complex timing. Always place a 10kΩ pull-up resistor on the data line.

2.2 Microcontroller/Board Programming for IoT

2.2.1 Arduino IDE vs. PlatformIO

2.2.2 ESP32/ESP8266 Specifics

• WiFi Modes: Station (STA), Access Point (AP), STA+AP.

• Deep Sleep: Major power saving. Wake sources: timer, external wakeup (ext0/ext1).

  
  esp_sleep_enable_timer_wakeup(10 * 1000000); // 10s
  
  esp_deep_sleep_start();
  
  

• OTA Updates: Upload new firmware over WiFi.

  1. Include ArduinoOTA library.

  2. ArduinoOTA.begin() in setup().

  3. ArduinoOTA.handle() in loop().

  4. Upload from IDE using "Upload Using Programmer" (ESP32) or specific port.

2.2.3 Raspberry Pi Pico & MicroPython

• Advantage: Dual-core ARM Cortex-M0+, cheap, good for real-time tasks.

• MicroPython: Python-like syntax for microcontrollers.

  • Key Modules: machine (GPIO, ADC, I2C, SPI), network (WiFi), urequests (HTTP).

  • Thonny IDE: Recommended for beginners.

  • Example (Blink):

    
    from machine import Pin
    
    import time
    
    led = Pin(25, Pin.OUT)
    
    while True:
    
        led.toggle()
    
        time.sleep(0.5)
    
    

2.2.4 Interfacing Shields/Modules

• Ethernet (W5500): Uses SPI. Assign static IP or use DHCP.

• GSM/GPS (SIM800L, NEO-6M): Serial communication (UART). AT commands for GSM. NMEA sentences for GPS.

[!TIP] Common Pitfall: ESP8266 has only one hardware serial (UART0). Use SoftwareSerial for GPS/GSM, but it's CPU-intensive. Prefer boards with multiple UARTs (ESP32).

2.3 IoT Communication Protocols & Middleware

2.3.1 MQTT Protocol Deep Dive

• Publish/Subscribe Model: Decouples publishers from subscribers via a Broker.

• Topic Structure: Hierarchical, e.g., home/livingroom/temperature.

• QoS (Quality of Service):

  • 0 (At most once): Fire-and-forget. Fast, no guarantee.

  • 1 (At least once): Requires PUBACK. Duplicate possible.

  • 2 (Exactly once): 4-step handshake. Guaranteed, slowest.

• Retain Flag: Broker stores last message with retain flag on a topic. New subscribers get it immediately.

• Last Will & Testament (LWT): Client sets a message & topic to be published by broker if client disconnects ungracefully (e.g., home/device/status = offline).

• Broker Setup (Mosquitto):

  
  # Install
  
  sudo apt-get install mosquitto mosquitto-clients
  
  # Run with config (enable auth, TLS)
  
  mosquitto -c /etc/mosquitto/mosquitto.conf
  
  

  • Test: mosquitto_sub -t "test/#" -v (subscribe) & mosquitto_pub -t "test/topic" -m "hello" (publish).

2.3.2 HTTP/REST APIs

• Model: Client-Server (Request-Response).

• Methods: GET (read), POST (create), PUT (update), DELETE.

• Use Case: Infrequent data upload, device configuration.

• Drawback: Overhead (headers), not real-time, power-inefficient.

• Example (ESP32 HTTP POST):

  
  HTTPClient http;
  
  http.begin("http://api.thingspeak.com/update");
  
  http.addHeader("Content-Type", "application/x-www-form-urlencoded");
  
  int httpCode = http.POST("api_key=XXX&field1=25");
  
  

2.3.3 CoAP (Constrained Application Protocol)

• Designed for: REST-like communication on constrained nodes (low power, low bandwidth).

• Like HTTP but: Uses UDP (no connection), binary header, small code footprint.

• Methods: GET, POST, PUT, DELETE.

• Observe Option: Server can push notifications (like MQTT).

2.3.4 Local Network Communication

• UDP: Connectionless, fast, no guarantee. Good for broadcast sensor discovery.

• WebSockets: Full-duplex, persistent TCP connection. Ideal for real-time web dashboards (Node-RED, custom JS frontend).

[!TIP] Exam Focus: Know MQTT QoS levels and LWT. Be able to contrast Pub/Sub (MQTT) vs Req/Res (HTTP).

2.4 Cloud IoT Platforms & Data Management

2.4.1 Platform Comparison

2.4.2 Device Shadow / Digital Twin

• Concept: A JSON document (shadow) stored in the cloud that represents the desired and reported state of a physical device.

• Sync Mechanism:

  1. Device reports state → reported section updated.

  2. App/cloud sets desired state.

  3. Cloud syncs desired → delta → device.

  4. Device acts on delta, updates reported.

• Benefit: Device state is available even if offline. App can set desired state anytime.

2.4.3 Rule Engines & Serverless

• Rule Engine: Filters incoming device data (MQTT topic, payload) and triggers actions.

  • AWS IoT Rule: SELECT * FROM 'topic/sensor' WHERE temperature > 30 → ACTION: Lambda, S3, SNS.

  • ThingsBoard Rule Chain: Visual node-based processing.

• Serverless Functions (Lambda, Cloud Functions): Execute code in response to events (e.g., new sensor data) without managing servers.

2.4.4 Time-Series Databases (TSDB)

• Purpose: Optimized for timestamped data (sensor readings). Fast writes/range queries.

• Examples: InfluxDB, TimescaleDB (PostgreSQL extension), AWS Timestream.

• Schema: Typically (timestamp, measurement, tags, fields).

  
  -- InfluxDB line protocol example
  
  temperature,device=esp32_01,location=livingroom value=25.3 1625097600000000000
  
  

[!TIP] Common Pitfall: Don't store high-frequency sensor data directly in a relational DB (MySQL). Use a TSDB for raw data, aggregate to relational for summaries.

2.5 IoT Security Fundamentals in Lab Context

2.5.1 Secure Communication

• TLS/SSL: Encrypts MQTT (MQTTS) and HTTP (HTTPS) traffic.

• Certificate-Based Auth (X.509): Most secure. Device has unique certificate & private key.

  • Broker Setup (Mosquitto): Requires cafile, certfile, keyfile.

  • ESP32: Use WiFiClientSecure and load certs from PROGMEM or filesystem.

• Lab Practice: Use self-signed CA for testing. Never disable certificate validation (setInsecure() is only for testing).

2.5.2 Authentication & Authorization

• API Keys: Simple token in header/query. Easy but less secure if leaked.

• JWT (JSON Web Token): Token containing claims. Signed by auth server. Stateless.

• X.509 Certificates: As above. Provides mutual auth (both client & server verify).

2.5.3 Device Security

• Secure Boot: Bootloader verifies firmware signature before execution.

• Firmware Signing: Sign firmware image with private key. Device verifies with public key.

• Credential Storage: Never hardcode in source. Use:

  • ESP32: NVS (Non-Volatile Storage) with encryption, or secure element (ATECC608A).

  • Raspberry Pi: Hardware security key (HUK), encrypted filesystem.

2.5.4 Common Vulnerabilities & Mitigation

[!TIP] Exam Tip: Know the difference between authentication (who are you?) and authorization (what can you do?). In MQTT, ACLs (Access Control Lists) handle authorization.

2.6 IoT System Design & Project Lifecycle

2.6.1 Requirement Analysis & Component Selection

• Questions: Data rate? Power source (battery/mains)? Range? Cost? Environment?

• Selection Flow: Sensing need → Sensor spec → Interface (Analog/Digital) → MCU (GPIO, ADC, comms) → Connectivity (WiFi/BLE/LoRa) → Cloud platform.

2.6.2 Edge vs. Cloud Processing

2.6.3 Prototyping to Deployment

• Version Control (Git): Track code, config files. Use .gitignore for secrets (secrets.h, *.key).

• Containerization (Docker): Package cloud services (broker, database, app) for consistent deployment.

  
  # Example Dockerfile for Node-RED
  
  FROM nodered/node-red:latest
  
  COPY flows.json /data/flows.json
  
  

2.6.4 Testing & Debugging Strategies

1. Serial Monitor: Basic prints (Serial.println()).

2. MQTT.fx / MQTT Explorer: Subscribe/publish to topics, inspect payloads.

3. Cloud Logs: AWS CloudWatch, Azure Monitor. View device-side logs sent via MQTT/HTTP.

4. Packet Sniffing: Wireshark with filter tcp port 8883 (for MQTTS) to verify TLS handshake.

5. Logic Analyzer: For precise timing on I2C/SPI/UART.

[!TIP] Project Lifecycle Flow: Requirement → Architecture (Edge/Cloud) → Component Selection → Prototype (Arduino) → Integrate (MQTT) → Cloud Setup → Test & Debug → Containerize Services → Deploy.

2.7 Advanced Lab Integrations & Case Studies

2.7.1 Integrating with External APIs

• Use Case: Send SMS on alert (Twilio), get weather (OpenWeatherMap), send email (IFTTT/Email API).

• Method: Device or cloud function makes HTTPS GET/POST request with API key.

• Lab Flow: Sensor triggers → MQTT → Cloud Rule → Lambda Function → External API call.

2.7.2 Simple Edge AI: TensorFlow Lite for Microcontrollers (TFLu)

• Flow: Train model in TensorFlow (Python) → Convert to .tflite → Quantize → Deploy to MCU (ESP32, Arduino).

• Library: TensorFlowLite_ESP32 or TensorFlowLite_Arduino.

• Example: Keyword spotting, simple image classification (camera + ESP32-CAM).

• Constraint: Model size (<250KB), RAM (<100KB). Use microSpeech, microImagenet examples.

2.7.3 IoT with Blockchain for Data Integrity

• Concept: Store sensor data hashes (not raw data) on blockchain (e.g., Ethereum, Hyperledger Fabric) for tamper-proof audit trail.

• Lab Implementation:

  1. Device sends data to cloud.

  2. Cloud function computes hash (SHA-256) of data + timestamp.

  3. Function writes hash to smart contract (via Web3.js, web3.py).

  4. Verification: Recompute hash from stored data, compare with on-chain hash.

• Note: Overhead is high. Use for critical logs (medical, legal), not high-frequency sensor data.

2.7.4 Mini-Project Walkthroughs

• Smart Home:

  • Sensors: DHT22, PIR, LDR.

  • Actuators: Relay (light/fan), Servo (door lock).

  • Cloud: ThingsBoard/Blynk for dashboard & mobile control.

  • Security: MQTTS with certs, device auth tokens.

• Agriculture:

  • Sensors: Soil moisture (analog), DHT22, DS18B20 (water temp).

  • Connectivity: LoRa (long range, low power) → Gateway → MQTT broker.

  • Cloud: Custom Node-RED dashboard, rule to trigger irrigation pump.

• Industrial Monitoring:

  • Sensors: Vibration (analog), current (CT sensor), temperature.

  • Edge: ESP32 for data acquisition, local anomaly detection (simple threshold).

  • Cloud: AWS IoT Core → Timestream for storage → Grafana dashboard. Alarms via SNS.

[!TIP] Case Study Focus: For any mini-project, be able to draw the system architecture diagram showing: Sensors → MCU (Edge logic) → Protocol (MQTT) → Cloud Platform → Application (Dashboard/Alert). Identify where security (TLS, Auth) is applied at each layer.