Forum: GNU Radio Processing multiple signals off single source block

B0dcd692de8265464487673c4df88f9e?d=identicon&s=25 Luke B (Guest)
on 2013-08-21 20:19
(Received via mailing list)
I am working on a processing multiple signals using a single source
block.
The background is below, but I had a couple of high level questions:

 - What is the best approach performance wise for selecting multiple
~15khz
channels from a 2mhz+ source block? Is it using a Xlating FIR Filter
with a
low-pass? Is it more efficient to use a SIN Sig source & Multiply Block
with a low-pass FIR Filter? Is there a better way to extract a filter?

 - What is the best way to have different bunch of blocks processing
each
signal run independently and not block each other? I want to do this as
a
GR C++ program is there any way to run the signal source and chanelizers
as
one thread and then have the different processing chains run as separate
threads? Is there a way to put a queue or buffer inbetween blocks that
would allow for a chain of blocks to be separated between threads?

Or am I better off doing the basic signal/channel processing for
everything
in a single process and then writing the results to a file and then
having a process which goes through the files and does the more
intensive
vocoder work in non-real time?

Any pointers or examples of how to do threading with GR C++ code would
be
really helpful. I am not sure of the best architectual approach.


Background:
I have taken the gr-smartnet code and done a skeleton implementation in
C++. I want to process the digital trunking channel and then decode and
record the digital audio from all of the different talk groups. Since it
is
trunked, channels will be randomly be turning on and off and talk groups
will be switching from channels. It would be good to have a separate
thread
for the trunk decoding and the separate digital audio recorders.
Ideally, I
would like to be able to do this over 8 or 10Mhz using my HackRF.

My code, which is working enough to decode the trunking channel, is
here:
https://github.com/robotastic/sdr

Thanks!

 - Luke
C2ed5433862330f8d76de8eb807851ca?d=identicon&s=25 Mike Jameson (Guest)
on 2013-08-21 20:41
(Received via mailing list)
Hi Luke,

I've found using the FFT blocks are the most cpu efficient way to
extract a
channel from the whole 20MHz of the HackRF.  Have a look at my latest
Scanoo release built in GRC which uses the 'Keep X in N' block to select
the channel required.  There's also a spectrum sense mode which locks on
to
the strongest signal within the 20MHz bandwidth if it is not in the
blocked
frequency list:

https://github.com/m0mik/scanoo

Cheers,

Mike

--
Mike Jameson M0MIK BSc MIET
Email: mike@scanoo.com
Web: http://scanoo.com
F18b7b61dfbfe46c7af3cbcbda568c4f?d=identicon&s=25 Vanush Vaswani (Guest)
on 2013-08-22 00:42
(Received via mailing list)
Mike, does this work with the Funcube Dongle Pro+?
C2ed5433862330f8d76de8eb807851ca?d=identicon&s=25 Mike Jameson (Guest)
on 2013-08-22 01:16
(Received via mailing list)
Hi Vanush,

It uses the gr-osmosdr GRC block and the Funcube Dongle Pro+ is second
in
the list of compatible devices so yes it will work:

http://sdr.osmocom.org/trac/wiki/GrOsmoSDR

However, In order to work using the 192KHz bandwidth of the Funcube Pro+
you will need to fiddle with the sample rates and make sure that they
are
something like the following:

1) samp_rate = 192e3
2) channel_samp_rate = (quad_samp_rate * 1)
3) quad_samp_rate = (audio_samp_rate * 1)
4) audio_samp_rate = (48e3)

I'll update Scanoo to have an option in the GUI for the
'channel_samp_rate'
and 'quad_samp_rate' multipliers for easy Funcube use and better
flexibility. Thanks for asking the question!

Regards,

Mike

--
Mike Jameson M0MIK BSc MIET
Email: mike@scanoo.com
Web: http://scanoo.com
7d89a70df32c0ae27c1235016f9e5441?d=identicon&s=25 "Marcus Müller" <marcus@hostalia.de> (Guest)
on 2013-08-22 12:26
(Received via mailing list)
On 08/21/2013 08:15 PM, Luke B wrote:
>  - What is the best approach performance wise for selecting multiple ~15khz
channels from a 2mhz+ source block? Is it using a Xlating FIR Filter with a
low-pass? Is it more efficient to use a SIN Sig source & Multiply Block with a
low-pass FIR Filter? Is there a better way to extract a filter?
Xlating FIRs just generate the sin internally and apply it themselves;
they are mathematically equivalent to shifting your signal and filtering
it afterwards.
You can, of course, use bandpasses, if you're after a specific sprectral
shape. Try the gr_filter_design toolbox, it's even neater than doing
your calculations in Matlab (or scipy).
However, as Mike already pointed out, depending on your signal and
potential interferers of course, selection by trunkated fft is faster
and as intuitive.
>  - What is the best way to have different bunch of blocks processing each signal
run independently and not block each other? I want to do this as a GR C++ 
program
is there any way to run the signal source and chanelizers as one thread and then
have the different processing chains run as separate threads? Is there a way to
put a queue or buffer inbetween blocks that would allow for a chain of blocks to
be separated between threads?
I'm not quite sure I understand your question correctly. GNU Radio has
built-in concurrency for blocks.
Tom Rondeau has a blog entry on core affinity, see
http://gnuradio.squarespace.com/home/2013/2/7/bloc... .

