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…
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).
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).
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
That wasn’t the point - the specific question concerned the required
amount of occupied spectral “bandwidth on the air”, which isn’t affected
by SPS.
filterbank
clock recovery system (called gr_pfb_clock_recovery_cc or
_ff) that
works much better
Probably because I didn’t spend sufficient time monkeying with that, it
didn’t work for me, at least as compared to the Gardner. Until I’ve
eliminated the newbi-ness factor w.r.t. that code, I can’t give any
authoritative complaints about it yet… :-\
Max
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.