Thanks Kyeong, Looking into this in a bit more detail I found that the attack and decay rate settings for the AGC2 block contained within the QAM Demod hier block affect the ability of the demodulator to recover from a zero-signal condition. Reducing the attack and decay rates from their default values of of 6e-2 and 1e-3 to something like 1e-5 allows the demodulator to recover reliably.
I'm not sure why such a big change is required. Maybe it is related to the high PAR of a QAM signal, but then the block was designed for QAM in the first place. Perhaps some changes have been made to the AGC2 block since the QAM Demod block was originally implemented. Ernest On Thu, Oct 19, 2017 at 6:48 PM, E Fardin & P Le <fardi...@tpg.com.au> wrote: > > > > > ----- Original Message ----- > From: > "Kyeong Su Shin" <kss...@uw.edu> > > To: > "Ernest Fardin" <efar...@ieee.org> > Cc: > "GNURadio Discussion List" <discuss-gnuradio@gnu.org> > Sent: > Wed, 18 Oct 2017 15:11:50 -0700 > Subject: > Re: [Discuss-gnuradio] Demodulation of Intermittent QAM Signal > > > Hello Ernest Fardin: > > As you thought, synchronization loops in the PSK/QAM demod blocks may > wander off if you input noise into those blocks. > > I asked a same question before, and the answer was not to feed in any data > to the QAM demod block when you think the transmitter is not on. I did not > try this, but maybe power squelch block can do the trick. > > (Or, alternatively, maybe you can implement your own synchronization > blocks and use a demod block that does not do synchronizations. I believe > that you can use a constellation receiver block to do this.) > > Regards, > Kyeong Su Shin > > On Tue, Oct 17, 2017 at 10:46 PM, Ernest Fardin <efar...@ieee.org> wrote: > >> Hi, >> >> I have a simple QAM16 loopback (Gray code, diff encoding, 4 sps) working >> as follows: >> >> QAM Mod ---> Throttle ---> QAM Demod >> >> This works fine if I have a constant signal level from the Tx. However, >> if I add a variable gain between the Tx and Rx and drop the Tx level to >> zero, then restore the Tx signal after a short time, the demod no longer >> works. I'm guessing a control loop inside the demod has wandered off during >> the interval with no signal. Is there any way to re-initialise the demod >> block to help it find its way again? >> >> The objective is to simulate a 'bursty' link where the Tx is not >> permanently keyed. >> >> Thanks in advance! >> >> Ernest >> >> _______________________________________________ >> 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