> Or am I better off doing the basic signal/channel processing for everything in a
single process and then writing the results to a file and then having a process
which goes through the files and does the more intensive vocoder work in 
non-real
time?
Ok, this is another issue: If you think your computation is too heavy
for your platform, then splitting it into an online and offline part
might make sense. If you really want to find out what eats your cpu, try
the helpful performance counters
http://gnuradio.org/redmine/projects/gnuradio/wiki... .
Since decoding voice is usually a process that has to happen only for
one channel at a time, you might as well just save the input samples for
later offline decoding, extract only one channel at a time online and
decode that one for playback.
Although that might be wasteful on storage capacities (2Msam/s with
2*4B/sam=16MB/s), but it gives you the power to do the most amazing and
computationally intensive filtering/equalizing/fec/... on your samples
when you're not doing it in real time anyways.
Another well-tested trick: Network sinks/sources. Just use your rx
machine to do the trunking, and if it has enough power left, select the
right frequencies of each talk group by filter/fft, and send streams of
samples for each group via network to your decoder machine(s).
> Any pointers or examples of how to do threading with GR C++ code would be really
helpful. I am not sure of the best architectual approach.
Well, you can "multi-thread" your own block's work function, but I'd
advise you not to do that unless you really know what your scheduler
will do to you. Simply rely on GNU Radio to fully use up your available
CPU power to schedule several blocks at once; you have enough of them.
> Background:
> I have taken the gr-smartnet code and done a skeleton implementation in C++. I
want to process the digital trunking channel and then decode and record the
digital audio from all of the different talk groups. Since it is trunked, 
channels
will be randomly be turning on and off and talk groups will be switching from
channels. It would be good to have a separate thread for the trunk decoding and
the separate digital audio recorders. Ideally, I would like to be able to do 
this
over 8 or 10Mhz using my HackRF.
> My code, which is working enough to decode the trunking channel, is here:
https://github.com/robotastic/sdr
Awesome project!

Happy hacking
Marcus
D3e3c5e41e9aed486856802be823e181?d=identicon&s=25 Johnathan Corgan (Guest)
on 2013-08-22 22:30
(Received via mailing list)
On Thu, Aug 22, 2013 at 3:24 AM, Marcus Mller <marcus@hostalia.de>
wrote:


> afterwards.
>

FYI, the Xlating FIR filter uses a rotating complex unit vector (with
periodic renormalization) to accomplish the frequency shift, so this is
much more computationally efficient than the signal source block.

Also, it may be an option to use the polyphase channelizer block.
B0dcd692de8265464487673c4df88f9e?d=identicon&s=25 Luke Berndt (Guest)
on 2013-08-22 23:34
(Received via mailing list)
> Xlating FIRs just generate the sin internally and apply it themselves; they are
mathematically equivalent to shifting your signal and filtering it afterwards.
> You can, of course, use bandpasses, if you're after a specific sprectral shape.
Try the gr_filter_design toolbox, it's even neater than doing your calculations 
in
Matlab (or scipy).
> However, as Mike already pointed out, depending on your signal and potential
interferers of course, selection by trunkated fft is faster and as intuitive.

Awesome - I will stick with Xlating FIRs then. I will have to get
smarter on how to use the FFT to do the frequency shifting. I checked
out Mike's app, but I don't have 3.7 installed yet so I couldn't play
around with it.

> I'm not quite sure I understand your question correctly. GNU Radio has built-in
concurrency for blocks.
> Tom Rondeau has a blog entry on core affinity,
seehttp://gnuradio.squarespace.com/home/2013/2/7/bloc... .

I will give the block core affinity a try. I think what maybe happening
is that 2 process heavy blocks are being scheduled for the same core. I
have a 4 core machine and it is only hitting ~60% CPU utilization, but
it stops/slows decoding the trunking stream while it is doing vocoder
work. It doesn't seem to have a problem doing NBFM Demod and recording,
so I think the additional processing requirements of decoding digital
audio is the problem. The Performance Counters seem like a great
approach. It should give me a better idea where all the cycles are
going. The network source/sink approach also sounds like a good one. And
I have a spare laptop... :)


> Awesome project!

Thanks! I am having way too much fun with a $20 dongle. GNURadio is
awesome.
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.