On Wed, Apr 28, 2010 at 12:30 AM, marcin_w <mwie9...@uni.sydney.edu.au> 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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio