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 Rondeau wrote:
> On Mon, Jun 18, 2012 at 11:31 PM, Nazmul Islam
> wrote:
> > 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
> > (
> http://lists.gnu.org/archive/html/discuss-gnuradio/2011-11/msg00080.html).
> > Can this strange phenomenon have 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.
>
> >
> > 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.
>
> 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.
>
> > 3. 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
>
>
> > Suggestion on any of the questions will be appreciated. Thanks a lot for
> > reading my long email :S
> >
> > Nazmul
>
--
Muhammad Nazmul Islam
Graduate Student
Elec