[USRP-users] Unexpected sample drift with X300 and X310

Marcus Müller marcus.mueller at ettus.com
Sat Oct 21 18:48:48 EDT 2017


Dear Kai,

to answer your explicit question first:

> I assume that the drifting effect is caused by lost or added samples
> on the Tx side.
> Are my assumptions about the expected behavior correct? 
unless you're seeing "U" on the console, no, that's not the case:
there's no lost samples.

If it wasn't for your observation regarding the multiplication:

The point would Probably™ be relative PLL drift between the RX and TX LO
generation. How fast is the drifting, i.e. can you give an estimate of
how many samples per second you shift?

I've made a very simple flow graph to demonstrate the problem,
completely without any involvement of the USRP, or any multiplication:

signal source (samp_rate = 2e6, freq = 10e3, ampl = 0.5) –> Qt GUI Time
sink (nr of samples = 1000).

Just like you, I see a drift!

Now, I monitored the amount of samples my computer pushes through this
flow graph (ca 250 million per second), and then made the estimate that
I shift by around 25 samples per second (looked like a little less);
that makes for an error of 25 "too little samples" every 250 million
samples, or 1/10 million, or 100 ppb. That's more than I expected, but ok:

If this breaks your application: I have a workaround. Simply replace the
signal source with a vector source, and put one period of your signal in
there; by using an "import block" with an value of "import numpy", and
using

numpy.exp(1j * numpy.linspace( 0, 2*numpy.pi, int(samp_rate/tone_freq),
endpoint=False) )

as the vector, you can get a perfectly periodic signal.

To explain: Sin and cos used to calculate the signal source's output
have numerical accuracy, and in this case, you see that.

This doesn't explain why you see that only in conjunction with specific
USRP models; but: something similar as to the numerical oscillator in
GNU Radio also applies to the synthesizers that generate the LO of the
TX side and the RX side; I'd expect the magnitude of that frequency
error, however, to be smaller – the error should be zero mean, and have
very bounded variance (something like the reference oscillator's phase
error variance, times the square of the ratio of reference oscillator
and RF frequency, so actually very little). Same applies to the digital
mixing within the FPGA in the USRP, by the way - these are (IIRC) 20bit
CORDICs, and I calculated the frequency quantization that this brings at
the rate they're running at (which is 200 MS/s in the X3x0), but it was
in the range of "several mHz", so that would only explain a *very* slow
drift, if any; for practically all daughterboards the TX LO and RX LO
synthesizers are the same. The digital mixing is only used to amount for
the difference between the closest element from the set of discrete
frequencies the hardware can generate and what RF frequency you
requested. Since you set the same frequency for RX and TX, these errors
should effectively cancel.

Best regards,
Marcus

On 21.10.2017 23:32, Kai-Uwe Storek via USRP-users wrote:
> Hey,
>
> the attached flowgraph simply generates a sine which is transmitted
> and received by the same USRP in a loop (30dB attenuation + coax cable
> between tx and rx port). I used the following USRPs:
>
> - B210
> - X300 (1G Eth)
> - X310 (1G Eth)
>
> On the Rx side I just added a time sink to view the complex sine.
>
> Here is my observation:
>
> If no multiplication operations are used on Tx side, one can observe a
> "time constant"  snippet (or segment) of the sine displayed by the
> time sink on Rx side - which is, imho, the expected behavior.
>
> As soon as one multiplication is part of the Tx side (just enable the
> "multiply const" block in the attached graph)  one can observe that
> the sine wave is "wandering" or drifting on Rx side.
>
> I assume that the drifting effect is caused by lost or added samples
> on the Tx side. This behavior is only present for the X300 and X310
> devices and not for the B210.
>
> Are my assumptions about the expected behavior correct? Is there any
> chance stop this drift with X3x0 devices?
>
> Background: The issue attractes attention because I'm working on a
> kind of channel estimation, where I noticed that my correlation
> sequence delivers some unexpected results as I changed from B210 to
> X300.
>
> Thanks!
> Kai
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171022/19938d59/attachment-0002.html>


More information about the USRP-users mailing list