SDRTrunk Using Multiple Tuners For Increased Bandwidth?

[Floridarailfanning]

I must be missing something obvious here but how do you actually use two RTL tuners to resolve the "Tuner Unavailable" issue?

Both of the tuners have unique serial numbers and are connected and appear in SDR Trunk but I can't seem to figure out how to combine the bandwidth. I've tried using the "Tuner - Multiple Frequencies" option but I don't want to monitor the same CC twice or two different sites.

I'm using v0.4.0. Any suggestions?

 

[maus92]

I must be missing something obvious here but how do you actually use two RTL tuners to resolve the "Tuner Unavailable" issue?

Both of the tuners have unique serial numbers and are connected and appear in SDR Trunk but I can't seem to figure out how to combine the bandwidth. I've tried using the "Tuner - Multiple Frequencies" option but I don't want to monitor the same CC twice or two different sites.

I'm using v0.4.0. Any suggestions?

What system / what is the lowest and uppermost frequency?

 

[Floridarailfanning]

TACN which is VHF and 7/800. The 700MHz range is 769 to 774 (5MHz) which is the only range I usually monitor.

I think two SDRs running at 2.56MHz should cover it.

 

[maus92]

TACN which is VHF and 7/800. The 700MHz range is 769 to 774 (5MHz) which is the only range I usually monitor.

I think two SDRs running at 2.56MHz should cover it.

Maybe not. One dongle will be roughly centered on the control channel (which I notice for this system is generally around 769-770,) while the other is free to tune across the range of frequencies. But if the other dongle is working a traffic channel on the low end of the range, the available VFOs may be out of band width limits to tune another active traffic channel in the upper range of frequencies.

 

[GTR8000]

Maybe not. One dongle will be roughly centered on the control channel (which I notice for this system is generally around 769-770,) while the other is free to tune across the range of frequencies. But if the other dongle is working a traffic channel on the low end of the range, the available VFOs may be out of band width limits to tune another active traffic channel in the upper range of frequencies.

SDRTrunk dynamically adjusts the centering on all dongles in an attempt to maximize spectrum availability. That is to say, even the dongle that is locked on a control channel will be re-tuned on the fly if necessary to grab traffic within the available bandwidth.

If the control channel is 769.95625, for example, dongle #1 may be centered at 769.99875 when the system is relatively quiet. If there is traffic on 774.60625, dongle #2 will obviously have to handle that, however if 772.18125 goes active with traffic, dongle #1 will retune itself to capture both 769.95625 and 772.18125. It's very efficient at doing so without missing a beat, and can be seen by bringing up the spectrum displays. You will see the control channel signal move around within the available bandwidth of the dongle.

By the way, I always run my RTL dongles @ 2.56 MHz sample rate in SDRTrunk to eek out every last drop of bandwidth, and have never had any issues doing so. I would recommend testing that sample rate for dropped samples using rtl_test, as not all USB controllers or dongles are created equal.

 

[Floridarailfanning]

So when setting up a channel how do you configure it to use both on the dongles?

 

[maus92]

SDRTrunk dynamically adjusts the centering on all dongles in an attempt to maximize spectrum availability. That is to say, even the dongle that is locked on a control channel will be re-tuned on the fly if necessary to grab traffic within the available bandwidth.

If the control channel is 769.95625, for example, dongle #1 may be centered at 769.99875 when the system is relatively quiet. If there is traffic on 774.60625, dongle #2 will obviously have to handle that, however if 772.18125 goes active with traffic, dongle #1 will retune itself to capture both 769.95625 and 772.18125. It's very efficient at doing so without missing a beat, and can be seen by bringing up the spectrum displays. You will see the control channel signal move around within the available bandwidth of the dongle.

By the way, I always run my RTL dongles @ 2.56 MHz sample rate in SDRTrunk to eek out every last drop of bandwidth, and have never had any issues doing so. I would recommend testing that sample rate for dropped samples using rtl_test, as not all USB controllers or dongles are created equal.

What happens if dongle #1 is locked onto a cch at 769.xxx, and dongle #2 is working a channel at 771.xxx and activity comes up on 774.xxx?

 

[GTR8000]

What happens if dongle #1 is locked onto a cch at 769.xxx, and dongle #2 is working a channel at 771.xxx and activity comes up on 774.xxx?

