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
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:
Anyhow, my questions relate to the Epsilon that lets you simulate
edges in a time-varying fashion. With Epsilon just slightly offset
John
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page [1]
Links:
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 M.
[email protected]
On Wed, Jun 17, 2015 at 12:56 PM, Murphy, John [email protected]
wrote:
[email protected]
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 2:14 PM, Murphy, John [email protected]
wrote:
is probably easier just to vernier the sample rate on one end).
John M.
[email protected]
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 further thought, not all resamplers need filters. In fact this may
be about the ideal case where a resampler does not need a filter.
If you are resampling a signal that does extend fully to the band
edge, and your resample ratio is close enough to unity to avoid
aliasing at the target new rate, do you still need to filter?
And with a Epsilon on the order of 1+/-1e-7 or so the change in
bandwidth from sample rate change is so small you can not even see it
on a spectrum with human vision.
Am I outside the box or up the creek without a paddle?
John M.
[email protected]
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 M.
[email protected]
eh, nevermind, hit send too quickly on a long day (decimators are
probably a special case, but rational resamplers when they interpolate
are going to generate aliases that fold back in band when decimated,
so yeah never mind)
John M.
[email protected]