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 <
[email protected]> 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" <[email protected]>
> *An:* "Lukas Haase" <[email protected]>
> *Cc:* "Marcus D Leech" <[email protected]>, "
> [email protected]" <[email protected]>
> *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 <[email protected]> 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" <[email protected]>
>> An: "Lukas Haase" <[email protected]>
>> Cc: "Marcus D Leech" <[email protected]>, "
>> [email protected]" <[email protected]>
>> 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 <[email protected][mailto:
>> [email protected]]> 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
> [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
