Re: [Discuss-gnuradio] QPSK demodulation problem

[Tom Rondeau]

Ahmet Hasim Gokceoglu wrote:
> hi,
>
> I am trying to implement a QPSK receiver with GNU radio using the
> board RFX2400 where I take the input from signal generator. The symbol
> rate  of signal generator is 1Msym/sec sending a constant pattern of
> "0010" and i have set the decimation in USRP to 16 to have 4 samples
> per symbol. I suppose that I have done the calculation correct since
> the ADC rate is 64 Msa/sec.
>   

Ahmet,
I'm not sure I understand how you are generating your input signal. What 
signal generator? Is this an external sig gen, or are you somehow 
generating the signal with GNU Radio?

Also, are you using the dqpsk.py for the DQPSK mod/demod functions? I 
wasn't sure if you were building your own QPSK receiver.

> Since i am not very familiar with the parameters of frequency and
> timing synchronization blocks i have just used the default ones:
> costas_alpha=0.15 mu=0.05 omega_re_limit=0.5
>   

These defaults were set because they worked with the implementation or 
the receiver. They should be fine.

> When I look at the demodulated bit stream by reading the file
> "rx_unpack.dat" (which should supposedly be showing the demodulated
> bits)  what I get is arbitrary 0's and 1's which has nothing to do
> with the pattern "0010" that I am sending. Does anybody have any idea
> where might be the problem?
>   

Again, it will depend on how you are generating the input symbols. If 
you are using the packet modulator code we have in 
/digital/benchmark_tx.py, the packets transmitted are first whitened. 
The file rx_unpack.dat is captured before the signal is dewhitened. You 
can turn whitening off by looking at 
gnuradio-core/src/python/gnuradio/packet_utils.py in the "unmake_packet" 
function for how.

If you are not using the benchmark_tx to generator your symbols and are 
sending over the "0010" bit stream, what you are doing is sending over a 
very specific pattern (0 degree shift followed by a 90 degree shift) 
that will bias the recovery loops. Try sending a longer more random 
sequence.

> Secondly I am recording the data before and after the frequency/time
> synchronization block so that I can plot the constellation points
> before and after the synchronization. I suppose that the recorded data
> is in the format [I Q] so for example when I read [32 64 128 196] then
> 32 is the decimal equivalent of the first 8 bits of I and 64 is the
> decimal equivalent of last 8 bits. Sİmilarly 128 is the first 8bits of
> Q and 196 is the last 8.  Can anyone validate this ? and how about the
> sign, how is it determined?
>   

If you're using file_sink(gr.sizeof_float, "file.dat"), the output is 
32-bit float for the I and 32-bit float for the Q. It's standard IEEE 
754 or whatever style.

You can use the Python/Matplotlib tools we have in gr-utils/src/python 
for plotting these files. They are installed into your system now 
(/usr/local/bin unless you changed the prefix) and called gr_plot_*. You 
can look at the constellation with gr_plot_const.py <filename>

Tom