Re: [Discuss-gnuradio] symbol_sync_cc stuck when error too large (resulting d_avg_period goes negative)

[Andy Walls]

Hello:

> Date:         Mon, 7 Jan 2019 20:24:57 +0800
> Bug
> 
> When input amplitude is too large, symbol_sync_cc get stuck.
> Screenshot
> 
> frame1
> frame2
> Tracing
> 
>     in file symbol_sync_cc_impl.cc line 537:
>       error = -488.4;
>       advance_loop(error);
>     in file clock_tracking_loop.cc line 128 function advance_loop(float 
> error) :
>       before: d_avg_period=10.771521, d_beta=0.0090558, error=-488.4;
>       d_avg_period = d_avg_period + d_beta * error;
>       after: d_avg_period = -0.417
>       out of range [d_min_avg_period, d_max_avg_period]
>     back to file symbol_sync_cc_impl.cc line 540:
>       d_clock->phase_wrap();
>     in file clock_tracking_loop.cc line 145 function phase_wrap()
> 
> phase = -87.227, limit=-0.417/2=-0.20895, now we stuck in these while
> loops;

Thank you! for the detailed tracing of the problem you encountered.

Please report the bug on the github.com/gnuradio Issue tracker:

https://github.com/gnuradio/gnuradio/issues

So this is certainly a problem with the block: it should never hang
even if used improperly.

However, given the large error sample value of -488.4, it looks like
you are not properly conditioning your input sample stream to the
block.

For best results with the symbol_sync_cc block, please ensure:

1. You have a filter block acting as a channel filter or IF filter,
filtering noise from the input signal

2. You use an Automatic Gain Control block to control the amplitude of
the input signal to a consistent value.  Your input amplitude should be
what the derivation of the particular Timing Error Detector (TED) in
use is expecting.  For Decision Directed TEDs, the input amplitudes
should match what the slicer constellation is expecting.  For the
signal*slope ML approximation TED, the input amplitude should be
significantly less than 1.0.  For the signum*slope TED, the amplitude
should be greater than 1.0.

3. Use a level shifter/DC removal block.  Almost all of the TED's
expect the amplitude excursions to be centered about 0.

4. You have a matched filter conditioning the input stream, either out
in front of the block, or done by the block's internal PFB
interpolation filter, to peak the symbol centers and reduce noise.  If
you have rectangular pulses and use a TED that requires a derivative,
you must use an external filter block for the matched filter.

5. That you have set the TED gain based of the slope of the TED S-Curve 
at timing offset = 0.  The TED S-Curve for you situation must be
determined from modeling and simulation of the TED with various timing
offsets in your specific Signal/Noise/ISI situation in MatLab, Octave,
Python, R, or some other mathematical simulation tool.


If you are doing all of the above and the problem is induced by AGC
amplifying up noise in between received bursts, I would like to know.


> ps: i think period should be d_avg_period, because avg period is
> estimated symbol period. when loop bandwidth relatively larger (
> 0.05~0.25 ), limiting d_inst_period can make tracking error larger,
> even loop unlock. i'll benchmark both later.
> Workaround
> 
> apply limit to d_avg_period immediately after d_avg_period changed

It is a potential change to make when fixing the block.

I pondered this choice when I initially wrote the block.  Back then I
decided to let the out of limits d_avg_period be applied to the
feedback, thinking that the excursion could never be so large as to
cause a problem, and that it might speed lock-in.  I never imagined the
error signal being so large with proper conditioning of the input and
setting of the TED gain.

Regards,
Andy

>     in file clock_tracking_loop.cc line 127
> 
> Ultimate solution
> 
>     check every input, state and output in range when calculate
> control loop
> 
>