On Wed, Jun 17, 2015 at 2:14 PM, Murphy, John <jmur...@comsonics.com> wrote:
> I uploaded a pair of images to show. > http://imgur.com/a/qAtEX#1 > This is with an Epsilon of 1-1e-7. > The signal droops at the edges as shown in the images then returns to > normal, cyclically, at a rate that depends on the offset of Epsilon > from unity. > With these settings the cyclical rate is about 30 seconds, keeping in > mind I have this throttled down to 320k fsamp without changing the > displays (to work on this I bypassed the radio link temporarily - it > does the same thing when used thru the radio although in that case it > is probably easier just to vernier the sample rate on one end). > > John Murphy > jmur...@comsonics.com Yep, that's the expected behavior of that fractional_resampler block. One thing to do to see this easily is just connect a noise source -> fractional_resampler -> freq_sink (and turn on averaging in the freq display) and that shows you the filter shape, which is about 20 dB lower at the edges with a fairly slow roll-off. Instead of the fractional_resampler with an interpolation ratio of r, plug in a pfb_arb_resampler (in Python use the filter.pfb.arb_resampler) with a ratio of 1.0/r. This one builds a better half-band filter to reduce those edge effects. If that's still not good enough for you, you can design your own filter for the Taps parameter to control that better. Tom > On Wed, Jun 17, 2015 at 1:06 PM, Tom Rondeau <t...@trondeau.com> wrote: > > On Wed, Jun 17, 2015 at 12:56 PM, Murphy, John <jmur...@comsonics.com> > > wrote: > >> > >> Any signal must be correct just because it is different? > >> I am talking about pretty severe amplitude effects (several 10's of dB > >> droop, accompanied by phase shift beyond what the timing error does) > >> near the band edges. > >> I don't think I should expect that from timing change. If I connected > >> another radio and ran it at a small delta sample rate, it would not > >> lok like that. > >> > >> > >> John Murphy > >> jmur...@comsonics.com > > > > > > > > Timing change is done by adding or removing samples, which is a form of > > resampling. All resamplers must also be filters to handle the signal > changes > > correctly. What you're seeing here is the effect of the filter in the > > fractional_resampler. > > > > How much are you off by 1? It doesn't need to be that much. Remember that > > normally our clocks are accurate to within parts per million. > > > > Also, any signal you have, you really need to make sure that the receiver > > can handle this kind of thing. And you should always be suspect of the > band > > edges since most hardware will likely distort that as well to some > degree. > > > > Tom > > > > > > > >> > >> On Wed, Jun 17, 2015 at 12:29 PM, <mle...@ripnet.com> wrote: > >> > Shouldn't this be an expected effect? > >> > > >> > if signal.isactuallysampledat() != signal.thewaywepretenditssampled() > >> > > >> > Then should you expect phase and frequency effects? > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > On 2015-06-17 11:59, Murphy, John wrote: > >> > > >> > Questions about the Channel Model block from > gr::channels::channel_model > >> > > >> > Noiose Voltage and Frequency Offset work as expected. > >> > I've been using a Seed of 0 and no multipath so Taps of 1+0i. Have not > >> > seen any issue there although one does have to be careful to not use > >> > Taps of just 1 for whatever reason - you have to fully specify the > >> > complex number or weird stuff will happen. The default is 1+1j and I > >> > guess you use that and just shift stuff 45 degrees which will likely > >> > be un-noticed, I have not tried that. > >> > > >> > Anyhow, my questions relate to the Epsilon that lets you simulate > >> > sample rate error at baseband, which you can use for a controlled > >> > symbol timing error. > >> > > >> > I read the code and figured out that 1 is perfect timing. Values less > >> > than 1 will add samples (input rate over output rate equals Epsilon), > >> > which will make my sync late and I see this. Also I see the opposite > >> > for values greater than 1. That seems as expected. > >> > > >> > What I have encountered, did not expect and have some trouble with, is > >> > the way non-unity Epsilon affects the frequency response of the band > >> > edges in a time-varying fashion. With Epsilon just slightly offset > >> > from unity I can see this causing the edges of my signal to droop and > >> > then come back at a rate proportional to the offset I am using. This > >> > gets to be problematic when I have a pilot tone near the band edge > >> > which is having not only its amplitude but its phase shifted. > >> > > >> > Anyone try to use this before? Really all I need is just something to > >> > stick extra samples in (or remove them) at some rate. I suppose I > >> > could loop thru the USRP at slightly different Tx and Rx sample rates. > >> > > >> > Thanks, > >> > John > >> > > >> > _______________________________________________ > >> > 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 > > > > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