Sorry, I should've been more clear in my reply. Basically, SDRTrunk will first try to use whatever dongle it knows can handle the range of traffic channels. In your example, it would've used dongle #1 to tune to 771.xxx instead of dongle #2, leaving dongle #2 free to tune to traffic on the upper portion of the band. In theory, at least.

I have three dongles monitoring three 700 sites. Dongle #1 is on a 774.4xxxx control channel, dongle #2 is on two 770.7xxxx control channels, and dongle #3 is rarely used, as SDRTrunk simply re-tunes the other two dongles as needed to cover 769-771.5 and 772.5-775. The only traffic channels on any of these systems in that 771.5-772.5 gap are secondary control channels, and are rarely used. When they do pop up, dongle #3 is free to handle those.

 

[GTR8000]

So when setting up a channel how do you configure it to use both on the dongles?

You shouldn't have to do anything to configure the dongles. SDRTrunk will simply re-tune them as necessary. Without knowing the exact channel layout at the site you're monitoring, I can't give you a definitive answer.

Oh, I see that you're still running 0.4.0. I'm running the latest 0.5.0-alpha6 release, so perhaps improvements were made that don't apply to you. Might way to consider upgrading to 0.5.0 (after backing up all of your existing 0.4.0 files, of course).

 

[maus92]

Sorry, I should've been more clear in my reply. Basically, SDRTrunk will first try to use whatever dongle it knows can handle the range of traffic channels. In your example, it would've used dongle #1 to tune to 771.xxx instead of dongle #2, leaving dongle #2 free to tune to traffic on the upper portion of the band. In theory, at least.

I have three dongles monitoring three 700 sites. Dongle #1 is on a 774.4xxxx control channel, dongle #2 is on two 770.7xxxx control channels, and dongle #3 is rarely used, as SDRTrunk simply re-tunes the other two dongles as needed to cover 769-771.5 and 772.5-775. The only traffic channels on any of these systems in that 771.5-772.5 gap are secondary control channels, and are rarely used. When they do pop up, dongle #3 is free to handle those.

Right, this is what I was trying to point out - 3 would probably be the proper amount of dongles if one wanted to ensure coverage / availability over the range of 769 - 775. The op is only using 2.

 

[GTR8000]

Right, this is what I was trying to point out - 3 would probably be the proper amount of dongles if one wanted to ensure coverage / availability over the range of 769 - 775.

Absolutely, I agree with that...two RTL dongles cannot cover the full 769-775. You may be able to get away with just two dongles depending on the channel layout at the site, but three dongles will give you some breathing room.

I'm running SDRTrunk on another PC where I've setup low and high "dummy" channels to essentially lock the center tuning of the dongles. I did this to optimize the setup so that all control and traffic channels would be as far away from the edges of the available bandwidth as possible, since the dongles have a bit of a dropoff at the edges. Probably a bit OCD of me to do that, but so far the decoding has been 100% perfect with clean, strong signals on all site channels.

 

[Floridarailfanning]

You shouldn't have to do anything to configure the dongles. SDRTrunk will simply re-tune them as necessary. Without knowing the exact channel layout at the site you're monitoring, I can't give you a definitive answer.

Oh, I see that you're still running 0.4.0. I'm running the latest 0.5.0-alpha6 release, so perhaps improvements were made that don't apply to you. Might way to consider upgrading to 0.5.0 (after backing up all of your existing 0.4.0 files, of course).

Thanks for the recommendation to update. This new v0.5.0 Alpha 6 does indeed automatically tune the second SDR as needed.

 

[GTR8000]

0.5.0 is a vast improvement over 0.4.0

 

[ChrisABQ]

I'm running SDRTrunk on another PC where I've setup low and high "dummy" channels to essentially lock the center tuning of the dongles. I did this to optimize the setup so that all control and traffic channels would be as far away from the edges of the available bandwidth as possible, since the dongles have a bit of a dropoff at the edges. Probably a bit OCD of me to do that, but so far the decoding has been 100% perfect with clean, strong signals on all site channels.

