On 12/07/2019 02:35 PM, Lukas Haase via USRP-users wrote:
Also: Why wouldn't such an approach cause issues due to the clock differences
between the host computer and the USRP?
The CPU clock plays no role here at all. Samples are timed by the USRP,
NOT the host. Further, in a "timed command"
example, the specified time is from the point-of-view of the USRP.
You'll need to look at the API here:
https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a191b78b00d051d3d51c2f719361c1fb5
and here:
https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a607aee766d21228a7aaabde2771eb46f
Basically, GRC will generate python code where it calls the
set_rx_freq() method (or set_tx_freq() method), and you need to modify this
code to have set_command_time() and clear_command_time() wrapped
around those operations.
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" <[email protected]>
An: "Lukas Haase" <[email protected]>
Cc: "[email protected]" <[email protected]>
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
<[email protected][mailto:[email protected]]> 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
[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
