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