subject:"Re\: \[USRP\-users\] USRP X310"

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  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" 
> *An:* "Lukas Haase" 
> *Cc:* "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 
> import epy_block_1
> ImportError: No module named epy_block_1
> Rob
>
> On Thu, Mar 19, 2020 at 6:28 PM Rob Kossler  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  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  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

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

2020-03-19 Thread Marcus D. Leech via USRP-users


On 03/19/2020 08:16 PM, Lukas Haase via USRP-users 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

So, having spent a couple of hours snooping around the X3xx FPGA code, 
where Verilog is not one of my native languages, I have come to
  a bit of a conclusion about the ways things work.  Now, keep in mind, 
this is like me reading War and Peace in the original Russian, and as
  an English speaker, coming the vague conclusion that "It was about 
Russia".


There's a "settings bus" within the FPGA that is implemented with AXI 
FIFO modules.  If your command (which results, most often in
  having to "set" one or more registers via the settings bus) is not a 
timed command, it enters the FIFO, and then is "executed" one
  clock later.  If it has a time associated with it, then it is 
withdrawn when that time has been reached in "vita_time".  Note that 
since this
  is a FIFO, commands that are to be executed "at the same time" will 
be serialized by the inherent FIFO nature of execution.


So, with two DDC settings and two DUC settings all sitting in the FIFO, 
their actual execution times will be 'spread' over (as far as I can tell)
  4 clocks cycles of the FIFO, or about 20nsec.  Now in the case where 
multiple X3xx are involved, the FIFO will look identical across all
  the units, and will execute at the same time, but still be 
serialized.  But if you have two DDC settings across a pair of X3xx, the 
settings
  will execute at exactly the same time, since they will in effect be 
executing in parallel.   Put another way, with shared clocks, and a common
  "view" of system time, parallel FIFOs will get drained in the same 
order and at the same rate.


Someone with a better understanding of the FPGA really should 
comment.But this is my (albeit incomplete) understanding of the

  settings-bus logic the FPGA.

Now, even having said THIS, since you'd expect the FIFO to be 
deterministic.  So, you'd not expect there to be large random

  phase offsets that differ from run to run, I think.



___
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

2020-03-19 Thread Lukas Haase via USRP-users

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" 
An: "Lukas Haase" 
Cc: "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 
    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

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

ote:
>>>
>>>> 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" 
>>>> *An:* "Lukas Haase" 
>>>> *Cc:* "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 relativ

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

y 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" 
>>> *An:* "Lukas Haase" 
>>> *Cc:* "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

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

ow 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" 
>> *An:* "Lukas Haase" 
>> *Cc:* "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

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

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  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" 
> *An:* "Lukas Haase" 
> *Cc:* "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
>

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

2020-03-19 Thread Lukas Haase via USRP-users

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"
An: "Lukas Haase"
Cc: "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_

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

ng
> 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" 
> *An:* "Lukas Haase" 
> *Cc:* "Marcus D Leech" , "
> 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  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" 
>> An: "Lukas Haase" 
>> Cc: "Marcus D Leech" , "
>> 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, tu

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

2020-03-18 Thread Lukas Haase via USRP-users

Hi Marcus,

> Gesendet: Freitag, 13. März 2020 um 13:29 Uhr
> On 03/13/2020 10:52 AM, Lukas Haase 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...
> It depends on whether the phase-accumulator in the DSP is reset to zero, 
> or whether just the increment register is updated with the
> new phase increment.   There are good arguments for both approaches.

As far as I learned the phase accumulator is reset to zero in the x310. Is this 
not the case?

Lukas



___
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

2020-03-18 Thread Lukas Haase via USRP-users

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" 
An: "Lukas Haase" 
Cc: "Marcus D Leech" , "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 t

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

2020-03-13 Thread Marcus D. Leech via USRP-users


On 03/13/2020 10:52 AM, Lukas Haase 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...
It depends on whether the phase-accumulator in the DSP is reset to zero, 
or whether just the increment register is updated with the

  new phase increment.   There are good arguments for both approaches.




Thanks,
Lukas
  
  
  


Gesendet: Freitag, 13. März 2020 um 10:07 Uhr
Von: "Rob Kossler" 
An: "Lukas Haase" 
Cc: "Marcus D Leech" , "USRP-users@lists.ettus.com" 

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

Also, is it true that now you can successfully tune both RF and DSP at the 
desired command time (but the remaining problem is that the Rx phase is not 
consistent when after you tune to a new frequency and then tune back to the 
original)? If this is not correct, please explain again.
Rob

On Fri, Mar 13, 2020 at 9:53 AM Rob Kossler 
mailto:rkoss...@nd.edu]> wrote:
Lukas,
Can you confirm the exact git hash for both UHD and the FPGA image you are 
using? Perhaps the easiest way is to run uhd_usrp_probe.
Rob

On Fri, Mar 13, 2020 at 1:00 AM Lukas Haase 
mailto:lukasha...@gmx.at]> wrote:Dear Marcus, Dear Rob,

Thank you very much for these tips with "Unknown PPS", stream 2 streams and the 
explanation of set_start_time. That makes sense.

Since then I spent hours and hours every day on TX+RX but STILL no synchronized 
phase for dspfreq!
Timed commands seem to work.
Also, in general, synchronization.
With this code, I get my long desired cohrent phase between TX+RX but ONLY if I 
do not touch dsp tuning (and only use the PLL in integer-N mode):

 tune_req_rx = uhd.tune_request()
 tune_req_rx.rf_freq_policy = uhd.tune_request.POLICY_MANUAL
 tune_req_rx.dsp_freq_policy = uhd.tune_request.POLICY_NONE # IMPORTANT!
 tune_req_rx.rf_freq = rf_freq
 tune_req_tx.dsp_freq = -dsp_freq
 tune_req_rx.args=uhd.device_addr(','.join(["mode_n=integer", 
"int_n_step=1000e3",]))

 tune_req_tx = uhd.tune_request()
 tune_req_tx.rf_freq_policy = uhd.tune_request.POLICY_MANUAL
 tune_req_tx.dsp_freq_policy = uhd.tune_request.POLICY_NONE # IMPORTANT!
 tune_req_tx.rf_freq = rf_freq
 tune_req_tx.dsp_freq = dsp_freq
 tune_req_tx.args=uhd.device_addr(','.join(["mode_n=integer", 
"int_n_step=1000e3",]))

 now = usrp_sink.get_time_now()
 when = now + uhd.time_spec(1.0)
 print("Clicked to switch R-T-X frf=" + str(rf_freq) + ", fdsp=" + str(dsp_freq) + " at " + 
str(now.get_full_secs()) + ":" + str(now.get_frac_secs()) + " for " + str(when.get_full_secs()) + ":" + 
str(when.get_frac_secs()))

 usrp_sink.set_command_time(when)
 usrp_source.set_command_time(when)
 res2 = usrp_sink.set_center_freq(tune_req_tx)   # "TX/RX" of first 
UBX160 is transmitter
 res1 = usrp_source.set_center_freq(tune_req_rx, 1)  # "RX2" of second 
UBX160 is receiver
 usrp_sink.clear_command_time()
 usrp_source.clear_command_time()

With phase coherence I mean if I read out the received phase and I switch 
between f1 and f2, I always get the same phase for f1 and f2, respectively.

But if I set dsp_freq_policy to MANUAL (or I add an LO offset which also 
required dsp retuning) I just don't get any coherent phase.

I used the tricks you mentioned:

- I use unknown PPS in both which makes USRP time start at zero (tested)
- Both "USRP Source" and "USRP Sink" have 2 channels (and one of each connects 
to Null Source/Sink). This should ensure that stream start time is set! (tested)
- Even if not, I also used explicitely
tb.uhd_usrp_source_0.set_start_time(uhd.time_spec(10))
tb.uhd_usrp_sink_0.set_start_time(uhd.time_spec(10))
   at the beginning of my flow graph. I see no signal until 10s, as expected
- I experimented with "tx_time" and stream tags but for some reason many timed 
I get flooded with L's


Can it be that there is another bug lurking somewhere deep in the USRP firmware?

Thanks,
Lukas



Gesendet: Mittwoch, 04. März 2020 um 19:27 Uhr
Von: "Marcus D Leech" mailto:patchvonbr...@gmail.com]>
An: "Rob Kossler" mailto:rkoss...@nd.edu]>
Cc: "Lukas Haase" mailto:lukasha...@gmx.at]>, 
"USRP-users@lists.ettus.com[mailto:USR

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  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" 
> An: "Lukas Haase" 
> Cc: "Marcus D Leech" , "
> 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]> 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

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

2020-03-13 Thread Lukas Haase via USRP-users

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" 
An: "Lukas Haase" 
Cc: "Marcus D Leech" , "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 
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
 
 
 

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

Also, is it true that now you can successfully tune both RF and DSP at the 
desired command time (but the remaining problem is that the Rx phase is not 
consistent when after you tune to a new frequency and then tune back to the 
original)? If this is not correct, please explain again.
Rob 

On Fri, Mar 13, 2020 at 9:53 AM Rob Kossler 
mailto:rkoss...@nd.edu][mailto:rkoss...@nd.edu[mailto:rkoss...@nd.edu]]>
 wrote:
Lukas,
Can you confirm the exact git hash for both UHD and the FPGA image you are 
using? Perhaps the easiest way is to run uhd_usrp_probe.
Rob 

On Fri, Mar 13, 2020 at 1:00 AM Lukas Haase 
mailto:lukasha...@gmx.at][mailto:lukasha...@gmx.at[mailto:lukasha...@gmx.at]]>
 wrote:Dear Marcus, Dear Rob,

Thank you very much for these tips with "Unknown PPS", stream 2 streams and the 
explanation of set_start_time. That makes sense.

