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 <[email protected]>: > 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 > [email protected] > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > > _______________________________________________ > USRP-users mailing list > [email protected] > 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 _______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
