Hi Jeon,
what USRP are you using?
You're right: The point is that only integer factor of the USRP's master
clock rate can be used.
So for example, if you're using the USRP2 or N210, the master clock rate
would be fixed at 100MHz.
That would explain the rates you're seeing. (3.703..MS/s = 100MHz/27,
7.692...MS/s = 100MHz/13, 14.2857 = 100MHz/7)
What I concern is, will such differences between given sampling rate
and tuned sampling rate make a big difference on a waveform,
throughput and performance? I don't think it would make a big
difference since ratio of differences are less than 5 percent.
Well, obviously: If you expect e.g. a 3.75MHz signal sampled at 15MS/s
to have a period of 4 samples, and it has a period of 3.8something
samples, you will see a frequency offset. Whether your application can
correct that is up to the design of the application.
But it would be better to know about it before I run a real experiment.
Well, frequency offset is relatively easy to model, so you might even be
able to translate that directly into error probabilities based on theory
alone.
1. 200 kHz signal -> rational resampler (interp: 15M, decim: 200k) ->
USRP (15 MHz)
2. 200 kHz signal -> rational resampler (interp: 75, decim: 1) -> USRP
(15 MHz)
3. 200 kHz signal -> repeat (interp:75) -> USRP (15 MHz)
When I run those three, first two using rational resampler blocks gave
me ugly waveforms.
These waveforms look perfectly normal to me! I can't imagine a digital
receiver that would have problems with that little overshoot at each
transition.
(Forgot to take a picutre of FFT, sorry.)
That's actually sad, because you would have noticed that the waveforms
you think look ugly actually look more beautiful in frequency domain:
(don't interpret x-Axis as Hz, but as numbers (-pi; pi))
Spectra of an interpolated and a repeated square wave
That's just basic DSP, hapening here:
All these strong red peaks outside the original signal's bandwidth
shouldn't be there -- after all, the signal you fed in had 1/75th of the
output nyquist bandwidth!
Interpolation needs an anti-imaging filter to suppress the spectral
images -- in DSP, you seldom really want to have the sharp transitions
when you interpolate something. That interpolated signal should only
occupy its original's bandwidth, usually. Hence, you filter to
b_nyquist/interpolation.
Finite filters can't have infinitely sharp passband edges, so you'll see
attenuation for the frequencies that are very close to the nyquist
frequency of the input signal. In your case, the abrupt change from 0 to
1 is exactly that, a signal with all the input bandwidth as spectrum, so
there's the highest frequency parts of that attenuated a little bit, and
you see these oscillations near the edge.
Since every physical system has low pass characteristics, you can
typically find high tolerance against this in baseband transceivers;
most of them just care about whether the signal has passed the threshold
or not. Overshoot is ignored, or even "slightly welcome" because it
antagonizes capacity-caused slowness (ie. the low pass characteristics
of the signal fits the low pass characteristics of the device).
So, long story short: this is good, and normally, you'd just go with it.
The implementation GNU Radio uses for the fractional resampler is a
minimum mean square error interpolator FIR, and unless you'd have a
specific metric that mathematically makes that a bad choice, I'd say
it's pretty optimal.
So in the cases where just using the repeat block is not an option,
you'll either need to repeat with changing factors (e.g to interpolate
by 1.5, how long should your "high" period be? 1 sample? 2 samples?
neither can be right, so you start changing that continously,
effectively altering the periodicity of your signal, making clock
recovery on the receiver side harder), or this filtering is *exactly*
what you want
Next thing is: The USRP interpolates with anti-imaging filters itself,
so you'll end up with these overshoots/oscillations, anyway (but only if
you zoom in with an oscilloscope closely enough).
Best regards,
Marcus
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
