Getting strange outputs from FLL_Band_Edge block

GNU Radio
1

I am trying to implement a PN_correlator through gnuradio-companion
generated python codes. I am transmitting a continuous stream of
repeated
GLFSR source and I want my receiver to be synchronized (as much as
possible) with the transmitter. I have followed the generic_mod_demod.py
in
designing the transmitter and the receiver and I have used the following
paths:

Tx: GLFSR source (producing +1 & -1) → RRC → USRP Sink

Rx: USRP Source → AGC2 → FLL Band Edge → Polyphase Clock Sync →
Costas → File Sink (the receiver snapshot is attached as
PN_receiver.png).

I have the following issues:

  1. When I run the Rx without FLL, the USRP sink spits out roughly 40 MB
    data by 1 second with 10M sample rate. However, if I run the Rx with
    FLL,
    the USRP spits out much lower amount of data, e.g., 4 - 6 MB within 1
    second. I think that Josh investigated a similar issue before (
    Re: [Discuss-gnuradio] Strange behavior in digital benchmark examples).
    Can this strange phenomenon have an adverse effect in the output?

  2. *More worryingly, I am getting strange outputs from FLL. I will be a
    bit verbose in explaining its weird nature and I am sorry for that.     *I
    am
    transmitting a PN sequence with 1023 chips. The theory is simple: if I
    correlate the Rx output with the PN sequence, I should get a high peak
    after every 1023 symbols and almost zero in between.

— The “Correlation_FLL_input.png” shows the correlation between the
AGC2 output and PN sequence. At this point, I have 2 sample/symbol. The
high value (~ 400) suggests that one sample fell close to the symbol
peaks.
The medium values (~ 200) denote that the other sample fell midway
between
two symbol peaks. Fair enough.

– If I take out the FLL_Band_Edge block (i.e. AGC2 →
Polyphase_Clock)
and take correlation after Polyphase_Clock_Recovery, the output takes
the
form of “Corr_timing_recovery_without_FLL.png”. High peaks after every
1023
symbol & almost zero correlation in between, great!

– If I keep the FLL block, the correlation after FLL_Band_Edge +
Polyphase_Clk_Recovery takes the form of
“Corr_timing_recovery_with_FLL.png”. You can see that it is completely
smeared and there is no pattern at all! I took the correlation after
FLL
and found that the strange output is due to the FLL block, not timing
recovery.

Am I doing any gross mistake with the FLL_Band_Edge parameters? I
pretty
much took the parameters from generic_mod_demod.py and they are also
aligned with the RRC of the Tx side.

  1. Does GNUradio have any other FLL block that I can test?

Suggestion on any of the questions will be appreciated. Thanks a lot for
reading my long email :S

Nazmul

–
Muhammad Nazmul I.

Graduate Student
Electrical & Computer Engineering
Wireless Information & Networking Laboratory
Rutgers, USA.

2

On Mon, Jun 18, 2012 at 11:31 PM, Nazmul I.
[email protected] wrote:

I have the following issues:

  1. When I run the Rx without FLL, the USRP sink spits out roughly 40 MB data
    by 1 second with 10M sample rate. However, if I run the Rx with FLL, the
    USRP spits out much lower amount of data, e.g., 4 - 6 MB within 1 second. I
    think that Josh investigated a similar issue before
    (Re: [Discuss-gnuradio] Strange behavior in digital benchmark examples).
    Can this strangephenomenonhave an adverse effect in the output?

Quite possibly. The problem was more that it was a huge latency issue.
I can’t reliably recreate this in the digital benchmark examples,
though, so it’s really hard to debug what’s going on. There’s no
reason that I can see for it to happen.

The main issue is that the filter operation isn’t done well in this
block, and it tends to run near the front of the receiver, so it’s
performing an inefficient filter at a high sample rate. That’ll slow
things down. With the new gr-filter work just merged today, I hope we
can use that to make use of Volk to improve it.

medium values (~ 200) denote that the other sample fell midway between two
smeared and there is no pattern at all! I took the correlation after FLL and
found that the strange output is due to the FLL block, not timing recovery.

Am I doing any gross mistake with the FLL_Band_Edge parameters? I pretty
much took the parameters from generic_mod_demod.py and they are also aligned
with the RRC of the Tx side.

Not sure. In my experience, the FLL takes a bit to converge, but once
it does, it’s stable and should be fine. There seems to be something
else involved in this block that’s causing issues with latency, which
might be the cause of this problem, too.

  1. Does GNUradio have any other FLL block that I can test?

Not really. There’s the Costas loop block, but that’s fairly limited
in the frequency offset that it can correct. On the other hand, the
FLL is when you are far away in frequency. So you can a) use a
reference clock that has more accuracy to make sure the frequencies
are close or b) hand tune the receiver to be close to the transmitter.
As long as you’re close, you can correct for the offset.

Since you’re working fine without the FLL, why do you need to add it?
Sounds like you’re fine just bypassing it altogether.

Tom

3

Hello Tom,

Thanks a lot for your reply. I am currently working with two USRP N210’s
and they have a frequency offset of a few hundred Hz. That’s why, the
costas loop is taking care of it. I previously worked with two USRP2’s
which had frequency offsets around 5 kHz (with 450 MHz carrier
frequency).
The costas loop did not work there, as expected.

We are purchasing two more USRP N210 for our experiments. I am having
all
my fingers crossed that their offsets will not be much! Otherwise, I
will
need the FLL block :S

Thanks again,

Nazmul

On Wed, Jun 20, 2012 at 10:34 PM, Tom R. [email protected] wrote:

Tx: GLFSR source (producing +1 & -1) → RRC → USRP Sink
USRP spits out much lower amount of data, e.g., 4 - 6 MB within 1

transmitting a PN sequence with 1023 chips. The theory is simple: if I
two
Polyphase_Clk_Recovery takes the form of
with the RRC of the Tx side.
FLL is when you are far away in frequency. So you can a) use a
Suggestion on any of the questions will be appreciated. Thanks a lot for
reading my long email :S

Nazmul

–
Muhammad Nazmul I.

Graduate Student
Electrical & Computer Engineering
Wireless Information & Networking Laboratory
Rutgers, USA.