OK, I'll give that block a try. Are you saying there's a bug in the PFB Clock Sync block? That was my suspicion but I'm not sure I understand what the block is doing well enough to know with certainty.
On Thu, Jun 8, 2017 at 2:29 PM, Andy Walls <a...@silverblocksystems.net> wrote: > 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
