Re: [Discuss-gnuradio] pfb_clock_sync fails with high signal amplitudes

[Andy Walls]

Hi Milos,

Please keep the discussion on list.

On Mon, 2018-03-12 at 18:06 +0000, Milos Milosavljevic wrote:
> Thank you Andy. Much appreciated the comments.
> 
> I checked the AGC. It is not that. Even if I bypass the AGC and
> manually change the gain on my signal it obviously crashes when the
> amplitude goes high. The high amplitude spikes I am talking about are
> not something I produce. They are more interference like that I cant
> control. It looks like that spikes in the signal just kind of lock
> the pfb and it wont return to its normal operation when the signal
> drops in amplitude. I suspect that with AGC control loop it takes
> time to adjust causing the pfb to go into this state. So now I am not
> surprised the there might be momentary signal spikes from the AGC. 

[snip]

> Do you know why the pfb has assumptions for the signal of [-1,1]?

The timing error detector in use is a small signal approximation of 

   e(kT) = tanh( 2E/No * y(kT) ) * y'(kT)

See equation (5) of this paper:

https://pdfs.semanticscholar.org/3077/d85fc72d89c72c4c6d11f1014c5175e319c3.pdf

and the paragraph just before equation (6).


Or see the derivation leading up to equation (3.31) in this paper:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.46.2884&rep=rep1&type=pdf

and also look at the discussion around equations (3.32) and (3.33).

For large signals, tanh(x) ~= sgn(x).
For small signals, tanh(x) ~= x.

The PFB clock sync TED, uses the small signal approximation; hence the
input amplitude must be small.


>  Do you by any chance have any ideas how I can circumvent this
> problem?

Well the problem is you're violating the assumption made in the
derivation for the TED to work as expected.  Don't violate the
assumption, and you won't have the problem. :)

Or use a different TED, such as the large signal ML approximation TED,
which is one of the options provided in the new symbol sync blocks on
the GNUradio master branch.

Please see the second half of this brief on the proper use of all these
PLL-based synchronizer blocks.

https://www.gnuradio.org/wp-content/uploads/2017/12/Andy-Walls-Samples-to-Digital-Symbols.pdf


> I am confident going into the code and modifying the pfb but dont
> really know where to start. 

Any meaningful bug the PFB clock sync block had was fixed in the new
symbol synch blocks (which are a superset of all the existing symbol
sync blocks).


If you must use the existing pfb_clock_sync block, the first two things
you need to do are:

1. Limit the input into the pfb_clock_sync block to +/-1.0 in
amplitude, using a smarter AGC block and/or rail blocks.

2. Prevent NaNs from flowing to the input of the pfb_clock_sync block,
if that has happened in any of your experiments/tests.

Regards,
Andy

> Many thanks. 
> Milos
> 
> 
> On 12 March 2018 at 13:19, Andy Walls <address@hidden>
> wrote:
> > > From:         Milos Milosavljevic
> > > Date:         Sun, 11 Mar 2018 14:36:19 +0000
> > > Dear All,
> > >
> > > I am using the pfb_clock_sync to estimate the timing offset in my
> > > QPSK receiver and I have a problem that I would like to ask
> > about.
> > >
> > > Basically if the amplitude of the incoming signal is set
> > relatively
> > > high (havent checked what actual threshold is) the flowgraph just
> > > hangs. After the process of elimination I discovered that it is
> > > actually the pfb_clock_sync block that causes this. Then I put
> > some
> > > printf statements in the code and found out that the d_k (phase)
> > > value becomes -NaN when signal amplitude becomes high. The same
> > thing
> > > is with the d_error from here d_error = (error_i + error_r) /
> > 2.0.
> > >
> > > I suspect it is due to some filtering (either the RC or diff
> > filter).
> > >
> > > Do you have any suggestions on where this might be coming from?
> > >
> > > Any comments will be highly appreciated.
> > 
> > This sounds like the pfb_clock_sync block is getting a NaN passed
> > in on
> > the input stream:
> > 
> >         input is NaN => filtered input is NaN => d_error is NaN =>
> > d_k is NaN .
> > 
> > Look at your upstream AGC blocks and division blocks as likely
> > culprits
> > for generating NaNs, since you say "the amplitude of the incoming
> > signal is set relatively high".
> > 
> > 
> > BTW, the small signal, low SNR, Maximum Likelyhood approximation,
> > Timing Error Detector (TED) used in the pfb_clock_sync block has a
> > built in assumption that the input amplitude should be noticeably
> > smaller than +/-1.0 .  Also, for consistent results, you always
> > want to
> > go into a clock sync block with a controlled signal amplitude.
> > 
> > Regards,
> > Andy
> > 
> > 
> > 
> > 
> > 
> > >
> > > Many thanks,
> > >
> > > Kind Regards
> > > Milos
> 
> 
>