Pocket scanner that only speaks in beeps

Oct 12, 2026 Last reply: 3 hours ago 3 Replies
Jump to replies (3)

The most surprising thing here is that the whole unit reports with sound alone. No screen, no phone needed, and it works face-down or buried in a pocket. A passive buzzer and a WS2812 bar are the only outputs, and somehow that is enough to find hidden gear.



The core is a XIAO ESP32-C5 with a dual-band U.FL antenna, sweeping 2.4 and 5 GHz at once while BLE scanning runs in parallel. The maker reports each category with its own pattern: a rising trill for drones, fast ticking for trackers, two long beeps for cameras. Locking onto a device switches to hunt mode, where beeps speed up as you close in. In the demo the signal climbed from roughly -80 dBm to -16 dBm until a wall-mounted device was located, which turned out to be LED string bulbs on the maker's front porch. Detection signatures live in an editable list of OUI, company ID, name, UUID and SSID, editable from the app without recompiling, and the firmware is GPL-3.0 with a browser flasher that tells a C5 from an S3.



I like that it only receives and cannot jam, deauth, inject or spoof, and that its own BLE advertising can be turned off so it stays quiet around other scanners. Settings also survive a pulled power cable, which makes sense for battery use.



The honest weak spot is the signature list itself. The maker says missed gear is the main risk and asks for pull requests when something goes undetected. There is also the S3 variant at 2.4 GHz only, where a heap leak from continuous NimBLE scans had to be fixed by setting maxResults to zero.


Disabling its own BLE advertising seems like the smartest single choice in the build. A scanner that broadcasts its presence would defeat its own purpose around anyone else running similar gear. It pairs well with the receive-only stance: the maker clearly wanted a tool that observes without leaving a trace, and that trade-off shapes the whole design.

How does the maker handle the C5 promiscuous callback delivering failed frames? I gather they must be dropped to avoid phantom transmitters, but I am curious whether that filtering happens in the callback itself or later in the pipeline. Also, does the near-100 percent BLE scan window that starved Wi-Fi of frames get balanced dynamically or with fixed timing?

The optional microSD and DS3231 additions look worth fitting. With pcap exports already flowing from the SD card over serial into Wireshark, timestamped captures would make it much easier to review what the scanner heard after the fact instead of relying on memory. On a tighter budget, the maker notes the same functions run on an S3 at 2.4 GHz only, which could be a good entry point.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required