How many multiple/simultaneous PLLs can I have running on USRP2?

Dear Community,

I have a question: I want to run multiple (as many as possible) PLLs
that
track the phase of multiple carriers in my band using the USRP N210. How
many can I have running in real time simultaneously? If I use the phase
from
these loops, are there unknown (gotcha) phase offsets between/among
them?

Thanks for reading,

LD

LD

Could you clarify your question?

Do you mean software PLLs in a Gnu Radio flow-graph? As many as you
want until your computer runs out of steam.

Thanks for your prompt answer. I have a 1MHz band of signals from which
I
would like to extract say 30 carriers. Is it possible to set up say 30
PLLs
in the flow graph and each will extract its own phase (and locked
frequency), and there are no additional phase offsets between/among the
different PLLs? What I mean by phase offsets is that the different PLLs
preserve the original phase relationships in the original 1MHz band of
data
stream. Is it difficult or easy?

Thanks much,

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: Wednesday, May 08, 2013 3:27 PM
To: [email protected]
Subject: Re: [Discuss-gnuradio] How many multiple/simultaneous PLLs can
I
have running on USRP2?

Dear Community,

I have a question: I want to run multiple (as many as possible) PLLs
that
track the phase of multiple carriers in my band using the USRP N210. How
many can I have running in real time simultaneously? If I use the phase
from
these loops, are there unknown (gotcha) phase offsets between/among
them?

Thanks for reading,

LD

Could you clarify your question?

Do you mean software PLLs in a Gnu Radio flow-graph? As many as you
want
until your computer runs out of steam.

I guess there may be an issue that since different PLLs will lock up at
different time, so there are unknown amount of initial phase offsets for
each PLLs. Would love to know if there are any ways around that.

LD

From: LD Zhang [mailto:[email protected]]
Sent: Wednesday, May 08, 2013 3:32 PM
To: ‘Marcus D. Leech’; ‘[email protected]
Subject: RE: [Discuss-gnuradio] How many multiple/simultaneous PLLs can
I
have running on USRP2?

Thanks for your prompt answer. I have a 1MHz band of signals from which
I
would like to extract say 30 carriers. Is it possible to set up say 30
PLLs
in the flow graph and each will extract its own phase (and locked
frequency), and there are no additional phase offsets between/among the
different PLLs? What I mean by phase offsets is that the different PLLs
preserve the original phase relationships in the original 1MHz band of
data
stream. Is it difficult or easy?

Thanks much,

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: Wednesday, May 08, 2013 3:27 PM
To: [email protected]
Subject: Re: [Discuss-gnuradio] How many multiple/simultaneous PLLs can
I
have running on USRP2?

Dear Community,

I have a question: I want to run multiple (as many as possible) PLLs
that
track the phase of multiple carriers in my band using the USRP N210. How
many can I have running in real time simultaneously? If I use the phase
from
these loops, are there unknown (gotcha) phase offsets between/among
them?

Thanks for reading,

LD

Could you clarify your question?

Do you mean software PLLs in a Gnu Radio flow-graph? As many as you
want
until your computer runs out of steam.

I guess there may be an issue that since different PLLs will lock up
at different time, so there are unknown amount of initial phase
offsets for each PLLs. Would love to know if there are any ways around
that.

LD

Well, presumably, you’d be using a PFB filterbank or something to create
the multiple streams, and then use PLL demodulators to extract bits from
those. The PFB filterbank should have uniform group delay across all
streams, as far as I know.

So maybe the PLL is not a good solution between it will have an unknown
amount of initial phase offsets by the time it locks. Since the relative
phase between different carriers is the essential information sought
after,
maybe the better way is to construct very narrowband filters. Now very
narrowband can mean a lot of taps, hence a lot of resources consumed.
Here
is where I don’t know the limitation of resources. If I want to set up a
filter of say 4 Hz bandwidth for a signal at 1MHz, and if you have a lot
of
these signals at different frequencies, what would be the best way to
extract these? Maybe the way to go is to have the LO at 1MHz, so the
many
signals being looked at are +/- many hundreds of kHz. How many taps
would it
require to extract a signal at say 300 kHz with the 4Hz bandwidth? Can
the
USRP do 200 taps for each of the 30 carriers (I am just asking without
exact
calculation here)?

Thanks,

LD

From: Marcus D. Leech [mailto:[email protected]]
Sent: Wednesday, May 08, 2013 3:39 PM
To: LD Zhang
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] How many multiple/simultaneous PLLs can
I
have running on USRP2?

I guess there may be an issue that since different PLLs will lock up at
different time, so there are unknown amount of initial phase offsets for
each PLLs. Would love to know if there are any ways around that.

LD

Well, presumably, you’d be using a PFB filterbank or something to create
the
multiple streams, and then use PLL demodulators to extract bits from
those. The PFB filterbank should have uniform group delay across all
streams, as far as I know.

at are +/- many hundreds of kHz. How many taps would it require to
extract a signal at say 300 kHz with the 4Hz bandwidth? Can the USRP
do 200 taps for each of the 30 carriers (I am just asking without
exact calculation here)?

Thanks,

LD

The USRP doesn’t care, since this all runs on the host under Gnu
Radio–unless you were under the impression (wildly incorrect) that Gnu
Radio
blocks run on the USRP hardware–they don’t.

Unless you want to implement in the FPGA.

In either case, the answer is “it depends”. Narrow filters consume
insane numbers of taps, which are resource-hogs whether it’s a FPGA
implementation or host-side hardware implementation.

Or am I wrong that the resource is in the computer and not in the USRP?

LD

It’s all in the computer, unless you do an FPGA-based implementation.
Gnu Radio blocks run on the host machine, not the USRP hardware.

