|
From: | devin kelly |
Subject: | Re: [Discuss-gnuradio] PFB Clock Sync stops producing samples |
Date: | Thu, 8 Jun 2017 15:41:38 -0400 |
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
>
[Prev in Thread] | Current Thread | [Next in Thread] |