Thanks you Tom and Marcus. Yes, well... I meant that I've also checked FFT but a picture of it was in another PC so I couldn't attach it when I was writing the previous post. Sorry about that. And I am currently using N210.
Today, carrying on from the yesterday, I've replaced a square wave signal source block with either a random source with a range of [0, 2) block or a custom source block from my module and made In the figure above, I've marked a timing difference between them with arrows. Although I adjust a timing difference between them, a waveform after the resampler seems ugly. Yesterday, a waveform was quite acceptable since it's not a (pseudo-)random signal, but an alternating square wave. In this situation, a decision maker may make a false decision, I think. But it can be different if I connect USRP at the end of the flow graph. So I'll try both of them with various parameters, see the results/differences and post something if I make some progress. Regards, Jeon. 2015-07-24 23:00 GMT+09:00 Marcus Müller <marcus.muel...@ettus.com>: > 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)) > [image: 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 > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
