Detection ESP32 is a coming-soon Fix I.T. Phill hardware project for documenting sustained environmental noise without recording conversations. The original inspiration was an older bark-detection collar experiment, but this version is being designed for factories, datacenters, AI centers, crypto mining operations, and similar sites where neighbors or property owners need honest, repeatable sound-level records.
The public code is not being released yet. This page is the public specification, privacy position, evidence posture, and hardware roadmap. The short URL for the project is fixitphill.com/detection-esp32.
Project status
- Status: hardware design and beta firmware planning.
- Public firmware: coming soon.
- Public API/verifier: coming soon.
- Target platform: ESP32-S3 with an I2S MEMS microphone and GPS/GNSS module.
- Goal: log sustained sound-level events, location, time, calibration ID, and tamper-evident record data.
- Privacy goal: no raw audio by default and no public exact GPS by default.
What this node is for
The node is meant to measure a sustained environmental condition: fan walls, compressors, chillers, transformers, mining rigs, generator noise, or other continuous industrial sound. It is not meant to identify people, words, conversations, or private activity.
For serious use, the device should produce a record that can be explained from sensor to server: the hardware used, the calibration profile, the timestamp source, the location accuracy, the firmware version, the device identity, and the record integrity checks.
What the node should record
- Average sound level for the event window.
- Peak sound level for the event window.
- Duration of the event.
- Sound-level stability across the window.
- Dominant frequency or stable broadband profile summary.
- UTC timestamp and time-source status.
- GPS/GNSS coordinates and accuracy.
- Public/private location privacy flag.
- Calibration profile ID.
- Device ID and public key ID.
- Firmware version and firmware hash.
- Previous record hash and current record hash.
- Device signature when production signing is enabled.
What the node should not record
- No raw audio by default.
- No speech transcription.
- No speaker identification.
- No automatic enforcement action.
- No public exact GPS unless the owner explicitly chooses that exposure.
- No secret API keys or device private keys in public code.
Open source plan
The right split is open measurement logic with closed secrets. The firmware, data schema, verifier, and calibration workflow can be open source so people can inspect how records are produced. Device private keys, server credentials, owner records, exact GPS access, and production signing infrastructure should stay private.
That gives the project a stronger trust posture than a black-box sensor. Reviewers can inspect the process while attackers cannot copy a production node identity.
Evidence posture in plain English
This should be described as tamper-evident noise documentation, not as automatic legal proof. Courts and regulators care about authentication, calibration, chain of custody, and whether the measurement process can be explained. Federal Rule of Evidence 901 includes authentication by describing a process or system and showing that it produces an accurate result. NIST SP 800-86 describes collection, examination, analysis, and reporting as a forensic process and advises readers to involve legal counsel for their situation.
For sound levels, we also need to be honest about certification. An ESP32 and MEMS microphone can produce useful records, but that does not automatically make the finished device an IEC 61672 class 1 or class 2 sound level meter. The practical path is to calibrate each node against known equipment, document the installation, preserve the original signed records, and avoid overstating the limits of the device.
Recommended beta hardware
- ESP32-S3 board with PSRAM.
- I2S MEMS microphone such as INMP441, ICS-43434, or a similar digital microphone.
- GPS/GNSS module with a clean antenna path.
- RTC module or reliable network time fallback.
- Optional ATECC608A secure element for device signing.
- Weather-resistant enclosure with a windscreen and controlled acoustic opening.
- Tamper label, stable mount, and installation photo checklist.
- Wi-Fi for early beta; LTE or Ethernet for stronger production deployments.
Detection approach
The device should be violation-first, with just enough baseline sampling to prove the system is alive and to show normal compliant periods. It should not waste battery, storage, or reporting attention by proving that every quiet minute was quiet.
The detector should not try to recognize speech. Instead, it should reject speech-like and transient events by looking for sustained machine-like noise. The first beta target is a rolling event window with all of these requirements:
- Sound level above calibrated ambient baseline plus a configured offset.
- A minimum absolute threshold so quiet sites do not create false reports.
- Continuous duration, likely 30 to 60 seconds.
- Low sound-level variance during the event.
- Stable dominant frequency or stable broadband profile.
- Local queueing if the node cannot upload immediately.
- Record hash chaining so later edits are detectable.
Two sampling lanes
The planned firmware should use two sampling lanes: a low-frequency baseline lane and a higher-priority violation lane.
Baseline lane: collect a short ambient sample every 30 to 60 minutes, save a tiny compliant summary when the sample is below the active threshold, and otherwise leave storage for events that matter.
Violation lane: sample more often, reject contaminated windows, and log detailed records when ambient-only noise stays above the local threshold. A confirmed violation should require multiple accepted above-threshold windows close together, such as three accepted windows inside 15 minutes.
Adaptive sampling modes
- Normal mode: sample about once every 10 to 15 minutes.
- Watch mode: if levels approach the active threshold, sample about once every 5 minutes.
- Violation mode: if accepted ambient-only samples exceed the threshold, sample every 1 to 2 minutes for a defined follow-up period.
- Recovery mode: after levels drop, keep sampling more often for a short period, then return to normal mode.
This makes the node efficient during quiet periods and much more aggressive when a facility starts producing sustained noise.
Threshold handling
Thresholds should be configurable per city, property, case, and time window. A common starting shape is separate daytime and nighttime limits, with the active threshold selected from local ordinance rules. The node should record which threshold was active for each event so the server can explain why the sample was accepted or rejected.
Useful threshold fields include day start time, day end time, day dBA limit, night dBA limit, minimum violation duration, number of accepted windows needed for confirmation, baseline save interval, normal sample interval, and violation sample interval.
Violation record fields
For an above-threshold ambient-only sample, the detailed record should include the device ID, timestamp, location ID, duration, active ordinance threshold, average dBA, over-limit dBA, minimum dBA, maximum dBA, peak dBA, stability score, speech rejection score, transient rejection score, dominant profile summary, accepted-ambient-only status, raw-audio-stored flag, previous record hash, current record hash, and device signature.
The raw-audio-stored flag should normally be false. The point is to preserve sound-level and frequency metadata, not conversations.
Server-side incident grouping
The server should group accepted violation samples into incidents. A confirmed incident can include the start time, end time, active threshold, average sound level, maximum sound level, maximum peak level, number of accepted samples, number of rejected contaminated samples, and status such as above-night-limit or above-day-limit.
A good report should show compliant samples and rejected samples too. For example, it should be able to say that a node collected a certain number of valid nighttime ambient-only samples, how many were compliant, how many exceeded the configured threshold, and how long the longest sustained above-threshold period lasted.
Dashboard priorities
- Violations today.
- Longest sustained violation.
- Worst hour.
- Average over-limit dBA.
- Night violations.
- Rejected contaminated samples.
- Compliant baseline samples.
- Battery and device health.
Location and privacy
Exact coordinates are useful for private evidence review, but they should not be public by default. A public map should round the location or show a broader area. The private evidence record can keep exact GPS, accuracy, timestamp, and owner-approved metadata under access control.
Mobile app relay plan
The mobile app may become useful for setup, nearby status checks, and delayed upload. It should not become the trusted measurement source. If a phone relays records, the node should sign and encrypt the record first, and the phone should only carry it to the server. The server should reject records that fail integrity checks.
Calibration checklist
- Record the device ID, firmware version, firmware hash, and public key ID.
- Compare the node with a known meter or acoustic calibrator.
- Record the reference device model, serial, calibration date, settings, and test environment.
- Test more than one level when possible.
- Store the calibration ID in firmware or configuration.
- Photograph the mounting location and record height, direction, and nearby reflective surfaces.
- Repeat calibration after microphone replacement, enclosure changes, firmware changes, or suspected tampering.
Privacy checklist
- Do not store raw audio by default.
- Do not publish exact GPS by default.
- Use rounded public coordinates unless the owner gives written approval.
- Keep owner identity and device registry private.
- Document retention and deletion rules.
- Separate public dashboards from private evidence records.
Production hardening path
- Move signing into ATECC608A or a protected ESP32 key path.
- Use secure boot, flash encryption, NVS encryption, and signed OTA updates.
- Add append-only server storage and offsite backups.
- Add a device registry with public key rotation.
- Add calibration import/export with signed calibration profiles.
- Build a field report that includes installation photos, event records, hash-chain verification, and calibration notes.
Coming soon
The public release should include the ESP-IDF firmware skeleton, JSON event schema, local verifier, API receiver, calibration worksheet, hardware build notes, and field-install checklist. For now, this page is the public specification and the permanent shortlink for the device project.
Bottom line
The goal is simple: document sustained noise in a way that is useful, privacy-aware, and explainable. The hard parts are calibration, chain of custody, tamper-evident records, and location privacy. Those pieces matter more than rushing code into public before the first hardware build is ready.