Re: [Discuss-gnuradio] DQPSK bug or incorrect settings?

[ikjtel]

> In a word, NEVER. No self respecting communication systems designer would 
> allow 
> that much excess bandwidth on the air or any realistic transmission medium.

To me this doesn't make sense.  The spectral bandwidth required is never a 
function of the
samples per symbol (SPS); it's a function of the symbol rate (usually there are 
pulse 
shaping/filtering considerations too, but these are likewise unrelated to the 
SPS).

Whether SPS equals two or ten, it comes out [of the LPF] the same.  Of course 
the host bus 
bandwidth *might* be impacted, but that's a different question.

> Typically 2-3 samples per baud is more than enough. You then use a polyphase 
> filter bank 
> based clock recovery tool to FIND the correct upsampled phase (at SAY, 6-10 
> samples per baud) 
> but you never operate the demodulator at that much oversampling.

In the op25-dev project we deal with signals with a 4800 baud rate and with 
soundcards for which
48,000 is the most common standard rate.  This suggests a natural value for SPS 
(i.e., ten) and 
that value has always worked very well for us.

This includes my modified version of gr_mpsk_receiver_cc() - the two main mods 
that come to mind:
 - A simplified Gardner loop is used (in place of the M&M loop)
 - There's a special hack to the Costas loop that's needed to lock to PI/4 DQPSK

I've been highly impressed with the error performance of the Gardner loop 
relative to the M&M loop.
If there's interest, I'll publish a tgz of the code as it stands today - or 
(shameless plug)
folks are encouraged to join the op25 project and help out.....

Best Regards

Max