In the old days, if you wanted to listen to police, fire, or other two-way radio users, you didn’t need much more than a simple receiver. Today, you are more likely to need something a little more exotic thanks to the adoption of trunked radio systems. To pick up the control channels and all the threads of a talk group conversation, you might need a wide bandwidth receiver.
[Luke Berndt] found he needed 6 MHz to monitor the stations he wanted to hear. This is easily in the reach of dedicated software defined radios (SDR). However, [Luke] wanted to use cheap RTL-SDRs and their bandwidth is about 2 MHz. The obvious hacker solution? Use three of them!
If you haven’t looked at a trunked system before, it essentially allows a large number of users to share a relatively small number of channels. When someone wants to talk, they move to an unused channel just for that transmission. Suppose Alice asks Bob a question that happens to be on channel 12. Bob’s reply might be on channel 4. A follow up from Alice could be on channel 3.
In practice, this means that receiving the signal isn’t difficult to decode. It is just difficult to find (and follow as it jumps around). This is an excellent job for multiple SDRs and the approach even reduces the burden on the CPU, which doesn’t have to decode signals that aren’t essential to the conversation.
[Luke] includes source code and also notes how to change the serial numbers of the dongles since each has to be unique. We have seen so many great projects with the RTL-SDR that it is hard to choose our favorite. It is especially great knowing that the dongle was only meant to receive television, and all these projects are hacks in the best sense of the word.
Thanks [WA5RRior] for the tip.
Interesting solution
Your USB hub has to be able to handle the triple bandwidth. Cheap hubs typically won’t, in my experience.
Looks like an Anker USB 3.0 hub to me in the image. Probably easily enough bandwidth there.
Anker seem to be regarded as making some of the best USB 3.0 hubs as well.
Ethernet would be a great interface for that use, if only there was a easy way to let those SDR chips spit out Ethernet frames.
Fast enough, near realtime, free as in speech and dirt cheap as in beer, hugely documented, stackable protocols, etc. etc. The more I see stuff having problems with USB (which frankly sucks for about everything but mice and keyboards), the more I’m convinced we already have the answer and all we need is a bit of logic to adapt it to other uses.
According to the comments in the article, those are USB 2 dongles AND that current USB 3.0 hubs don’t aggregate or ‘multiplex’ USB 2.0 bandwidth to the wider 3.0 space. So other than using a USB hub, you would have to have 3 open root nodes from a USB host controller. My desktop has 4 but even that is from the mobo and it actually compacts them into 2 host nodes, YMMV.
wat? 3x 4MB/s is too much for USB 2.0 hub?
This is pretty cool, but by the time you have three cheap dongles, I feel like going for the SDRPlay is the more obvious choice.
Okay, on reading the article I see this solution was based more on CPU performance than cost. So three dongles maybe isn’t so crazy.
To follow a call as described above, is almost like drinking from a waterfall. Works great if you want to capture all traffic for a trunked system and decode it afterwards. A much better solution is to decode the control channel. I think it is encrypted these days, but the data signal is predictable, so the key can be reversed. it is a rather simple format the control channel uses. When the radio in the field wishes to talk (i.e. mike button depressed) it sends a channel request to the controller, showing its unitID and current groupID. The controller sends an ack and a channel number for transmit (i.e. 1a,2a,3a,4a,5a, etc) and sends a second for the receivers in the groupID to listen on channel (1b,2b,3b… etc). Each radio is preprogrammed with the channels and controller key (systemID), as well as a groupID and unitID. A unitID could be a member in multiple groups. The groupIDs and unitIDs are visible in the control signal, as well as the channel number (remember send and receive are on different frequencies, and not necessarily on a fixed offset). The controller does not send the actual frequency.
To listen in on a specific conversation, you need to track the groupID and channelID for receive. It may take a while to identify all the channels. When trunking was setup in the 80s, most sites had consecutive channels allocated. There have been so many mergers since, that for any given controller, the channels may be spread over the entire frequency range used for trunking – and not in any order.
Most of the systems are motorola based. Every 24 hours or so, these systems flip the control channel to another frequency, to avoid burnout on the transmitters. These are preprogrammed in the mobile radios and they know to scan for this. Will take a few days to find all the controllers.
Most of the protocol used is documented, but you need to find the old system manuals from the early 80’s. By the late 80’s motorola realized the stupidity of publishing the protocols (i.e. someone can build competing radios) and the system manuals since then have obfuscated the info. If you need more info, there were monitoring systems developed in the late 80’s to track the control channel for billing purposes. If you dig around, you may still be able to find info on these. By the mid 90s, most of the independent operators were bought out (or forced out) of the market, so the independent billing systems are gone now. Lastly, find an old guy that used to run these systems. About 1 in 20 figured out how it works – especially those, that were able to stay independent for >10 years. FCC records searches can help here.
Last… there is a backdoor into some of these systems via radio. I have never seen official documentation for this feature, but the old independents did decode and share this info. Listen to the uplink on the control channel, that will start to give you clues.
Disclosure – I myself do not know the details of how the above works, so don’t ask. I just happened to sit at the same dinner table with an independent owner/engineer and a crazy sw engineer trying to keep Motorola’s fingers out of the system…
A lot of that information can be found on http://radioreference.com/. Example: http://www.radioreference.com/apps/db/?sid=2983
You must be a RadioReferenceRetard……. your post is so full of gibberish, if it were printed it would be bird cage liner. Hopefully no one will put any credibility in anything you wrote. A simple search of P25 trunking systems would have yielded a more educational fruitful bounty then the misinformation in your post.
…shots fired
NicholasPetty – thanks for the radioreference link. Based on the info there, I feel I need to put my comment above into proper context. My commentary was based on Motorola Type I and early Type II trunking systems, before the advent of cdma and tdma.
KLV4000 – RadioReferenceRetard… gotcha. Best of health to your children. I will be quiet from now on. Enjoy.
What a prick…. at least he’s contributing to the conversation
Motorola, out of radio? LOL
That’s got to be right up there with keeping Microsoft out of the PC business.
This feels like overkill. Don’t get me wrong, it gets the job done, and it does allow for up to three separate lines to be heard simultaneously, but if your trying to follow a conversation that could get tedious.
I had a similar issue trying to listen in on local police transmissions (I live in the boonies where they still transmit analog!). I couldn’t keep up with the multiple frequencies. The solution was an Android app called SDRtouch, which includes frequency storage, squelch and scanning. I stored all the frequencies I wanted to listen in on and set it to scan. Sometimes I miss a call while listening to another but it’s pretty rare. The other benefit is that SDRtouch remembers the characteristics of each stored frequency; FM/am/USB/LSB/ I/Q, bandwidth, and squelch settings.
The app is free in a demo mode, but the demo includes stored frequencies, squelch and scanning so it would work just fine in this application. It also only needs one SDR to work, certainly cheaper than using three SDRs.
Trunking doesn’t quite work the way the article describes. Conversations are assigned a channel (in almost every trunked system) and it sticks with that channel for the duration of that call. It’s inefficient to break up a typically short two-way conversation in the way described.
And if we’re being accurate, and excluding the US, the majority of international trunked radio systems use either the MPT-1327 open standard first developed in the UK over 30 years ago (Still works well) or the widely duplicated LTR system originally developed by EF Johnson. The US was dominated by various Motorola systems arguably due to antics from the big M back in the day which effectively blocked entry of the better, cheaper, multi-vendor MPT1327 system into North America. The rest of the commercial world, however, went with MPT or LTR. (Government systems used a mix of Motorola, GE-Ericsson, MPT-1327, LTR and other stuff depending on budget)
Mind you, there were also the antics of a large European vendor who…. And the shambled of TETRA. And digital trunked radio….
But that’s a whole ‘nuther story.
This has to be my 2nd favourite commentary of the last few days, i can’t let you know the top, it may offend you!
What about MA/Com open sky?