CE-705: IOT Lab - UNIT 1 Short Notes (Provisional Template)

⚠️ Critical Disclaimer: These notes are based on a generic, speculative template for a typical introductory IoT Lab unit. They are NOT aligned to the official RGPV syllabus for CE-705. You must replace this content with topics from your actual course syllabus and past exam papers. Use this only as a structural reference.

1.0 Introduction to IoT Systems & Lab Environment

1.1 Definition & Scope of the Internet of Things (IoT)

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

• Core Concept: Connecting "things" to the internet to enable remote sensing, monitoring, and control.

• Typical Application Domains: Smart homes, industrial automation (IIoT), smart cities, healthcare (remote monitoring), agriculture (precision farming).

[!TIP] Exam Focus: Be prepared to differentiate between IoT (focused on consumer/enterprise devices) and IIoT (focused on industrial systems with higher demands for security, reliability, and scale).

1.2 Key Components of an IoT System (The 5-Layer Model)

1. Thing/Device: Physical object with sensors/actuators (e.g., temperature sensor, LED).

2. Connectivity: Communication hardware/module (Wi-Fi, Bluetooth, cellular) to send data to the cloud.

3. Data Processing/Cloud: Backend platform to ingest, store, process, and analyze data.

4. Application/User Interface: Dashboard, mobile app, or web interface for user interaction and visualization.

5. Business Logic: Rules and actions triggered based on processed data (e.g., "If temp > 30°C, turn on fan").

1.3 Lab Safety, Documentation, and Reporting Standards

• Electrical Safety: Proper use of multimeters, avoiding short circuits, correct power supply usage (e.g., 5V vs 3.3V for ESP32).

• ESD Precautions: Use anti-static mats/wrist straps when handling sensitive boards.

• Documentation: MUST maintain a Lab Notebook/Record with:

  • Circuit diagrams (Fritzing or schematic).

  • Code snippets with version control (date, purpose).

  • Observations, errors, and troubleshooting steps.

  • Final output screenshots (serial monitor, cloud dashboard).

• Report Structure: Objective, Theory/Components, Methodology/Procedure, Results & Screenshots, Discussion/Analysis, Conclusion.

1.4 Setting Up the Development Environment

• IDE Installation: Arduino IDE or PlatformIO (VS Code extension).

• Board Manager: Installing support packages for specific boards (e.g., ESP32, Arduino Nano).

• Serial Monitor: Primary tool for debugging – Serial.begin(9600); Serial.println();.

• Library Management: Installing required libraries (e.g., WiFi.h, PubSubClient.h for MQTT, DHT.h for sensor).

[!TIP] Common Pitfall: "Board not found" errors are usually due to missing board packages in the IDE or incorrect COM port selection.

2.0 Foundational Hardware & Microcontrollers

2.1 Overview of Common IoT Development Boards

2.2 Microcontroller Basics: GPIO, ADC, PWM, Communication

• GPIO (General Purpose Input/Output): Digital pins set as INPUT or OUTPUT. Use pinMode(), digitalWrite().

• ADC (Analog-to-Digital Converter): Converts analog voltage (0-Vref) to a digital value.

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

Where:

*   $D$ = Digital Output (integer)

*   $$\displaystyle V_{in} $$ = Input Analog Voltage

*   $$\displaystyle V_{ref} $$ = Reference Voltage (e.g., 3.3V or 5V)

*   $n$ = Resolution in bits (e.g., 10-bit for Uno → $$\displaystyle 2^{10}-1 = 1023 $$)

\boxed{D = \left( \frac{V_{in}}{V_{ref}} \right) \times 1023 \quad \text{(for 10-bit ADC)}}

• PWM (Pulse Width Modulation): Simulates analog output by rapidly switching digital pin ON/OFF. analogWrite(pin, value) (0-255). Used for LED dimming, motor speed control.

• Communication Interfaces:

  • UART (Serial): Serial.begin(baud). Point-to-point. TX (pin 1), RX (pin 0).

  • I2C: 2-wire (SDA, SCL). Multi-master, multi-slave. Uses 7-bit slave addresses. Wire.begin().

  • SPI: 4-wire (MOSI, MISO, SCK, SS). High-speed, full-duplex. Master-slave only.

2.3 Reading Sensor Data: Digital vs. Analog

• Digital Sensors: Output discrete digital signals (I2C/SPI/UART). Examples: DHT11 (temp/humidity), DS18B20 (temp). Advantage: Less noise, easier interfacing.

• Analog Sensors: Output continuous voltage proportional to measured quantity. Examples: LDR (light), MQ-2 (gas), potentiometer. Requires ADC on MCU.

2.4 Controlling Actuators

• LEDs: Direct drive via GPIO with current-limiting resistor (220Ω-1kΩ).

• Relays: Electromechanical switch for high-voltage/current loads. Controlled by a low-power GPIO signal. ⚠️ Use optocoupler for isolation.

• DC Motors: Require driver (L293D, L298N) for direction/speed control (PWM).

• Servo Motors: Position control via PWM signal (50Hz). Use Servo.h library.

[!TIP] Exam Trap: "Can I connect a 5V relay directly to a 3.3V ESP32 GPIO pin?" No. The coil voltage must match the control signal voltage or use a transistor driver circuit.

3.0 Basic Connectivity & Communication Protocols

3.1 Introduction to Wireless Protocols (Conceptual)

3.2 Connecting to a Wi-Fi Network (Station Mode)

