The Problem We Set Out to Solve

Flames are not always what kills a firefighter. CO poisoning, heat exhaustion, and disorientation inside burning structures claim lives too. The moment a firefighter crosses a threshold into a smoke-filled building, their incident commander loses them entirely. No vitals. No gas readings. No location. Just silence, and hope.

We wanted to change that.

Field Research: Starting with Real Problems, Not Assumptions

We visited Byculla Fire Headquarters, Mumbai and spoke directly with experienced firefighters about what actually goes wrong during operations. This happened before any code was written, before any components were ordered.

Their answer was consistent: once a firefighter enters a structure, the outside world loses them. Command makes decisions blind. There is no way to know whether the person inside is still safe, struggling, or down.

That conversation became the foundation of every design decision in FAiMN, from sensor selection to the chest-mounted form factor to prioritizing audio alerts over visual displays.

What FAiMN Does

FAiMN (Firefighters' Assistant IoT-based Monitoring Network) is a wearable IoT safety system that gives incident commanders real-time visibility of every firefighter in the field, even deep inside concrete structures where phones and radios fail.

The wearable continuously measures:

• Carbon monoxide concentration (ZE16B electrochemical sensor)
• Body temperature (PT100 RTD via skin contact)
• Ambient and environmental temperature (second PT100 RTD)
• Motion, orientation, and fall detection (MPU9250 9-axis IMU)
• Atmospheric pressure for floor estimation (BMP388)

All data is transmitted over LoRa, a long-range, low-power radio protocol that works without any cellular or Wi-Fi infrastructure, to a receiver at the command post. That receiver pushes everything live to a Flutter dashboard visible to the incident commander.

The firefighter themselves receives immediate voice alerts through an in-ear earphone, without ever needing to look at a screen.

Communication Flow

Our Design Journey: 3 Prototypes Over One Year

FAiMN did not arrive fully formed. It was built, broken, rebuilt, and rethought across three complete hardware iterations.

Prototype 1: Proving the Concept

Goal: Verify that sensing, processing, and wireless transmission could work together reliably.

We started on a breadboard, then moved to a single custom PCB designed in KiCad and fabricated at the AICTE Idea Lab, SAKEC. A separate receiver board (ESP32 + SX1278) was built alongside it to receive transmissions and forward data to ThingSpeak for visualisation.

Hardware:

• ESP32 Dev Board (30-pin)
• LoRa SX1278 (433 MHz)
• MQ-2 + MQ-7 gas sensors
• Dual PT100 + MAX31865
• ADXL345 accelerometer
• Cloud: ThingSpeak

What we proved: Sensing, LoRa communication, and cloud visualization all worked end-to-end.

What we learned: ThingSpeak introduced roughly 15-second update delays, which is unacceptable for emergency monitoring. The board also had no wearable form factor whatsoever.

Prototype 2: Making It Wearable (First Attempt)

Goal: Turn the working electronics into something a firefighter could actually wear.

We redesigned the PCB into three smaller boards arranged as a neckband. ThingSpeak was replaced with Firebase Realtime Database, which dropped synchronization latency from around 15 seconds to under 1 second. A Flutter dashboard was developed to display live readings. The receiver now pushed incoming LoRa packets directly to Firebase instead. The sensors stayed the same as Prototype 1. We also validated multi-firefighter support in this version — a 2-position DIP switch assigned unique IDs across two simultaneous units, confirming the multi-unit architecture worked end-to-end.

What we proved: Near-instant cloud sync. Flutter dashboard functional. Wearable in principle. Multi-unit ID assignment working.

What we learned: The neckband form factor was mechanically unstable and uncomfortable during active movement. A product designer reviewing the prototype confirmed it was not viable for operational use.

Prototype 3: Product-Oriented Redesign (Current Version)

Goal: Build something that could survive real deployment, worn by real firefighters.

The redesign drew on two things: the product designer's feedback and the insights from our visit to Byculla Headquarters. Firefighters already carry equipment in chest pockets inside their protective jackets, so that is where FAiMN belongs.

The receiver was not changed. The same ESP32 + SX1278 board from Prototype 1 still bridges field transmissions to Firebase — a testament to that original design holding up through every iteration.

Step-by-Step Build Guide

Step 1: Sensor Selection — Mapping Risks to Hardware

Each firefighter hazard maps directly to a sensor:

Step 2: Individual Sensor Testing

Each sensor was tested independently before integration:

• ZE16B outputting around 0 ppm in clean air, rising measurably on CO exposure
• Both PT100 sensors cross-checked against a reference thermometer
• BMP388 detecting pressure change when moved between floors
• MPU9250 outputting correct axis readings for each movement direction
• Serial MP3 module playing correct audio tracks on GPIO trigger

ZE16B Calibration

The ZE16B electrochemical sensor requires a warm-up period before its readings stabilise. On power-on, FAiMN starts a 4-minute calibration timer. During this window, CO readings are continuously received but not used to trigger alerts or transmit warnings. At 30 seconds, the system plays an audio confirmation that it has started. At 4 minutes, it plays a second audio confirmation that calibration is complete and CO monitoring is now active. This is managed via a calibrationDone flag in firmware — all CO alert logic is gated behind it.

if (!calibrationDone && now - startTime > 240000) {
  playTrack(10); // "Calibration complete"
  calibrationDone = true;
}

if (calibrationDone) {
  if (co_ppm >= 30 && co_ppm < 99 && now - lastCOWarn > 30000) {
    playTrack(13);
    lastCOWarn = now;
  }
}

Step 3: Multi-Sensor Firmware Integration

Integrating all sensors into a single firmware was the hardest engineering challenge of the project.

Key problems solved:

• Multiple SPI devices (2x MAX31865, BMP388, SX1262) required careful chip-select (CS) pin management to avoid bus conflicts
• MPU9250 on I2C required address configuration to avoid conflicts with BMP388
• Sensor polling was structured by priority — CO and temperature are sampled every cycle; BMP388 and MPU9250 run at reduced rates to manage processing load

Step 4: LoRa Communication

The Heltec WiFi LoRa 32 V3 (SX1262) transmits a data packet containing all sensor readings every few seconds. The receiver — an ESP32 Dev Board with SX1278 — sits at the command post and immediately forwards incoming packets to Firebase Realtime Database over Wi-Fi.

Range testing confirmed stable communication across the full campus range, well beyond the distances expected inside a multi-storey building deployment.

Receiver Firmware: Parsing and Firebase Push

The receiver parses each incoming LoRa string by key-value lookup. It then calculates direction, floor change, fall status, and movement status locally before pushing a structured JSON to Firebase at two paths simultaneously: /firefighters/device_001/latest is always overwritten with the most recent reading for live dashboard display, while /firefighters/device_001/history/[timestamp] appends a timestamped entry for the full operational log. The receiver also tracks RSSI and SNR per packet and counts missed packets by checking for gaps in the sequential packet number.

FirebaseJson json;
json.set("packet", currentPacketNo);
json.set("temp_body", t2);
json.set("temp_ambient", at);
json.set("co", co);
json.set("direction", direction);
json.set("floor", floorStatus);
json.set("fall", fallStatus);
json.set("movement", movementStatus);

// Live latest reading
Firebase.RTDB.setJSON(&fbdo,
  "/firefighters/device_001/latest", &json);

// Historical log with timestamp key
Firebase.RTDB.setJSON(&fbdo,
  ("/firefighters/device_001/history/" + timestampKey).c_str(), &json);

Note: Prototype 3 is validated as a single unit (device_001). Multi-firefighter ID assignment via DIP switch was confirmed working in Prototype 2 with two simultaneous units. Re-integrating DIP-based dynamic ID assignment into the Prototype 3 firmware is the next development step, with the Firebase database structure already designed to support multiple units under /firefighters/[deviceID]/.

Step 5: PCB Design in KiCad

With all sensors verified working together, we designed the final PCB in KiCad.

The board integrates:

• Heltec WiFi LoRa 32 V3
• 2x MAX31865 RTD interface modules
• BMP388 and MPU9250
• ZE16B CO sensor interface
• Serial MP3 module
• LM7805 (12V to 5V) and LM1117 (5V to 3.3V) voltage regulators
• 12V Li-ion battery input with power distribution
• 2-position DIP switch for firefighter ID assignment

Three PCB revisions were completed before reaching the current design. All fabrication was done by us at the AICTE Idea Lab, SAKEC.

Step 6: Audio Alert System

Pre-recorded voice files are stored on the Serial MP3 module's microSD card. The firmware triggers specific tracks when sensor readings cross defined thresholds:

Alerts use cooldown timers to prevent repetition. Warning alerts play no more than once every 30 seconds. Danger alerts play no more than once every 15 seconds.

The output routes directly to an in-ear earphone — no display, no button press, instant awareness.

// ===== ALERTS =====
  if (tAmbient >= 35 && tAmbient < 50 && now - lastAmbientWarn > 30000) {
    playTrack(2);
    lastAmbientWarn = now;
  }
  else if (tAmbient >= 50 && now - lastAmbientDanger > 15000) {
    playTrack(3);
    lastAmbientDanger = now;
  }

  if (tBody >= 37 && tBody < 39 && now - lastBodyWarn > 30000) {
    playTrack(6);
    lastBodyWarn = now;
  }
  else if (tBody >= 39 && now - lastBodyDanger > 15000) {
    playTrack(7);
    lastBodyDanger = now;
  }

  if (calibrationDone) {
    if (co_ppm >= 30 && co_ppm < 99 && now - lastCOWarn > 30000) {
      playTrack(13);
      lastCOWarn = now;
    }
    else if (co_ppm >= 100 && now - lastCODanger > 15000) {
      playTrack(14);
      lastCODanger = now;
    }
  }

Step 7: Fall Detection & Movement Monitoring

Fall detection and movement monitoring both run on the receiver side, calculated from the raw AX, AY, AZ values transmitted in every LoRa packet.

Fall Detection uses a two-phase model: it first looks for a free-fall signature — magnitude dropping below 3,000 — then watches for a sudden impact spike above 20,000 within 1 second. If both occur in sequence, a fall is confirmed. A 5-second lockout prevents repeated false triggers.

No Movement Detection monitors for collapse separately — if magnitude delta stays below 500 for 8 consecutive seconds, the system flags a potential collapse event.

String detectFall(float mag) {
  if (mag < 3000) lastLow = millis(); // free-fall phase

  if (mag > 20000 &&
     (millis() - lastLow < 1000) &&   // impact within 1s of free-fall
     (millis() - lastFallTime > 5000)) { // 5s lockout
    lastFallTime = millis();
    return "FALL DETECTED";
  }
  return "NORMAL";
}

String detectNoMovement(float mag) {
  float diff = abs(mag - prevMag);
  prevMag = mag;
  if (diff > 500) { lastMovementTime = millis(); return "MOVING"; }
  if (millis() - lastMovementTime > 8000) return "NO MOVEMENT (COLLAPSE)";
  return "STILL";
}

Both statuses are included in every Firebase push and displayed on the Flutter dashboard in real time.

Step 8: Firebase + Flutter Dashboard

The receiver ESP32 forwards all incoming LoRa packets to Firebase Realtime Database. The Flutter web dashboard displays:

• Live CO level with color-coded warning and danger states
• Body and ambient temperature
• Current floor estimate from BMP388 pressure readings
• Motion and fall detection status
• Real-time alert log with timestamps
• Firebase Cloud Messaging push notifications to the operator's device

Flutter dashboard — overview screen

Flutter dashboard — individual firefighter detail screen

Step 9: Enclosure Design

The PCB and 12V battery pack are housed in a chest-mounted enclosure designed to sit inside the firefighter's protective jacket pocket. 

The enclosure features:

• Perforated mesh panel aligned over the ZE16B sensor for air exposure
• Top cable exit for the in-ear earphone and body-contact PT100 probe, routed together toward the collar
• The ambient PT100 probe remains inside the enclosure, sensing temperature through the perforated mesh panel
• Jacket pocket with corresponding mesh alignment for ventilation
• ABS construction rated for elevated temperatures

The enclosure below is a design concept model created in Onshape, representing the proposed chest-mounted housing for the FAiMN PCB. Physical fabrication is planned as the next development step.

FAiMN enclosure modelled in Onshape — two-part shell with ventilation mesh grid, screw bosses, and cable exit for the earphone.

Rendered views of the FAiMN enclosure — closed with the in-ear earphone routed through the cable exit (left), and with the snap-fit lid removed to show the PCB and battery seated inside (right).

FAiMN chest-mounted on a firefighter — designed to sit inside the protective jacket with the earphone routed to the collar.

Dual ear assembly — in-ear audio alert monitor and PT100 body temperature probe, routing to the FAiMN chest unit via a single cable tucked along the collar.

Step 10: Full System Test

End-to-end testing confirmed:

• All sensor readings displaying correctly and simultaneously on the Flutter dashboard
• Audio alerts triggered by simulated threshold breaches (CO exposure via incense, warming the PT100 with a lighter flame, tilting the board for fall detection)
• LoRa range stable across campus
• Firebase sync latency confirmed under 1 second

Results & Achievements

• Patent published — Application No. 202621018251
• 1st place — SAKEC Creathon 2025
• 1st place — TechExpo Pillai HOC 2026
• 2nd place — FCRIT Avishkar 2026 (national level)
• Real-time CO, dual temperature, floor detection, and motion tracking confirmed working simultaneously
• LoRa communication stable across campus-scale range
• Flutter dashboard live with sub-1-second Firebase sync
• Three complete PCB revisions fabricated and tested

Path to Productization

FAiMN is designed from the start with deployment in mind:

• Infrastructure-independent: LoRa requires no cellular network, Wi-Fi, or repeaters inside the building
• Multi-firefighter scalable: Multi-unit ID assignment via DIP switch was validated in Prototype 2 with two simultaneous units; the Firebase database structure under /firefighters/[deviceID]/ is already built to support it
• Low-cost hardware: The full BOM uses commercially available components, around ₹7500
• Field-serviceable: The snap-fit enclosure allows battery replacement and sensor swap without tools
• Patent-protected: Application No. 202621018251 protects the core system architecture

Software Stack

FAiMN firmware and dashboard source code is released under the MIT License. The underlying system architecture is protected under Patent Application No. 202621018251.