I'm having some issues where a bad decode will be played, can be anywhere from a few seconds to 329 seconds, it's very irritating.
I'm wondering if the workaround above has/would help to resolve that issue (please also let me know how you did this). I'm thinking it's happening because maybe a frequency comes in on the "fringe" of the bandwidth or while dongles are locked on the opposite side of the spectrum. Also, is there a way to lock the rtl's at a static centered frequency? The control channel dongle never seems to move off the same frequency.

I'm running the latest 0.5.0-alpha6 release, 3 rtl sdr dongles at 2.56 Mhz sample rate, 700 Mhz system 769-771 and 773-775 range with 12 frequencies on one site.

 

[GTR8000]

I'm having some issues where a bad decode will be played, can be anywhere from a few seconds to 329 seconds, it's very irritating.
I'm wondering if the workaround above has/would help to resolve that issue (please also let me know how you did this). I'm thinking it's happening because maybe a frequency comes in on the "fringe" of the bandwidth or while dongles are locked on the opposite side of the spectrum. Also, is there a way to lock the rtl's at a static centered frequency? The control channel dongle never seems to move off the same frequency.

I'm running the latest 0.5.0-alpha6 release, 3 rtl sdr dongles at 2.56 Mhz sample rate, 700 Mhz system 769-771 and 773-775 range with 12 frequencies on one site.

How many sites are you decoding? Do you have a strong and reliable signal on all frequencies? Have you dialed in the tuner correction for each dongle with PPM auto-correction enabled? What gain settings are you using? Are you getting any "Error obtaining channel from tuner" error messages being logged?

Provide a link to the site(s) you're decoding so that I can see the exact range of frequencies so I can give a more specific answer to your situation. A few screenshots of the spectrum for all three dongles wouldn't hurt either, would like to see what it looks like while there is activity on the system.

 

[ChrisABQ]

Here's my specifics:
One site - 12 frequency simulcast system
One mile from tower
Clear signal with gain set at 279 (was having issue holding on control channel, so was turned up a bit which has corrected issue)
PPM auto correction is enabled with readings between 0.0 to 0.2
No errors that have been logged.

Issue is audio artifacts, everything else seems okay. Since posting, I have decreased the sample rate from 2.4 to 2.048 Mhz. I have 3 dongles, spanning a 5.3 Mhz system, so 2.048 that would cover about 6.1 Mhz. Been testing all day with good results so far.
If you have any other suggestions, it would be appreciated.

 

[GTR8000]

I'm curious why you're using three dongles when two will suffice. If the site is not using any frequencies between 771-773, then you only need to cover 769-771 (2 MHz) and 773-775 (also 2 MHz). Setting your sample rate to 2.048 might actually be detrimental, as it would cause one dongle trying to decode channels at either extreme of one of those blocks to be on the fringes of the available bandwidth.

Either provide a link to the site, or post all of the frequencies so I can get a better sense of the coverage required. You may be able to go down to just two dongles @ 2.56 msps and cover everything.

Edit: Okay looks like you're decoding the Albuquerque Simulcast of the statewide system. Let me take a look at the frequencies and see what's what.

 

[ChrisABQ]

1 (1)	011 (B)	Albuquerque Simulcast	Bernalillo	769.45625c	769.70625a	769.95625a	770.15625a	770.41875	770.69375	770.91875
				773.06875	773.34375	773.81875	774.54375	774.78125

Two dongles was worse as this is a very busy metro system covering City PD, Sheriff, City & County Fire.

 

[GTR8000]

1 (1)	011 (B)	Albuquerque Simulcast	Bernalillo	769.45625c	769.70625a	769.95625a	770.15625a	770.41875	770.69375	770.91875
				773.06875	773.34375	773.81875	774.54375	774.78125

Two dongles was worse as this is a very busy metro system covering City PD, Sheriff, City & County Fire.

It should not be any worse as long as your PC has the horsepower to keep up with all that decoding. It really doesn't matter if you have two or three dongles, it's going to use the same horsepower to decode the voice. In fact, three dongles is slightly less efficient than two, because it requires more overhead.

The key is to set the optimal sample right and gain, then perhaps add a few dummy channels to keep the two dongles fixed. SDRTrunk loves to constantly change the center frequency, which is not always ideal. It can very easily wind up putting a channel or two at the fringe of the bandwidth, resulting in lousy decoding.

 

[ChrisABQ]

You mentioned dummy channels before, if you could explain a bit more about that, that's actually why I posted to this topic.