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 <[email protected]> wrote: > On Mon, Jun 18, 2012 at 11:31 PM, Nazmul Islam > <[email protected]> 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 Electrical & Computer Engineering Wireless Information & Networking Laboratory Rutgers, USA.
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
