Re: [Discuss-gnuradio] Channel Model block - Epsilon effect on band edges

[Tom Rondeau]

On Wed, Jun 17, 2015 at 2:14 PM, Murphy, John <address@hidden> 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
address@hidden

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 <address@hidden> wrote:
> On Wed, Jun 17, 2015 at 12:56 PM, Murphy, John <address@hidden>
> 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
>> address@hidden
>
>
>
> 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,  <address@hidden> 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
>> > address@hidden
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>