Re: [USRP-users] USRP X310 ignored DSP retuning on TX when using a timed command

Lukas Haase via USRP-users Fri, 20 Mar 2020 11:15:47 -0700

Hi Rob,

Thanks again so much for reproducing the setup.

Based on Cases 1-4 this is consistent which what I get and it really feels good that you are able to reproduce it.

I have been wrapping my head around WHY can happen for TX/RX but not for TX/TX or RX/RX. It's really hard to imagine to me why if everything clearly happens at the same time. One thought that I had:

At time X, when the frequency is tuned, the phase accumulator is actually NOT reset to zero, to my knowledge. All that happens is that the phase increment is updated, such that at the next run, the LO signal is "current_value+1/freq_new/resolution" instead of "current_value+1/old_freq/resolution".
The one thing that's different between TX and RX is the sign ... can it be that phase coherence is somehow lost because of the different sign?

Next, really sorry for confusing you with the block diagram. I use gnuradio-companion where it's really easy to connect/disconnect lines. And I used them for transparently switching between the cases "absolute phase RX1", "absolute phase RX2" and "relative phase RX1-RX2" ... by just rewiring and recreating the block diagram. Hence I added the annotations in https://snipboard.io/i9jLJg.jpg : "Take this for RX1", "Take this for RX2", "Take this for rel. phase". Again, sorry that this was inconsistent between the screenshot and the code. I had rewired it to absolute phase at that point.

Great idea with the multiply_conjugate_cc block, I haven't thought of this yet. Thank for for sending your updated code ... I will continue with that now ...

Best,

Lukas

Gesendet: Freitag, 20. März 2020 um 12:04 Uhr
Von: "Rob Kossler" <rkoss...@nd.edu>
An: "Lukas Haase" <lukasha...@gmx.at>, usrp-users <usrp-users@lists.ettus.com>
Betreff: Re: [USRP-users] USRP X310 ignored DSP retuning on TX when using a timed command

Lukas,

After looking at this a bit, I think that there is indeed an issue. I think that it is possible to get consistent tx-to-tx phase results and consistent rx-to-rx phase results, but NOT consistent rx-to-tx phase results. A few remarks:

