discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] DQPSK Modulation/Demodulation issue


From: marcin_w
Subject: Re: [Discuss-gnuradio] DQPSK Modulation/Demodulation issue
Date: Tue, 27 Apr 2010 22:30:03 -0700 (PDT)

Hi Jason thanks for the feedback.

Sorry about the code, it was generated mostly via Grc. I've cleaned it up,
should make much more sense now:
http://users.tpg.com.au/marcinw//qpskTest.py

I've tried using the available DQPSK blocks as you suggested, but i get the
same result. i.e with 108 as the input i get either 108, 177, 27 or 198 as
the output.

The source code for the graph using the available DQPSK block is given here:
http://users.tpg.com.au/marcinw//QPSKtest16.py

Onto the differential Encoder, i believe it is encoding my data correctly. I
have proven this by connecting a vector sink at the output of the encoder
and so with:

Input [108] = [1 2 3 0]   >> Packed2Unpacked [2, MSB] >> Binary2Gray >>
Differential Encoder >> Vector Sink

the output at the encoder is:

y[0] = (x[0] + y[-1]) % M    (where M = 4 for QPSK)

y[0] = 1
y[1] = 0
y[2] = 2
y[3] = 2

y[4] = 3
y[5] = 2
y[6] = 0
y[7] = 0

y[8] = 1
y[9] = 0
y[10] = 2
y[11] = 2

y[8] = 3
y[9] = 2
y[10] = 0
y[11] = 0

and so on....

If the system is Encoding my data correctly, i am still led to believe the
problem lies with the noisy channel?
Do you have any more suggestions?

Regards,

Marcin

p.s Your suggested input of [92d] actually produced the correct output



Jason Uher wrote:
> 
> 1) To be honest, your code is really hard to read, which is the reason
> I didn't originally reply to your question.  I started to look through
> to make sure your blocks and connections were set up correctly, but
> it's just a big mess.
> 
> 2) There is a DQPSK implementation in the gnuradio blks2 source,
> search the repository for it, there is a transmitter and a receiver.
> 
> 3) I would guess your problem has to do with incorrectly applying the
> differential coding, since you get a unique stream of symbols in each
> of your four cases:
> 108d - 1h 2h 3h 0h
> 177d - 2h 3h 0h 1h
> 27d   - 0h 1h 2h 3h
> 198d - 3h 0h 1h 2h
> 
> Notice that the difference is the same in each of these cases:
> (previous+1) % 4.  This comes from the phase ambiguities in the costas
> loop, it locks on to wherever.  That's why the differential coding is
> used.  You can confirm this by sending something that's not an even
> distribution of symbols.  For example, send: 92d - (1h 1h 3h 0h) = (+1
> +0 +2 +1) and I bet you'll get back four different values just like
> you do now:
> (1h 1h 3h 0h) = (+x +0 +2 +1)
> (2h 2h 0h 1h) = (+x +0 +2 +1)
> (3h 3h 1h 2h) = (+x +0 +2 +1)
> (0h 0h 2h 3h) = (+x +0 +2 +1)
> 
> 
> Jason
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

-- 
View this message in context: 
http://old.nabble.com/DQPSK-Modulation-Demodulation-issue-tp28288015p28384967.html
Sent from the GnuRadio mailing list archive at Nabble.com.





reply via email to

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