I built a better mousetrap for listening to the radio

I built a better mousetrap for listening to the radio

I built a better mousetrap, but so far, nobody really cares. There's a lesson here about product development, I'm sure.

There are places where you can go to hear police and fire radio traffic online. They basically consist of a MP3 stream where someone has plugged a scanning radio into a computer and is pushing out audio. When it's idle, you hear the background fuzz. When it's running, you hear whatever the scanner is hearing and sometimes you get a bit of text which describes the channel it stopped on.

Let's think about this here. If you have a scanner and it's actually scanning, it's going to round-robin between a bunch of frequencies and will stop on the first one which "opens the squelch" -- where people are talking. Anything else which happens at the same time on another channel disappears forever.

When they stop talking and the squelch closes, a scanner will resume scanning after a short delay. It will then land on the next thing which happens to be active. If it was already a conversation in progress, you will miss whatever was going on before that point. Again, it's just gone.

One way to "handle" this would be to have multiple streams. Put the fire department on one stream and the police on another and just turn them both on at the same time. I hope you have really good "cocktail party" ears and can follow two conversations at once, since you'll need it to keep track of things.

As you can see, it's a usability disaster. I decided to come at this problem from a totally different angle.

Instead of just pushing out a dumb stream of raw audio, I actually treat transmissions as individual calls. When they stop talking, I stop recording. That means there is no idle time in the timeline. If you listen to my recordings after the fact, you can just fly through them! This is a great way to save time.

I don't just stop there, though. I do all of this radio decoding in software, so I can do some neat things like recording in parallel. If the fire and police departments are talking at the same time, it's no big deal. I just record both of them as separate calls. It all works out in the end, since those are just two more entries on the timeline.

Here's a real example from this afternoon when three different groups of people were talking at the same time. Notice the constant overlap based on the start and stop times.

That's what it looks like on the real thing. Calls play from top to bottom and they play all the way through unless you skip them. If you miss something, just replay it. You just can't do this with other techniques.

There's no way you could have heard all of that on a normal scanner or an ordinary stream. You would have gotten all of call 324848 from 14:17:58 to 14:18:16, while totally missing 324849 -- gone forever.

It would have then jumped to 324850, giving you the last little bit from 14:18:16 to 14:18:19. You just got three seconds of an eight second call. Hope it wasn't anything important!

Next, you'd land on 324851 at 14:18:19 until it ended at 14:18:21. Then you'd hear nothing but fuzz for three seconds until 324853 started at 14:18:21. You'd listen to that until it ended at 14:18:24.

You see how it works. You just keep hopping around, and the only time you get a full call is when you suffer through the background hiss of a radio that's waiting to find a channel. Then you miss anything else which was going on at the same time.

I'm spoiled by this. I never want to go back.