Setup
- 2-channel X310/UBX-160 with two external loopback RF cables (with attenuation) such that Tx0=>Rx0 and Tx1=>Rx1 (I likely don't even need the loopback cables because I could operate on just the leakage signal from each channel, but I decided to use external cables).
- UHD 3.15.LTS and gnuradio 3.7.13.5.

Methodology
- Transmit an identical waveform (1 MHz tone) out of both Tx ports
- Measure relative Rx phase by using a multiply_conjugate block for the 2 Rx channels (see below for description of why I changed what you sent me) with output connected to a complex_to_mag_phase block and subsequent moving_average
- Use digital tuning (with timed commands) to toggle between 2 dsp frequencies while noting the relative phase results
Test cases
- Case 1: Verify rx-to-rx phase results by sending tune requests to the 2 Rx channels (but sending nothing to the Tx channels)
- Case 2: Verify tx-to-tx phase results by sending tune requests to the 2 Tx channels (but sending nothing to the Rx channels)
- Case 3: Verify rx-to-tx phase results by sending tune requests to channel 0 Rx and Tx (but sending nothing to channel 1 Rx and Tx)
- Case 4: Verify rx-to-tx phase results by sending tune requests to channel 1 Rx and Tx (but sending nothing to channel 0 Rx and Tx)

Cases 1 and 2 show consistent results, but cases 3 and 4 do not. I cannot conceive of what the problem is. It is so perplexing that I hesitate to send this email because it seems I must be doing something wrong. Perhaps there is a problem in the methodology above along with the test cases. But, it seems sound to me.

The Rx block diagram you sent me does not match the Python code you sent. This threw me off for a while. In your block diagram, the phase measurement is made from the division of the two low pass filter outputs. In the Python code you sent, the phase measurement uses only the first low pass filter output. The reason this is important is that I suspected early on that the problem might be related to your gnuradio signal_source used for IF downconversion. This signal source is not synchronous with the USRP as you change USRP freqs. However, I figured that it wasn't a problem because it was "divided out". But, since it is actually not divided out,I believe that this was providing misleading results.

In the end, I just changed your code to add a "multiply_conjugate_cc" block with the two Rx channels as the two inputs. This effectively uses one channel to downconvert the other and thus eliminates the need for the signal source in the Rx block diagram. I then connected this multiply_conjugate directly to the complex_to_mag_phase. You could simplify the code by removing the other multiply blocks, low pass filters, and divide since these are not used. Also, I put all of the functionality in the rxtx (together) button callback. I did not really use the other buttons. Attached is the modified code.

Rob

On Fri, Mar 20, 2020 at 2:38 AM Rob Kossler <rkoss...@nd.edu> wrote:

Hi Lukas,

A few remarks:

The 2nd code you sent works fine. Thanks.

I'm not sure that starting/stopping as I do in my program is causing the issue. The only reason I didn't continuously stream both Rx and Tx like you do in gnuradio is because my software is not setup to do that.

So, I still think it's possible that UHD can do the job with continuous streaming but perhaps there is still something in the gnuradio config that is not quite right. But, I don't know what that is right now. I need to think about this a bit....

Rob

On Thu, Mar 19, 2020 at 8:17 PM Lukas Haase <lukasha...@gmx.at> wrote:

Hi Rob,

Sorry I really should have ran the python file before uploading. The issue was that I combined to files into one and forgot to remove the imported file.

Here is a new one (tested): http://paste.ubuntu.com/p/VsGRmsbZQ5/

Thanks for reporting your results .... very interesting!

Why do you think second mode makes sense to you? (assuming you are using timed commands to to retune TX+RX at the same time)

In general, it seems to me that things are related to streaming start/stop. Maybe things are reset when streaming starts/ends but not when re-tuning?

Maybe this is what Marcus was mentioning: resetting phase accumulator vs. "increment register is updated with the new phase increment"?

MAYBE stopping/starting resets the phase accumulator to zero and just timed retuning doesn't reset anything. But still, my question is left why this would result in a random phase offset between DUC and DDC.

Thanks again!!

Lukas

Gesendet: Donnerstag, 19. März 2020 um 19:16 Uhr
Von: "Rob Kossler" <rkoss...@nd.edu>
An: "Lukas Haase" <lukasha...@gmx.at>
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Betreff: Re: [USRP-users] USRP X310 ignored DSP retuning on TX when using a timed command

Lukas,

I installed gnuradio and tried to run but encounter the following. I'm guessing this is your block.

Traceback (most recent call last):
File "test.py", line 25, in <module>
import epy_block_1
ImportError: No module named epy_block_1

Rob

On Thu, Mar 19, 2020 at 6:28 PM Rob Kossler <rkoss...@nd.edu> wrote:

Ok. False alarm. I forgot about the dboard clock needing set to 20MHz for RF freq below 1 GHz. When I made this change, now I get consistent Rx-Tx phase for the first mode where both Tx and Rx start/stop at each test.

Rob

On Thu, Mar 19, 2020 at 6:10 PM Rob Kossler <rkoss...@nd.edu> wrote:

Ok. I modified my code to be more like yours...

toggling dsp freq rather than LO freq

LO at 900 MHz

external connections Tx0 => Splitter_1x2 => both Rx0 and Rx1

Previously, I was starting / stopping both Rx & Tx in between each test. Now, I added a mode where the Tx is on continuously, and the Rx starts & stops for each test after the dsp freq change

The results are the following:

In the first mode where both Tx and Rx start/stop at each test, I get consistent group delay (as measured by the correlation peak index) for both Rx-Rx and Rx-Tx. But for phase, the Rx-Rx phase is consistent, but the Rx-Tx phase seems random

In the second mode where Tx is on continuously and I start/stop Rx after each dsp freq change, the group delay is constant for Rx-Rx but random for Rx-Tx. The phase results are constant for Rx-Rx but random for Rx-Tx.

Regarding the 2nd mode, this makes sense to me. But, for the 1st mode, I don't understand why the Rx-Tx phase seems random. Still thinking about it....

Rob

On Thu, Mar 19, 2020 at 4:35 PM Rob Kossler <rkoss...@nd.edu> wrote:

Lukas,

Just before receiving your email, I ran the following with my custom c++ & matlab software using X310/UBX-160 with the connections I described. The following shows the output which is very consistent. I used a 100 tone multi-tone waveform spread over 4 MHz bandwidth (using 5 MS/s sample rate on Tx and Rx). Note the consistency of results as I toggled between 2 frequencies: 2450 and 2460 MHz.

My method was the following:

Tx waveform was 500 points long

Rx capture was 5000 points long

Compute cross-correlation (using Matlab xcorr) as follows: xcorr(rx0, conj(tx)) AND xcorr(rx0,conj(rx1))

Find the correlation peak (which was very pronounced) which shows the sample delay between the two signals. Extract the phase at the peak

Oops, I just realized that I used a constant DSP freq (10 MHz) and I changed the LO freq in my test. I will try again with moving the DSP freq instead.

Rob

Test 1: freq = 2450.0 MHz
Rx0/Tx0 xcorr peak at index 108 with phase -121.8
Rx0/Rx1 xcorr peak at index 115 with phase -95.7
Test 2: freq = 2460.0 MHz
Rx0/Tx0 xcorr peak at index 108 with phase -58.7
Rx0/Rx1 xcorr peak at index 115 with phase 13.1
Test 3: freq = 2450.0 MHz
Rx0/Tx0 xcorr peak at index 108 with phase -121.7
Rx0/Rx1 xcorr peak at index 115 with phase -95.8
Test 4: freq = 2460.0 MHz
Rx0/Tx0 xcorr peak at index 108 with phase -58.6
Rx0/Rx1 xcorr peak at index 115 with phase 13.0
Test 5: freq = 2450.0 MHz
Rx0/Tx0 xcorr peak at index 108 with phase -121.7
Rx0/Rx1 xcorr peak at index 115 with phase -95.8
Test 6: freq = 2460.0 MHz
Rx0/Tx0 xcorr peak at index 108 with phase -58.8
Rx0/Rx1 xcorr peak at index 115 with phase 12.7
Test 7: freq = 2450.0 MHz
Rx0/Tx0 xcorr peak at index 108 with phase -121.8
Rx0/Rx1 xcorr peak at index 115 with phase -95.9
Test 8: freq = 2460.0 MHz
Rx0/Tx0 xcorr peak at index 108 with phase -58.7
Rx0/Rx1 xcorr peak at index 115 with phase 12.9
Test 9: freq = 2450.0 MHz
Rx0/Tx0 xcorr peak at index 108 with phase -121.8
Rx0/Rx1 xcorr peak at index 115 with phase -95.8
Test 10: freq = 2460.0 MHz
Rx0/Tx0 xcorr peak at index 108 with phase -58.7
Rx0/Rx1 xcorr peak at index 115 with phase 12.9
>>

On Thu, Mar 19, 2020 at 4:21 PM Lukas Haase <lukasha...@gmx.at> wrote:

Hi Rob,

Yes, I confirm your conclusion.

I calculate the relative phase by dividing the outputs of both receivers. To understand better, note that I have an additional "IF stage" in my own signal flow such that I exclude DC offset correction etc. the USRP may perform. This is the block diagram of the transmitter part: https://snipboard.io/YFgIKs.jpg . I send "exp(1j*1MHz*t) . This shows the receiver part: https://snipboard.io/i9jLJg.jpg . I multiply the received signal with exp(-1j*1MHz*t) and filter them. Then I divide both streams and take the phase part. I take a moving average (for flucatuations), add pi and display the number.

https://snipboard.io/YFgIKs.jpg https://snipboard.io/YFgIKs.jpg https://snipboard.io/YFgIKs.jpg That's so nice, thank you!! My code is here: http://paste.ubuntu.com/p/MbCJfPGzYW/ . I'm not sure if you have gnuradio(and QT) installed but if yes, simply "python2 switch_on_click.py" should do. Let me quickly elaborate how it works:

Class "switch_on_click" implements a normal gnuradio flow with USRP transmitter and receiver.

It also uses a custom module together with buttons and a probe block to call functions upon clicking on a button

The callback functions are defined in class "blk"

The most important is "def button_rtx_handler" on line 106 which is executed when user clicks on button "Switch RTX (together)"

Again, thank you for trying this out!! If it works, would you mind sharing this code then? I may be able to check then where it breaks on my system

I use 900 MHz as default center frequency (and "rf_freq"). When clicking, I jump between dsp_freq=0 and dsp_freq=500e3. As to my waveform, you can infer from my screenshots and code above: I am transmitting and receiving a 1MHz waveform (which acts as an additional "IF stage"). The received signal is then downconcerted from 1MHz to DC. I use 5 MSsps sampling rate.

Again, thank you SO much.

Best,

Lukas

Gesendet: Donnerstag, 19. März 2020 um 10:43 Uhr
Von: "Rob Kossler" <rkoss...@nd.edu>
An: "Lukas Haase" <lukasha...@gmx.at>
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Betreff: Re: [USRP-users] USRP X310 ignored DSP retuning on TX when using a timed command

Hi Lukas,
So, the conclusion is that your Rx0-to-Rx1 relative phase is nearly constant such that it seems that both Rx0/Rx1 are phase coherent and Tx0/Tx1 are phase coherent. But, phase from Tx-to-Rx is random. Please correct me if that is wrong.

I have a few comments:

How do you measure/calculate the relative phase?

Can you send me the full Python code to look at? As I mentioned previously, I am not too good at gnuradio/Python, but I might be able to spot something.

As to your question, I always use synchronous measurements. And, I'm confident that my Rx-to-Rx phase is coherent. But, I haven't really looked at Tx-to-Rx in a while so I will do so later today. Here are the steps I plan to take:

Connect Tx0 to Rx1. Note that there is a pretty strong leakage signal from Tx0 to Rx0 so I don't really need to provide a physical connection in order to get a signal on Rx0. The signal attenuation in this leakage path is approx 40 dB so it is not too much different than the signal level I will receive on Rx1 if I use an external 30 dB attenuator.

Set Rx and Tx frequency to freq 1

Measure and note the relative phase for Rx0/Tx0 and Rx1/Tx0 for freq 1

Set Rx and Tx frequency to freq 2

Measure and note the relative phase for Rx0/Tx0 and Rx1/Tx0 for freq 2

Repeat steps 2-5 a few times to ensure that the measurements are repeatable

Questions: what should I use for freq 1 and freq 2? What waveform are you transmitting? What sample rates for Tx and Rx?

Rob

On Wed, Mar 18, 2020 at 7:47 PM Lukas Haase via USRP-users <usrp-users@lists.ettus.com> wrote:

Hi Rob,

I think the issue is really having two usrp_multi devices with timed commands and same timestmap or similar. From your tests below:

1.) I can confirm that the relative phase between two RX in your suggested test is always the same! In fact, it is always 4.56 rad, even across restarts and for different frequencies! That somewhat makes sense because the phase offset is now only dependent on the difference between the two channels (fixed) and cable lengths from the splitter (fixed). I verified by removing the timed command on usrp source, the phase offset becomes random after each retune. Of course, this is independent of TX tuning (timed vs. not). For reference, this is the code used:

        tune_req_rx = uhd.tune_request()
        tune_req_rx.rf_freq_policy = uhd.tune_request.POLICY_NONE
        tune_req_rx.dsp_freq_policy = uhd.tune_request.POLICY_MANUAL
        tune_req_rx.dsp_freq = -dsp_freq

        tune_req_tx = uhd.tune_request()
        tune_req_tx.rf_freq_policy = uhd.tune_request.POLICY_NONE
        tune_req_tx.dsp_freq_policy = uhd.tune_request.POLICY_MANUAL
        tune_req_tx.dsp_freq = dsp_freq

        now = usrp_sink.get_time_now()
        when = now + uhd.time_spec(1.0)

        usrp_sink.set_command_time(when)
        usrp_source.set_command_time(when)

        res1 = usrp_sink.set_center_freq(tune_req_tx)          # TX
        res2 = usrp_source.set_center_freq(tune_req_rx, 0) #RX1
        res3 = usrp_source.set_center_freq(tune_req_rx, 1) #RX2

        usrp_sink.clear_command_time()
        usrp_source.clear_command_time()

