Most trunked radio systems have the channels they use spread out over a couple MHz worth of spectrum. In order to be able to record more than one broadcast at once, you pretty much need to have an SDR that has enough bandwidth to cover the lowest channel in the system and the highest on at the same time. For the DC Fire & EMS system, the lowest channel is at 854.86250 MHz and the highest is at 860.98750 MHz. This means that your SDR needs to have 6+ MHz of bandwidth. This isn’t too much for most modern SDR, like HackRF, BladeRF or one of the Ettus. These are great SDR, but they cost atleast $300.
The lowly RTL-SDR is a $20 SDR that is just a repurposed USB TV dongle. While it makes for an OK SDR, it only has ~2MHz of bandwidth. When I re-wrote Trunk Recorder, I designed it to support using multiple SDR, but I never really tried it out, so I decided to give it a try.
One of the reasons I was interested was to see if I could get better CPU performance. There is a lot of CPU time dedicated to cutting down the full bandwidth that is coming from the SDR into the small sliver that is interesting. This has to be done for each of the “recorders” that is actively trying to capture a channel. When I was using a single SDR, each Recorder had to take in the full 8MHz and pull out the small 12.5KHz that was interesting. The end results is that I could only record about 3 channels at once before the CPU got overloaded. Since that control channel was going at the same time, that was the equivalent of about 32MHz of bandwidth to process.
With the RTL-SDR, each Recorder only has to look at 2MHz, which puts a lot lighter load on the CPU. Roughly speaking, having 3 Recorders active, plus the control channel would mean that only a total of 8MHz was being processed. As you can see, this means that it scales much more efficiently.
The new code for multiple SDRs has been merged in, give it a try!
A couple notes on my setup…
First, start out with an RTL-SDR dongle that has a TXO. This helps make sure the tuning is pretty accurate and will not drift as it gets warmer. These dongles from rtl-sdr.com have been great and the antenna they come with seems to be pretty good.
Also, make sure you assign your dongles each a unique serial number. You can do this with the rtl-eeprom -s command. Using this serial number, you can define different error corrections values for each dongle. I have notice they will very by a few hundred hertz between dongles. There is an example of how to do this in the multi-sdr config file.
The other thing I got was a USB 3 hub. Having more than 2 USB 2 dongle connected to a USB 2 hub might max out the bandwidth. I am not sure if this is necessary, but I wanted to limit the places where things could get screwed up.
Comments
11 responses to “Using Multiple RTL-SDR to Capture a Trunking System”
[…] [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! […]
The USB3 hub thing is an incorrect assumption I also made (for a different project) – turns out that USB3 has completely separate USB2 and USB3 data lines and (critically) hubs don’t aggregate the USB2 traffic onto USB3; they’re literally two separate hubs in one – hence the USB3 side of your hub is being completely unused. I know, lame huh? When I looked (late 2015) there were NO hub chips that actually aggregate USB2 traffic onto the USB3 bus. That may change someday but it’s complex to do and manufacturers don’t have much incentive.
drtune – Doh! Thanks for helping solve that mystery. On the plus side, the USB 3 hub does have nice blue lights.
I wonder how many dongles you could have on a USB hub before it gets max out.
[…] system that may be spread out over a larger bandwidth. In order to get around this limitation Luke Brendt has been using three RTL-SDR dongles together to capture a trunking system in his area which is spread over 6 MHz of […]
[…] [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! […]
Nice Blue Lights !
I feel better now… I thought I was the only one. LOL
Thank you from the Public Safety “Community” for all that you have written. Unfortunately, my wife now hates you even more than me! It appears that I am going to have to learn Linux now just to get your application up & running here.
That essentially means no gardening or yard work from me until I learn a new O/S. (I promised myself that I’d never give it a try after spending all of that time learning Netware and getting a CNE — ROFL)
I have heard from a few friends (“youngsters” that actually DO know unix/linux) that you have really created a great utility that meets the needs of the under-funded volunteer FD’s. RTL-SDR’s are sure a whole lot cheaper than multiple XTL5000’s or APX’s or even the lowly Uniden x36hp p25 capable scanners when you need to record all channels of a TRS.
I first have to finish up learning the Quantar’s v.24 interface so I can link several repeaters together that I am donating to my FD, then onto the world of linux. :)
All kidding aside. Thanks !
BTW: when u retire and can create products/projects that can earn you $$ (i’m in the same boat), here’s a concept for you —> a “Field Comm Kit” comprised of a pelican style case full of gadgetry that can be deployed at a routine incident or a large incident and give the IC a “heads up” & situational awareness of users operating on simplex “fireground channels”. (NFPA / every fire chief’s assoc. / etc.. all recommend the use of analog simplex comms @ a fire/emergency/swat scene)
BUT… if the IC is “busy” or “distracted” and no one else can discern a call for help, it’d be great to have a display to decode all MDC1200 traffic (especially “mayday” or “emergency” calls w/ ptt ani) and alert everyone AND relay it over to the dispatch facility via RF or IP or cellular-modem etc.. (and a HUGE plus would be recording of all audio traffic locally — and relayed out in the event of the loss of the recording equipment should the incident be the type desired by members of the religion of peac… i can’t continue the rest of that or I will get my typing hand slapped.
But I think it’d be a big lifesaver with tremendous potential.
:) RB
Luke,
I got a patch you might want to try and really don’t see the point of joining github to post
there when this is likely the only time i would use it.
Anyway the patch,
* Adds your priority>99 code to the analog recorder.
* Adds config setting ‘defaultMode’ for default mode to use for unlisted talkgroups. [digital/analog]
* Adds 2 phase squelch to analog recorder and a config setting ‘squelch’ for each source, setting to 0
will disable it. (Based on Ham2mon code)
* It updates the README and the config examples.
*** Patch: http://pastebin.com/zTrrjCnD
I’m using rtl-sdr’s and on the local analog system each call had several seconds of very load static at
end of it, Using the squelch code you commented out did help, but the code i used which came from ham2mon
seems to give a better result.
I don’t know squat about C/C++, but the only thing i really had trouble with was just passing the
squelch setting from main.cc to analog_recorder.cc, i think i finally got it done in a correct manner,
but might want to give it a quick look. I tested it in every possible way i could think of digital/analog,
missing setting, etc, and no problems. And it works great for my setup.
Been testing this for several months and seems like you have got it to a very usable state, thanks for
all the work you put into it!!
Random Dude :)
Thanks Rich – It is great to hear that this is actually useful. Sorry for the late response – kids keep me busy.
That sounds like a great concept! I just need some free time to work on it.
Let me know if you have trouble getting things to compile: lukekb@gmail.com
Beautiful article! I just have a question though.. Would this perform better with say, Airspy R2 SDR or Airspy mini?
…just a passing thought I had.
Will this work on a Pi? I have a laptop that I could sacrifice but the Pi would be so much better.
Basically looking to record all the audio from two talkgroups from whichever site it can pick up the stongest on the simulcast system. If this is possible it would be great as I already have all the pieces to do this and it would give our small department a way to archive all of our radio communications.
Thank you
Hi! Since I’m new to the SDR field, I have quick question.
1. Can you scale in more SDR for a greater mhz range coverage?