usrp-users@lists.ettus.com
Discussion and technical support related to USRP, UHD, RFNoC
View all threadsRe: [USRP-users] Phase relation between RX/TX LO
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
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> 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
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
On 12/07/2019 12:05 PM, Nate Temple via USRP-users wrote:
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
The other thing to consider is the contribution of Fractional-N
synthesis to the unpredictable nature of the phase of two synthesizers,
even when
using a common reference.
Many years ago, Texas Instruments published a quite-nice technical brief
on the difference between Fractional-N and Integer-N synthesis:
http://www.ti.com/lit/an/swra029/swra029.pdf
A side-effect of fractional-N synthesis is that two frac-N synthesizers
will not necessarily have a zero phase-offset with respect to one another,
without a bit of "help". That "help" comes in the form of a special
"phase reset" signal on some modern PLL synthesizers. One of the
caveats is that all the synthesizers have to have this "phase reset"
signal triggered at the same time (or, I think, more properly, within less
than one cycle of Fref). So, that is the reason that timed commands
must be used to allow predictable phase-offset. Fortunately, the MAX2871
used on the UBX is such a synthesizer.
A further complication, just as a bit of trivia not relevant to this
case, is that SOME fractional-N synthesizers "dither" the averaging schedule
used to change between N and N+1 states, in order to spread-out
synthesizer spurs to reduce energy at sharply-defined frequencies.
In those cases, it's easy to see how maintaining coherence among
multiple instances would be impossible, even with a common
reference.
But this also brings up another issue (not relevant in this case, but
something to be aware of). Two frac-N synthesizers of different
design may not be able to maintain mutual coherence of predictable
phase-offset. So these "timed command" tricks can only
really be used among synthesizers of exactly the same type. In the
Ettus case, that means among daughterboards of exactly
the same type.
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.temple@ettus.com
An: "Lukas Haase" lukashaase@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
Hi Luke,
There is an example of setting timed commands in a custom block for the
TwinRX in gr-doa here:
https://github.com/EttusResearch/gr-doa/blob/master/python/twinrx_usrp_source.py#L101-L121
You can do this with the standard UHD source/sink blocks, by first making
your flowgraph, then generate the .py in GRC, then open up that .py file
and modify it to add the timed command calls.
If you modify the GRC and regenerate the .py, it'll overwrite your changes.
Regards,
Nate Temple
On Sat, Dec 7, 2019 at 11:35 AM Lukas Haase lukashaase@gmx.at wrote:
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.temple@ettus.com
An: "Lukas Haase" lukashaase@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
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:
and here:
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" nate.temple@ettus.com
An: "Lukas Haase" lukashaase@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
Hi Nate,
Nate wrote:
Hi Luke,
There is an example of setting timed commands in a custom block for the TwinRX in gr-doa here:
https://github.com/EttusResearch/gr-doa/blob/master/python/twinrx_usrp_source.py#L101-L121
You can do this with the standard UHD source/sink blocks, by first making your flowgraph, then generate the .py in GRC,
then open up that .py file and modify it to add the timed command calls.
If you modify the GRC and regenerate the .py, it'll overwrite your changes.
Thanks a lot! That makes sense.
Unfortunately I did not mention that I have a special case too: My TX is at fcenter and my RX is at 2*fcenter.
The code which is generated by GRC looks like this (currently I have one TX and two RX):
def set_fcenter(self, fcenter):
self.fcenter = fcenter
self.uhd_usrp_sink_0.set_center_freq(self.fcenter, 0)
self.uhd_usrp_source_0.set_center_freq(2self.fcenter, 0)
self.uhd_usrp_source_0.set_center_freq(2self.fcenter, 1)
Hence the code in your link does not 100% apply. However, I modified it as follows:
def set_fcenter(self, fcenter):
self.fcenter = fcenter
tune_resp = self.uhd_usrp_sink_0.set_center_freq(fcenter, 0)
tune_req_tx = uhd.tune_request(rf_freq=fcenter, rf_freq_policy=uhd.tune_request.POLICY_MANUAL,
dsp_freq=tune_resp.actual_dsp_freq, dsp_freq_policy=uhd.tune_request.POLICY_MANUAL)
tune_req_rx = uhd.tune_request(rf_freq=2*fcenter, rf_freq_policy=uhd.tune_request.POLICY_MANUAL,
dsp_freq=2*tune_resp.actual_dsp_freq, dsp_freq_policy=uhd.tune_request.POLICY_MANUAL)
self.uhd_usrp_source_0.set_center_freq(tune_req_rx, 0)
self.uhd_usrp_source_0.set_center_freq(tune_req_rx, 1)
# Synchronize the tuned channels
now = self.uhd_usrp_sink_0.get_time_now()
self.uhd_usrp_sink_0.set_command_time(now + uhd.time_spec(0.01))
self.uhd_usrp_source_0.set_command_time(now + uhd.time_spec(0.01))
self.uhd_usrp_sink_0.set_center_freq(tune_req_tx, 0)
self.uhd_usrp_source_0.set_center_freq(tune_req_rx, 0)
self.uhd_usrp_source_0.set_center_freq(tune_req_rx, 1)
self.uhd_usrp_source_0.clear_command_time()
So I think I need two tune_request objects because I have two different frequencies.
However, this does not work: Now my downconverted signal seems to be frequency shifted by roughly 5kHz.
Do you have an idea how to fix this for my scenario?
Thanks again,
Luke
Hi Marcus,
You'll need to look at the API here:
and here:
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.
Thank you.
As I understand you referenced the USRP driver whereas GRC creates gnuradio objects (e.g.: usrp_source https://www.gnuradio.org/doc/doxygen-3.7.2/classgr_1_1uhd_1_1usrp__source.html )
My dilemma is that I need to set the center frequency of the TX to "fc" and the center frequency of the RX to "2*fc" and its phase relationship should be identical for each "fc" (at least as long the USRP does not power cycle).
The gnuradio API als exposes the USRP API you mentioned so I tried:
now = self.uhd_usrp_sink_0.get_time_now()
self.uhd_usrp_sink_0.set_command_time(now + uhd.time_spec(1))
self.uhd_usrp_source_0.set_command_time(now + uhd.time_spec(1))
self.uhd_usrp_source_0.set_center_freq(2*self.fcenter, 0)
self.uhd_usrp_source_0.set_center_freq(2*self.fcenter, 1)
self.uhd_usrp_sink_0.set_center_freq(self.fcenter, 0)
self.uhd_usrp_source_0.clear_command_time()
self.uhd_usrp_sink_0.clear_command_time()
But this this the phase still jumps after a frequency change.
I also tried this (in order to perform the commands on a single USRP multi object):
dev = self.usrp_source_0.get_device()
# dev = self.uhd_usrp_sink_0.get_device() should be identical
now = dev.get_time_now()
dev.set_command_time(now + uhd.time_spec(1))
dev.set_rx_freq(2*self.fcenter)
dev.set_tx_freq(self.fcenter)
dev.clear_command_time()
but it has no effect (it does not even change the center frequencies).
And I have also tried to modify Nate's suggestion to different RX/TX frequencies: http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-December/061114.html
And interestingly the received signal has a frequency shift (approximately 5kHz which is very weird).
Any further advice is highly appreciated.
Thanks,
Luke
On 12/08/2019 05:19 PM, Lukas Haase wrote:
Hi Marcus,
You'll need to look at the API here:
and here:
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.
Thank you.
As I understand you referenced the USRP driver whereas GRC creates gnuradio objects (e.g.: usrp_source https://www.gnuradio.org/doc/doxygen-3.7.2/classgr_1_1uhd_1_1usrp__source.html )
My dilemma is that I need to set the center frequency of the TX to "fc" and the center frequency of the RX to "2*fc" and its phase relationship should be identical for each "fc" (at least as long the USRP does not power cycle).
The gnuradio API als exposes the USRP API you mentioned so I tried:
now = self.uhd_usrp_sink_0.get_time_now()
self.uhd_usrp_sink_0.set_command_time(now + uhd.time_spec(1))
self.uhd_usrp_source_0.set_command_time(now + uhd.time_spec(1))
self.uhd_usrp_source_0.set_center_freq(2*self.fcenter, 0)
self.uhd_usrp_source_0.set_center_freq(2*self.fcenter, 1)
self.uhd_usrp_sink_0.set_center_freq(self.fcenter, 0)
self.uhd_usrp_source_0.clear_command_time()
self.uhd_usrp_sink_0.clear_command_time()
But this this the phase still jumps after a frequency change.
So, you're trying to measure the 2nd-harmonic energy of the TX signal?
What frequencies are involved here?
Hi Marcus,
Von: "Marcus D. Leech" patchvonbraun@gmail.com
On 12/08/2019 05:19 PM, Lukas Haase wrote:
Hi Marcus,
You'll need to look at the API here:
and here:
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.
Thank you.
As I understand you referenced the USRP driver whereas GRC creates gnuradio objects (e.g.: usrp_source https://www.gnuradio.org/doc/doxygen-3.7.2/classgr_1_1uhd_1_1usrp__source.html )
My dilemma is that I need to set the center frequency of the TX to "fc" and the center frequency of the RX to "2*fc" and its phase relationship should be identical for each "fc" (at least as long the USRP does not power cycle).
The gnuradio API als exposes the USRP API you mentioned so I tried:
now = self.uhd_usrp_sink_0.get_time_now()
self.uhd_usrp_sink_0.set_command_time(now + uhd.time_spec(1))
self.uhd_usrp_source_0.set_command_time(now + uhd.time_spec(1))
self.uhd_usrp_source_0.set_center_freq(2*self.fcenter, 0)
self.uhd_usrp_source_0.set_center_freq(2*self.fcenter, 1)
self.uhd_usrp_sink_0.set_center_freq(self.fcenter, 0)
self.uhd_usrp_source_0.clear_command_time()
self.uhd_usrp_sink_0.clear_command_time()
But this this the phase still jumps after a frequency change.
So, you're trying to measure the 2nd-harmonic energy of the TX signal?
Precicely.
What frequencies are involved here?
Example: Transmit 900 Mhz (USRP Sink).
Receive 1800 MHz (USRP Source).
The received signal will have arbitrary phase phi1.
Tune to frequency 950 MHz and receive 1900 MHz. The phase will be phi2.
Then tuning back to 900 MHz and I need to read out phi1 again.
Then tuning back to 950 MHz and I need to read out phi2 again.
And so on.
Does this make sense?
Thanks,
Luke