Re: [Discuss-gnuradio] debugging uhd_corr_and_sync example
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 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
Re: [Discuss-gnuradio] debugging uhd_corr_and_sync example
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
Re: [Discuss-gnuradio] debugging uhd_corr_and_sync example
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... Achilleas On Wed, Jul 10, 2019 at 12:16 AM Ernest Fardin wrote: > Hi, > > I think this behaviour may be due to the level into the Polyphase Clock > Sync block. The block expects a signal amplitude of 1 as explained in [1]. > > An AGC between the Correlate and Sync and the Polyphase Clock Sync blocks > might do the trick. > > Cheers > > Ernest > > [1] https://destevez.net/2017/08/agc-for-gr-satellites/ > > > On Wed, Jul 10, 2019 at 6:22 AM Achilleas Anastasopoulos < > anas...@umich.edu> wrote: > >> Hi all, >> >> I am not very successful in running the uhd_corr_and_sync_tx/rx.grc >> example in the gr-digital examples directory (3.7.13.5) using usrps. >> >> In an effort to debug it, i merged the two graphs and eliminated the uhd >> sink/sources (see attached) and so I am running a simulation without the >> usrps. I also eliminated the FLL block as I do not have any frequency error >> and not even any noise. >> >> The behavior I see is as follows: >> >> The transmission seems fine (a nice rrc spectrum followed by silence >> periodically on and off). >> On the reception side the blocks seem to be working fine producing >> appropriate tags (one every 20Ksamples as expected) which means that the >> "correlate_and_sync" block works as expected. >> >> When I plot the output of the "polyphase_clock_sync" I expect to see >> three clear points: +/- A and 0. Indeed this is what I see at first. >> >> Now I do the following: I increase the noise for a while to a large >> number (~10dB) and then I take it back almost to 0 (-20dB). From that point >> on, although the "correlate_and_sync" block works as expected (I see the >> tag offsets back to normal) the picture does not contain three clear points >> but is blurred indicating that the "polyphase_clock_sync" does not work >> appropriately and I can never recover from this. >> >> I was hopping that since the "correlate_and_sync" block recovers and adds >> the appropriate tags to the stream, the downstream block can recover as >> well. However the behavior is not as robust as I expected. >> >> Can someone shed some light into this. >> >> thanks >> Achilleas >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] debugging uhd_corr_and_sync example
Hi, I think this behaviour may be due to the level into the Polyphase Clock Sync block. The block expects a signal amplitude of 1 as explained in [1]. An AGC between the Correlate and Sync and the Polyphase Clock Sync blocks might do the trick. Cheers Ernest [1] https://destevez.net/2017/08/agc-for-gr-satellites/ On Wed, Jul 10, 2019 at 6:22 AM Achilleas Anastasopoulos wrote: > Hi all, > > I am not very successful in running the uhd_corr_and_sync_tx/rx.grc > example in the gr-digital examples directory (3.7.13.5) using usrps. > > In an effort to debug it, i merged the two graphs and eliminated the uhd > sink/sources (see attached) and so I am running a simulation without the > usrps. I also eliminated the FLL block as I do not have any frequency error > and not even any noise. > > The behavior I see is as follows: > > The transmission seems fine (a nice rrc spectrum followed by silence > periodically on and off). > On the reception side the blocks seem to be working fine producing > appropriate tags (one every 20Ksamples as expected) which means that the > "correlate_and_sync" block works as expected. > > When I plot the output of the "polyphase_clock_sync" I expect to see three > clear points: +/- A and 0. Indeed this is what I see at first. > > Now I do the following: I increase the noise for a while to a large number > (~10dB) and then I take it back almost to 0 (-20dB). From that point on, > although the "correlate_and_sync" block works as expected (I see the tag > offsets back to normal) the picture does not contain three clear points but > is blurred indicating that the "polyphase_clock_sync" does not work > appropriately and I can never recover from this. > > I was hopping that since the "correlate_and_sync" block recovers and adds > the appropriate tags to the stream, the downstream block can recover as > well. However the behavior is not as robust as I expected. > > Can someone shed some light into this. > > thanks > Achilleas > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] debugging uhd_corr_and_sync example
Hi all, I am not very successful in running the uhd_corr_and_sync_tx/rx.grc example in the gr-digital examples directory (3.7.13.5) using usrps. In an effort to debug it, i merged the two graphs and eliminated the uhd sink/sources (see attached) and so I am running a simulation without the usrps. I also eliminated the FLL block as I do not have any frequency error and not even any noise. The behavior I see is as follows: The transmission seems fine (a nice rrc spectrum followed by silence periodically on and off). On the reception side the blocks seem to be working fine producing appropriate tags (one every 20Ksamples as expected) which means that the "correlate_and_sync" block works as expected. When I plot the output of the "polyphase_clock_sync" I expect to see three clear points: +/- A and 0. Indeed this is what I see at first. Now I do the following: I increase the noise for a while to a large number (~10dB) and then I take it back almost to 0 (-20dB). From that point on, although the "correlate_and_sync" block works as expected (I see the tag offsets back to normal) the picture does not contain three clear points but is blurred indicating that the "polyphase_clock_sync" does not work appropriately and I can never recover from this. I was hopping that since the "correlate_and_sync" block recovers and adds the appropriate tags to the stream, the downstream block can recover as well. However the behavior is not as robust as I expected. Can someone shed some light into this. thanks Achilleas uhd_corr_and_sync_tx_rx.grc Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