Since then I spent hours and hours every day on TX+RX but STILL no synchronized 
phase for dspfreq!
Timed commands seem to work.
Also, in general, synchronization.
With this code, I get my long desired cohrent phase between TX+RX but ONLY if I 
do not touch dsp tuning (and only use the PLL in integer-N mode):

        tune_req_rx = uhd.tune_request()
        tune_req_rx.rf_freq_policy = uhd.tune_request.POLICY_MANUAL
        tune_req_rx.dsp_freq_policy = uhd.tune_request.POLICY_NONE # IMPORTANT!
        tune_req_rx.rf_freq = rf_freq
        tune_req_tx.dsp_freq = -dsp_freq
        tune_req_rx.args=uhd.device_addr(','.join(["mode_n=integer", 
"int_n_step=1000e3",]))

        tune_req_tx = uhd.tune_request()
        tune_req_tx.rf_freq_policy = uhd.tune_request.POLICY_MANUAL
        tune_req_tx.dsp_freq_policy = uhd.tune_request.POLICY_NONE # IMPORTANT!
        tune_req_tx.rf_freq = rf_freq
        tune_req_tx.dsp_freq = dsp_freq
        tune_req_tx.args=uhd.device_addr(','.join(["mode_n=integer", 
"int_n_step=1000e3",]))

        now = usrp_sink.get_time_now()
        when = now + uhd.time_spec(1.0)
        print("Clicked to switch R-T-X frf=" + str(rf_freq) + ", fdsp=" + 
str(dsp_freq) + " at " + str(now.get_full_secs()) + ":" + 
str(now.get_frac_secs()) + &qu

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  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
>
>
>
>
> Gesendet: Freitag, 13. März 2020 um 10:07 Uhr
> Von: "Rob Kossler" 
> An: "Lukas Haase" 
> Cc: "Marcus D Leech" , "
> USRP-users@lists.ettus.com" 
> Betreff: Re: [USRP-users] USRP X310 ignored DSP retuning on TX when using
> a timed command
>
> Also, is it true that now you can successfully tune both RF and DSP at the
> desired command time (but the remaining problem is that the Rx phase is not
> consistent when after you tune to a new frequency and then tune back to the
> original)? If this is not correct, please explain again.
> Rob
>
> On Fri, Mar 13, 2020 at 9:53 AM Rob Kossler  rkoss...@nd.edu]> wrote:
> Lukas,
> Can you confirm the exact git hash for both UHD and the FPGA image you are
> using? Perhaps the easiest way is to run uhd_usrp_probe.
> Rob
>
> On Fri, Mar 13, 2020 at 1:00 AM Lukas Haase  lukasha...@gmx.at]> wrote:Dear Marcus, Dear Rob,
>
> Thank you very much for these tips with "Unknown PPS", stream 2 streams
> and the explanation of set_start_time. That makes sense.
>
> Since then I spent hours and hours every day on TX+RX but STILL no
> synchronized phase for dspfreq!
> Timed commands seem to work.
> Also, in general, synchronization.
> With this code, I get my long desired cohrent phase between TX+RX but ONLY
> if I do not touch dsp tuning (and only use the PLL in integer-N mode):
>
> tune_req_rx = uhd.tune_request()
> tune_req_rx.rf_freq_policy = uhd.tune_request.POLICY_MANUAL
> tune_req_rx.dsp_freq_policy = uhd.tune_request.POLICY_NONE #
> IMPORTANT!
> tune_req_rx.rf_freq = rf_freq
> tune_req_tx.dsp_freq = -dsp_freq
> tune_req_rx.args=uhd.device_addr(','.join(["mode_n=integer",
> "int_n_step=1000e3",]))
>
> tune_req_tx = uhd.tune_request()
> tune_req_tx.rf_freq_policy = uhd.tune_request.POLICY_MANUAL
> tune_req_tx.dsp_freq_policy = uhd.tune_request.POLICY_NONE #
> IMPORTANT!
> tune_req_tx.rf_freq = rf_freq
> tune_req_tx.dsp_freq = dsp_freq
> tune_req_tx.args=uhd.device_addr(','.join(["mode_n=integer",
> "int_n_step=1000e3",]))
>
> now = usrp_sink.get_time_now()
> when = now + uhd.time_spec(1.0)
> print("Clicked to switch R-T-X frf=" + str(rf_freq) + ", fdsp=" +
> str(dsp_freq) + " at " + str(now.get_full_secs()) + ":" +
> str(now.get_frac_secs()) + " for " + str(when.get_full_secs()) + ":" +
> str(when.get_frac_secs()))
>
> usrp_sink.set_command_time(when)
> usrp_source.set_command_time(when)
> res2 = usrp_sink.set_center_freq(tune_req_tx)   # "TX/RX" of
> first UBX160 is transmitter
> res1 = usrp_source.set_center_freq(tune_req_rx, 1)  # "RX2" of
> second UBX160 is receiver
> usrp_sink.clear_command_time()
> usrp_source.clear_command_time()
>
> With phase coherence I mean if I read out the received phase and I switch
> between f1 and f2, I always get the same phase for f1 and f2, resp

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

2020-03-13 Thread Lukas Haase via USRP-users

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
 
 
 

Gesendet: Freitag, 13. März 2020 um 10:07 Uhr
Von: "Rob Kossler" 
An: "Lukas Haase" 
Cc: "Marcus D Leech" , "USRP-users@lists.ettus.com" 

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

Also, is it true that now you can successfully tune both RF and DSP at the 
desired command time (but the remaining problem is that the Rx phase is not 
consistent when after you tune to a new frequency and then tune back to the 
original)? If this is not correct, please explain again.
Rob 

On Fri, Mar 13, 2020 at 9:53 AM Rob Kossler 
mailto:rkoss...@nd.edu]> wrote:
Lukas,
Can you confirm the exact git hash for both UHD and the FPGA image you are 
using? Perhaps the easiest way is to run uhd_usrp_probe.
Rob 

On Fri, Mar 13, 2020 at 1:00 AM Lukas Haase 
mailto:lukasha...@gmx.at]> wrote:Dear Marcus, Dear Rob,

Thank you very much for these tips with "Unknown PPS", stream 2 streams and the 
explanation of set_start_time. That makes sense.

Since then I spent hours and hours every day on TX+RX but STILL no synchronized 
phase for dspfreq!
Timed commands seem to work.
Also, in general, synchronization.
With this code, I get my long desired cohrent phase between TX+RX but ONLY if I 
do not touch dsp tuning (and only use the PLL in integer-N mode):

        tune_req_rx = uhd.tune_request()
        tune_req_rx.rf_freq_policy = uhd.tune_request.POLICY_MANUAL
        tune_req_rx.dsp_freq_policy = uhd.tune_request.POLICY_NONE # IMPORTANT!
        tune_req_rx.rf_freq = rf_freq
        tune_req_tx.dsp_freq = -dsp_freq
        tune_req_rx.args=uhd.device_addr(','.join(["mode_n=integer", 
"int_n_step=1000e3",]))

        tune_req_tx = uhd.tune_request()
        tune_req_tx.rf_freq_policy = uhd.tune_request.POLICY_MANUAL
        tune_req_tx.dsp_freq_policy = uhd.tune_request.POLICY_NONE # IMPORTANT!
        tune_req_tx.rf_freq = rf_freq
        tune_req_tx.dsp_freq = dsp_freq
        tune_req_tx.args=uhd.device_addr(','.join(["mode_n=integer", 
"int_n_step=1000e3",]))

        now = usrp_sink.get_time_now()
        when = now + uhd.time_spec(1.0)
        print("Clicked to switch R-T-X frf=" + str(rf_freq) + ", fdsp=" + 
str(dsp_freq) + " at " + str(now.get_full_secs()) + ":" + 
str(now.get_frac_secs()) + " for " + str(when.get_full_secs()) + ":" + 
str(when.get_frac_secs()))

        usrp_sink.set_command_time(when)
        usrp_source.set_command_time(when)
        res2 = usrp_sink.set_center_freq(tune_req_tx)       # "TX/RX" of first 
UBX160 is transmitter
        res1 = usrp_source.set_center_freq(tune_req_rx, 1)  # "RX2" of second 
UBX160 is receiver
        usrp_sink.clear_command_time()
        usrp_source.clear_command_time()

With phase coherence I mean if I read out the received phase and I switch 
between f1 and f2, I always get the same phase for f1 and f2, respectively.

But if I set dsp_freq_policy to MANUAL (or I add an LO offset which also 
required dsp retuning) I just don't get any coherent phase.

I used the tricks you mentioned:

- I use unknown PPS in both which makes USRP time start at zero (tested)
- Both "USRP Source" and "USRP Sink" have 2 channels (and one of each connects 
to Null Source/Sink). This should ensure that stream start time is set! (tested)
- Even if not, I also used explicitely
   tb.uhd_usrp_source_0.set_start_time(uhd.time_spec(10))
   tb.uhd_usrp_sink_0.set_start_time(uhd.time_spec(10))
  at the beginning of my flow graph. I see no signal until 10s, as expected
- I experimented with "tx_time" and stream tags but for some reason many timed 
I get flooded with L's


Can it be that there is another bug lurking somewhere deep in the USRP firmware?

Thanks,
Lukas



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

When you select one of the PPS synch options in a GRC USRP block it will set 
the time to zero. 
 
Easy enough to

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

2020-03-13 Thread Lukas Haase via USRP-users

|   |   | _
|   |   |/
|   |   |   |   TX Frontend: 0
|   |   |   |   Name: UBX TX
|   |   |   |   Antennas: TX/RX, CAL
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 10.000 to 6000.000 MHz
|   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
|   |   |   |   Bandwidth range: 16000.0 to 16000.0 step 0.0 Hz
|   |   |   |   Connection Type: QI
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   TX Codec: B
|   |   |   |   Name: ad9146
|   |   |   |   Gain Elements: None
|   | _
|   |/
|   |   |   RFNoC blocks on this device:
|   |   |
|   |   |   * DmaFIFO_0
|   |   |   * Radio_0
|   |   |   * Radio_1
|   |   |   * DDC_0
|   |   |   * DDC_1
|   |   |   * DUC_0
|   |   |   * DUC_1


Thanks!
Lukas
 
 

Gesendet: Freitag, 13. März 2020 um 09:53 Uhr
Von: "Rob Kossler" 
An: "Lukas Haase" 
Cc: "Marcus D Leech" , "USRP-users@lists.ettus.com" 

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

Lukas,
Can you confirm the exact git hash for both UHD and the FPGA image you are 
using? Perhaps the easiest way is to run uhd_usrp_probe.
Rob 

On Fri, Mar 13, 2020 at 1:00 AM Lukas Haase 
mailto:lukasha...@gmx.at]> wrote:Dear Marcus, Dear Rob,

Thank you very much for these tips with "Unknown PPS", stream 2 streams and the 
explanation of set_start_time. That makes sense.

Since then I spent hours and hours every day on TX+RX but STILL no synchronized 
phase for dspfreq!
Timed commands seem to work.
Also, in general, synchronization.
With this code, I get my long desired cohrent phase between TX+RX but ONLY if I 
do not touch dsp tuning (and only use the PLL in integer-N mode):

        tune_req_rx = uhd.tune_request()
        tune_req_rx.rf_freq_policy = uhd.tune_request.POLICY_MANUAL
        tune_req_rx.dsp_freq_policy = uhd.tune_request.POLICY_NONE # IMPORTANT!
        tune_req_rx.rf_freq = rf_freq
        tune_req_tx.dsp_freq = -dsp_freq
        tune_req_rx.args=uhd.device_addr(','.join(["mode_n=integer", 
"int_n_step=1000e3",]))

        tune_req_tx = uhd.tune_request()
        tune_req_tx.rf_freq_policy = uhd.tune_request.POLICY_MANUAL
        tune_req_tx.dsp_freq_policy = uhd.tune_request.POLICY_NONE # IMPORTANT!
        tune_req_tx.rf_freq = rf_freq
        tune_req_tx.dsp_freq = dsp_freq
        tune_req_tx.args=uhd.device_addr(','.join(["mode_n=integer", 
"int_n_step=1000e3",]))

        now = usrp_sink.get_time_now()
        when = now + uhd.time_spec(1.0)
        print("Clicked to switch R-T-X frf=" + str(rf_freq) + ", fdsp=" + 
str(dsp_freq) + " at " + str(now.get_full_secs()) + ":" + 
str(now.get_frac_secs()) + " for " + str(when.get_full_secs()) + ":" + 
str(when.get_frac_secs()))

        usrp_sink.set_command_time(when)
        usrp_source.set_command_time(when)
        res2 = usrp_sink.set_center_freq(tune_req_tx)       # "TX/RX" of first 
UBX160 is transmitter
        res1 = usrp_source.set_center_freq(tune_req_rx, 1)  # "RX2" of second 
UBX160 is receiver
        usrp_sink.clear_command_time()
        usrp_source.clear_command_time()

With phase coherence I mean if I read out the received phase and I switch 
between f1 and f2, I always get the same phase for f1 and f2, respectively.

But if I set dsp_freq_policy to MANUAL (or I add an LO offset which also 
required dsp retuning) I just don't get any coherent phase.

I used the tricks you mentioned:

- I use unknown PPS in both which makes USRP time start at zero (tested)
- Both "USRP Source" and "USRP Sink" have 2 channels (and one of each connects 
to Null Source/Sink). This should ensure that stream start time is set! (tested)
- Even if not, I also used explicitely
   tb.uhd_usrp_source_0.set_start_time(uhd.time_spec(10))
   tb.uhd_usrp_sink_0.set_start_time(uhd.time_spec(10))
  at the beginning of my flow graph. I see no signal until 10s, as expected
