Re: [Discuss-gnuradio] Problems with dvbt 8k 64QAM

[Ron Economos]

The test file adv16.cfile is only meant to work with the parameters of 
the test flow graph dvbt_rx_8k.grc. Specifically, 16QAM, 2/3 rate, 1/32 
guard interval.

The GNU Radio DVB-T receiver is very CPU resource intensive. I have an 
E5-1650 based workstation (6 cores/12 threads at 3.6 GHz) and it can 
just barely do 64QAM 2/3 rate in an 8 MHz channel.

Depending on your CPU, you may have to drop down to QPSK and/or a 
smaller channel size. To change the channel size, change the sample rate 
equation from (8000000.0 * 8) / 7 to:

(8000000.0 * 7) / 7    /* 7 MHz */

(8000000.0 * 6) / 7    /* 6 MHz */

(8000000.0 * 5) / 7    /* 5 MHz */

or as low as you need to go to make things work. Note that any overflow 
will restart the symbol acquisition, and a chunk of video will be lost 
causing glitchy playback. If there are too many overflows, the receiver 
will never lock.

Ron

On 03/14/2018 07:46 AM, Juan Antonio wrote:
> Hello, I am trying to receive a real channel of 8K 64QAM 1/4 2/3 using 
> as a base the example dvbt_rx_demo_8k and a hackrf
>
>
> If I use the adv16.cfile file as a source, the constellation hooks 
> independently of whether I put 16QAM or 64 QAM (the representation is 
> only 16 points). But  if I do use the hackrf (many 
> oooooooooooooooooooooo) or the hackrf recording using gqrx (here there 
> is no ooooooo ) I only get a central point in the output of the FFT block
> and many points moving wildly at the exit of the block 
> dtv_dvbt_demod_reference_signals_0
>
> If the signal does not engage in the constellation in my opinion it is 
> clear that everything that comes after will not be useful at all
>
> Best  Regards