30 Dec
2012
30 Dec
'12
11:21 p.m.
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?
31 Dec
31 Dec
2:03 a.m.
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.
2:17 a.m.
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?
4141
days inactive
4142
days old
2 comments
3 participants
participants (3)
-
Adam Nielsen -
James Sharp -
Leif Asbrink