- I experimented with "tx_time" and stream tags but for some reason many timed 
I get flooded with L's


Can it be that there is another bug lurking somewhere deep in the USRP firmware?

Thanks,
Lukas



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

When you select one of the PPS synch options in a GRC USRP block it will set 
the time to zero. 
 
Easy e

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

Also, is it true that now you can successfully tune both RF and DSP at the
desired command time (but the remaining problem is that the Rx phase is not
consistent when after you tune to a new frequency and then tune back to the
original)? If this is not correct, please explain again.
Rob

On Fri, Mar 13, 2020 at 9:53 AM Rob Kossler  wrote:

> Lukas,
> Can you confirm the exact git hash for both UHD and the FPGA image you are
> using? Perhaps the easiest way is to run uhd_usrp_probe.
> Rob
>
> On Fri, Mar 13, 2020 at 1:00 AM Lukas Haase  wrote:
>
>> Dear Marcus, Dear Rob,
>>
>> Thank you very much for these tips with "Unknown PPS", stream 2 streams
>> and the explanation of set_start_time. That makes sense.
>>
>> Since then I spent hours and hours every day on TX+RX but STILL no
>> synchronized phase for dspfreq!
>> Timed commands seem to work.
>> Also, in general, synchronization.
>> With this code, I get my long desired cohrent phase between TX+RX but
>> ONLY if I do not touch dsp tuning (and only use the PLL in integer-N mode):
>>
>> tune_req_rx = uhd.tune_request()
>> tune_req_rx.rf_freq_policy = uhd.tune_request.POLICY_MANUAL
>> tune_req_rx.dsp_freq_policy = uhd.tune_request.POLICY_NONE #
>> IMPORTANT!
>> tune_req_rx.rf_freq = rf_freq
>> tune_req_tx.dsp_freq = -dsp_freq
>> tune_req_rx.args=uhd.device_addr(','.join(["mode_n=integer",
>> "int_n_step=1000e3",]))
>>
>> tune_req_tx = uhd.tune_request()
>> tune_req_tx.rf_freq_policy = uhd.tune_request.POLICY_MANUAL
>> tune_req_tx.dsp_freq_policy = uhd.tune_request.POLICY_NONE #
>> IMPORTANT!
>> tune_req_tx.rf_freq = rf_freq
>> tune_req_tx.dsp_freq = dsp_freq
>> tune_req_tx.args=uhd.device_addr(','.join(["mode_n=integer",
>> "int_n_step=1000e3",]))
>>
>> now = usrp_sink.get_time_now()
>> when = now + uhd.time_spec(1.0)
>> print("Clicked to switch R-T-X frf=" + str(rf_freq) + ", fdsp=" +
>> str(dsp_freq) + " at " + str(now.get_full_secs()) + ":" +
>> str(now.get_frac_secs()) + " for " + str(when.get_full_secs()) + ":" +
>> str(when.get_frac_secs()))
>>
>> usrp_sink.set_command_time(when)
>> usrp_source.set_command_time(when)
>> res2 = usrp_sink.set_center_freq(tune_req_tx)   # "TX/RX" of
>> first UBX160 is transmitter
>> res1 = usrp_source.set_center_freq(tune_req_rx, 1)  # "RX2" of
>> second UBX160 is receiver
>> usrp_sink.clear_command_time()
>> usrp_source.clear_command_time()
>>
>> With phase coherence I mean if I read out the received phase and I switch
>> between f1 and f2, I always get the same phase for f1 and f2, respectively.
>>
>> But if I set dsp_freq_policy to MANUAL (or I add an LO offset which also
>> required dsp retuning) I just don't get any coherent phase.
>>
>> I used the tricks you mentioned:
>>
>> - I use unknown PPS in both which makes USRP time start at zero (tested)
>> - Both "USRP Source" and "USRP Sink" have 2 channels (and one of each
>> connects to Null Source/Sink). This should ensure that stream start time is
>> set! (tested)
>> - Even if not, I also used explicitely
>>tb.uhd_usrp_source_0.set_start_time(uhd.time_spec(10))
>>tb.uhd_usrp_sink_0.set_start_time(uhd.time_spec(10))
>>   at the beginning of my flow graph. I see no signal until 10s, as
>> expected
>> - I experimented with "tx_time" and stream tags but for some reason many
>> timed I get flooded with L's
>>
>>
>> Can it be that there is another bug lurking somewhere deep in the USRP
>> firmware?
>>
>> Thanks,
>> Lukas
>>
>>
>>
>> Gesendet: Mittwoch, 04. März 2020 um 19:27 Uhr
>> Von: "Marcus D Leech" 
>> An: "Rob Kossler" 
>> Cc: "Lukas Haase" , "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
>>
>> When you select one of the PPS synch options in a GRC USRP block it will
>> set the time to zero.
>>
>> Easy enough to modify the code to do something more sophisticated, but
>> knowing that it will be set to zero helps you know how to proceed.
>>
>>
>> Sent from my iPhone
>>  On Mar 4, 2020,

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

Lukas,
Can you confirm the exact git hash for both UHD and the FPGA image you are
using? Perhaps the easiest way is to run uhd_usrp_probe.
Rob

On Fri, Mar 13, 2020 at 1:00 AM Lukas Haase  wrote:

> Dear Marcus, Dear Rob,
>
> Thank you very much for these tips with "Unknown PPS", stream 2 streams
> and the explanation of set_start_time. That makes sense.
>
> Since then I spent hours and hours every day on TX+RX but STILL no
> synchronized phase for dspfreq!
> Timed commands seem to work.
> Also, in general, synchronization.
> With this code, I get my long desired cohrent phase between TX+RX but ONLY
> if I do not touch dsp tuning (and only use the PLL in integer-N mode):
>
> tune_req_rx = uhd.tune_request()
> tune_req_rx.rf_freq_policy = uhd.tune_request.POLICY_MANUAL
> tune_req_rx.dsp_freq_policy = uhd.tune_request.POLICY_NONE #
> IMPORTANT!
> tune_req_rx.rf_freq = rf_freq
> tune_req_tx.dsp_freq = -dsp_freq
> tune_req_rx.args=uhd.device_addr(','.join(["mode_n=integer",
> "int_n_step=1000e3",]))
>
> tune_req_tx = uhd.tune_request()
> tune_req_tx.rf_freq_policy = uhd.tune_request.POLICY_MANUAL
> tune_req_tx.dsp_freq_policy = uhd.tune_request.POLICY_NONE #
> IMPORTANT!
> tune_req_tx.rf_freq = rf_freq
> tune_req_tx.dsp_freq = dsp_freq
> tune_req_tx.args=uhd.device_addr(','.join(["mode_n=integer",
> "int_n_step=1000e3",]))
>
> now = usrp_sink.get_time_now()
> when = now + uhd.time_spec(1.0)
> print("Clicked to switch R-T-X frf=" + str(rf_freq) + ", fdsp=" +
> str(dsp_freq) + " at " + str(now.get_full_secs()) + ":" +
> str(now.get_frac_secs()) + " for " + str(when.get_full_secs()) + ":" +
> str(when.get_frac_secs()))
>
> usrp_sink.set_command_time(when)
> usrp_source.set_command_time(when)
> res2 = usrp_sink.set_center_freq(tune_req_tx)   # "TX/RX" of
> first UBX160 is transmitter
> res1 = usrp_source.set_center_freq(tune_req_rx, 1)  # "RX2" of
> second UBX160 is receiver
> usrp_sink.clear_command_time()
> usrp_source.clear_command_time()
>
> With phase coherence I mean if I read out the received phase and I switch
> between f1 and f2, I always get the same phase for f1 and f2, respectively.
>
> But if I set dsp_freq_policy to MANUAL (or I add an LO offset which also
> required dsp retuning) I just don't get any coherent phase.
>
> I used the tricks you mentioned:
>
> - I use unknown PPS in both which makes USRP time start at zero (tested)
> - Both "USRP Source" and "USRP Sink" have 2 channels (and one of each
> connects to Null Source/Sink). This should ensure that stream start time is
> set! (tested)
> - Even if not, I also used explicitely
>tb.uhd_usrp_source_0.set_start_time(uhd.time_spec(10))
>tb.uhd_usrp_sink_0.set_start_time(uhd.time_spec(10))
>   at the beginning of my flow graph. I see no signal until 10s, as expected
> - I experimented with "tx_time" and stream tags but for some reason many
> timed I get flooded with L's
>
>
> Can it be that there is another bug lurking somewhere deep in the USRP
> firmware?
>
> Thanks,
> Lukas
>
>
>
> Gesendet: Mittwoch, 04. März 2020 um 19:27 Uhr
> Von: "Marcus D Leech" 
> An: "Rob Kossler" 
> Cc: "Lukas Haase" , "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
>
> When you select one of the PPS synch options in a GRC USRP block it will
> set the time to zero.
>
> Easy enough to modify the code to do something more sophisticated, but
> knowing that it will be set to zero helps you know how to proceed.
>
>
> Sent from my iPhone
>  On Mar 4, 2020, at 12:43 PM, Rob Kossler via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> 
>
> Regarding #2)
> I don't think that what you want is a "command" tag, but rather a "time
> stamp tag" which I believe is "tx_time" based on the link you provided to
> the documentation.  The documentation says, "The timestamp tag value is a
> PMT tuple of the following: (uint64 seconds, double fractional seconds)".
> If I am correct, perhaps the code snipped you provided will not come into
> play.
>
> Just to be clear, I don't think you should need to do both #1 and #2.
> But, I "believe" that either method should be possible to accomplish the
> goa

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

2020-03-12 Thread Lukas Haase via USRP-users

Dear Marcus, Dear Rob,

Thank you very much for these tips with "Unknown PPS", stream 2 streams and the 
explanation of set_start_time. That makes sense.

Since then I spent hours and hours every day on TX+RX but STILL no synchronized 
phase for dspfreq!
Timed commands seem to work.
Also, in general, synchronization.
With this code, I get my long desired cohrent phase between TX+RX but ONLY if I 
do not touch dsp tuning (and only use the PLL in integer-N mode):

tune_req_rx = uhd.tune_request()
tune_req_rx.rf_freq_policy = uhd.tune_request.POLICY_MANUAL
tune_req_rx.dsp_freq_policy = uhd.tune_request.POLICY_NONE # IMPORTANT!
tune_req_rx.rf_freq = rf_freq
tune_req_tx.dsp_freq = -dsp_freq
tune_req_rx.args=uhd.device_addr(','.join(["mode_n=integer", 
"int_n_step=1000e3",]))

tune_req_tx = uhd.tune_request()
tune_req_tx.rf_freq_policy = uhd.tune_request.POLICY_MANUAL
tune_req_tx.dsp_freq_policy = uhd.tune_request.POLICY_NONE # IMPORTANT!
tune_req_tx.rf_freq = rf_freq
tune_req_tx.dsp_freq = dsp_freq
tune_req_tx.args=uhd.device_addr(','.join(["mode_n=integer", 
"int_n_step=1000e3",]))

now = usrp_sink.get_time_now()
when = now + uhd.time_spec(1.0)
print("Clicked to switch R-T-X frf=" + str(rf_freq) + ", fdsp=" + 
str(dsp_freq) + " at " + str(now.get_full_secs()) + ":" + 
str(now.get_frac_secs()) + " for " + str(when.get_full_secs()) + ":" + 
str(when.get_frac_secs()))

usrp_sink.set_command_time(when)
usrp_source.set_command_time(when)
res2 = usrp_sink.set_center_freq(tune_req_tx)   # "TX/RX" of first 
UBX160 is transmitter
res1 = usrp_source.set_center_freq(tune_req_rx, 1)  # "RX2" of second 
UBX160 is receiver
usrp_sink.clear_command_time()
usrp_source.clear_command_time()

