I'm Ray — based in Joplin, MO. Repairman. Builder. Nerd.
I do apartment maintenance for a living, which mostly means the same things breaking in the same ways. Problem-solving is what I'm actually good at, and building is what I love. I have component-level electronics experience from back when people still got things repaired. Nobody does that anymore, but it turns out that background is a pretty good foundation for what's happening right now: ESP32s, Arduinos, Raspberry Pis, a flood of cheap sensors, and AI tools that mean I can build things I never could have written code for on my own. It's an embarrassment of riches and I'm spending every spare hour taking advantage of it.
I get why people are scared of AI. We don’t have a good track record lately of using technological improvements for the good of the many. But like it or not, the technology is here. The real question is what are we going to do with it? We as a society have a chance to shape things in a positive, as well as profitable direction for all.
My own experience has been astonishing: these tools let me build things I never could have built alone, and I work harder for it, not less. Nobody lost a job so I could do this — something new just got made that didn't exist before. Make the right choices as a society, and everyone gets to share in that kind of improvement without absorbing the downsides.
In long apartment hallways, one chirp sounds exactly like another no matter where you're standing. Without a system, finding the dead battery means walking 200 feet of corridor and pressing your ear to every unit door — sometimes multiple passes, sometimes needing the tenant home. A 30-minute service call for a $3 battery.
A coordinator ESP32 broadcasts a radio timing pulse via ESP-NOW every second. Two sensor nodes — mounted at opposite ends of the hallway — each run an INMP441 digital microphone. When a chirp arrives, each node records the exact microsecond offset from the nearest coordinator pulse. The coordinator compares those two timestamps: the time difference, combined with the known node spacing, resolves which unit the chirp came from — logged live with unit position, timestamp, and confidence to a dashboard the technician can check from anywhere. No walking required.
The two nodes measure their own separation acoustically instead of requiring a tape measure at install time: the coordinator fires a buzzer pulse from one node, times how long its partner takes to hear it, then reverses the shot. The round-trip pair resolves both distance and clock offset. A boot-time and periodic (6-hour) auto-recalibration keeps the system accurate even if a node gets bumped or repositioned, with an outlier-rejecting median-of-several-shots average smoothing out single-measurement noise. Turns out to matter less than it first seemed, though — once nodes are permanently mounted, spacing is just measured by hand at install time. A later test also found the two nodes don't reliably hear each other's own onboard buzzer at all, even though it's audibly loud in person; since self-ranging isn't load-bearing for a real install, that's now a low-priority diagnostic curiosity, not something blocking progress. The buzzer exists for this self-test and nothing else — it plays no role in actual chirp detection.
Each node runs the Goertzel algorithm — an efficient single-frequency detector — locked onto the measured chirp tone (~3,327 Hz) and a second "confuser" tone shared by common false alarms like microwaves. An adaptive noise floor (an exponential moving average that only updates while nothing is triggered) tracks the room's own background level instead of relying on one fixed number. Empirical tuning against a live HVAC-noise session found a clean separation — ambient noise topped out around 9–10x that floor, real chirps scored 15–68x — landing the detection threshold at 12x with zero false positives across a 90-minute confirmation run.
Rather than hand-writing a new rule every time a new confuser sound turns up, every trigger's underlying audio is independently re-analyzed against the chirp's actual full spectral fingerprint — frequency, duration, and spectral purity — pulled straight from the recorded audio stream, not just the live narrowband check. A same-instant hit on the confuser channel — the signature of a cough or a slammed door, not a pure tone — is rejected outright. Every result feeds a growing, automatically-labeled corpus of confirmed chirps versus confirmed noise that the system uses to retune its own thresholds instead of requiring another manual bench session.
When one node picks up a candidate chirp, it immediately broadcasts a prime signal to its partner via ESP-NOW. That node drops into high-sensitivity mode — tightened filter, lower detection threshold — ready for the next event. Low-battery chirps repeat on a fixed interval (typically every 30–60 seconds) and never stop, so the system learns exactly when to expect the next one, and confidence compounds with every confirmed pass.
Each node already has power, ESP-NOW connectivity, and a microphone doing double duty as an ambient-noise sensor. Motion (a $1–2 PIR add-on), temperature/humidity (a few-dollar I2C sensor), and ambient noise-level trending (the data's already flowing, it just isn't logged yet) are all telemetry the existing hardware could carry for next to nothing — worth designing in before the next hardware revision, even if chirp detection stays the primary job.
Deployed at real hallway distance (10–14 m node spacing, self-measured via the ranging system above) with 81 confirmed alarms fired live during testing and development. An initial bench test (37 chirp events, controlled conditions) measured ±2.5 ft positioning accuracy; ongoing field work is refining that further, including a from-scratch waveform cross-correlation mode (in development) that resolves timing directly from the recorded chirp shape instead of a simple threshold crossing. The noise-rejection corpus is already earning its keep — 1,500+ auto-labeled triggers in, it's shown that quiet-room calibration doesn't fully hold in a live, noisy hallway: real chirps are measuring lower spectral purity and longer duration under HVAC noise than the original bench numbers, which is exactly the kind of drift the corpus exists to catch and correct. Development paused 2026-07-16 to focus elsewhere; picking back up now means re-verifying the physical boards before trusting any of the above as current state — last known, both nodes were intentionally running a stripped diagnostic firmware build rather than production.
The pipeline described above — networking, detection, pairing, ranging, OTA — works end-to-end on the bench. A second track, chirp_detect_lab, is a from-scratch offline rebuild of just the detection algorithm, started after the production firmware's tuning constants were found drifting undocumented across commits, with no clean way to test whether the algorithm itself actually recognizes a chirp in isolation. It scored four candidate detectors against a real recorded corpus and found recall low across all four (19–31%) — the working theory is corpus quality (no real physical detector recording yet, only speaker playback standing in for one), not a broken algorithm, but that's still unconfirmed.
The full re-entry checklist and open-issue tracking for picking this back up live on the resume board rather than here.
rtl_433 for ISM-band devices, multimon-ng for pagers, rtl_adsb for aircraft transponders, redsea for FM RDS station call letters and genre. Pager hits are logged as "a transmission occurred" only — the real decoded message, third-party content picked up passively off the air, never leaves the acquisition side. Where a decoder resolves real content, the dashboard now shows it directly: rtl_433 temperature, humidity and soil-moisture readings, and TPMS tire pressure — deliberately pressure only, never the per-tire ID a passing car's own sensor broadcasts, since unlike Ray's own stationary sensors that's a persistent identifier for someone else's vehicle. rtl_adsb gained a from-scratch Mode S decoder (callsign, altitude, speed, heading, vertical rate) with real CRC-24 validation — the raw demodulator does no error-checking of its own and will happily emit noise shaped like a valid frame — plus a dedicated periodic listen at 1090 MHz, independent of the anomaly detector, which structurally can't catch a transponder burst that short — after zero genuine catches in over three weeks on the old sweep-triggered path, the very first listen under the new one caught a real aircraft. Because pure baseline deviation can never notice something that's been broadcasting the whole time, a one-time startup census and a daily recheck separately catalog everything continuously on-air, flag anything that's since gone quiet, and flag anything unusual enough to be worth a second look — right now that includes a strong signal sitting inside the protected radio-astronomy band. Identification runs on a separate server, not the field Pi — real decoder evidence first, then a lookup against 11M+ FCC license records for this region, then a static band-allocation table, then previously-identified signal fingerprints — falling through to a capped, text-only Claude guess only when nothing else resolves it. That server is the only thing with API keys or internet access of its own; the acquisition Pi can only ever push captures to it over one restricted upload channel, nothing more. A frequency×day activity heatmap tracks what this specific antenna and placement actually pick up, building up on its own as the sweep keeps running, and the dashboard's cluster list filters by content type — radio, aircraft, TPMS, sensors, licensed, or still-unidentified — with search and sort, instead of one long scroll..env/.git credential hunts, router-botnet RCE checks, none of it targeted, all of it automated. This server was already classifying each request's source IP as residential vs. datacenter for its own logs; this panel makes that visible, names the ~30 specific exploit/scanner signatures being thrown at it, and tracks who's hosting the traffic — instead of letting it rot in a log file that rotates out after a few days.// known constraints
Samsung controls the token lifecycle, and it's gotten stricter: personal access tokens issued after December 2024 now expire in 24 hours, so anything meant to run unattended needs a full OAuth2.0 flow instead of a PAT. Starting October 2026, Samsung is also ending free API access — non-commercial developers get a grace period through Q3, then a $4.99/month "Personal Plan" becomes the price of admission, a change big enough that even Home Assistant is scrambling to figure out how it affects their SmartThings integration. On top of that, there's still no true polling model: sensor data lives behind Samsung's cloud, so you're dependent on their infrastructure and now their billing. A SmartThings outage — or an unpaid invoice — is silently also your monitoring outage. You're always a guest in their ecosystem, and soon a paying one.
Got a project, a question, or something broken that needs a second opinion? Send a packet my way.