2.) I also tried your second suggestion. Before reading on, you wanna guess what the outcome is?

I connected "TX/RX" to "RX2" on UBX #1 (TX1 --> RX1) and "TX/RX" to "RX2" on UBX #2 (TX2 --> RX2). In absence of a second 30dB attenuator I used two antennas closely spaced together. For reference, my code looks now like:

        tune_req_rx = uhd.tune_request()
        tune_req_rx.rf_freq_policy = uhd.tune_request.POLICY_NONE
        tune_req_rx.dsp_freq_policy = uhd.tune_request.POLICY_MANUAL
        tune_req_rx.dsp_freq = -dsp_freq

        tune_req_tx = uhd.tune_request()
        tune_req_tx.rf_freq_policy = uhd.tune_request.POLICY_NONE
        tune_req_tx.dsp_freq_policy = uhd.tune_request.POLICY_MANUAL
        tune_req_tx.dsp_freq = dsp_freq

        now = usrp_sink.get_time_now()
        when = now + uhd.time_spec(1.0)

        usrp_sink.set_command_time(when)
        usrp_source.set_command_time(when)

        res1 = usrp_sink.set_center_freq(tune_req_tx, 0)    # TX1
        res2 = usrp_sink.set_center_freq(tune_req_tx, 1)     # TX2
        res3 = usrp_source.set_center_freq(tune_req_rx, 0) # RX1
        res4 = usrp_source.set_center_freq(tune_req_rx, 1) # RX2

        usrp_sink.clear_command_time()
        usrp_source.clear_command_time()

