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: >> 1. 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. >> 2. Set Rx and Tx frequency to freq 1 >> 3. Measure and note the relative phase for Rx0/Tx0 and Rx1/Tx0 for >> freq 1 >> 4. Set Rx and Tx frequency to freq 2 >> 5. Measure and note the relative phase for Rx0/Tx0 and Rx1/Tx0 for >> freq 2 >> 6. 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
