Re: [Discuss-gnuradio] PFB Clock Sync stops producing samples

[Andy Walls]

One minor correction on the settings to use, since it appears the
PFB_clock_synch block uses a ridiculously over-damped loop filter:

https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/pfb_clock_sync_ccf_impl.cc#L82

So the revised settings guidance to get exactly what the PFB clock synch
block does is:
Damping Factor:  Use 2 times whatever you're using now for Filter Size


However, that seems silly to me.  I normally use one of:

0.707 (underdamped, but maximally flat, loop filter),
1.0 (critically damped loop filter),
1.5 (overdamped loop filter), or
2.0 (overdamped loop filter) 

for the damping factor.

-Andy

On Thu, 2017-06-08 at 14:08 -0400, Andy Walls wrote:
> For a block that performs the identical function of the PFB clock synch
> block with correct tag propagation, use the Symbol Synchronizer Block
> available in this pull request:
> 
> https://github.com/gnuradio/gnuradio/pull/1294
> https://github.com/awalls-cx18/gnuradio/tree/symbol_sync2
> 
> or this OOT module:
> 
> https://github.com/awalls-cx18/gr-nwr
> 
> Use the following settings:
> Timing Error Detector:   y[n]y'[n] Maximum Likelyhood
> Samples per Symbol:      whatever you're using now
> Loop Bandwidth:          whatever you're using now (may need tweaking)
> Damping Factor:          1.0/math.sqrt(2.0)
> Maximum Deviation:       whatever you're using now
> Output Samples/Symbol:   whatever you're using now
> Interpolating Resampler: Polyphase Filterbank, MF
> Filterbank Arms:         whatever you're using now for Filter Size
> PFB MF Taps:             whatever prototype filter taps you're using now
> 
> 
> Properly fixing the tag propagation in the PFB_clock_sync block is a
> major change, which is one reason I wrote the new Symbol Synchronizer
> blocks.
> 
> FWIW, I also do think get_tags_in_range() could stand to perform a
> sanity check, but that won't fix the underlying problem.
> 
> -Andy
> 
> 
> >                              From: 
> > devin kelly
> >                           Subject: 
> > [Discuss-gnuradio] PFB Clock Sync
> > stops producing samples
> >                              Date: 
> > Thu, 8 Jun 2017 12:08:12 -0400
> > 
> > ______________________________________________________________________
> > I'm having a problem with the Polyphase Clock Sync block.  I believe
> > what's happening is that the block is calling get_tags_in_range
> > improperly and then causing an infiite loop in
> > gnuradio-runtime/lib/buffer.cc, at this point the PFB Clock Sync block
> > stops emitting samples.
> > 
> > 
> > The problem occurs in the PFB clock sync block here:
> > https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/pfb_clock_sync_ccf_impl.cc#L473
> > 
> > 
> > The PFB block calls get_tags_in_range where the start sample number is
> > greater than then end sample number, here's the code in buffer.cc that
> > may be getting stuck in an infiite loop.
> > 
> > 
> > The entire file is here:
> > https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/lib/buffer.cc#L354
> 
> [snip]
> > When I run into this problem, my code seems to get stuck on itr++ (see
> > debugger output below).  Though I'm not sure if the itr++ call just
> > stalls or if itr just never equals itr_end.
> > 
> > 
> > When the PFB Clock Sync block stalls, I attach with GDB, find the PFB
> > thread and get a back trace, I then go to the PFB general_work frame
> > and print the two inputs to get_tags_in_range
> 
> [snip]
> 
> >I've also found (separately, using breakpoints) that sometimes count is
> >negative.  Is that the way it should be?
> 
> [snip]
> 
> 
> > I'm not sure if we're putting bad data into the PFB block or if
> > there's some bug in the PFB block.  Or should there be some checking
> > in get_tags_in_range that checks if start > end.  What's the best way
> > to proceed?
> > 
> > 
> > Thanks,
> > 
> > Devin
>