I again look at the relative phase of RX1 and RX2 (obtained by dividing the two) and guess what: Also now the relative phase stays constant! (This time it actually slightly varies from 3.0 rad to 3.7 rad between two different frequencies).

What does that mean? I think it means that TX must be tuned coherently and RX must be tuned coherently, i.e., timed commands generally work for multiple TX's and multiple RX's individually. Do I get that right?

What doesn't seem to work is RX+TX together.

I am very desperately asking if you had coherent TX+RX setup working at any point or know somebody who did. It would be so much worth to know if this is something that never worked to begin with or if I'm just doing something wrong. On the other hand I don't want to believe being the only person on the planet having tried TX+RX phase coherent operation :-/

Any other further suggestions on how to continue debugging with the above in mind would be helpful too.

In my opinion there are two options left:

1.) There is still a nondeterministic delay between the TX and RX timed commands (to my understanding, even a constant delay would result in coherent phase)

2.) While the phase accumulators in RX are set to the same values (and in TX as well), they may be set to a different, random value.

However, I don't really know how to test these.

Thanks,

Lukas

Gesendet: Freitag, 13. März 2020 um 12:27 Uhr
Von: "Rob Kossler" <rkoss...@nd.edu>
An: "Lukas Haase" <lukasha...@gmx.at>
Cc: "Marcus D Leech" <patchvonbr...@gmail.com>, "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Betreff: Re: [USRP-users] USRP X310 ignored DSP retuning on TX when using a timed command

