Hi Jeon, > In the figure above, I've marked a timing difference between them with > arrows. that's only natural. There's filtering involved, hence you get a delay. > Although I adjust a timing difference between them, a waveform after > the resampler seems ugly. I still beg to differ :) It looks like a band-limited interpolated version of the signal below. > In this situation, a decision maker may make a false decision, I think. That really depends on the decision maker, but I can see your point. For me, this looks like BPSK, and I'd say with a very modest high pass filter, and a 0 threshold, things might look pretty OK :)
So the thing is: there's nothing stopping you to implement an N/M interpolation by repeating with N and then using a decimating FIR with a decimation factor of M; try that, it might really suit you better. Best regards, Marcus On 07/25/2015 08:12 AM, Jeon wrote: > 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 > <mailto: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)) > 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 <mailto: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
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
