Project 25 phase 2 (TDMA) decoding in software works
Over a year ago, I started worrying about what would become of my software-based scanner site after the county built their new radio system. Whereas my existing work from 2011 worked on a Motorola Smartnet system with regular analog FM audio channels, this new system would be P25 with TDMA channels ("phase II") -- two talk paths per frequency.
We've all known this was coming, and so back in June 2013 I put out an offer to supply a raw recording of a new-style system to anyone who wanted to hack on it. I didn't get many queries, but fortunately out of the few people I did manage to reach, I found the right ones: the folks behind the OP25 project.
Yep, that's right, they managed to do it. There is TDMA decoding support in the OP25 tree as of earlier this year. You have to glue together the pieces yourself, but that's relatively easy. The hard work of figuring out all of the TIA-102 standards documents and turning it into code has been done already.
In terms of practical applications, this means it's possible to take a wideband stream of a whole trunked system, filter out the control channel, and send it through OP25 to get P25 messages out. You still have to figure out what all of those opcodes and bitfields mean, but that's a largely solved problem. Tools like UniTrunker have been doing this for years. Plus, the TIA-102 documents explain all of it if you can afford to get a copy... or just find it online at some sketchy PDF viewer site overseas.
With the control channel messages decoded, it becomes possible to look for "voice grant" and "voice grant update" messages which tell you who's talking (the radio ID), where they are talking (channel number) and who they are talking to (talkgroup). It's around this time you realize that the channel number itself does not directly tell you where to tune your receiver. For that, you have to capture a few other messages which tell you how the system lays out its bands.
Once you know that band 1 is from X to Y MHz and is using 2 slot TDMA with channels that are Z kHz wide, then when you see a call arrive for "band 1 chan 1234", you can do the math and arrive at some actual usable frequency. It'll also tell you what slot number you should be decoding from the data stream.
This is the point anyone could have gotten to before with the previously-available tools: knowing a TDMA transmission was happening, and even knowing exactly where it was, but the actual voice was unattainable. OP25 developments of the past year have changed that. It's now possible to set up a receiver on that channel (as determined above) and do the whole demod/slicing/framing pipeline into their new phase II handler, and it will yield 8 kHz audio, ready for storage in a WAV file or whatever else you might like.
I can say this with some certainty since as of last weekend, this now exists. There is a prototype system running here which will decode control channel messages and kick off TDMA listeners to grab audio. When the call is done, I wind up with a nice MP3 file.
Want proof? Okay, here's a call recorded on Saturday night using a $20 RTLSDR stick, a Mac mini running GNU Radio, OP25, and my own software:
As with the existing system, parallel calls are no problem, even if they are two timeslots from the same channel. It's currently handling this rather inefficiently by duplicating the tuning paths, but optimization is not worth the trouble at this point. Eventually it will get smarter.
If OP25 had this support months ago, why did this not happen for me until Saturday? That's easy. It took a "real event" on this new radio system to generate enough traffic to make it worth working on this problem. Before that point, it was thousands (not an exaggeration) of test calls over and over from different radio techs calling each other from different parts of the valley. For a little while we did have some Public Works stuff going on, but that's completely uninteresting and it stopped anyway.
It took an actual stadium event using 3 talkgroups on the new system at the same time to make it worth the trouble. While there are now scanners being sold which can receive this new traffic, no scanner can receive more than one call at a time, never mind three. That kind of parallelism is the real reason to bother with this kind of software setup.
What happens now? Well, there still is no traffic on the new system from day to day. As I write this on a Monday morning, there hasn't been anything significant to report for over 24 hours. (I can tell by looking at the recordings from the new program!) It won't start getting really interesting until local police and fire agencies switch over.
At that point, it'll make sense to work on it some more. Until then, I have bigger fish to fry.