Ok, great. I am trying to think of ways to now add the phase measurement. Ideas...

In order to get consistent phase, you would need to tune Rx and Tx DSP at the same time (rather than below where you are only tuning one of them). So, assuming that this will not produce consistent phase results, then maybe try the following idea...

If you want to check just Rx DSP tuning (with fixed Tx DSP tuning), you could try a 2 channel Rx measurement where the Tx is split externally with 1:2 splitter in order to drive both Rx0 and Rx1. Then, measure the relative phase Rx0/Rx1 and then tune back and forth between two Rx DSP freqs to see if the relative phase on Rx remains constant. If so, this would give you good confidence that Rx DSP tuning is indeed happening synchronously

Assuming that the Rx IS synchronous in the step above (perhaps a bad assumption, but here goes), you could then check TX DSP tuning (with fixed Rx DSP tuning) by using two Tx and two Rx channels with Tx0 connected to Rx0 and Tx1 connected to Rx1. At this point we are confident that Rx DSP tuning is synchronous so any synchronous misbehavior would imply a Tx sync problem.

Sorry I can't think of better ideas.

Rob

On Fri, Mar 13, 2020 at 12:12 PM Lukas Haase <lukasha...@gmx.at> wrote:

Hi Rob,

1.) yes, works(*)
2.) yes, works(*)

