I've been playing around with rtl-sdr as a way to stream trunking radio and air band traffic. I've done a bit of research and found people who are using multiple dongles, one to digest the control channel and one or more to tune and receive the voice channels as the talk groups come and go. They're also using multiple dongles and/or squelch scanning to stream airband signals
Around here, all of the channels of the trunking system as well as all of the "interesting" fit inside the bandwidth of a dongle running at 3.6Msps. So, my question is this:
Would it not be more efficient to have a single tuner dongle outputting all of its samples over multicast (or into a shared memory segment for that matter, if you want to stay on the same host) and then having a bunch of decoder processes listening to the samples and decoding what they need out of them?
Would it not be more efficient to have a single tuner dongle outputting all of its samples over multicast (or into a shared memory segment for that matter, if you want to stay on the same host) and then having a bunch of decoder processes listening to the samples and decoding what they need out of them?
I believe the dongles start to drop samples over 3.2Msps, so you may find you get a better quality signal by using multiple dongles with a lower sampling rate.
I don't think it is necessarily any more efficient to use one dongle instead of multiple, it just depends on whether the channels of interest fit within the bandwidth of the dongle. If they do, then great, you will only need one. If not then you don't have much of a choice.
Cheers, Adam.
Hello James,
You might use Linrad: http://www.sm5bsz.com/linuxdsp/linrad.htm Preferrable under Linux where performance is very good.
You can run a master instance of Linrad connected to the dongle and set it to send fourier transforms (fft1) as UDP to the network.
You can then runn a large number of linrad slaves that pick up the data and produce the sound output of the channels of your choice. You may use the squelch to make all the channels quiet when there is no signal. You may route all the channels to your loudspeaker and you can also save all the channels as separate .wav files at i.e. 8 kHz sampling rate which means 16 kB/s per channel. In case you want to monitor 10 channels that is 9.6 megabytes per hour. Normally you would throw those files away, but if something happens they might be interesting. You can also save the raw data, but linrad would save 16 bit per sample which means 3.2*2*2=12.8 megabytes per second which is 46 gigabytes per hour. Still, with a modern disk you can save 24 hours (1.1 TB) in a single file. In case there was no interesting event, just delete it. You can use Linrad to save a small fraction of the big file just as if it were a signal from the antenna.
Linrad is a bit different from other SDR software and many people find it has a steeper learning curve. Depending on who you are this may be more or less true. Linrad is quite general and a bit old-fashioned. You do not have buttons for USB CW or LSB. The user has to set a suitable bandwidth and place the BFO at a suitable point outside the filter for those modes. One can also place the BFO inside the filter or far outside for other modes just as in radios from 1960 and earlier.
Regards
Leif / SM5BSZ
I've been playing around with rtl-sdr as a way to stream trunking radio and air band traffic. I've done a bit of research and found people who are using multiple dongles, one to digest the control channel and one or more to tune and receive the voice channels as the talk groups come and go. They're also using multiple dongles and/or squelch scanning to stream airband signals
Around here, all of the channels of the trunking system as well as all of the "interesting" fit inside the bandwidth of a dongle running at 3.6Msps. So, my question is this:
Would it not be more efficient to have a single tuner dongle outputting all of its samples over multicast (or into a shared memory segment for that matter, if you want to stay on the same host) and then having a bunch of decoder processes listening to the samples and decoding what they need out of them?
-
Adam Nielsen -
James Sharp -
Leif Asbrink