2

Building a better scanner

 3 years ago
source link: http://rachelbythebay.com/w/2011/07/29/scanner/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Building a better scanner

People might be wondering what I've been up to since I struck out on my own to try building things which wouldn't automatically become owned by my former employer. Here's a sampling. First, there's this whole writing thing you see here, and the software which generates the pages and Atom feed for it. Then there's my buzzword game experiment, and my go/foo redirector, too. I've also been fiddling with something which does not need Makefiles to handle ordinary C++ build tasks (unreleased at the moment, but contact me if you're interested in it).

Those are the things I've been talking about for a while. But what about those things I couldn't talk about? Okay, here's one.

TL;DR right up front: you can check out the demo, or keep reading here and see what all of this is about.

Many cities use what's called a trunked radio system for police, fire, water, sewer, streets, parks and recreation, traffic, electric, and all sorts of similar civic duties. Trunked refers to the manner in which the radios actually work. Instead of the olden days when each group of people might have their own frequency, in a trunked system they are pooled and shared intelligently.

Many cities have a scheme where each radio is a member of one or more "talkgroups", and it will only open the squelch and let sound through if there's traffic for one of the groups it cares about. This way, you don't have to listen to fire calls if you're a police officer, or vice-versa.

Now, since there are just a handful of frequencies and a bunch of users, there has to be some way to coordinate this. These systems usually have at least one channel which is nothing but a data stream that says "hey, all of you on talkgroup X, tune to channel Y right now", and they do it. As long as the number of calls is at or below the number of available voice channels, it works out just fine.

So now imagine that you want to know what's going in your city. Maybe you follow Twitter feeds for your area, but you still don't get to find out what's going on when helicopters start circling your house and police cars go screaming by at 70 mph, code 3, lights and sirens. For that, you need a "police scanner", as many call it. Now, you can't just grab one that's been on the shelf since the '90s, since odds are it won't understand trunking. Nope, you need another one for that.

Even if you have a trunking scanner, you're still limited to listening to just one call at a time. If both the police and fire units are working different parts of the same event, you want to hear both, right? A traditional scanner approach forces you to miss out on the overlapping calls. If you go really out-there and buy a second or third scanner to run in parallel, well, I hope you're really good at focusing on multiple conversations at the same time!

There has to be a better way. Well, now there is. By using some crazy custom hardware and software hacks, I've set up a system which tracks calls and records them in parallel. Then it renders them as a nice web page where you can flip through the calls and play back the ones which interest you.

Also, you don't have to be listening right when interesting things happen. You can make a note of the time and go back to the records to see what was going on. How cool is that?

See the demo.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK