Thanks Andy. Indeed the "symbol_sync" block is very robust and recovers immediately. Everything seems to be working now.
Achilleas On Wed, Jul 10, 2019 at 9:45 AM Andy Walls <a...@silverblocksystems.net> 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. > > Regards, > Andy > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