With phase coherence I mean if I read out the received phase and I switch 
between f1 and f2, I always get the same phase for f1 and f2, respectively.

But if I set dsp_freq_policy to MANUAL (or I add an LO offset which also 
required dsp retuning) I just don't get any coherent phase.

I used the tricks you mentioned:

- I use unknown PPS in both which makes USRP time start at zero (tested)
- Both "USRP Source" and "USRP Sink" have 2 channels (and one of each connects 
to Null Source/Sink). This should ensure that stream start time is set! (tested)
- Even if not, I also used explicitely
   tb.uhd_usrp_source_0.set_start_time(uhd.time_spec(10))
   tb.uhd_usrp_sink_0.set_start_time(uhd.time_spec(10))
  at the beginning of my flow graph. I see no signal until 10s, as expected
- I experimented with "tx_time" and stream tags but for some reason many timed 
I get flooded with L's


Can it be that there is another bug lurking somewhere deep in the USRP firmware?

Thanks,
Lukas



Gesendet: Mittwoch, 04. März 2020 um 19:27 Uhr
Von: "Marcus D Leech" 
An: "Rob Kossler" 
Cc: "Lukas Haase" , "USRP-users@lists.ettus.com" 

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

When you select one of the PPS synch options in a GRC USRP block it will set 
the time to zero. 
 
Easy enough to modify the code to do something more sophisticated, but knowing 
that it will be set to zero helps you know how to proceed. 
 
 
Sent from my iPhone
 On Mar 4, 2020, at 12:43 PM, Rob Kossler via USRP-users 
 wrote:
 


Regarding #2)
I don't think that what you want is a "command" tag, but rather a "time stamp 
tag" which I believe is "tx_time" based on the link you provided to the 
documentation.  The documentation says, "The timestamp tag value is a PMT tuple 
of the following: (uint64 seconds, double fractional seconds)".  If I am 
correct, perhaps the code snipped you provided will not come into play.
 
Just to be clear, I don't think you should need to do both #1 and #2.  But, I 
"believe" that either method should be possible to accomplish the goal of 
attaching a time stamp to the streaming.  
 
Also, keep in mind that the time stamp that you provide to the DUC block for 
the freq change is related to the time stamp you attach to the streaming 
samples.  Let me explain with a few remarks:

If you apply the time stamp of 0.5 to the streaming samples, then the first 
sample will have time 0.5 and then UHD will keep track of all subsequent 
samples to know the absolute time of any given sample.  I am assuming that once 
you start transmitting you will keep transmitting continuously until the flow 
graph ends.If you then start hopping your DUC with time stamps such as 0.6, 
0.7, 0.8, etc, then UHD should apply the hop at the correct part of the stream 
since it knows the tim

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

2020-03-04 Thread Marcus D Leech via USRP-users

annoying is 
>>> that I have two objects for the same device (*one* USRP and "USRP 
>>> Source"+"USRP Sink", both with their independent uhd::usrp::multi_usrp 
>>> objects. My question is, is it possible to just use "USRP Source" (this is 
>>> where timed commands work) to execute the retuning for *both* RX+TX?
>>> 
>>> 3.a.) Given: X310 with 2xUBX-160. What is the subdev spec if I wanted to 
>>> receive on all FOUR inputs??
>>> The problem is that both RX and TX frontends have the same name "0" 
>>> (according to uhd_usrp_probe).
>>> 
>>> Two receivers, receiving both from "TX/RX" input of each UBX-160 would be 
>>> trivial: "A:0 B:0". However, how do I address "RX2"? Intuitively "A:0 A:1 
>>> B:0 B:1" but as said, both "TX/RX" and "RX2" are named "0".
>>> What would I do if I wanted to transmit from "TX/RX" of the second UBX and 
>>> receive on all other boards?
>>> 
>>> On the USRP Sink: "B:0"
>>> On the USP Source intuitively: "A:0 A:1 B:1" but that's wrong.
>>> 
>>> 3.b.) In gr, there will be two multi_usrp objects: One for the receiver 
>>> (member variable of USRP Source) and one for the transmitter (member 
>>> variable of USRP Sink).
>>> Can I set up a USRP Source that has two channels where the second one is 
>>> actually a TX channel? (only used for retuning via timed commands)?
>>> 
>>> 
>>> Thanks,
>>> Lukas
>>> 
>>> 
>>>  
>>>  
>>> 
>>> Gesendet: Dienstag, 03. März 2020 um 15:22 Uhr
>>> Von: "Rob Kossler" 
>>> An: "Lukas Haase" 
>>> Cc: "Sam Reiter" , "USRP-users@lists.ettus.com" 
>>> 
>>> Betreff: Re: [USRP-users] USRP X310 ignored DSP retuning on TX when using a 
>>> timed command
>>> 
>>> I did a quick google search using "gnuradio uhd timed tx streaming". I 
>>> found that the GR 
>>> usrp_sink[https://www.gnuradio.org/doc/sphinx-3.7.7/uhd.html] has the 
>>> function "set_start_time" which seems to be what you need.  The question 
>>> is: what time do you set?  Probably just something like "get_time_now() + 
>>> 0.1". It may be a bit tricky since this value is to be set before starting 
>>> the flow graph.  Maybe you could set it to some fixed constant like 0.5 and 
>>> then when the flow graph starts you could execute a command to 
>>> set_time_now() to 0.0.  Anyway, if this advice doesn't pan out, perhaps 
>>> just search around a bit in GR archives.  I'm sure others have successfully 
>>> streamed with timed Tx commands.
>>> Rob 
>>> 
>>> On Tue, Mar 3, 2020 at 3:00 PM Lukas Haase 
>>> mailto:lukasha...@gmx.at]> wrote:
>>> 
>>> Hi Sam, Hi Rob,
>>> 
>>> This makes so much sense!
>>> I think you are right.
>>> And indeed, the issue I found only with TX, not RX.
>>> 
>>> 
>>> Could you think of a possible hack sending a "dummy command" to the RF 
>>> board along with the timed tuning request?
>>> 
>>> 
>>> Regarding the sending of time stamps in the TX in gr-uhd, I am confused 
>>> though. I do think this IS happening. I reproduce the work function of 
>>> "USRP Sink" here:
>>> 
>>> int usrp_sink_impl::work(int noutput_items,
>>>  gr_vector_const_void_star& input_items,
>>>  gr_vector_void_star& output_items)
>>> {
>>> int ninput_items = noutput_items; // cuz it's a sync block
>>> 
>>> // default to send a mid-burst packet
>>> _metadata.start_of_burst = false;
>>> _metadata.end_of_burst = false;
>>> 
>>> // collect tags in this work()
>>> const uint64_t samp0_count = nitems_read(0);
>>> get_tags_in_range(_tags, 0, samp0_count, samp0_count + ninput_items);
>>> if (not _tags.empty())
>>> this->tag_work(ninput_items);
>>> 
>>> if (not pmt::is_null(_length_tag_key)) {
>>> // check if there is data left to send from a burst tagged with 
>>> length_tag
>>> // If a burst is started during this call to work(), tag_work() 
>>> should have
>>> // been called and we should have _nitems_to_se

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

2020-03-04 Thread Rob Kossler via USRP-users

e from the sample time
>>> msg_handler_command(value);
>>> }
>>>
>>> 3.) So I am really back to the start. What is generally a bit annoying
>>> is that I have two objects for the same device (*one* USRP and "USRP
>>> Source"+"USRP Sink", both with their independent uhd::usrp::multi_usrp
>>> objects. My question is, is it possible to just use "USRP Source" (this is
>>> where timed commands work) to execute the retuning for *both* RX+TX?
>>>
>>> 3.a.) Given: X310 with 2xUBX-160. What is the subdev spec if I wanted to
>>> receive on all FOUR inputs??
>>> The problem is that both RX and TX frontends have the same name "0"
>>> (according to uhd_usrp_probe).
>>>
>>> Two receivers, receiving both from "TX/RX" input of each UBX-160 would
>>> be trivial: "A:0 B:0". However, how do I address "RX2"? Intuitively "A:0
>>> A:1 B:0 B:1" but as said, both "TX/RX" and "RX2" are named "0".
>>> What would I do if I wanted to transmit from "TX/RX" of the second UBX
>>> and receive on all other boards?
>>>
>>> On the USRP Sink: "B:0"
>>> On the USP Source intuitively: "A:0 A:1 B:1" but that's wrong.
>>>
>>> 3.b.) In gr, there will be two multi_usrp objects: One for the receiver
>>> (member variable of USRP Source) and one for the transmitter (member
>>> variable of USRP Sink).
>>> Can I set up a USRP Source that has two channels where the second one is
>>> actually a TX channel? (only used for retuning via timed commands)?
>>>
>>>
>>> Thanks,
>>> Lukas
>>>
>>>
>>>
>>>
>>>
>>> Gesendet: Dienstag, 03. März 2020 um 15:22 Uhr
>>> Von: "Rob Kossler" 
>>> An: "Lukas Haase" 
>>> Cc: "Sam Reiter" , "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
>>>
>>> I did a quick google search using "gnuradio uhd timed tx streaming". I
>>> found that the GR usrp_sink[
>>> https://www.gnuradio.org/doc/sphinx-3.7.7/uhd.html] has the function
>>> "set_start_time" which seems to be what you need.  The question is: what
>>> time do you set?  Probably just something like "get_time_now() + 0.1". It
>>> may be a bit tricky since this value is to be set before starting the flow
>>> graph.  Maybe you could set it to some fixed constant like 0.5 and then
>>> when the flow graph starts you could execute a command to set_time_now() to
>>> 0.0.  Anyway, if this advice doesn't pan out, perhaps just search around a
>>> bit in GR archives.  I'm sure others have successfully streamed with timed
>>> Tx commands.
>>> Rob
>>>
>>> On Tue, Mar 3, 2020 at 3:00 PM Lukas Haase >> lukasha...@gmx.at]> wrote:
>>>
>>> Hi Sam, Hi Rob,
>>>
>>> This makes so much sense!
>>> I think you are right.
>>> And indeed, the issue I found only with TX, not RX.
>>>
>>>
>>> Could you think of a possible hack sending a "dummy command" to the RF
>>> board along with the timed tuning request?
>>>
>>>
>>> Regarding the sending of time stamps in the TX in gr-uhd, I am confused
>>> though. I do think this IS happening. I reproduce the work function of
>>> "USRP Sink" here:
>>>
>>> int usrp_sink_impl::work(int noutput_items,
>>>  gr_vector_const_void_star& input_items,
>>>  gr_vector_void_star& output_items)
>>> {
>>> int ninput_items = noutput_items; // cuz it's a sync block
>>>
>>> // default to send a mid-burst packet
>>> _metadata.start_of_burst = false;
>>> _metadata.end_of_burst = false;
>>>
>>> // collect tags in this work()
>>> const uint64_t samp0_count = nitems_read(0);
>>> get_tags_in_range(_tags, 0, samp0_count, samp0_count + ninput_items);
>>> if (not _tags.empty())
>>> this->tag_work(ninput_items);
>>>
>>> if (not pmt::is_null(_length_tag_key)) {
>>> // check if there is data left to send from a burst tagged with
>>> length_tag
>>>

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

2020-03-04 Thread Rob Kossler via USRP-users

uot; input of each UBX-160 would be
>> trivial: "A:0 B:0". However, how do I address "RX2"? Intuitively "A:0 A:1
>> B:0 B:1" but as said, both "TX/RX" and "RX2" are named "0".
>> What would I do if I wanted to transmit from "TX/RX" of the second UBX
>> and receive on all other boards?
>>
>> On the USRP Sink: "B:0"
>> On the USP Source intuitively: "A:0 A:1 B:1" but that's wrong.
>>
>> 3.b.) In gr, there will be two multi_usrp objects: One for the receiver
>> (member variable of USRP Source) and one for the transmitter (member
>> variable of USRP Sink).
>> Can I set up a USRP Source that has two channels where the second one is
>> actually a TX channel? (only used for retuning via timed commands)?
>>
>>
>> Thanks,
>> Lukas
>>
>>
>>
>>
>>
>> Gesendet: Dienstag, 03. März 2020 um 15:22 Uhr
>> Von: "Rob Kossler" 
>> An: "Lukas Haase" 
>> Cc: "Sam Reiter" , "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
>>
>> I did a quick google search using "gnuradio uhd timed tx streaming". I
>> found that the GR usrp_sink[
>> https://www.gnuradio.org/doc/sphinx-3.7.7/uhd.html] has the function
>> "set_start_time" which seems to be what you need.  The question is: what
>> time do you set?  Probably just something like "get_time_now() + 0.1". It
>> may be a bit tricky since this value is to be set before starting the flow
>> graph.  Maybe you could set it to some fixed constant like 0.5 and then
>> when the flow graph starts you could execute a command to set_time_now() to
>> 0.0.  Anyway, if this advice doesn't pan out, perhaps just search around a
>> bit in GR archives.  I'm sure others have successfully streamed with timed
>> Tx commands.
>> Rob
>>
>> On Tue, Mar 3, 2020 at 3:00 PM Lukas Haase > lukasha...@gmx.at]> wrote:
>>
>> Hi Sam, Hi Rob,
>>
>> This makes so much sense!
>> I think you are right.
>> And indeed, the issue I found only with TX, not RX.
>>
>>
>> Could you think of a possible hack sending a "dummy command" to the RF
>> board along with the timed tuning request?
>>
>>
>> Regarding the sending of time stamps in the TX in gr-uhd, I am confused
>> though. I do think this IS happening. I reproduce the work function of
>> "USRP Sink" here:
>>
>> int usrp_sink_impl::work(int noutput_items,
>>  gr_vector_const_void_star& input_items,
>>  gr_vector_void_star& output_items)
>> {
>> int ninput_items = noutput_items; // cuz it's a sync block
>>
>> // default to send a mid-burst packet
>> _metadata.start_of_burst = false;
>> _metadata.end_of_burst = false;
>>
>> // collect tags in this work()
>> const uint64_t samp0_count = nitems_read(0);
>> get_tags_in_range(_tags, 0, samp0_count, samp0_count + ninput_items);
>> if (not _tags.empty())
>> this->tag_work(ninput_items);
>>
>> if (not pmt::is_null(_length_tag_key)) {
>> // check if there is data left to send from a burst tagged with
>> length_tag
>> // If a burst is started during this call to work(), tag_work()
>> should have
>> // been called and we should have _nitems_to_send > 0.
>> if (_nitems_to_send > 0) {
>> ninput_items = std::min(_nitems_to_send, ninput_items);
>> // if we run out of items to send, it's the end of the burst
>> if (_nitems_to_send - long(ninput_items) == 0)
>> _metadata.end_of_burst = true;
>> } else {
>> // There is a tag gap since no length_tag was found
>> immediately following
>> // the last sample of the previous burst. Drop samples until
>> the next
>> // length_tag is found. Notify the user of the tag gap.
>> std::cerr << "tG" << std::flush;
>> // increment the timespec by the number of samples dropped
>> _metadata.time_spec += ::uhd::time_spec_t(0, ninput_items,
>> _sample_rate);
>> return ninput_items;
>> }
>> }
>>
>> boost::this_thread::disable_interruption disable_interrupt;
>>

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

2020-03-04 Thread Rob Kossler via USRP-users

Hi Lukas,
Let me respond to #1 right away.  The "set_start_time" function sets the
time of the tx stream.  It does not set the "clock time" on the usrp.  If
you are indeed correct that the "clock time" on the usrp is initialized to
0.0 at the start of the GR run, then you are lucky and all you should need
to do is use the "set_start_time" function with a time spec of something
like 0.2 or 0.5 (any time after 0.0 with perhaps a little delay built in).
To see if it is working, you could set the time spec to something very
large like 5.0 or 10.0 and then you should see the GR run start up but no
Tx for the next 5 or 10 seconds.  Then the Tx should start.  Does that make
sense?
Rob


On Wed, Mar 4, 2020 at 12:06 PM Lukas Haase  wrote:

> Hi Rob,
>
> 1.) I do not really understand how "set_start_time" is related to my
> problem and why this is what I need. Based on my experiments, the time is
> automatically set to 0 when the flow diagram starts.
>
> I am also sure others must have used timed TX+RX but it does not seem so.
> No kidding, I am working on this since Dec and I still do not have it
> working. I left my traces various times on this and the gnuradio mailing
> list but I did not get help.
>
> 2.) I have played around using stream tags and was very happy that it
> worked but I found now that this is because gr-uhd does NOT attach a
> command time although the documentation says so.
>
> https://www.gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__sink.html:
> tx_command tag. The command is attached to a sample, and will executed
> before the sample is transmitted, and after the previous sample.
>
> However, in the code (usrp_sink_impl.cc:433, usrp_sink_impl::tag_work):
>
> else if (pmt::equal(key, COMMAND_KEY)) {
> if (my_tag_count != samp0_count) {
> max_count = my_tag_count;
> break;
> }
> // TODO set the command time from the sample time
> msg_handler_command(value);
> }
>
> 3.) So I am really back to the start. What is generally a bit annoying is
> that I have two objects for the same device (*one* USRP and "USRP
> Source"+"USRP Sink", both with their independent uhd::usrp::multi_usrp
> objects. My question is, is it possible to just use "USRP Source" (this is
> where timed commands work) to execute the retuning for *both* RX+TX?
>
> 3.a.) Given: X310 with 2xUBX-160. What is the subdev spec if I wanted to
> receive on all FOUR inputs??
> The problem is that both RX and TX frontends have the same name "0"
> (according to uhd_usrp_probe).
>
> Two receivers, receiving both from "TX/RX" input of each UBX-160 would be
> trivial: "A:0 B:0". However, how do I address "RX2"? Intuitively "A:0 A:1
> B:0 B:1" but as said, both "TX/RX" and "RX2" are named "0".
> What would I do if I wanted to transmit from "TX/RX" of the second UBX and
> receive on all other boards?
>
> On the USRP Sink: "B:0"
> On the USP Source intuitively: "A:0 A:1 B:1" but that's wrong.
>
> 3.b.) In gr, there will be two multi_usrp objects: One for the receiver
> (member variable of USRP Source) and one for the transmitter (member
> variable of USRP Sink).
> Can I set up a USRP Source that has two channels where the second one is
> actually a TX channel? (only used for retuning via timed commands)?
>
>
> Thanks,
> Lukas
>
>
>
>
>
> Gesendet: Dienstag, 03. März 2020 um 15:22 Uhr
> Von: "Rob Kossler" 
> An: "Lukas Haase" 
> Cc: "Sam Reiter" , "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
>
> I did a quick google search using "gnuradio uhd timed tx streaming". I
> found that the GR usrp_sink[
> https://www.gnuradio.org/doc/sphinx-3.7.7/uhd.html] has the function
> "set_start_time" which seems to be what you need.  The question is: what
> time do you set?  Probably just something like "get_time_now() + 0.1". It
> may be a bit tricky since this value is to be set before starting the flow
> graph.  Maybe you could set it to some fixed constant like 0.5 and then
> when the flow graph starts you could execute a command to set_time_now() to
> 0.0.  Anyway, if this advice doesn't pan out, perhaps just search around a
> bit in GR archives.  I'm sure others have successfully streamed with timed
> Tx commands.
> Rob
>
> On Tue, Mar 3, 2020 at 3:00 PM Lukas Haase  lukasha...@gmx.at]>

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

