Hi Nate, Thank you so much, this is very useful.
I am using Gnuradio 3.7 on Windows and according to uhd_cal_rx_iq_balance.exe for example, UHD version is UHD_3.14.1.HEAD-0-g5491b80e. That should have the issue fixed, right? Would you mind to elaborate briefly how to get the "timed command"? (I am working with grc for a few weeks and I am fairly new to it) Just conceptually how to do it would be amazing or a pointer to an example that I could modify even better! For example, I went through the example at https://wiki.gnuradio.org/index.php/Guided_Tutorial_GNU_Radio_in_Python#3.1._Intro_to_Using_GNU_Radio_with_Python but I do not know if this really creates these "timed commands". Yes, I can store the frequency value in a variable but how do I ensure that it's updated exactly at a rate of say, 1/100ms? Also: Why wouldn't such an approach cause issues due to the clock differences between the host computer and the USRP? And if you are able to dig up any more information about the additional caveats you were mentioning, that would be truly amazing. Thanks a lot, Luke Gesendet: Samstag, 07. Dezember 2019 um 12:05 Uhr Von: "Nate Temple" <nate.tem...@ettus.com> An: "Lukas Haase" <lukasha...@gmx.at> Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com> Betreff: Re: [USRP-users] Phase relation between RX/TX LO Hi Luke, What version of UHD are you using? There was an issue with the DUC/DDC phase accumulator's resolution, but it was fixed with UHD 3.14.1.0. The threads below are were this was identified: http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-May/059914.html http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-April/059465.html As recommended from the thread: Phase may change each time streamers are created, but the phase between TX and RX should remain consistent during streaming. Tuning must be done with timed commands and a consistent time delta between the tune time of TX and RX must be maintained that is greater than 500us to maintain the coherence across re-tunes. If you're using the QT widget without any modifications, it will not be using timed commands, you'll need to generate the python file and manually add in the timed commands to the set_freq calls. Also, if I remember correctly, even with the phase accumulator fix, there was some caveats to which frequencies would stay coherent. I need to go back and look at some notes on it. Regards, Nate Temple On Fri, Dec 6, 2019 at 11:11 PM Lukas Haase via USRP-users <usrp-users@lists.ettus.com[mailto:usrp-users@lists.ettus.com]> wrote:Hi Marcus, Marcus wrote:> On 12/06/2019 09:33 PM, Lukas Haase via USRP-users wrote: >> Hi, >> >> I am using the USRP X310+UBX160 with gnuradio to perform very >> precicse phase measurements: The TX transmits a CW which is >> reflected by an object and received by the RX. >> >> The received phase provides an accurate estimate of the distance >> to>> the reflected object, once the fixed phase relation (between >> TX/RX- LO, filters, cables etc.) has been subtracted out. >> >> This works nicely so far. >> >> However, I need my system to work across power cycles, and more >> importantly, across different frequencies: The goal is to perform >> fast frequency hopping and obtain the phase for each frequency. >> >> Unfortunately it seems that the phase relationship between TX/RX >> is>> lost when I tune the USRP to a different center frequency and >> back. For example, I have the center frequency set to 900 MHz and >> the phase. I measure (by computing the angle of the I/Q samples) >> stays constant. But when I set the center frequency to 950 MHz and >> then back to 900 MHz, the phase has a random value again. >> >> Is there any way to avoid this? Or is there any way to lock the LO >> phase to a particular phase when>> tuning back to the original >> frequency? > > It *might* be possible to phase-synchroniez the RX and TX LOs using > timed commands combined, possibly with INTEGER_N tuning. > > There's an APP Note on phase-synchronization here: > > https://kb.ettus.com/Synchronization_and_MIMO_Capability_with_USRP_Devices[https://kb.ettus.com/Synchronization_and_MIMO_Capability_with_USRP_Devices] Thank you, I'm studying this right now. > My gut tells me this is going to be hard, though, since the > requirement is to bring a synthesizer back to the same relative phase > it had when it was previously tuned to the same frequency. Yes, this is about multiple devices, certainly hard. Let's take a step back and I am happy when just the TX/RX LO on a single device is synchronized. This is what I do right now: In gnuradio, I generate a sinudoid (fif=1MHz) at baseband and transmit (UHD: USRP Sink) it with fcenter=900MHz. Then I receive (UHD: USRP Source) it and multiply it with "-fif" again. This gives me a constant signal in I and Q. The center frequency is configured via "QT GUI Entry". I enter 900e6 and press enter. Then I plot "Complex to Arg". As long as I do nothing this value is fairly constant (somewhere between -pi and pi). Now I hit enter again in the QT GUI Entry. Although it's the same center frequency, the USRP retunes and the phase jumps to another value. Now let's look at the USRP block diagram: https://kb.ettus.com/images/1/16/2920_simplified_system_diagram.gif[https://kb.ettus.com/images/1/16/2920_simplified_system_diagram.gif] Yes, both TX and RX path have a separate PLL and VCO. However, the *reference* for this PLL is the same. Hence the PLL should lock to the phase of this reference (after all, it's a *phase* locked loop). And this implies that the *relative* phase between TX and RX, for a given frequency, should be fixed -- at least as long as the USRP is powered. So, how can it be that this is not the case?! There is just a single suspicion that I have: DSP on gnuradio (host computer runs a different clock) versus USRP clock. What do I mean by that? Initially I was transmitting a pure CW (in gnuradio, connecting a "Constant Source" to USRP Sink and setting the frequency to fcenter+fif). However, downconversion was performed with fcenter only and multiplying with fif in gnuradio. I could see a slow phase drift. It took me hours to figure out that this is caused by the different clocks. The effect was gone once I also generated the transmitted waveform in gnuradio. In order to fix this, I would subtract the phase of this generated waveform in gnuradio. But obviously this phase is always zero ... I hope you understand what I am writing. Best, Luke _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
