[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] QPSK demodulation problem

From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] QPSK demodulation problem
Date: Mon, 28 Apr 2008 18:20:58 +0100
User-agent: Thunderbird (Windows/20080213)

Ahmet Hasim Gokceoglu wrote:

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.

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>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]