# Getting strange outputs from FLL\_Band\_Edge block **URL:** \ **Category:** GNU Radio\ **Created:** [June 19, 2012, 5:33am UTC](https://www.ruby-forum.com/t/getting-strange-outputs-from-fll-band-edge-block/220741 "2012-06-19T05:33:04Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![aris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/258eb7/32.png) [@aris](https://www.ruby-forum.com/u/aris)\ **Post date:** [June 19, 2012, 5:33am UTC](https://www.ruby-forum.com/t/getting-strange-outputs-from-fll-band-edge-block/220741/1 "2012-06-19T05:33:04Z")
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](http://lists.gnu.org/archive/html/discuss-gnuradio/2011-11/msg00080.html)). 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. ---
**Author:** ![Nazmul\_I](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e495f1/32.png) [@Nazmul\_I](https://www.ruby-forum.com/u/Nazmul_I)\ **Post date:** [June 21, 2012, 4:35am UTC](https://www.ruby-forum.com/t/getting-strange-outputs-from-fll-band-edge-block/220741/2 "2012-06-21T04:35:25Z")
On Mon, Jun 18, 2012 at 11:31 PM, Nazmul I. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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](http://lists.gnu.org/archive/html/discuss-gnuradio/2011-11/msg00080.html)). > 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 ---
**Author:** ![Nazmul\_I](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e495f1/32.png) [@Nazmul\_I](https://www.ruby-forum.com/u/Nazmul_I)\ **Post date:** [June 21, 2012, 4:48am UTC](https://www.ruby-forum.com/t/getting-strange-outputs-from-fll-band-edge-block/220741/3 "2012-06-21T04:48:52Z")
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. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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.