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

[marcin_w]

Jason Uher wrote:
> 
> 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?
> 

Yes, the graph works perfectly when i remove the channel/usrp.

i.e.

   TX
   Vector Source [180] > Packed To Unpacked > Mapper [Binary 2 Gray] >
Differential Encoder >
   Chunks to Symbols

   RX
   Differential Phasor > Constellation Decoder > Mapper [Gray 2 Binary] >
Unpacked To Packed > Vector Sink

No problems here, my output is always 108.

Getting back to the USRP model, i can't seen to work out whether my
bitrates/sample rates are correct. 
For instance, the interpolation of my USRP sink is set to 500, meaning it
should be accepting samples at a rate of of 256ks/s.

I've had a look at pick_bitrate.py in the examples, but here are a few more
questions:

1) Do my sample rates  / interpolation / decimation look correct, according
to: 
http://users.tpg.com.au/marcinw//qpskTest.py

2) Do i need to use the throttle block in my graph to control the bit rates?
, or does simply setting the interpolation on the usrp automatically control
this?

3) Would setting the interpolation of the usrp to 500, automatically set the
bit rate to 128kb/s if my graph looks like this:

Vector Source [180] > Packed To Unpacked > Mapper [Binary 2 Gray] >
Differential Encoder >
Chunks to Symbols > Interpolating FIR Filter (RRC) [samples/symbol = 2 ,
interpolation = 2 ] > USRP sink [ interp: 500]

4) Why do we even bother using an interpolating filter in the modulator
block. Why not just a RRC filter?

5) For the demodulator block, why is the decimation level on the decimating
FIR filter set to 1 and not to 2.

Regards,

Marcin

Jason Uher wrote:
> 
> Ah, generated code would explain a lot.
> 
> 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
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

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