Re: [Discuss-gnuradio] QPSK demodulation problem

[Ahmet Hasim Gokceoglu]

On Mon, Apr 28, 2008 at 8:20 PM, Tom Rondeau <address@hidden> wrote:
> 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?
>
I am using an external signal generator by which I generate the bit
stream and modulate it by QPSK.
>  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.
>
>
yeah I am using dqpsk.py for demod
>
> > 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.
>
>

I was also thinking about the same thing and will try with 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.

 I have read from http://www.nd.edu/~jnl/sdr/docs/tutorials/4.pdf
that the data coming from USRP is in 16 bit I and 16 bit Q format so
why is it changed to 32 bits ?
>
>  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
>


>