Project Overview & Team Integration

--:--:-- • --
Connecting...
DEMO DATA ACTIVE: Running in simulated sensor mode on standard computer without physical Raspberry Pi I²C hardware. All readings are clearly marked as demo.
TEMPERATURE THRESHOLD WARNING

Sensor reading has exceeded the safety threshold.

Configurable temperature warning for school environmental monitoring. Not a medical or industrial diagnosis.
VA | Virtual Atmosphere Student IoT Science Project
Understand Your Atmosphere.
Live Dashboard: va.developerhut.in Status: Operational Prototype

Virtual Atmosphere (VA) is a student-built environmental monitoring and atmospheric intelligence platform engineered using a Raspberry Pi 3 Model B+ and a precision GY-BMP280 atmospheric sensor. The project bridges physical environmental observation with modern full-stack web telemetry to monitor local microclimates, log persistent records, visualize thermodynamic trends, and detect critical thermal variations.

Direct I²C Interface
Sensor connects directly to Raspberry Pi GPIO. Zero intermediate microcontrollers (no ESP32 required).
Edge SQLite Storage
Runs completely locally with SQLite in Write-Ahead Logging (WAL) mode. Zero cloud dependency.
Active Warning System
Configurable high-temperature threshold detection with persistent logging and deduplication.
Scientific Integrity
Accurate reporting of valid BMP280 metrics (temperature and barometric pressure). No fabricated data.

Problem Statement & Purpose

Context

Commercial weather applications rely on macro-scale radar stations situated at distant airports, often kilometers away. These broad forecasts fail to capture localized indoor microclimates, classroom heat accumulation, computer lab thermal spikes, or rapid barometric fluctuations within a school building.

Furthermore, many educational IoT setups depend on proprietary third-party cloud brokers or fragile intermediate microcontrollers that introduce unnecessary latency, subscription fees, and internet vulnerability. Virtual Atmosphere solves this by providing a self-hosted, offline-capable monitoring station that runs entirely on local school network infrastructure.

Project Objectives & Expected Outcomes

Goals
  • Real-Time Physical Telemetry: Sample ambient temperature and atmospheric pressure at configurable sampling intervals (default 10s).
  • Local Historical Retention: Index historical measurements in SQLite for analytical querying across 1h, 6h, 24h, and 7d horizons.
  • Responsive Visualization: Render interactive Chart.js graphs and live gauges accessible via mobile, tablet, and desktop browsers.
  • Configurable Safety Alerts: Detect thermal threshold violations with deduplicated alert tracking and hysteresis resolution.
  • Scientific Data Export: Provide one-click CSV data export for scientific graphing, spreadsheet modeling, and STEM coursework.
Current Development Status: Fully functional prototype deployed at https://va.developerhut.in/dashboard, supporting both Raspberry Pi live I²C hardware and laptop demo mode.

Project Workflow

Step-by-step end-to-end data acquisition, validation, storage, and presentation pipeline
7-Stage Pipeline
1
Sensor Setup

Connect the GY-BMP280 sensor to the Raspberry Pi 3 Model B+ 40-pin GPIO header using the hardware I²C interface (3.3V, GND, SDA on GPIO2, SCL on GPIO3).

2
Data Collection

Use Python and smbus2 to query I²C bus 1, read raw calibration registers, and poll temperature and atmospheric pressure registers.

3
Data Processing

Apply Bosch compensation polynomial formulas, validate readings within physical bounds (-40 to 85°C, 300 to 1100 hPa), and attach UTC timestamps.

4
Data Storage

Commit validated measurements to the local SQLite database using Write-Ahead Logging (WAL) and parameterized queries to preserve historical continuity.

5
Backend Processing

Flask REST APIs serve telemetry, compute min/max/average stats, and evaluate threshold alerts with deduplication and hysteresis recovery.

6
Dashboard View

Render dynamic Chart.js time-series charts, live telemetry cards, delta tendencies, and historical logs on a responsive scientific dark UI.

7
Testing & Deploy

Execute automated unit tests, verify failover without hardware, configure systemd startup services, and deploy for local LAN and web access.

Meet the Team

