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

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@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

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