Processing multiple signals off single source block

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

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 J. M0MIK BSc MIET
Email: [email protected]
Web: http://scanoo.com

Mike, does this work with the Funcube Dongle Pro+?

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 J. M0MIK BSc MIET
Email: [email protected]
Web: http://scanoo.com

On Thu, Aug 22, 2013 at 3:24 AM, Marcus M. [email protected]
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.

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 R. has a blog entry on core affinity, see
    http://gnuradio.squarespace.com/home/2013/2/7/block-core-affinity.html .

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/performancecounters .
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

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 R. has a blog entry on core affinity,
seehttp://gnuradio.squarespace.com/home/2013/2/7/block-core-affinity.html .

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… :slight_smile:

Awesome project!

Thanks! I am having way too much fun with a $20 dongle. GNURadio is
awesome.