Student engineering and research team driving the Virtual Atmosphere project
Project Team
V
Vasu
Team Lead
Core Responsibilities
Project coordination, system architecture, software development, full-stack integration, database schema design, and system testing.
TS
Thakshanamoorthi S
Project Team Member
Core Responsibilities
Assist with project development, hardware setup, I²C sensor wiring, reliability testing, and project documentation.
N
Nithilan
Project Team Member
Core Responsibilities
Assist with sensor calibration experiments, atmospheric data validation, threshold verification testing, and project presentation.
Note: Member responsibilities represent primary focus areas and can be adapted as project tasks evolve.

System Architecture & Data Flow

Component-level data progression from physical transducer to client interface
Data Flow
1. Physical Sensor
GY-BMP280 Sensor

Piezoresistive transducer reading ambient temperature and barometric pressure.

→
2. Bus Interface
I²C Interface

Two-wire synchronous serial communication bus (SDA/SCL) running at 3.3V logic.

→
3. Single-Board Host
Raspberry Pi 3B+

Embedded Linux host executing services, managing I²C bus, and local network serving.

→
4. Service Layer
Python Sensor Service

Daemon worker polling registers, computing polynomial compensation, and validating bounds.

→
5. Web Engine
Flask Backend

Lightweight web application serving REST endpoints and managing threshold alert logic.

→
6. Persistent Storage
SQLite Database

Thread-safe local database storing indexed time-series readings and alert event logs.

→
7. User Interface
VA Dashboard

Client interface rendering live gauges, Chart.js trends, and historical query tables.

Hardware Specifications

Bill of Materials
Host Computer: Raspberry Pi 3 Model B+ (Broadcom BCM2837B0, quad-core Cortex-A53 @ 1.4GHz, 1GB LPDDR2 RAM)
Sensor Module: GY-BMP280 Barometric Pressure & Temperature Breakout (Bosch Sensortec)
Power Supply: 5.0V / 2.5A micro-USB power adapter with stable voltage regulation
I²C Connections: Direct female-to-female Dupont jumper wires (VCC to Pin 1 [3.3V], GND to Pin 6, SDA to Pin 3, SCL to Pin 5)
Physical Logic Level: 3.3V DC logic (strictly never connected to 5.0V pins to prevent sensor damage)

Software Stack

Application Architecture
Language Runtime: Python 3.9+ with virtual environment isolation (.venv)
Backend Framework: Flask 3.x WSGI framework with factory pattern and canonical REST endpoints
Database Engine: SQLite 3 with Write-Ahead Logging (WAL) and parameterized indexed queries
Hardware Driver: Python smbus2 direct I²C register driver with fallback simulation engine
Frontend Interface: HTML5, custom responsive CSS3 design system, Bootstrap 5 grid, Chart.js v4.4
Service Management: Linux systemd background service for autostart on Raspberry Pi boot

Measurement Limitations & Scientific Accuracy

Scientific Standards

Humidity & Heat Index Transparency

The onboard GY-BMP280 sensor breakout houses a piezoresistive barometric pressure element and an integrated temperature sensor. It does not contain a relative humidity sensor (unlike the BME280).

  • No Fabricated Humidity: Virtual Atmosphere strictly adheres to scientific honesty and does not generate or display synthetic humidity data as real readings.
  • Heat Index & WBGT Boundaries: Calculating a validated Heat Index or Wet Bulb Globe Temperature (WBGT) requires simultaneous relative humidity and wet-bulb thermodynamic measurements. These calculations cannot be reliably performed using a BMP280 sensor alone.
  • Future Expansion: Supporting WBGT or Heat Index would require adding a dedicated humidity sensor (e.g., DHT22/SHT31) or natural wet-bulb temperature apparatus.

Hardware vs. Demo Mode Separation

The application strictly segregates live hardware measurements from development simulation:

  • Live Hardware Mode: If the physical sensor is disconnected, the system unambiguously reports Sensor Offline and records zero fake measurements into the database.
  • Demo Mode: All simulated records are explicitly labeled with source="demo" and accompanied by a visible notification banner.
  • Educational Disclaimer: This system is developed for school IoT science projects and environmental study. Temperature threshold alerts are educational notifications, not medical diagnoses or OSHA industrial safety ratings.