• Code Skeleton (ESP32/Arduino MKR1000):

  
  #include <WiFi.h>
  
  const char* ssid = "Your_SSID";
  
  const char* password = "Your_PASS";
  
  void setup() {
  
    Serial.begin(115200);
  
    WiFi.begin(ssid, password);
  
    while (WiFi.status() != WL_CONNECTED) {
  
      delay(500); Serial.print(".");
  
    }
  
    Serial.println("Connected! IP: " + WiFi.localIP());
  
  }
  
  

• Modes: Station (STA) connects to an AP. Access Point (AP) creates its own network. Many boards support AP+STA simultaneously.

3.3 Simple Client-Server Communication (HTTP/HTTPS)

• HTTP GET Request (to fetch data from a server/REST API):

  
  #include <HTTPClient.h>
  
  HTTPClient http;
  
  http.begin("http://api.example.com/data");
  
  int httpCode = http.GET();
  
  if (httpCode == 200) {
  
    String payload = http.getString(); // Process JSON/XML
  
  }
  
  http.end();
  
  

• Use Case: Fetching weather data from an API.

3.4 MQTT Protocol Fundamentals (The IoT Standard)

• Publish/Subscribe Model: Decouples message sender (Publisher) from receiver (Subscriber).

• Broker: Central server (e.g., Mosquitto, HiveMQ, Cloud broker) that routes messages.

• Topic: Hierarchical string (like a URL) used for message routing. home/livingroom/temp.

• QoS (Quality of Service):

  • QoS 0: "At most once" – Fire and forget. Fastest, may lose messages.

  • QoS 1: "At least once" – Acknowledgment required. May get duplicates.

  • QoS 2: "Exactly once" – Handshake protocol. Slowest, most reliable.

• Basic Code (PubSubClient library):

  
  #include <PubSubClient.h>
  
  WiFiClient espClient;
  
  PubSubClient client(espClient);
  
  void callback(char* topic, byte* payload, unsigned int length) {
  
    // Message received logic
  
  }
  
  void setup() {
  
    client.setServer("broker.hivemq.com", 1883);
  
    client.setCallback(callback);
  
  }
  
  void loop() {
  
    client.loop(); // Maintain connection
  
    if (!client.connected()) reconnect();
  
    client.publish("my/topic", "Hello"); // Publish
  
  }
  
  

[!TIP] Exam Favorite: "Explain the role of the MQTT Broker." Answer: It's the central message router that receives all messages from publishers, filters them by topic, and distributes them to all subscribed clients. It manages client connections and session state.

4.0 Data Handling & Cloud Platforms (Introductory)

4.1 Concept of Cloud IoT Platforms

• Purpose: Provide scalable infrastructure for device management, data ingestion, storage, processing, and visualization.

• Common Platforms:

  • Public Cloud: AWS IoT Core, Azure IoT Hub, Google Cloud IoT Core.

  • Specialized IoT PaaS: ThingsBoard (open-source), Ubidots, Blynk (simpler, app-focused).

4.2 Sending Data to a Cloud Platform

• Typical Flow: Device → MQTT/HTTP → Cloud IoT Broker → Rules Engine → Database/Dashboard.

• Authentication: Often uses X.509 certificates (for MQTT) or API Keys/Token (for HTTP).

• Data Format: Usually JSON.

  
  {
  
    "device_id": "sensor_001",
  
    "timestamp": 1678901234,
  
    "temperature": 26.5,
  
    "humidity": 60
  
  }
  
  

4.3 Visualizing Simple Data Streams

• Dashboard Widgets: Gauges, charts (line, bar), text displays, maps.

• Configuration: Map incoming JSON keys (e.g., temperature) to specific widget data sources.

• Example (ThingsBoard): Create a "Time Series Chart" widget, set data source to temperature key from telemetry.

4.4 Basic Remote Control (Actuation)

• Downlink/Command: Cloud sends a command message to a specific device topic (e.g., device/001/command).

• Device Logic: In the MQTT callback(), check incoming topic/payload and trigger action.

  
  if (strcmp(topic, "device/001/command") == 0) {
  
    if (strcmp((char*)payload, "LED_ON") == 0) digitalWrite(LED_PIN, HIGH);
  
  }
  
  

5.0 Simple End-to-End IoT Project Integration

5.1 Project: Sensor -> Microcontroller -> Cloud -> Dashboard

1. Hardware Setup: Connect sensor (e.g., DHT11) to MCU (ESP32) pins.

2. Firmware: Read sensor data periodically. Connect to Wi-Fi. Connect to MQTT broker. Publish JSON data to topic sensors/room1.

3. Cloud Setup: Create device on platform (ThingsBoard/AWS). Get credentials (token/cert).

4. Dashboard: Create widgets, link to device's telemetry keys (temperature, humidity).

5. Test: Verify data appears on dashboard. Test remote command (e.g., publish "BUZZER_ON" to command topic).

5.2 Troubleshooting Common Issues

5.3 Lab Report Structure (Critical for Practical Exams)

1. Title & Objective: Clear statement of aim.

2. Components & Tools List: Specific board, sensor, software (IDE version, library names).

3. Circuit Diagram: Neat, labeled. Use standard symbols.

4. Procedure/Algorithm: Step-by-step. Include code flowchart if possible.

5. Implementation: Full, commented code in appendix. Main report shows key snippets.

6. Results & Screenshots: Serial monitor output, cloud dashboard screenshot, physical setup photo.

7. Discussion: Explain results. Analyze errors. Compare expected vs. actual.

8. Conclusion: State if objective met. Suggest improvements.

[!TIP] Viva Voce Prep: Be ready to explain every line of your code and every connection in your circuit. Know the function of each library and pin used. Practice explaining the entire data flow from sensor to dashboard.