2020-03-04 Thread Lukas Haase via USRP-users

Hi Rob,

1.) I do not really understand how "set_start_time" is related to my problem 
and why this is what I need. Based on my experiments, the time is automatically 
set to 0 when the flow diagram starts.

I am also sure others must have used timed TX+RX but it does not seem so. No 
kidding, I am working on this since Dec and I still do not have it working. I 
left my traces various times on this and the gnuradio mailing list but I did 
not get help.

2.) I have played around using stream tags and was very happy that it worked 
but I found now that this is because gr-uhd does NOT attach a command time 
although the documentation says so.

https://www.gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__sink.html:
tx_command tag. The command is attached to a sample, and will executed before 
the sample is transmitted, and after the previous sample.

However, in the code (usrp_sink_impl.cc:433, usrp_sink_impl::tag_work):

else if (pmt::equal(key, COMMAND_KEY)) {
if (my_tag_count != samp0_count) {
max_count = my_tag_count;
break;
}
// TODO set the command time from the sample time
msg_handler_command(value);
}

3.) So I am really back to the start. What is generally a bit annoying is that 
I have two objects for the same device (*one* USRP and "USRP Source"+"USRP 
Sink", both with their independent uhd::usrp::multi_usrp objects. My question 
is, is it possible to just use "USRP Source" (this is where timed commands 
work) to execute the retuning for *both* RX+TX?

3.a.) Given: X310 with 2xUBX-160. What is the subdev spec if I wanted to 
receive on all FOUR inputs??
The problem is that both RX and TX frontends have the same name "0" (according 
to uhd_usrp_probe).

Two receivers, receiving both from "TX/RX" input of each UBX-160 would be 
trivial: "A:0 B:0". However, how do I address "RX2"? Intuitively "A:0 A:1 B:0 
B:1" but as said, both "TX/RX" and "RX2" are named "0".
What would I do if I wanted to transmit from "TX/RX" of the second UBX and 
receive on all other boards?

On the USRP Sink: "B:0"
On the USP Source intuitively: "A:0 A:1 B:1" but that's wrong.

3.b.) In gr, there will be two multi_usrp objects: One for the receiver (member 
variable of USRP Source) and one for the transmitter (member variable of USRP 
Sink).
Can I set up a USRP Source that has two channels where the second one is 
actually a TX channel? (only used for retuning via timed commands)?


Thanks,
Lukas


 
 

Gesendet: Dienstag, 03. März 2020 um 15:22 Uhr
Von: "Rob Kossler" 
An: "Lukas Haase" 
Cc: "Sam Reiter" , "USRP-users@lists.ettus.com" 

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

I did a quick google search using "gnuradio uhd timed tx streaming". I found 
that the GR usrp_sink[https://www.gnuradio.org/doc/sphinx-3.7.7/uhd.html] has 
the function "set_start_time" which seems to be what you need.  The question 
is: what time do you set?  Probably just something like "get_time_now() + 0.1". 
It may be a bit tricky since this value is to be set before starting the flow 
graph.  Maybe you could set it to some fixed constant like 0.5 and then when 
the flow graph starts you could execute a command to set_time_now() to 0.0.  
Anyway, if this advice doesn't pan out, perhaps just search around a bit in GR 
archives.  I'm sure others have successfully streamed with timed Tx commands.
Rob 

On Tue, Mar 3, 2020 at 3:00 PM Lukas Haase 
mailto:lukasha...@gmx.at]> wrote:

Hi Sam, Hi Rob,

This makes so much sense!
I think you are right.
And indeed, the issue I found only with TX, not RX.


Could you think of a possible hack sending a "dummy command" to the RF board 
along with the timed tuning request?


Regarding the sending of time stamps in the TX in gr-uhd, I am confused though. 
I do think this IS happening. I reproduce the work function of "USRP Sink" here:

