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

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
>

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio