Dear List,
We have made a test program using a source and a file sink (see fg.jpg)
where we are receiving a fixed number of samples (with UHD and USRP2 and
WBX-card) from an AWGN-generator (constant power -19dB). If we plot the
abs value of the received signal we always see a “spike” in the 10 first
samples (see fig1) before the abs value settles to a more expected
value. Sometimes (seldom) there is no “spike” but the result is still
not as expected, the received data starts at a higher level and slopes
down during a quite long time before settling to a stable level (see fig
2).
Have we missed something or why does this “spike” occur? Is there some
initialization time in the hardware that we need to take into
consideration before we start to receive samples (recv) after setting
all parameters?
Br,
Patrik
It’s likely that initialization of the board gain and frequency settings
will take some finite but non-zero amount of time to settle. It’s always
a good idea to toss the first few samples until things settle down. The
settling time will be different for each daughterboard and should be
experimentally determined in your application.
–n
On Tue, 2010-09-28 at 15:15 +0200, Patrik E. wrote:
Dear List,
We have made a test program using a source and a file sink (see fg.jpg) where we are receiving a fixed number of samples (with UHD and USRP2 and WBX-card) from an AWGN-generator (constant power -19dB). If we plot the abs value of the received signal we always see a “spike” in the 10 first samples (see fig1) before the abs value settles to a more expected value. Sometimes (seldom) there is no “spike” but the result is still not as expected, the received data starts at a higher level and slopes down during a quite long time before settling to a stable level (see fig 2).
Have we missed something or why does this “spike” occur? Is there some initialization time in the hardware that we need to take into consideration before we start to receive samples (recv) after setting all parameters?
Br,
Patrik
_______________________________________________ Discuss-gnuradio mailing list [email protected] Discuss-gnuradio Info Page
I see also some kind of transient spur the 1000-2000 first samples when
using XCVR2450 (I have mentioned this before on the list :-). Next time
I have a basic dB connected I will check if this behavior is observed
also there. I always discard the 1000-2000 samples to avoid the problem.
BR/
Per
It’s likely that initialization of the board gain and frequency settings
will take some finite but non-zero amount of time to settle. It’s always
a good idea to toss the first few samples until things settle down. The
settling time will be different for each daughterboard and should be
experimentally determined in your application.
–n
Yup, and I’d like to point out that this isn’t just a “quirk” of this
particular hardware. All such hardware takes a finite amount of time
to “settle” – the synthesizers often take a handful of milliseconds
to settle to their final value, and even VGA settings take finite time.
The A/D has no way of knowing what that time is, so it starts sending
samples right away–those samples will contain “artifacts” of
whatever settling has to take place. Fact of life.
I don’t know how the filters in the FPGA are coded, but it also wouldn’t
surprise me if they take some finite amount of time to converge
on correct output, since they’ll have some indeterminate startup
state.
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
On Tue, 2010-09-28 at 13:34 -0400, Marcus D. Leech wrote:
Yup, and I’d like to point out that this isn’t just a “quirk” of this
on correct output, since they’ll have some indeterminate startup state.
My experience is that it doesn’t matter how long I wait after setting
the gain and frequency.
It could be FPGA filters.
BR/
Per
Thanks for all your replies!
We did some additional experiments where we divided our program into 2
phases.
In phase 1 we did all the initialization like setting rx rate, center
frequency, gain, synchronizing to ref clock, and finally issued a stream
command to receive samples. The received samples are then thrown away as
you suggested.
In phase 2 all the settings are already set so we issue a new stream
command to receive new samples. If we look at the abs value of these
samples we still have the same “spike” in the beginning of the collected
set.
Our conclusion is that the stream command somehow introduce this “spike”
so we always need to receive more samples with the stream command and
throw away the beginning of the collected set. We also tried different
stream modes (STREAM_MODE_NUM_SAMPS_AND_DONE or
STREAM_MODE_NUM_SAMPS_AND_MORE) but with the same result.
Regards