int usrp_sink_impl::work(int noutput_items,
                         gr_vector_const_void_star& input_items,
                         gr_vector_void_star& output_items)
{
    int ninput_items = noutput_items; // cuz it's a sync block

    // default to send a mid-burst packet
    _metadata.start_of_burst = false;
    _metadata.end_of_burst = false;

    // collect tags in this work()
    const uint64_t samp0_count = nitems_read(0);
    get_tags_in_range(_tags, 0, samp0_count, samp0_count + ninput_items);
    if (not _tags.empty())
        this->tag_work(ninput_items);

    if (not pmt::is_null(_length_tag_key)) {
        // check if there is data left to send from a burst tagged with 
length_tag
        // If a burst is started during this call to work(), tag

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

cluding
> _metadata:
>
> const size_t num_sent = _tx_stream->send(input_items, ninput_items,
> _metadata, 1.0);
>
> The "time_spec" is updated for each block that is sent out:
>
> _metadata.time_spec += ::uhd::time_spec_t(0, num_sent, _sample_rate);
>
> Now you mentioned "has_time_spec" below. I extended to code in the
> following way:
>
> // increment the timespec by the number of samples sent
> _metadata.time_spec += ::uhd::time_spec_t(0, num_sent, _sample_rate);
> GR_LOG_DEBUG(d_debug_logger, boost::format("Setting metadata
> time_spec: %d:%f") % _metadata.time_spec.get_full_secs() %
> _metadata.time_spec.get_frac_secs());
> _metadata.has_time_spec = true;
>
>
> To my understanding, gr-uhd now passes the correct timestamps on to UHD.
> However, the timed command is still ignored.
>
>
> Thanks,
> Lukas
>
>
> PS: I will attempt to use the tagged stream ... but then I will have the
> issue that I need to tune TX *plus* RX at the same time! Furthermore, the
> streaming tags API is super rudimentary. Also, skimming the source code for
> the tag processing, I am not sure if this would change anything.
>
>
>
>
>
>
>
>
> Gesendet: Dienstag, 03. März 2020 um 13:25 Uhr
> Von: "Sam Reiter" 
> An: "Rob Kossler" 
> Cc: "Lukas Haase" , "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
>
> Everything Rob is saying is dead on - the "sense of time" for the radio is
> a 64-bit counter within the radio core that other blocks (like the DDC and
> DUC) don't have access to. Those blocks need to derive a sense of time from
> the timestamps of CHDR packets passing through them. I just wrapped up a
> new app note that covers this (among other synchronization-related topics):
>
>
> https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD#Clocking_and_Timekeeping_in_the_USRP
>
> Lukas, I would doubt that this is an undiscovered bug as much as it is an
> issue with implementation. If this were in C++, you'd want to set the
> 'has_time_spec' and 'time_spec' fields of your TX metadata for at least 1
> packet to impart a sense of time on the DUC:
>
>
> https://files.ettus.com/manual/structuhd_1_1tx__metadata__t.html[https://files.ettus.com/manual/structuhd_1_1tx__metadata__t.html]
>
> I just spoke with someone on my end who said you need to use stream tags
> to do this, but again, I don't currently have much direction for how that
> would be implemented in your code.
>
>
> Sam Reiter
>
> On Tue, Mar 3, 2020 at 11:48 AM Rob Kossler  rkoss...@nd.edu]> wrote:
> Also, note that there is no corresponding issue on receive because the Rx
> radio always inserts the time stamp in the sample stream. So, I guess you
> would not see this with the DDC.
> Rob
>
> On Tue, Mar 3, 2020 at 12:43 PM Rob Kossler  rkoss...@nd.edu]> wrote:
>
> Hi Lukas,
> The FPGA image on the USRP is divided into blocks such as the DUC block
> and the Radio block.  The latter controls the RF daughterboard and has
> access to the device clock.  So, when you provide a timed command to the
> Radio block (such as for tuning the RF) it can implement the command at the
> specified time by comparing to the device clock.  The DUC block does not
> have access to the MB clock and so when you give it a timed command, it
> monitors the incoming sample stream to extract the time. If the sample
> stream does not include a time stamp, the command never executes.  Don't
> think of this as a bug, but rather as a design limitation.
>
> When I work directly with UHD from C++, I use the function
> rx_streamer::issue_stream_command() which has options to stream data with
> no time stamp or with a time stamp.  When using timed commands with DUC or
> DDC, I must include the time stamp or else the command will never be
> executed.  But, with GR, I don't know how to specify the corresponding
> options.
> Rob
>
> On Tue, Mar 3, 2020 at 12:29 PM Lukas Haase  lukasha...@gmx.at]> wrote:Hi Sam, Hi Rob,
>
> Thanks for following up on this!
> I am very happy you were able to reproduce this ... which means that at
> least an issue exists :)
>
> What Sam suggests makes sense even though hard to believe for me:
>
> 1. How could something like that go unnoticed for so long? (I am sure I am
> not the first performing digital tuning)
> 2. In the past I got successful phase coherence using automatic tuning
> (passing center frequency + offset to tune_request_t and using integer-N
> tuning) using timed com

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

2020-03-03 Thread Lukas Haase via USRP-users

Hi Sam, Hi Rob,

This makes so much sense!
I think you are right.
And indeed, the issue I found only with TX, not RX.


Could you think of a possible hack sending a "dummy command" to the RF board 
along with the timed tuning request?


Regarding the sending of time stamps in the TX in gr-uhd, I am confused though. 
I do think this IS happening. I reproduce the work function of "USRP Sink" here:

int usrp_sink_impl::work(int noutput_items,
 gr_vector_const_void_star& input_items,
 gr_vector_void_star& output_items)
{
int ninput_items = noutput_items; // cuz it's a sync block

// default to send a mid-burst packet
_metadata.start_of_burst = false;
_metadata.end_of_burst = false;

// collect tags in this work()
const uint64_t samp0_count = nitems_read(0);
get_tags_in_range(_tags, 0, samp0_count, samp0_count + ninput_items);
if (not _tags.empty())
this->tag_work(ninput_items);

if (not pmt::is_null(_length_tag_key)) {
// check if there is data left to send from a burst tagged with 
length_tag
// If a burst is started during this call to work(), tag_work() should 
have
// been called and we should have _nitems_to_send > 0.
if (_nitems_to_send > 0) {
ninput_items = std::min(_nitems_to_send, ninput_items);
// if we run out of items to send, it's the end of the burst
if (_nitems_to_send - long(ninput_items) == 0)
_metadata.end_of_burst = true;
} else {
// There is a tag gap since no length_tag was found immediately 
following
// the last sample of the previous burst. Drop samples until the 
next
// length_tag is found. Notify the user of the tag gap.
std::cerr << "tG" << std::flush;
// increment the timespec by the number of samples dropped
_metadata.time_spec += ::uhd::time_spec_t(0, ninput_items, 
_sample_rate);
return ninput_items;
}
}

boost::this_thread::disable_interruption disable_interrupt;
#ifdef GR_UHD_USE_STREAM_API
// send all ninput_items with metadata
const size_t num_sent = _tx_stream->send(input_items, ninput_items, 
_metadata, 1.0);
#else
const size_t num_sent = _dev->get_device()->send(input_items,
 ninput_items,
 _metadata,
 *_type,
 
::uhd::device::SEND_MODE_FULL_BUFF,
 1.0);
#endif
boost::this_thread::restore_interruption 
restore_interrupt(disable_interrupt);

// if using length_tags, decrement items left to send by the number of 
samples sent
if (not pmt::is_null(_length_tag_key) && _nitems_to_send > 0) {
_nitems_to_send -= long(num_sent);
}

// increment the timespec by the number of samples sent
_metadata.time_spec += ::uhd::time_spec_t(0, num_sent, _sample_rate);

// Some post-processing tasks if we actually transmitted the entire burst
if (not _pending_cmds.empty() && num_sent == size_t(ninput_items)) {
GR_LOG_DEBUG(d_debug_logger,
 boost::format("Executing %d pending commands.") %
 _pending_cmds.size());
BOOST_FOREACH (const pmt::pmt_t& cmd_pmt, _pending_cmds) {
msg_handler_command(cmd_pmt);
}
_pending_cmds.clear();
}

return num_sent;
}

From this code, it can be seen that the data is transmitted including _metadata:

const size_t num_sent = _tx_stream->send(input_items, ninput_items, _metadata, 
1.0);

The "time_spec" is updated for each block that is sent out:

_metadata.time_spec += ::uhd::time_spec_t(0, num_sent, _sample_rate);

Now you mentioned "has_time_spec" below. I extended to code in the following 
way:

// increment the timespec by the number of samples sent
_metadata.time_spec += ::uhd::time_spec_t(0, num_sent, _sample_rate);
GR_LOG_DEBUG(d_debug_logger, boost::format("Setting metadata time_spec: 
%d:%f") % _metadata.time_spec.get_full_secs() % 
_metadata.time_spec.get_frac_secs());
_metadata.has_time_spec = true;


To my understanding, gr-uhd now passes the correct timestamps on to UHD.
However, the timed command is still ignored.


Thanks,
Lukas


PS: I will attempt to use the tagged stream ... but then I will have the issue 
that I need to tune TX *plus* RX at the same time! Furthermore, the streaming 
tags API is super rudimentary. Also, skimming the source code for the tag 
processing, I am not sure if this would change anything.




 
 
 

Gesendet: Dienstag, 03. März 2020 um 13:25 Uhr
Von: "Sam Reiter" 
An: &q

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

2020-03-03 Thread Sam Reiter via USRP-users

Everything Rob is saying is dead on - the "sense of time" for the radio is
a 64-bit counter within the radio core that other blocks (like the DDC and
DUC) don't have access to. Those blocks need to derive a sense of time from
the timestamps of CHDR packets passing through them. I just wrapped up a
new app note that covers this (among other synchronization-related topics):

https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD#Clocking_and_Timekeeping_in_the_USRP

Lukas, I would doubt that this is an undiscovered bug as much as it is an
issue with implementation. If this were in C++, you'd want to set the
'has_time_spec' and 'time_spec' fields of your TX metadata for at least 1
packet to impart a sense of time on the DUC:

https://files.ettus.com/manual/structuhd_1_1tx__metadata__t.html

I just spoke with someone on my end who said you need to use stream tags to
do this, but again, I don't currently have much direction for how that
would be implemented in your code.

Sam Reiter

On Tue, Mar 3, 2020 at 11:48 AM Rob Kossler  wrote:

> Also, note that there is no corresponding issue on receive because the Rx
> radio always inserts the time stamp in the sample stream. So, I guess you
> would not see this with the DDC.
> Rob
>
> On Tue, Mar 3, 2020 at 12:43 PM Rob Kossler  wrote:
>
>> Hi Lukas,
>> The FPGA image on the USRP is divided into blocks such as the DUC block
>> and the Radio block.  The latter controls the RF daughterboard and has
>> access to the device clock.  So, when you provide a timed command to the
>> Radio block (such as for tuning the RF) it can implement the command at the
>> specified time by comparing to the device clock.  The DUC block does not
>> have access to the MB clock and so when you give it a timed command, it
>> monitors the incoming sample stream to extract the time. If the sample
>> stream does not include a time stamp, the command never executes.  Don't
>> think of this as a bug, but rather as a design limitation.
>>
>> When I work directly with UHD from C++, I use the function
>> rx_streamer::issue_stream_command() which has options to stream data with
>> no time stamp or with a time stamp.  When using timed commands with DUC or
>> DDC, I must include the time stamp or else the command will never be
>> executed.  But, with GR, I don't know how to specify the corresponding
>> options.
>> Rob
>>
>> On Tue, Mar 3, 2020 at 12:29 PM Lukas Haase  wrote:
>>
>>> Hi Sam, Hi Rob,
>>>
>>> Thanks for following up on this!
>>> I am very happy you were able to reproduce this ... which means that at
>>> least an issue exists :)
>>>
>>> What Sam suggests makes sense even though hard to believe for me:
>>>
>>> 1. How could something like that go unnoticed for so long? (I am sure I
>>> am not the first performing digital tuning)
>>> 2. In the past I got successful phase coherence using automatic tuning
>>> (passing center frequency + offset to tune_request_t and using integer-N
>>> tuning) using timed commands. This did not work reliably and only for
>>> certain frequencies but in my opinion this should have INCLUDED the DUC
>>> tuning. If the DUC retune wouldn't have been executed as part of this
>>> automatic tuning, I could not have gotten phase coherence (and actually,
>>> not even the desired frequency).
>>>
>>> The reason why I am only doing DUC tuning now is to avoid all the hassle
>>> with integer-N tuning, PLL retuning and settling time.
>>>
>>> Sam, what is the "radio block" you were talking about?
>>>
>>> Anyway, would it be worthwile to attempt debugging this is absence of gr?
>>> The only reason this prevented me from doing is that I would need to
>>> manually create the baseband samples and continuously stream them out while
>>> in parallel do the retuning.
>>> I am not too familiar with UHD on its own but I assume this would be
>>> very complicated, require multithreading etc.
>>> Do you have any demo code that could be easily modified for this
>>> scenario?
>>>
>>> Best,
>>> Lukas
>>>
>>>
>>> Gesendet: Dienstag, 03. März 2020 um 12:08 Uhr
>>> Von: "Sam Reiter" 
>>> An: "Rob Kossler" 
>>> Cc: "Lukas Haase" , "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
>>>
>>> For what it's worth,

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

