Re: [Discuss-gnuradio] Demodulation of Intermittent QAM Signal

[Ernest Fardin]

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 <address@hidden> wrote:

 

----- Original Message -----

From:

"Kyeong Su Shin" <address@hidden>

To:

"Ernest Fardin" <address@hidden>

Cc:

"GNURadio Discussion List" <address@hidden>

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 <address@hidden> 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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio