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 > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