I admit to being a little bit surprised that you don’t know that
already, given how long you’ve been posting things to this list,
and using USRP hardware.

Sorry for the confusion. I have been using USRP in a rather micky-mouse
way.
For the longest time, I was just capturing data on host computer disk
and do
brute force processing in MATLAB. It’s time for me to think about speed
up.
And the first thing is to consider the USRP processing capability. The
PLL
may still be the right solution if the PLL faithfully replicates the
original signal, which I think it should. But having the gnu-radio doing
the
PLL, I am not sure there is much of a speed gain. Maybe there are
intelligent ways of organizing this so that it can be sped up? Maybe the
Gnuradio is faster than Matlab. But these days the matlab has been awful
fast, not much slower than C. Still my matlab is not organized as nicely
as
the gnuradio. Right now I don’t have any streamlined processing. The
suggestion on using the PFB filterbanks and PLLs in parallel and
streaming
operation may have significant speed up? Your opinion is appreciated.

LD

From: Marcus D. Leech [mailto:[email protected]]
Sent: Wednesday, May 08, 2013 4:03 PM
To: LD Zhang; [email protected]
Subject: Re: [Discuss-gnuradio] How many multiple/simultaneous PLLs can
I
have running on USRP2?

Or am I wrong that the resource is in the computer and not in the USRP?

LD

It’s all in the computer, unless you do an FPGA-based implementation.
Gnu
Radio blocks run on the host machine, not the USRP hardware.

I admit to being a little bit surprised that you don’t know that
already,
given how long you’ve been posting things to this list,
and using USRP hardware.

On 05/08/2013 04:33 PM, LD Zhang wrote:

Matlab. But these days the matlab has been awful fast, not much slower
than C. Still my matlab is not organized as nicely as the gnuradio.
Right now I don’t have any streamlined processing. The suggestion on
using the PFB filterbanks and PLLs in parallel and streaming operation
may have significant speed up? Your opinion is appreciated.

I can’t tell you if your application will run in real-time, but the
polyphase filterbank is the most CPU-efficient way to extract multiple
(usually, more than four) signals from a sample stream in Gnuradio. You
will probably find Gnuradio much faster than offline processing in
Matlab.

If the relative phase offset of multiple carriers is important, then you
really only want to run a single PLL on one of the carriers, and use the
frequency estimate to apply to all the carriers – i.e., the entire bank
of signals – so that phase is preserved relative to the “reference”
carrier.

–n

Sorry to dig up an old thread, but does anyone know of anyone who’s
implemented a polyphase filter bank on a USRP FPGA?

John

Or am I wrong that the resource is in the computer and not in the USRP?

LD

From: LD Zhang [mailto:[email protected]]
Sent: Wednesday, May 08, 2013 3:51 PM
To: ‘Marcus D. Leech’
Cc: ‘[email protected]
Subject: RE: [Discuss-gnuradio] How many multiple/simultaneous PLLs can
I
have running on USRP2?

So maybe the PLL is not a good solution between it will have an unknown
amount of initial phase offsets by the time it locks. Since the relative
phase between different carriers is the essential information sought
after,
maybe the better way is to construct very narrowband filters. Now very
narrowband can mean a lot of taps, hence a lot of resources consumed.
Here
is where I don’t know the limitation of resources. If I want to set up a
filter of say 4 Hz bandwidth for a signal at 1MHz, and if you have a lot
of
these signals at different frequencies, what would be the best way to
extract these? Maybe the way to go is to have the LO at 1MHz, so the
many
signals being looked at are +/- many hundreds of kHz. How many taps
would it
require to extract a signal at say 300 kHz with the 4Hz bandwidth? Can
the
USRP do 200 taps for each of the 30 carriers (I am just asking without
exact
calculation here)?

Thanks,

LD

From: Marcus D. Leech [mailto:[email protected]]
Sent: Wednesday, May 08, 2013 3:39 PM
To: LD Zhang
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] How many multiple/simultaneous PLLs can
I
have running on USRP2?

I guess there may be an issue that since different PLLs will lock up at
different time, so there are unknown amount of initial phase offsets for
each PLLs. Would love to know if there are any ways around that.

LD

Well, presumably, you’d be using a PFB filterbank or something to create
the
multiple streams, and then use PLL demodulators to extract bits from
those. The PFB filterbank should have uniform group delay across all
streams, as far as I know.

Hi John,

You can do a single FPGA Polyphase filter quite easily on a PicoSDR,
using Xilinx System Generator FIR Compiler and control your FPGA design
from GNU Radio:

http://nutaq.com/en/blog/using-nutaqs-mbdk-gnu-radio-–-part-2-implementing-polyphase-channelizer

Regards,

~Tristan

De : discuss-gnuradio-bounces+tristan.martin=removed_email_address@domain.invalid
[mailto:discuss-gnuradio-bounces+tristan.martin=removed_email_address@domain.invalid] De la
part de John W.
Envoy : 11 avril 2014 09:22
: Marcus D. Leech
Cc : [email protected]
Objet : Re: [Discuss-gnuradio] How many multiple/simultaneous PLLs can I
have running on USRP2?

Sorry to dig up an old thread, but does anyone know of anyone who’s
implemented a polyphase filter bank on a USRP FPGA?

John

On Thu, May 9, 2013 at 12:02 AM, Marcus D. Leech [email protected]
wrote:

Or am I wrong that the resource is in the computer and not in the
USRP?

LD

It’s all in the computer, unless you do an FPGA-based implementation.
Gnu Radio blocks run on the host machine, not the USRP hardware.

I admit to being a little bit surprised that you don’t know that
already, given how long you’ve been posting things to this list,
and using USRP hardware.


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium