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:
>>>> 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
