Re: [Discuss-gnuradio] QPSK demodulation problem

[bkakedjo]

Do we have a QPSK (not a DQPSK)Demodulator available and operational in
gnuradio???


> 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
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>