[USRP-users] Unexpected sample drift with X300 and X310
Kai-Uwe Storek
kaiuwe.storek at googlemail.com
Sat Oct 21 19:19:10 EDT 2017
Hey Marcus,
thanks for the fast reply!
1) I've no Us or something else - everything is fine.
2) Your suggestion (vector source with one period of my sequence) is
exactly what I'm doing in my project (where I noticed the problem).
The sine source was just to create a simple example graph for the
mail-list to isolate the problem.
3) I'dont think it has something to do with an oscillator drift (as
you already mentioned: Rx and Tx are using the same LO synth) because:
As soon as I disable or bypass the multiplication block (mult const)
on Tx side of my example graph, everything is fine - even with X300
and X310. Just by adding a multiplication operation while generating
the Tx signal causes the drift I observed.
If you look into the graph: I just added a zero (multiplicated with 0
before) to my sine signal - this should not have any influence in my
opinion, but actually it made the difference.
Best regards,
Kai
2017-10-22 0:48 GMT+02:00 Marcus Müller via USRP-users
<usrp-users at lists.ettus.com>:
> 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
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
--
Kai-Uwe Storek
Privatsphäre auch bei eMails? eMail-Verschlüsselung leicht gemacht:
Thunderbird: http://www.thunderbird-mail.de/wiki/Enigmail_OpenPGP
Outlook:https://code.google.com/p/outlook-privacy-plugin/
Outlook (kostenpflichtig): http://www.gpg4o.de/en/product/productinfo-gpg4o.html
Mein Schlüssel: http://goo.gl/QGVvsw
More information about the USRP-users
mailing list