[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] DQPSK bug or incorrect settings?
From: |
ikjtel |
Subject: |
Re: [Discuss-gnuradio] DQPSK bug or incorrect settings? |
Date: |
Wed, 11 Aug 2010 06:49:20 -0700 (PDT) |
> 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
- Re: [Discuss-gnuradio] DQPSK bug or incorrect settings?,
ikjtel <=