Also, note that there is no corresponding issue on receive because the Rx
radio always inserts the time stamp in the sample stream. So, I guess you
would not see this with the DDC.
Rob

On Tue, Mar 3, 2020 at 12:43 PM Rob Kossler  wrote:

> Hi Lukas,
> The FPGA image on the USRP is divided into blocks such as the DUC block
> and the Radio block.  The latter controls the RF daughterboard and has
> access to the device clock.  So, when you provide a timed command to the
> Radio block (such as for tuning the RF) it can implement the command at the
> specified time by comparing to the device clock.  The DUC block does not
> have access to the MB clock and so when you give it a timed command, it
> monitors the incoming sample stream to extract the time. If the sample
> stream does not include a time stamp, the command never executes.  Don't
> think of this as a bug, but rather as a design limitation.
>
> When I work directly with UHD from C++, I use the function
> rx_streamer::issue_stream_command() which has options to stream data with
> no time stamp or with a time stamp.  When using timed commands with DUC or
> DDC, I must include the time stamp or else the command will never be
> executed.  But, with GR, I don't know how to specify the corresponding
> options.
> Rob
>
> On Tue, Mar 3, 2020 at 12:29 PM Lukas Haase  wrote:
>
>> Hi Sam, Hi Rob,
>>
>> Thanks for following up on this!
>> I am very happy you were able to reproduce this ... which means that at
>> least an issue exists :)
>>
>> What Sam suggests makes sense even though hard to believe for me:
>>
>> 1. How could something like that go unnoticed for so long? (I am sure I
>> am not the first performing digital tuning)
>> 2. In the past I got successful phase coherence using automatic tuning
>> (passing center frequency + offset to tune_request_t and using integer-N
>> tuning) using timed commands. This did not work reliably and only for
>> certain frequencies but in my opinion this should have INCLUDED the DUC
>> tuning. If the DUC retune wouldn't have been executed as part of this
>> automatic tuning, I could not have gotten phase coherence (and actually,
>> not even the desired frequency).
>>
>> The reason why I am only doing DUC tuning now is to avoid all the hassle
>> with integer-N tuning, PLL retuning and settling time.
>>
>> Sam, what is the "radio block" you were talking about?
>>
>> Anyway, would it be worthwile to attempt debugging this is absence of gr?
>> The only reason this prevented me from doing is that I would need to
>> manually create the baseband samples and continuously stream them out while
>> in parallel do the retuning.
>> I am not too familiar with UHD on its own but I assume this would be very
>> complicated, require multithreading etc.
>> Do you have any demo code that could be easily modified for this scenario?
>>
>> Best,
>> Lukas
>>
>>
>> Gesendet: Dienstag, 03. März 2020 um 12:08 Uhr
>> Von: "Sam Reiter" 
>> An: "Rob Kossler" 
>> Cc: "Lukas Haase" , "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
>>
>> For what it's worth, I was able to reproduce the behavior described here,
>> but didn't get to dig into it much. My leading suspicion would be what Rob
>> mentioned about timestamping. Lukas' code sets a command time, but I'm not
>> clear on how timestamp metadata for packets being sent to the radio are
>> handled. Might be a good question to loop the discuss-gnuradio mailing list
>> in on?
>>
>>
>>
>> Sam Reiter
>>
>> On Tue, Mar 3, 2020 at 10:59 AM Rob Kossler via USRP-users <
>> usrp-users@lists.ettus.com[mailto:usrp-users@lists.ettus.com]> wrote:
>> I wonder if the issue is related to a missing time stamp on the baseband
>> samples going from GR to UHD.  If the stream does not have a time stamp,
>> the DUC is unable to apply the timed command because the DUC does not
>> really know the time - it must pull the time from the streaming samples.
>> This is in contrast to the radio block which does have access to time and
>> can apply timed commands by referring to the motherboard clock.
>>
>> I am not too familiar with GR so I'm not sure how to know if GR is
>> putting a time stamp on the streaming samples.
>> Rob
>>
>> On Mon, Mar 2, 2020 at 10:04 AM Lukas Haase via USRP-users <
>> usrp-users@lists.ettus.com[mailto:usrp-users@lists.ettus.co

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

Hi Marcus,
I'm pretty sure that the DDC and DUC don't have access to the MB clock and
thus have no option but to executed timed commands using the time stamp in
the sample stream.
Rob

On Tue, Mar 3, 2020 at 12:41 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 03/03/2020 12:08 PM, Sam Reiter via USRP-users wrote:
>
> For what it's worth, I was able to reproduce the behavior described here,
> but didn't get to dig into it much. My leading suspicion would be what Rob
> mentioned about timestamping. Lukas' code sets a command time, but I'm not
> clear on how timestamp metadata for packets being sent to the radio are
> handled. Might be a good question to loop the discuss-gnuradio mailing list
> in on?
>
> Sam Reiter
>
> Timed commands, I thought, were ALWAYS referred to the motherboard clock,
> without regard to timestamps in the stream?
>
>
>
> On Tue, Mar 3, 2020 at 10:59 AM Rob Kossler via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> I wonder if the issue is related to a missing time stamp on the baseband
>> samples going from GR to UHD.  If the stream does not have a time stamp,
>> the DUC is unable to apply the timed command because the DUC does not
>> really know the time - it must pull the time from the streaming samples.
>> This is in contrast to the radio block which does have access to time and
>> can apply timed commands by referring to the motherboard clock.
>>
>> I am not too familiar with GR so I'm not sure how to know if GR is
>> putting a time stamp on the streaming samples.
>> Rob
>>
>> On Mon, Mar 2, 2020 at 10:04 AM Lukas Haase via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi Marcus,
>>>
>>> Thank you that would be amazing!
>>>
>>> I followed the tutorial and built everything from source:
>>>
>>> $ lsb_release -a
>>> No LSB modules are available.
>>> Distributor ID: Ubuntu
>>> Description:Ubuntu 18.04.4 LTS
>>> Release:18.04
>>> Codename:   bionic
>>> $ uname -a
>>> Linux sdr 5.3.0-40-generic #32~18.04.1-Ubuntu SMP Mon Feb 3 14:05:59 UTC
>>> 2020 x86_64 x86_64 x86_64 GNU/Linux
>>> $ cd uhd
>>> $ git status
>>> HEAD detached at v3.15.0.0
>>> $ cd ../gnuradio
>>> $ git status
>>> HEAD detached at v3.7.14.0
>>>
>>>
>>> Thank you!
>>>
>>> Lukas
>>>
>>>
>>>
>>> PS: For some reason I sometimes do not get responses from this list. I
>>> just saw it looking at the mailman archives. Hence I cannot respond (to
>>> keep headers intact) but need to create a new message and manually "quote".
>>> I hope that still preserves the context somehow.
>>>
>>>
>>>
>>> Marcus Leech wrote:
>>> > On 02/28/2020 01:01 PM, Lukas Haase via USRP-users wrote:
>>> >> Hi again,
>>> >>
>>> >> I created a minimum example (gnuradio) that shows the issue described
>>> below.
>>> >> To summarize: Retuning to a different dsp frequency on an USRP X310
>>> (+UBX160) does not work (command ignored) ONLY if a timed command (in
>>> future is used).
>>> >> The code shows it in a simple manner. Commenting out the single line
>>> with set_command_time makes the example work.
>>> >>
>>> >> I am absolutely out of ideas and would appreciate any input!
>>> >>
>>> >> Best,
>>> >> Lukas
>>> > Lukas.
>>> >
>>> > Thanks for sticking with this.  I'll have a discussion with Ettus R&D
>>> to
>>> > see if this is a known issue and/or if there's a workaround.
>>> >
>>> > Remind me which version of UHD you're using?
>>>
>>>
>>>
>>> ___
>>> 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
>>
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://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
>
___
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

Hi Lukas,
The FPGA image on the USRP is divided into blocks such as the DUC block and
the Radio block.  The latter controls the RF daughterboard and has access
to the device clock.  So, when you provide a timed command to the Radio
block (such as for tuning the RF) it can implement the command at the
specified time by comparing to the device clock.  The DUC block does not
have access to the MB clock and so when you give it a timed command, it
monitors the incoming sample stream to extract the time. If the sample
stream does not include a time stamp, the command never executes.  Don't
think of this as a bug, but rather as a design limitation.

When I work directly with UHD from C++, I use the function
rx_streamer::issue_stream_command() which has options to stream data with
no time stamp or with a time stamp.  When using timed commands with DUC or
DDC, I must include the time stamp or else the command will never be
executed.  But, with GR, I don't know how to specify the corresponding
options.
Rob

On Tue, Mar 3, 2020 at 12:29 PM Lukas Haase  wrote:

> Hi Sam, Hi Rob,
>
> Thanks for following up on this!
> I am very happy you were able to reproduce this ... which means that at
> least an issue exists :)
>
> What Sam suggests makes sense even though hard to believe for me:
>
> 1. How could something like that go unnoticed for so long? (I am sure I am
> not the first performing digital tuning)
> 2. In the past I got successful phase coherence using automatic tuning
> (passing center frequency + offset to tune_request_t and using integer-N
> tuning) using timed commands. This did not work reliably and only for
> certain frequencies but in my opinion this should have INCLUDED the DUC
> tuning. If the DUC retune wouldn't have been executed as part of this
> automatic tuning, I could not have gotten phase coherence (and actually,
> not even the desired frequency).
>
> The reason why I am only doing DUC tuning now is to avoid all the hassle
> with integer-N tuning, PLL retuning and settling time.
>
> Sam, what is the "radio block" you were talking about?
>
> Anyway, would it be worthwile to attempt debugging this is absence of gr?
> The only reason this prevented me from doing is that I would need to
> manually create the baseband samples and continuously stream them out while
> in parallel do the retuning.
> I am not too familiar with UHD on its own but I assume this would be very
> complicated, require multithreading etc.
> Do you have any demo code that could be easily modified for this scenario?
>
> Best,
> Lukas
>
>
> Gesendet: Dienstag, 03. März 2020 um 12:08 Uhr
> Von: "Sam Reiter" 
> An: "Rob Kossler" 
> Cc: "Lukas Haase" , "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
>
> For what it's worth, I was able to reproduce the behavior described here,
> but didn't get to dig into it much. My leading suspicion would be what Rob
> mentioned about timestamping. Lukas' code sets a command time, but I'm not
> clear on how timestamp metadata for packets being sent to the radio are
> handled. Might be a good question to loop the discuss-gnuradio mailing list
> in on?
>
>
>
> Sam Reiter
>
> On Tue, Mar 3, 2020 at 10:59 AM Rob Kossler via USRP-users <
> usrp-users@lists.ettus.com[mailto:usrp-users@lists.ettus.com]> wrote:
> I wonder if the issue is related to a missing time stamp on the baseband
> samples going from GR to UHD.  If the stream does not have a time stamp,
> the DUC is unable to apply the timed command because the DUC does not
> really know the time - it must pull the time from the streaming samples.
> This is in contrast to the radio block which does have access to time and
> can apply timed commands by referring to the motherboard clock.
>
> I am not too familiar with GR so I'm not sure how to know if GR is putting
> a time stamp on the streaming samples.
> Rob
>
> On Mon, Mar 2, 2020 at 10:04 AM Lukas Haase via USRP-users <
> usrp-users@lists.ettus.com[mailto:usrp-users@lists.ettus.com]> wrote:Hi
> Marcus,
>
> Thank you that would be amazing!
>
> I followed the tutorial and built everything from source:
>
> $ lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:Ubuntu 18.04.4 LTS
> Release:18.04
> Codename:   bionic
> $ uname -a
> Linux sdr 5.3.0-40-generic #32~18.04.1-Ubuntu SMP Mon Feb 3 14:05:59 UTC
> 2020 x86_64 x86_64 x86_64 GNU/Linux
> $ cd uhd
> $ git status
> HEAD detached at v3.15.0.0
> $ cd ../gnuradio
> $ git status
> HEAD detached at v3.7.14.0
>
>
> Than

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

