u/yo3gnd

Ever ended up with a POCSAG pager that has only a partial RIC on the sticker and, if you are lucky, a vague rumour about where it might be tuned? I had one of those charming little problems and did not particularly fancy building yet another programming interface just to ask the thing what it already knows. So I wrote pocsag-probe.

It throws messages through a HackRF or rpitx, sweeps frequencies, walks RIC ranges, reads candidate RICs from a file, and expands partial patterns like 0118 or 3xx21x into valid POCSAG addresses. The point is not elegance. The point is to automate the dull detective work until the pager finally admits what it is listening for. It's not really a prober, it's a bruteforcer. It works. Eventually.

The folks working on open-hamclock-backend/OHB have rebuilt a backend that speaks the HamClock protocol, which is very good news for keeping older installs useful after the original CSI service goes away.

For Linux/Raspberry Pi-style builds, switching backend is relatively painless because the client can be started with a different backend host. For ESP8266 units, I do not think we get that luxury: depending on the exact build, this likely means DNS/hosts-file trickery somewhere on the network, or rebuilding/flashing a client that points at the new backend. I can do that work, publish a build, and possibly keep it maintained if there is actually an audience for it.

What I am trying to figure out is how many people would benefit from an upgrade path beyond the old ESP8266 3.10 line. The initial goal would be deliberately boring: not a rewrite, not a new product, not “HamClock but better”; just a functional build that lets existing devices keep working past June 2026.

Pics of working setups would be lovely.