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

[Tom Rondeau]

On Wed, Aug 11, 2010 at 9:49 AM, ikjtel <address@hidden> wrote:
>> 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.

Remember your Nyquist (at least with uniform sampling and dense signal
space): you only need twice the sample rate as the bandwidth to fully
represent the signal. If you are using more than 2 samples per symbol,
you are oversampling. That is, you are wasting your radio's time and
power processing more samples than is required. The computational
burden of a signal processing algorithm is pretty much proportional to
the sample rate, so you always want to get to the lowest sample rate
required as quickly as possible.


>> 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.


Sure, you bring the signal in at 10 sps. When working with the
USRP(2)s, we do something similar. The USRP2 samples at 100 Msps, but
we really don't need all of those samples for most signals we are
working with. So we first as the USRP2 to decimate down to something
as small as possible while still representing the signal. Then, we
usually go through stages of decimation as we are processing the
signal to continually reduce the number of samples per symbol (and
therefore the sample rate).


> 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

I have no objections to having the Gardner loop in GNU Radio as a
matter of course; I think it's good to have many different algorithms
available. However, we have actually moved past the analog-based clock
recovery schemes. If you look at the super-secret new D(B/Q)PSK
receiver code, we have implemented the use of a polyphase filterbank
clock recovery system (called gr_pfb_clock_recovery_cc or _ff) that
works much better (it's super-secret because it's called dbpsk2.py or
dqpsk2.py and you have to use all of the examples with a 2 suffix to
access them; they will replace the current implementation soon
enough).

Tom