A question on gnuradio capacity of handling real time data streaming and signal processing with USRP

GNU Radio
1

Dear Group,

I have a need to do real time or near real time tracking (most likely
phase-lock loop) of multiple narrow-band carriers/tones in a 1MHz band
of
signal input using USRP N210 and gnuradio running on a reasonable linux
host. Say the carriers/tones are embedded in the band from -500 kHz to
+500
kHz. If I want to lock on to 20 carriers in that band using gnuradio
PLLs,
will this choke up the computer? If there is a problem, I also would
like to
think how to reduce data rates. But I don’t know whether multiple LO’s
are
an option.

Thanks for reading,

LD

2

Thanks for reading,

LD

The best thing to do is to put together a simulation, and see if your
computer is up to the task or not.

Something that we don’t have a really good handle on in Gnu Radio is
some estimates for the computational complexity of
individual blocks in a flow graph.

If we did, one could do some simple arithmetic:

add up all the complexities of all the blocks on your “fast path” (by
this I mean blocks that must necessarily operate at the input sample
rate)
multiply that by the sample rate

That gives you an idea of the numbers of MFLOPS/GFLOPS required to
support your application.

3

Thanks I will try a simple one and report back.

LD

From: discuss-gnuradio-bounces+ldz10565=removed_email_address@domain.invalid
[mailto:discuss-gnuradio-bounces+ldz10565=removed_email_address@domain.invalid] On Behalf
Of
Marcus D. Leech
Sent: Monday, May 13, 2013 4:46 PM
To: [email protected]
Subject: Re: [Discuss-gnuradio] A question on gnuradio capacity of
handling
real time data streaming and signal processing with USRP N210 + gnuradio
on
host linux computer

Dear Group,

I have a need to do real time or near real time tracking (most likely
phase-lock loop) of multiple narrow-band carriers/tones in a 1MHz band
of
signal input using USRP N210 and gnuradio running on a reasonable linux
host. Say the carriers/tones are embedded in the band from -500 kHz to
+500
kHz. If I want to lock on to 20 carriers in that band using gnuradio
PLLs,
will this choke up the computer? If there is a problem, I also would
like to
think how to reduce data rates. But I don’t know whether multiple LO’s
are
an option.

Thanks for reading,

LD

The best thing to do is to put together a simulation, and see if your
computer is up to the task or not.

Something that we don’t have a really good handle on in Gnu Radio is
some
estimates for the computational complexity of
individual blocks in a flow graph.

If we did, one could do some simple arithmetic:

add up all the complexities of all the blocks on your “fast path” (by
this I
mean blocks that must necessarily operate at the input sample rate)
multiply that by the sample rate

That gives you an idea of the numbers of MFLOPS/GFLOPS required to
support
your application.

4

On Tue, May 14, 2013 at 12:45 AM, Marcus D. Leech [email protected]
wrote:

think how to reduce data rates. But I dont know whether multiple LOs are
The best thing to do is to put together a simulation, and see if your
multiply that by the sample rate

That gives you an idea of the numbers of MFLOPS/GFLOPS required to support
your application.

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

We actually now have the Performance Counters. They have just been
added and are undocumented, almost completely. We’re still working on
them as a concept, but we’ll be promoting their use more and more soon
(once 3.7 is done, most likely). But they can tell you the
instantaneous, average, and variance of the amount of CPU time spent
in work for all blocks. You can get these values by calling
pc_work_time() (add _avg() or _var() for the other two statistics.

There will be more stuff on this in the coming months.

Tom

5

I am still learning from on line examples on how to do this in the
gnuradio
flow graph for testing out the ideas.

There seems to be two kinds of approaches to deal with the potential
problem
of data stream processing choke up:

  1. Use a filterbank with many outputs. But for each output use a digital
    downconversion (DDC) block so that the data rates can go way down. Do
    say 5
    streams at a time. Use throttle, or delay (if there is any), or skip
    head
    block to delay the processing the rest of the streams (besides the 5).

  2. Still use the same filterbank but with no DDC. Phase lock on the
    first 5
    carriers and delay/throttle/skip the rest. When done with the first 5,
    record the phase and terminate execution. Then move on the rest, so on
    and
    so forth.

I would like to check if these ideas sound correct. Also since I am a
beginner in GRC, I am curious to hear for a seasoned developer which of
the
two above looks easier to do.

Thanks,

LD

From: discuss-gnuradio-bounces+ldz10565=removed_email_address@domain.invalid
[mailto:discuss-gnuradio-bounces+ldz10565=removed_email_address@domain.invalid] On Behalf
Of
Marcus D. Leech
Sent: Monday, May 13, 2013 4:46 PM
To: [email protected]
Subject: Re: [Discuss-gnuradio] A question on gnuradio capacity of
handling
real time data streaming and signal processing with USRP N210 + gnuradio
on
host linux computer

Dear Group,

I have a need to do real time or near real time tracking (most likely
phase-lock loop) of multiple narrow-band carriers/tones in a 1MHz band
of
signal input using USRP N210 and gnuradio running on a reasonable linux
host. Say the carriers/tones are embedded in the band from -500 kHz to
+500
kHz. If I want to lock on to 20 carriers in that band using gnuradio
PLLs,
will this choke up the computer? If there is a problem, I also would
like to
think how to reduce data rates. But I don’t know whether multiple LO’s
are
an option.

Thanks for reading,

LD

The best thing to do is to put together a simulation, and see if your
computer is up to the task or not.

Something that we don’t have a really good handle on in Gnu Radio is
some
estimates for the computational complexity of
individual blocks in a flow graph.

If we did, one could do some simple arithmetic:

add up all the complexities of all the blocks on your “fast path” (by
this I
mean blocks that must necessarily operate at the input sample rate)
multiply that by the sample rate

That gives you an idea of the numbers of MFLOPS/GFLOPS required to
support
your application.

6

add up all the complexities of all the blocks on your “fast path” (by
this I mean blocks that must necessarily operate at the input sample rate)
multiply that by the sample rate

That gives you an idea of the numbers of MFLOPS/GFLOPS required to
support your application.

The advanced scheduler comes with a web 2.0 status monitor + gui
builder: Stats · guruofquality/gras Wiki · GitHub

  • Make your flow graph with simulation or live data sources
  • Drop the GRAS query server block into your flow graph
  • Run flow graph, open the browser to http://localhost:8080
  • Create throughput and overhead compare charts with the GUI builder
  • Measure throughput over time and detect blocks with high contention
  • Enjoy!

-josh