Beacon

Laser turret
Server racks

Inspiration

Data centers watch pretty much everything over the network, but only the stuff that's actually hooked up to monitoring. If a UPS or PDU never got connected, the only way it can tell anyone something's wrong is by beeping. And in a loud room full of identical racks, you can hear the beep but you can't tell where it's coming from. There are real threads online of sysadmins trying to track down a mystery beep in their server room.

We looked for something that already solves this and couldn't really find anything. The usual answer is "just connect it to monitoring," which is exactly what didn't happen for the units that end up beeping. The closest things we found were a couple of patents where servers play a special sound on purpose, or every rack gets its own sensor. We wanted to use the beep that's already there, with fewer mics than racks.

What it does

Beacon listens to a row of five server racks with three cheap microphones. When an alarm goes off, a machine learning model figures out which rack it's coming from, a laser on a servo swings over to point at that rack, and the technician's phone gets an alert saying "Server Rack B might have an issue. Check it out." Hitting Mark as Checked turns the laser off and logs who checked it and how long it took.

How we built it

The hardware side is pretty simple. A Raspberry Pi Pico 2 WH samples all three mics 16,000 times a second. For every 16 ms chunk of sound it runs a Goertzel filter (basically a cheap way to measure one frequency) to see how strong the 2.5 kHz alarm tone is at each mic, and it also checks 2 kHz and 3 kHz so it can tell a clean beep apart from general noise. That's about 55 readings a second per mic, sent to a laptop over USB. The laptop keeps track of how loud the room normally is and picks out individual beeps from there.

Most of our time went into the data. Our "server racks" are five cardboard boxes, 10 cm wide, lined up in a row. The mics sit in front of racks A, C and E, so B and D don't have a mic at all, and that's the whole challenge. To record, we put a phone inside one box at a time playing a UPS-style alarm (four quick 2.5 kHz beeps, then a pause). Meanwhile, 15 minutes of fake chatter we made with the Mac's text-to-speech voices played in the background, because a real data hall isn't quiet. Our recording script labeled every beep, skipped ones that were too faint, and told us to move the phone to a different spot in the box every four beeps so the model couldn't just memorize one position. We also recorded the chatter by itself and labeled it "no beep." At one point we recorded a batch with the phone in the wrong box, so we tossed it and redid it.

After two full recording sessions we had 437 usable clips: 375 beeps and 62 no-beep clips.

Each beep gets turned into 19 numbers: how loud it was at each mic, each mic's share of the total, the loudness ratios between pairs of mics, the peak level, how far above the room noise it was, how clean the tone was, and how long it lasted. No single mic can tell you the rack. The model has to figure it out from how the sound splits across all three.

The part we're proudest of is how we tested it. We trained on session 1 and tested on session 2, which the model never heard. Randomly splitting one recording would have given us a nicer number, since beeps from the same take sound almost identical, but it wouldn't tell us whether this works on a different day. Here's how everything did on session 2:

Random guessing: 20%
Just picking the loudest mic: 57.5%
Weighted average of mic loudness: 55%
k-nearest neighbors on the mic ratios: 58%
Random forest, one beep: 64.5%
Random forest, voting over 4 beeps: 70%

Picking the loudest mic is what you'd build without ML, and it literally can't say B or D because there's no mic there. Our random forest (300 trees) gets B right 72.5% of the time and D 47.5% of the time from a single beep, just from how the sound splits between the three mics. Before it moves the laser, Beacon averages its confidence over 4 beeps. The model we actually run is retrained on both sessions, but every number above is from the session it never saw.

The laser sits on an SG90 servo and gets switched through a transistor. Cheap servos have some slop in their gears, so every move ends with a slow approach from the same side, which makes the laser land in the same spot every time. The phone page updates live, and we tuned its alert chime way away from 2.5 kHz so our own mics don't mistake the phone for an alarm.

Challenges we ran into

B and D have no mic, so telling them apart from their neighbors was the main problem. It's also why "loudest mic wins" tops out at 57.5%.
Neighboring racks sound almost the same. The boxes are only 10 cm apart, and most of the model's mistakes are the rack right next door.
Early on, the recorder kept counting random bits of chatter as beeps. We added a minimum signal-to-noise cutoff and used the same one for both recording and training.
Two of our mics were reading almost the same level for a while. A tap test showed the wiring was fine. They were just in a bad spot.
None of us had done hardware before this weekend. One of us had to ask what a servo even was. Getting the Pico to show up on a laptop took a while because we didn't have a data cable at first, and with no breadboard or multimeter, we ended up powering the mics straight off the Pico's GPIO pins.

Accomplishments that we're proud of

70% with four-beep voting on a recording session the model never heard. Random guessing gets 20%, and the loudest-mic approach gets 57.5%.
The right rack is in its top two 88% of the time, and 95% of single-beep guesses are either right or one rack off.
It finds the racks that don't have a mic, which the simple approach can't do at all.
It actually works end to end. Beep in a box, laser on the rack, alert on your phone, all in a few seconds.
We went from zero hardware experience to a working laser turret in one weekend.

What we learned

Mostly that the data is the hard part. How you split it matters as much as which model you pick, and testing on a separate session gave us a lower number, but one we actually trust. Having a dumb baseline mattered a lot too, because without it 70% doesn't really mean anything. On the hardware side we learned basically everything from scratch: reading a mic, running a filter on a microcontroller, moving a servo smoothly, and switching a laser with a transistor.

What's next for Beacon

Use timing, not just loudness. Comparing when the beep reaches each mic should separate neighboring racks a lot better.
Record real UPS units in an actual data hall and retrain on that.
Decode the beep pattern. UPS beeps are codes ("on battery" sounds different from "overload"), so Beacon could tell you what's wrong too.
Make it listen all the time instead of on demand, and scale it to full rows with a cheap mic node every few racks.