discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Sampling rate mismatch and rational resampler vs


From: Marcus Müller
Subject: Re: [Discuss-gnuradio] Sampling rate mismatch and rational resampler vs Repeat
Date: Fri, 24 Jul 2015 16:00:09 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]