(*): qualitatively. I set the timed command to "get_current_time() + uhd.time_spec(2.0)" and I see the chance 2 seconds after my click on the screen. I cannot (do not know how) check if it actually happens at sample-precicse location.

Great, any ideas to simplify the setup would nice. I just don't know how I could continue to debugging the phase.

Best,
Luke

Gesendet: Freitag, 13. März 2020 um 11:08 Uhr
Von: "Rob Kossler" <rkoss...@nd.edu>
An: "Lukas Haase" <lukasha...@gmx.at>
Cc: "Marcus D Leech" <patchvonbr...@gmail.com>, "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Betreff: Re: [USRP-users] USRP X310 ignored DSP retuning on TX when using a timed command

Thanks Lukas,
I wanted to confirm that you did not have an older version of FPGA firmware because there was a DDC/DUC bug fix[https://github.com/EttusResearch/fpga/commit/0b2364653405612a6d5dfaa0e69b1c6798771e6d] related to phase. However, the version you provided with uhd_usrp_probe confirms that you have the bug fix included. So, this is not the problem.

>From what you said, I assume that you can successfully do the following:
1) with Rx tuning fixed (no re-tuning at all), tune Tx DSP only (do not change TX RF) and you can see the frequency change at the specified command time (i.e., if you specify the command time 1 sec in the future, the change does not occur until 1 sec in the future).
2) opposite of #1: with Tx tuning fixed, tune Rx DSP only and you can see the frequency change at the specified command time.

I am trying to simplify the issue by removing RF tuning completely and by tuning only 1 of Rx/Tx at a time. Perhaps this will help lead to the answer.
Rob



On Fri, Mar 13, 2020 at 10:53 AM Lukas Haase <lukasha...@gmx.at[mailto:lukasha...@gmx.at]> wrote:Hi again Rob,

Yes, I confirm:

1.) Finally I get the commands to execute at the same time (TX and RX individually and both at the same time)
2.) Yes, the phase is random after each retune, even when I retune back to the same frequency
3.) (2) is only true if it includes *DSP* retuning. With naalog retuning (+integer-N retuning) I get phase coherence, as expected.

I actually expected the PLL retuning much more challenging than the DSP retuning but for some reason it seems to be the opposite...

Thanks,
Lukas



_______________________________________________
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

Re: [USRP-users] USRP X310 ignored DSP retuning on TX when using a timed command

Reply via email to