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
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 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
