WhistleSense

Navigate this project

• 1. Project Overview
• 2. Problem Statement
• 3. V0 Prototype
• 4. System Architecture
• 5. Sensor Stack
• 6. Whistle Detection Logic
• 7. Data Logging & Testing
• 8. Accelerometer & Sensor Fusion
• 9. Technical Lessons Learned
• 10. Project Outcome

Problem Statement

In many Indian kitchens, pressure cooker cooking is still tracked manually by counting whistles. This sounds simple, but it becomes inconvenient when the user steps away, gets distracted, or is managing multiple tasks at once.

The project explored whether a small alert-only device could reduce this mental load by detecting whistles and notifying the user once a target count is reached. The key product question was whether people would value an alert-only product, or whether they would only find the concept compelling if it could also turn off the stove automatically.

WhistleSense V0 Prototype

WhistleSense V0 was designed as a temporary sensor band or clip attached to a pressure cooker handle. The goal of this prototype was not to build a polished final consumer product, but to collect real cooking-session data and understand whether whistles could be detected accurately.

The V0 prototype did not need internet connectivity or mobile notifications. Its main purpose was data capture: measuring sensor signals, saving timestamped readings, and allowing manual whistle marking so the algorithm could be compared against human-labelled ground truth.

V0 prototype setup used to capture pressure cooker audio, vibration, temperature, and manual whistle markers.

System Architecture

The WhistleSense architecture was built around an ESP32 microcontroller collecting multiple sensor streams and sending structured readings to a laptop over serial for logging and analysis. The design was kept intentionally simple so that early testing could focus on signal quality and detection feasibility.

System architecture showing sensor capture, ESP32 processing, serial CSV logging, and offline analysis.

Sensor Stack

The first sensor stack was selected to test whether whistle detection could be made more reliable by combining sound, vibration, and heat context. The microphone provided the primary signal, while accelerometer and temperature readings were included to support future sensor fusion and reduce false positives.

Whistle Detection Logic

The detection logic evolved through multiple iterations. The first version relied on RMS sound energy crossing a threshold for a minimum duration. This worked for controlled audio clips, but was not reliable enough for real kitchens because human speech and kitchen noise can also produce high RMS values.

The algorithm then moved toward frequency-band analysis. A real cooker whistle was treated not only as a loud sound, but as a signal with energy concentrated in whistle-like frequency bands. This helped distinguish actual whistle events from random loud noises.

CSV analysis showing how RMS and whistle-like frequency ratios change during confirmed pressure cooker whistles.

In one of the later test runs, the updated algorithm detected four whistles while the manual button also marked four real whistles. The delay between the manual marker and algorithm detection was consistently around 760 ms, which was acceptable for an alert-focused prototype.

Data Logging and Testing

Data logging was the most important feature of the V0 prototype. Instead of trying to perfect the product immediately, the project focused on collecting real signals from real cooking sessions and using those logs to decide whether the idea was technically promising.

Testing included human speech, kitchen background noise, pressure cooker audio played from a phone, and real pressure cooker whistle audio. Real cooker data became the main source of truth because phone audio did not match the strength and behaviour of an actual cooker whistle closely enough.

Accelerometer and Sensor Fusion

The PDF notes mainly describe the microphone-focused development path, but the accelerometer was an important part of the intended prototype direction. The purpose of adding an MPU6050 accelerometer/gyro was to measure vibration bursts travelling through the cooker handle during whistle events.

The reason this matters is that sound alone can be fooled by speech, TV, utensils, mixers, or background noise. A real pressure cooker whistle should create a combination of signals: strong whistle-like audio, vibration activity on the cooker, and a temperature profile indicating that cooking is actually happening.

Accelerometer testing would help verify whether real whistle events create measurable vibration bursts at the cooker handle.

This sensor fusion direction is also what makes the project more interesting from an engineering perspective. It shows that the system was not treated as a simple sound trigger, but as a small embedded sensing problem where multiple noisy real-world signals need to be combined.

Technical Lessons Learned

The project produced several useful technical lessons about embedded sensing, audio detection, and real-world data collection. These lessons are the strongest part of the project from a portfolio perspective.

Offline analysis helped compare raw sensor readings, detected events, and manually labelled whistle moments.

Project Outcome

WhistleSense is being positioned as a completed independent hobby project and prototype exploration rather than an active commercial product. The technical prototype showed promising signs, especially in microphone-based whistle detection using RMS, duration, and frequency-ratio filtering.

However, turning this into a profitable consumer product would require extensive industrial design, safety validation, market testing, manufacturing, app development, support infrastructure, and differentiation against established appliance and kitchen technology brands. Based on that commercial reality, the project is best presented as a strong technical learning project rather than a startup attempt.