OraScan H — Halitosis IoT Device

The Problem

Bad breath affects 1 in 4 people, but most never get it properly diagnosed because it's embarrassing to bring up with a doctor. People need a way to check privately at home — without buying expensive clinical lab equipment or visiting a specialist.

The Challenge

Halitosis affects an estimated 25% of the population but is severely under-diagnosed due to social stigma around clinical evaluation. The product needed to be a consumer-grade, handheld device that anyone could use at home — not a lab instrument. The engineering challenges were multi-layered: H2S sensor signal is noisy and temperature-sensitive, requiring careful analog conditioning; the Raspberry Pi Zero 2W has only 1 GB RAM, constraining the on-device AI pipeline; the Flutter mobile app needed to reliably pair via BLE, stream sensor readings, and present results in a clinically actionable way.

Architecture & System Design

IoT device with dual gas sensor arrays connected to mobile app via wireless protocol. On-device machine learning model processes sensor readings for analysis. Mobile app provides real-time results and trend history. Backend service handles data persistence and optional cloud synchronization with secure firmware update mechanism.

The hardware stack centres on a Raspberry Pi Zero 2W running a Python BLE GATT server (D-Bus/BlueZ). Two gas sensor arrays (DTS4H2S + MQ316) are read via ADS1115 ADC over I2C, with GPIO-based LED status indicators and a serial interface for auxiliary sensors. Sensor readings feed into a TensorFlow Lite model running on-device that classifies halitosis severity. The Flutter mobile app (flutter_blue_plus) discovers and pairs with the device, streams live readings, and renders severity scores with trend history. A PHP 8.2 + MySQL 8.0 backend on Hostinger handles session persistence and optional cloud sync. OTA firmware updates are signed and verified on-device before installation.

Code Walkthrough

3-step walk-through of the production implementation — file paths and intent shown above each block.

1. 01

   Step 1 of 3

   Serial sensor with auto-reconnect and framed protocol parsing

   OraScan_H_DeviceCode/h2s_sensors.py

   UART-attached gas sensors drop out randomly — loose connectors, kernel USB events, or the sensor's own firmware resetting. The driver thread has to survive a disconnect without restarting the whole device process, so reconnection sits behind an exponential-backoff loop while frame parsing validates every read with a checksum before trusting the value.

   pythonCopy

   Takeaway

   Serial devices need three layers of defence: a checksum on every frame, a reconnect loop with exponential backoff, and a daemon thread that hides all of it from the rest of the app.

2. 02

   Step 2 of 3

   BLE connection health with RSSI hysteresis

   OraScan_H_Mobile_App/lib/features/ble/data/services/connection_monitor_service.dart

   A BLE link that's technically connected but losing packets is worse than a clean disconnect — the UI looks fine while the session silently corrupts. The monitor polls RSSI every few seconds and emits weak / critical events when the signal crosses thresholds, but uses a 5-dB hysteresis gate so a hovering signal near the threshold doesn't spam the user with 'signal weak → signal ok → signal weak' toasts.

   dartCopy

   Takeaway

   Hysteresis is what turns a noisy physical signal into a usable UX event stream — without the 5-dB deadband, any device on the edge of range would flood the UI with alternating weak/ok toasts.

3. 03

   Step 3 of 3

   D-Bus GATT characteristic with read/write callbacks

   OraScan_H_DeviceCode/ble_gatt_server.py

   BlueZ 5.82+ dropped the higher-level helper libraries, so the device exposes its GATT service by registering a D-Bus object directly. The trick is keeping business logic out of the D-Bus layer: the Characteristic class just forwards Read/Write into injected callbacks, so each feature (sensor stream, device info, config write) only has to implement two plain Python functions.

   pythonCopy

   Takeaway

   Expose D-Bus as a plumbing layer, not a domain layer — each GATT characteristic is just a thin wrapper over two callbacks, so adding a new feature is a pure-Python exercise with zero D-Bus knowledge required.

Results

OraScan H reached 92% software completion in Sprint 3 with production-ready mobile app and backend. BLE pairing achieves stable connection within 3 seconds. The TFLite classifier runs on the Pi Zero 2W in under 500ms. The Flutter app is live on both iOS and Android with a full onboarding, pairing, and results flow. Hostinger backend handles session persistence with rate-limited API endpoints and MIME-validated image uploads.

Gallery & Demos

Device Front View

Handheld form factor with mouthpiece intake, dual gas sensor arrays inside, and GPIO-driven LED status indicators.

LED Status States

Four GPIO-driven LED states: off (standby), green (scan complete / pass), blue (scanning), red (alert / fail).

Hardware Evolution

Design iterations from prototype to production across multiple sprints.

Cloud Architecture

BLE pairing flow, on-device TFLite inference, and PHP backend session storage with rate-limited endpoints.

Click any image or video to expand · ← → keys navigate