I noticed that the generic_mod_demod.py script in gr-digital uses a
root-raised cosine filter taps and the polyphase filterbank arbitrary
resampler block. I want to resample so that I can exactly hit a
supported USRP transmit sample rate. What kind of issues will I
encounter trying to do this? My understanding is that the USRP can only
sample at integer divisions of the DSP rate (100MSPS for N200/210)., and
that if a requested sample rate doesn’t hit a supported rate exactly, it
picks the nearest faster one. Is this correct?
On Wed, Feb 29, 2012 at 10:33 AM, Nowlan, Sean [email protected]wrote:
Thanks,****
Sean
The benchmark scripts take care of this, if I understand your question.
We
try to set the sample rate through the UHD interface, then ask for the
actual sample rate it set. This is done in benchmark_tx where we use
this
info to set the actual samples per symbol (a real number) based on the
the
difference between the asked for and actual sample rate. It’s this
number
that is then used in the generic_mod_demod code to set the sample rate
in
the pfb_arb_resampler to match the sample rates.
That makes sense, but what about in a case like MSK? It looks like the
GMSK example in gr-digital requires an integer for samples_per_symbol
due to the Gaussian pre-filter. In that case, aren’t possible data rates
limited to those that will result in a USRP sample rate that is
supported exactly?
(Also, is my understanding correct about what the possible USRP rates
are? Must be an integer division of DSP clock rate?)
On Wed, Feb 29, 2012 at 10:33 AM, Nowlan, Sean
<[email protected]mailto:[email protected]> wrote:
I noticed that the generic_mod_demod.py script in gr-digital uses a
root-raised cosine filter taps and the polyphase filterbank arbitrary
resampler block. I want to resample so that I can exactly hit a
supported USRP transmit sample rate. What kind of issues will I
encounter trying to do this? My understanding is that the USRP can only
sample at integer divisions of the DSP rate (100MSPS for N200/210)., and
that if a requested sample rate doesn’t hit a supported rate exactly, it
picks the nearest faster one. Is this correct?
Thanks,
Sean
The benchmark scripts take care of this, if I understand your question.
We try to set the sample rate through the UHD interface, then ask for
the actual sample rate it set. This is done in benchmark_tx where we use
this info to set the actual samples per symbol (a real number) based on
the the difference between the asked for and actual sample rate. It’s
this number that is then used in the generic_mod_demod code to set the
sample rate in the pfb_arb_resampler to match the sample rates.
On Thu, Mar 1, 2012 at 10:23 AM, Nowlan, Sean [email protected]wrote:
Thanks,****
Sean
I tried to do the same with the GMSK, but I screwed up the filter
definition and it didn’t work at all. So I went back to the old way
because
at the time, I didn’t have time to make it work correctly.
And yes, you are correct about the rates of the USRP with the UHD. I
don’t
know the current setup with the UHD implementation, but there used to be
restrictions on the filters that were used based on using different
decimations/interpolations.