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

[Jason Uher]

On Wed, Apr 28, 2010 at 12:30 AM, marcin_w <address@hidden> wrote:
> 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
>

Ah, generated code would explain a lot.

The code has no glaring errors that I can see, but if you suspect that
it's the channel, what happens if you simply remove it? or replace it
with a simulated one?

I like the 'outside in' approach when developing gnuradio graphs,
especially for learning the system.  For DQPSK I would start with just
my vector source/sink pair and make sure the extraneous fluff worked,
then add in the chunks-to-symbols and test, and so on.  It takes about
20 minutes for simple graphs and you can debug single problems as they
arise rather than all of them at once (O(n) vs O(n^2)).

You can remove the USRP/channel from the equation as long as your
samples per symbol line up for the transmitter and receiver you'll be
fine, then you'll know.

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

Interesting, what happens if you send longer than single byte vectors
(I assume you are going to want to do that eventually anyway)


Jason