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

[Murphy, John]

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


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
>
>