[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] debugging uhd_corr_and_sync example

From: Achilleas Anastasopoulos
Subject: Re: [Discuss-gnuradio] debugging uhd_corr_and_sync example
Date: Wed, 10 Jul 2019 21:17:06 -0400

Thanks Andy.

Indeed the "symbol_sync" block is very robust and recovers immediately.
Everything seems to be working now.


On Wed, Jul 10, 2019 at 9:45 AM Andy Walls <address@hidden> wrote:
Hi Achilleas:

> From:         Achilleas Anastasopoulos
> Date:         Wed, 10 Jul 2019 08:45:03 -0400
> Hi Ernest,
> Although this explains why the system breaks when the noise becomes
> large (~10dB) and so the overall signal amplitude increases beyond
> (~1), it cannot explain why the system does not recover AFTER
> all amplitudes are set back to normal values (~1) and noise back to
> -30dB ...
> It was my impression that the polyphase sync block will completely
> reset once it sees a tag from the correlate and sync block, but this
> does not seem to be the actual behavior...

It does not, unfortunately.

The nominal symbol clock period, which is stored in the integral branch
of the loop filter internal to the pfb_clock_sync block, is not reset
upon receipt of a "time_est" tag.

If processing the noise pulled the nominal clock symbol period estimate
way off from the actual symbol clock period, the pfb_clock_sync block
could take a long time to recover depending on the damping factor and
loop bandwidth you provided.  The pfb_clock_sync block (errantly)
defaults to extremely overdamped, BTW.

The new symbol_sync block does reset it's nominal symbol clock period
estimate on receipt of a "time_est" (or "clock_est") tag, but can be
configured to act like the pfb_clock_sync block in other respects.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]