2020-03-03 Thread Marcus D. Leech via USRP-users

On 03/03/2020 12:08 PM, Sam Reiter via USRP-users wrote:
For what it's worth, I was able to reproduce the behavior described 
here, but didn't get to dig into it much. My leading suspicion would 
be what Rob mentioned about timestamping. Lukas' code sets a command 
time, but I'm not clear on how timestamp metadata for packets being 
sent to the radio are handled. Might be a good question to loop the 
discuss-gnuradio mailing list in on?

Sam Reiter
Timed commands, I thought, were ALWAYS referred to the motherboard 
clock, without regard to timestamps in the stream?

On Tue, Mar 3, 2020 at 10:59 AM Rob Kossler via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:

I wonder if the issue is related to a missing time stamp on the
baseband samples going from GR to UHD.  If the stream does not
have a time stamp, the DUC is unable to apply the timed command
because the DUC does not really know the time - it must pull the
time from the streaming samples. This is in contrast to the radio
block which does have access to time and can apply timed commands
by referring to the motherboard clock.

I am not too familiar with GR so I'm not sure how to know if GR is
putting a time stamp on the streaming samples.
Rob

On Mon, Mar 2, 2020 at 10:04 AM Lukas Haase via USRP-users
mailto:usrp-users@lists.ettus.com>>
wrote:

Hi Marcus,

Thank you that would be amazing!

I followed the tutorial and built everything from source:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 18.04.4 LTS
Release:18.04
Codename:   bionic
$ uname -a
Linux sdr 5.3.0-40-generic #32~18.04.1-Ubuntu SMP Mon Feb 3
14:05:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$ cd uhd
$ git status
HEAD detached at v3.15.0.0
$ cd ../gnuradio
$ git status
HEAD detached at v3.7.14.0

Thank you!

Lukas

PS: For some reason I sometimes do not get responses from this
list. I just saw it looking at the mailman archives. Hence I
cannot respond (to keep headers intact) but need to create a
new message and manually "quote". I hope that still preserves
the context somehow.

Marcus Leech wrote:
> On 02/28/2020 01:01 PM, Lukas Haase via USRP-users wrote:
>> Hi again,
>>
>> I created a minimum example (gnuradio) that shows the issue
described below.
>> To summarize: Retuning to a different dsp frequency on an
USRP X310 (+UBX160) does not work (command ignored) ONLY if a
timed command (in future is used).
>> The code shows it in a simple manner. Commenting out the
single line with set_command_time makes the example work.
>>
>> I am absolutely out of ideas and would appreciate any input!
>>
>> Best,
>> Lukas
> Lukas.
>
> Thanks for sticking with this.  I'll have a discussion with
Ettus R&D to
> see if this is a known issue and/or if there's a workaround.
>
> Remind me which version of UHD you're using?

___
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

___
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

2020-03-03 Thread Lukas Haase via USRP-users

Hi Sam, Hi Rob, 

Thanks for following up on this!
I am very happy you were able to reproduce this ... which means that at least 
an issue exists :)

What Sam suggests makes sense even though hard to believe for me:

1. How could something like that go unnoticed for so long? (I am sure I am not 
the first performing digital tuning)
2. In the past I got successful phase coherence using automatic tuning (passing 
center frequency + offset to tune_request_t and using integer-N tuning) using 
timed commands. This did not work reliably and only for certain frequencies but 
in my opinion this should have INCLUDED the DUC tuning. If the DUC retune 
wouldn't have been executed as part of this automatic tuning, I could not have 
gotten phase coherence (and actually, not even the desired frequency).

The reason why I am only doing DUC tuning now is to avoid all the hassle with 
integer-N tuning, PLL retuning and settling time.

Sam, what is the "radio block" you were talking about?

Anyway, would it be worthwile to attempt debugging this is absence of gr?
The only reason this prevented me from doing is that I would need to manually 
create the baseband samples and continuously stream them out while in parallel 
do the retuning.
I am not too familiar with UHD on its own but I assume this would be very 
complicated, require multithreading etc.
Do you have any demo code that could be easily modified for this scenario?

Best,
Lukas

Gesendet: Dienstag, 03. März 2020 um 12:08 Uhr
Von: "Sam Reiter" 
An: "Rob Kossler" 
Cc: "Lukas Haase" , "USRP-users@lists.ettus.com" 

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

For what it's worth, I was able to reproduce the behavior described here, but 
didn't get to dig into it much. My leading suspicion would be what Rob 
mentioned about timestamping. Lukas' code sets a command time, but I'm not 
clear on how timestamp metadata for packets being sent to the radio are 
handled. Might be a good question to loop the discuss-gnuradio mailing list in 
on?

Sam Reiter  

On Tue, Mar 3, 2020 at 10:59 AM Rob Kossler via USRP-users 
mailto:usrp-users@lists.ettus.com]> wrote:
I wonder if the issue is related to a missing time stamp on the baseband 
samples going from GR to UHD.  If the stream does not have a time stamp, the 
DUC is unable to apply the timed command because the DUC does not really know 
the time - it must pull the time from the streaming samples. This is in 
contrast to the radio block which does have access to time and can apply timed 
commands by referring to the motherboard clock.

I am not too familiar with GR so I'm not sure how to know if GR is putting a 
time stamp on the streaming samples.
Rob 

On Mon, Mar 2, 2020 at 10:04 AM Lukas Haase via USRP-users 
mailto:usrp-users@lists.ettus.com]> wrote:Hi Marcus,

Thank you that would be amazing!

I followed the tutorial and built everything from source:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.4 LTS
Release:        18.04
Codename:       bionic
$ uname -a
Linux sdr 5.3.0-40-generic #32~18.04.1-Ubuntu SMP Mon Feb 3 14:05:59 UTC 2020 
x86_64 x86_64 x86_64 GNU/Linux
$ cd uhd
$ git status
HEAD detached at v3.15.0.0
$ cd ../gnuradio
$ git status
HEAD detached at v3.7.14.0

Thank you!

Lukas

PS: For some reason I sometimes do not get responses from this list. I just saw 
it looking at the mailman archives. Hence I cannot respond (to keep headers 
intact) but need to create a new message and manually "quote". I hope that 
still preserves the context somehow.

Marcus Leech wrote:
> On 02/28/2020 01:01 PM, Lukas Haase via USRP-users wrote:
>> Hi again,
>>
>> I created a minimum example (gnuradio) that shows the issue described below.
>> To summarize: Retuning to a different dsp frequency on an USRP X310 
>> (+UBX160) does not work (command ignored) ONLY if a timed command (in future 
>> is used).
>> The code shows it in a simple manner. Commenting out the single line with 
>> set_command_time makes the example work.
>>
>> I am absolutely out of ideas and would appreciate any input!
>>
>> Best,
>> Lukas
> Lukas.
>
> Thanks for sticking with this.  I'll have a discussion with Ettus R&D to
> see if this is a known issue and/or if there's a workaround.
>
> Remind me which version of UHD you're using?

___
USRP-users mailing list
USRP-users@lists.ettus.com[mailto: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[mailto: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

2020-03-03 Thread Sam Reiter via USRP-users

For what it's worth, I was able to reproduce the behavior described here,
but didn't get to dig into it much. My leading suspicion would be what Rob
mentioned about timestamping. Lukas' code sets a command time, but I'm not
clear on how timestamp metadata for packets being sent to the radio are
handled. Might be a good question to loop the discuss-gnuradio mailing list
in on?

Sam Reiter

On Tue, Mar 3, 2020 at 10:59 AM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I wonder if the issue is related to a missing time stamp on the baseband
> samples going from GR to UHD.  If the stream does not have a time stamp,
> the DUC is unable to apply the timed command because the DUC does not
> really know the time - it must pull the time from the streaming samples.
> This is in contrast to the radio block which does have access to time and
> can apply timed commands by referring to the motherboard clock.
>
> I am not too familiar with GR so I'm not sure how to know if GR is putting
> a time stamp on the streaming samples.
> Rob
>
> On Mon, Mar 2, 2020 at 10:04 AM Lukas Haase via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi Marcus,
>>
>> Thank you that would be amazing!
>>
>> I followed the tutorial and built everything from source:
>>
>> $ lsb_release -a
>> No LSB modules are available.
>> Distributor ID: Ubuntu
>> Description:Ubuntu 18.04.4 LTS
>> Release:18.04
>> Codename:   bionic
>> $ uname -a
>> Linux sdr 5.3.0-40-generic #32~18.04.1-Ubuntu SMP Mon Feb 3 14:05:59 UTC
>> 2020 x86_64 x86_64 x86_64 GNU/Linux
>> $ cd uhd
>> $ git status
>> HEAD detached at v3.15.0.0
>> $ cd ../gnuradio
>> $ git status
>> HEAD detached at v3.7.14.0
>>
>>
>> Thank you!
>>
>> Lukas
>>
>>
>>
>> PS: For some reason I sometimes do not get responses from this list. I
>> just saw it looking at the mailman archives. Hence I cannot respond (to
>> keep headers intact) but need to create a new message and manually "quote".
>> I hope that still preserves the context somehow.
>>
>>
>>
>> Marcus Leech wrote:
>> > On 02/28/2020 01:01 PM, Lukas Haase via USRP-users wrote:
>> >> Hi again,
>> >>
>> >> I created a minimum example (gnuradio) that shows the issue described
>> below.
>> >> To summarize: Retuning to a different dsp frequency on an USRP X310
>> (+UBX160) does not work (command ignored) ONLY if a timed command (in
>> future is used).
>> >> The code shows it in a simple manner. Commenting out the single line
>> with set_command_time makes the example work.
>> >>
>> >> I am absolutely out of ideas and would appreciate any input!
>> >>
>> >> Best,
>> >> Lukas
>> > Lukas.
>> >
>> > Thanks for sticking with this.  I'll have a discussion with Ettus R&D to
>> > see if this is a known issue and/or if there's a workaround.
>> >
>> > Remind me which version of UHD you're using?
>>
>>
>>
>> ___
>> 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
>
___
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