Re: [USRP-users] transmitting on two channels with replay block

[Thomas Harder via USRP-users]

Hi Sam,
Thank you for your reply.
 This morning I set the MCR to 184.32 and I am still having continuous 
underruns using also 
replay_ctrl->get_record_fullness
for both channels.

But since I need the full bandwidth of 160MHz I would like implement a second 
replay block in my fpga image.

Could anyone help me with this? 
I am really new in fpga programming and for the image with one replay block I 
was just following the instructions in 
https://kb.ettus.com/Using_the_RFNoC_Replay_Block.
Thank you,
Thomas


From: Sam Reiter
Sent: Friday, December 6, 2019 10:23 PM
To: Thomas Harder
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] transmitting on two channels with replay block

Thomas,

Upon further investigation, we may be running up to a practical limit of a 
single CHDR interface rather than an issue with your code. A single replay 
block servicing two radios will have a max (theoretical) rate of 187.5 MSPS on 
either channel. This means that you might be able to squeeze full rate out on 2 
channels with an MCR of 184.32, but that's cutting it pretty close. Sounds like 
2 channels at 200 MSPS with a replay setup will require 2 replay blocks serving 
each channel independently. If you end up trying either of the above out, I'd 
be curious to know what results you observe.

Sam Reiter 
Ettus Research


On Fri, Dec 6, 2019 at 2:38 PM Sam Reiter  wrote:
Thomas,

I'd need to set it up on my end, but I believe you can TX two distinct 
waveforms from a single replay block instance. You'd need to make sure that 
your adding your data to the buffer in separate locations and at an address 
that is a multiple of 8 bytes (which it looks like you're doing from the above 
snippets). Are you seeing continuous underruns, or just a handful at the 
beginning on the run? Does your duplicated code also use:

replay_ctrl->get_record_fullness

on both channels before kicking off the stream start?

Sam Reiter 
Ettus Research

On Wed, Dec 4, 2019 at 3:48 AM Thomas Harder via USRP-users 
 wrote:
Hello everyone,
Is it possible to transmit two different waveforms on the two channels of the 
USRP X310 with the two UBX-160 daughterboards?
I want to transmit two different waveforms simultaneous (synchronized ) on the 
two channels of the USRP with the full sample rate of 200 MS/s. I tried already 
to do it with a dual 10Gbit-ethernet connection and I seemed to be limited by 
my computer. Now I am trying to do it with the replay block.
 
I built the FPGA image with one Replay block as described in 
https://kb.ettus.com/Using_the_RFNoC_Replay_Block to run the example 
“replay_samples_from_file” and it is working fine if I transmit just on one 
channel. Now I was modifying the code by connecting the replay block to both 
channels:
replay_graph->connect(replay_ctrl->get_block_id(),replay_chan,tx_blockid,tx_chan,replay_spp);
replay_graph->connect(replay_ctrl->get_block_id(),replay_chan1,tx_blockid1,tx_chan,replay_spp);
 
and writing the same waveform into another region of the DRAM-buffer:
replay_ctrl->config_record(0,words_to_replay*replay_word_size, replay_chan);
replay_ctrl->config_record(2,words_to_replay*replay_word_size, 
replay_chan1);
and
replay_ctrl->config_play(0,words_to_replay*replay_word_size, replay_chan);
replay_ctrl->config_play(2,words_to_replay*replay_word_size, replay_chan1);
 
where 
words_to_replay*replay_word_size=16000
replay_chan=0
replay_chan1=1
tx_blockid=0/Radio_0
tx_blockid=0/Radio_1
 
then I stream my waveforms to the replay block as defined in the example and I 
start to replay the data:
replay_ctrl->issue_stream_cmd(stream_cmd, replay_chan);
replay_ctrl->issue_stream_cmd(stream_cmd, replay_chan1);
 
It works but with plenty of Underflows!!
 
So what does it mean when it says in the manual:
“Note that the record and playback buffers do not need to the same, allowing a 
single Replay block to both record and playback to different regions of memory 
simultaneously.”
(https://kb.ettus.com/Using_the_RFNoC_Replay_Block)?
 
Because in the manual it says also:
“The replay block has the following features: One input and one output”
(https://files.ettus.com/manual/classuhd_1_1rfnoc_1_1replay__block__ctrl.html)
 
So if the replay block has just one output why does it have two channels 
connected to it (replay_chan= 0 and 1)?
 
If one replay block can just stream to one channel at the same time, can I 
implement easily a second replay block in the FPGA to stream on the two 
channels of my USRP two different waveforms simultaneously?
 
Thank you,
Thomas
 
 
 
 
 
___
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] Default RFNoC image for N310 does not compile

[Nate Temple via USRP-users]

Hi Robert,

Thanks for the bug report.

If you're just trying to use RFNoC at this point, I would recommend to
stick with the latest stable release, which at this time is v3.14.1.1.

Note, 3.14.x.x UHD will require Vivado 2017.4.


Regards,
Nate Temple

On Mon, Dec 9, 2019 at 7:33 AM Robert via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all!
>
> I tried to compile the default RFNoC image for the N310, using UHD on tag
> v3.15.0.0-rc2 and Xilinx Vivado 2018.3.1.
>
> Running "make N310_RFNOC_XG", the IP cores are compiled successfully, but
> then Vivado shows the following errors:
>
> ERROR: [Synth 8-524] part-select [15:8] out of range of prefix
> 'STR_SINK_FIFOSIZE'
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:270]
> ERROR: [Synth 8-521] parameter assignment could not be resolved to a
> constant [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:270]
> ERROR: [Synth 8-196] conditional expression could not be resolved to a
> constant [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:239]
> WARNING: [Synth 8-693] zero replication count - replication ignored
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:26]
> WARNING: [Synth 8-693] zero replication count - replication ignored
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:27]
> WARNING: [Synth 8-693] zero replication count - replication ignored
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:31]
> ERROR: [Synth 8-6156] failed synthesizing module
> 'noc_shell__parameterized9'
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:21]
> ERROR: [Synth 8-6156] failed synthesizing module 'noc_block_fosphor'
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_block_fosphor.v:8]
> ERROR: [Synth 8-6156] failed synthesizing module 'n3xx_core'
> [/usr/local/src/uhd/fpga-src/usrp3/top/n3xx/n3xx_core.v:17]
> ERROR: [Synth 8-6156] failed synthesizing module 'n3xx'
> [/usr/local/src/uhd/fpga-src/usrp3/top/n3xx/dboards/mg/n3xx.v:13]
>
> The full build.log file is attached. I did not modify any files, just
> trying to compile the RFNoC example as provided.
>
>
>
>
> Btw I also tried to build the default image with "make N310_XG", this one
> compiles but failed later during DRC:
>
> [DRC BIVC-1] Bank IO standard Vcc: Conflicting Vcc voltages in bank 34.
> For example, the following two ports in this bank have conflicting VCCOs:
> ddr3_ck_p[0] (DIFF_SSTL15, requiring VCCO=1.500) and ddr3_addr[15]
> (LVCMOS18, requiring VCCO=1.800)
> [Vivado_Tcl 4-23] Error(s) found during DRC. Placer not run.
>
>
> ___
> 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] Phase relation between RX/TX LO

[Marcus D. Leech via USRP-users]

On 12/08/2019 05:19 PM, Lukas Haase wrote:

Hi Marcus,


You'll need to look at the API here:

https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a191b78b00d051d3d51c2f719361c1fb5

and here:

https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a607aee766d21228a7aaabde2771eb46f

Basically, GRC will generate python code where it calls the
set_rx_freq() method (or set_tx_freq() method), and you need to modify this
   code to have set_command_time() and clear_command_time() wrapped
around those operations.

Thank you.

As I understand you referenced the USRP driver whereas GRC creates gnuradio 
objects (e.g.: usrp_source 
https://www.gnuradio.org/doc/doxygen-3.7.2/classgr_1_1uhd_1_1usrp__source.html )

My dilemma is that I need to set the center frequency of the TX to "fc" and the center frequency of 
the RX to "2*fc" and its phase relationship should be identical for each "fc" (at least 
as long the USRP does not power cycle).

The gnuradio API als exposes the USRP API you mentioned so I tried:

 now = self.uhd_usrp_sink_0.get_time_now()
 self.uhd_usrp_sink_0.set_command_time(now + uhd.time_spec(1))
 self.uhd_usrp_source_0.set_command_time(now + uhd.time_spec(1))

 self.uhd_usrp_source_0.set_center_freq(2*self.fcenter, 0)
 self.uhd_usrp_source_0.set_center_freq(2*self.fcenter, 1)
 self.uhd_usrp_sink_0.set_center_freq(self.fcenter, 0)

 self.uhd_usrp_source_0.clear_command_time()
 self.uhd_usrp_sink_0.clear_command_time()

But this this the phase still jumps after a frequency change.

So, you're trying to measure the 2nd-harmonic energy of the TX signal?

What frequencies are involved here?



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Phase relation between RX/TX LO

[Lukas Haase via USRP-users]

Hi Marcus,

> Von: "Marcus D. Leech" 
> On 12/08/2019 05:19 PM, Lukas Haase wrote:
> > Hi Marcus,
> >
> >> You'll need to look at the API here:
> >>
> >> https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a191b78b00d051d3d51c2f719361c1fb5
> >>
> >> and here:
> >>
> >> https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a607aee766d21228a7aaabde2771eb46f
> >>
> >> Basically, GRC will generate python code where it calls the
> >> set_rx_freq() method (or set_tx_freq() method), and you need to modify this
> >>code to have set_command_time() and clear_command_time() wrapped
> >> around those operations.
> > Thank you.
> >
> > As I understand you referenced the USRP driver whereas GRC creates gnuradio 
> > objects (e.g.: usrp_source 
> > https://www.gnuradio.org/doc/doxygen-3.7.2/classgr_1_1uhd_1_1usrp__source.html
> >  )
> >
> > My dilemma is that I need to set the center frequency of the TX to "fc" and 
> > the center frequency of the RX to "2*fc" and its phase relationship should 
> > be identical for each "fc" (at least as long the USRP does not power cycle).
> >
> > The gnuradio API als exposes the USRP API you mentioned so I tried:
> >
> >  now = self.uhd_usrp_sink_0.get_time_now()
> >  self.uhd_usrp_sink_0.set_command_time(now + uhd.time_spec(1))
> >  self.uhd_usrp_source_0.set_command_time(now + uhd.time_spec(1))
> >
> >  self.uhd_usrp_source_0.set_center_freq(2*self.fcenter, 0)
> >  self.uhd_usrp_source_0.set_center_freq(2*self.fcenter, 1)
> >  self.uhd_usrp_sink_0.set_center_freq(self.fcenter, 0)
> >
> >  self.uhd_usrp_source_0.clear_command_time()
> >  self.uhd_usrp_sink_0.clear_command_time()
> >
> > But this this the phase still jumps after a frequency change.
> So, you're trying to measure the 2nd-harmonic energy of the TX signal?

Precicely.

> What frequencies are involved here?

Example: Transmit 900 Mhz (USRP Sink).
Receive 1800 MHz (USRP Source).

The received signal will have arbitrary phase phi1.

Tune to frequency 950 MHz and receive 1900 MHz. The phase will be phi2.

Then tuning back to 900 MHz and I need to read out phi1 again.
Then tuning back to 950 MHz and I need to read out phi2 again.
And so on.

Does this make sense?


Thanks,
Luke




___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Default RFNoC image for N310 does not compile

[Nate Temple via USRP-users]

Hi Robert,

So this is a bug related to Vivado, you will need to install this linked
below patch and it should resolve it.

https://www.xilinx.com/support/answers/71898.html

Regards,
Nate Temple

On Mon, Dec 9, 2019 at 10:38 AM Nate Temple  wrote:

> Hi Robert,
>
> Thanks for the bug report.
>
> If you're just trying to use RFNoC at this point, I would recommend to
> stick with the latest stable release, which at this time is v3.14.1.1.
>
> Note, 3.14.x.x UHD will require Vivado 2017.4.
>
>
> Regards,
> Nate Temple
>
> On Mon, Dec 9, 2019 at 7:33 AM Robert via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi all!
>>
>> I tried to compile the default RFNoC image for the N310, using UHD on tag
>> v3.15.0.0-rc2 and Xilinx Vivado 2018.3.1.
>>
>> Running "make N310_RFNOC_XG", the IP cores are compiled successfully,
>> but then Vivado shows the following errors:
>>
>> ERROR: [Synth 8-524] part-select [15:8] out of range of prefix
>> 'STR_SINK_FIFOSIZE'
>> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:270]
>> ERROR: [Synth 8-521] parameter assignment could not be resolved to a
>> constant [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:270]
>> ERROR: [Synth 8-196] conditional expression could not be resolved to a
>> constant [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:239]
>> WARNING: [Synth 8-693] zero replication count - replication ignored
>> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:26]
>> WARNING: [Synth 8-693] zero replication count - replication ignored
>> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:27]
>> WARNING: [Synth 8-693] zero replication count - replication ignored
>> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:31]
>> ERROR: [Synth 8-6156] failed synthesizing module
>> 'noc_shell__parameterized9'
>> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:21]
>> ERROR: [Synth 8-6156] failed synthesizing module 'noc_block_fosphor'
>> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_block_fosphor.v:8]
>> ERROR: [Synth 8-6156] failed synthesizing module 'n3xx_core'
>> [/usr/local/src/uhd/fpga-src/usrp3/top/n3xx/n3xx_core.v:17]
>> ERROR: [Synth 8-6156] failed synthesizing module 'n3xx'
>> [/usr/local/src/uhd/fpga-src/usrp3/top/n3xx/dboards/mg/n3xx.v:13]
>>
>> The full build.log file is attached. I did not modify any files, just
>> trying to compile the RFNoC example as provided.
>>
>>
>>
>>
>> Btw I also tried to build the default image with "make N310_XG", this one
>> compiles but failed later during DRC:
>>
>> [DRC BIVC-1] Bank IO standard Vcc: Conflicting Vcc voltages in bank 34.
>> For example, the following two ports in this bank have conflicting VCCOs:
>> ddr3_ck_p[0] (DIFF_SSTL15, requiring VCCO=1.500) and ddr3_addr[15]
>> (LVCMOS18, requiring VCCO=1.800)
>> [Vivado_Tcl 4-23] Error(s) found during DRC. Placer not run.
>>
>>
>> ___
>> 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] Phase relation between RX/TX LO

[Marcus D. Leech via USRP-users]

On 12/09/2019 02:38 PM, Lukas Haase wrote:


Precicely.


What frequencies are involved here?

Example: Transmit 900 Mhz (USRP Sink).
Receive 1800 MHz (USRP Source).

The received signal will have arbitrary phase phi1.
To make sure we're on the same page, you're measuring the phase offset 
between the two RX channels, correct?



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Phase relation between RX/TX LO

[Lukas Haase via USRP-users]

Hi Marcus,

> Von: "Marcus D. Leech" 
>
> On 12/09/2019 02:38 PM, Lukas Haase wrote:
> >
> > Precicely.
> >
> >> What frequencies are involved here?
> > Example: Transmit 900 Mhz (USRP Sink).
> > Receive 1800 MHz (USRP Source).
> >
> > The received signal will have arbitrary phase phi1.
> To make sure we're on the same page, you're measuring the phase offset
> between the two RX channels, correct?

No, I only have one RX channel at the moment.
--> One TX @ f and one RX @ 2f.
The phase relation between this TX+RX should stay constant/coherent once both 
TX+RX tune to a different f and back.

Let me know if the setup is clear, otherwise I'll try to draw a block 
diagram/equations or I can also send the GRC screenshots.

Thanks,
Luke



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Phase relation between RX/TX LO

[Marcus D. Leech via USRP-users]

On 12/09/2019 03:11 PM, Lukas Haase wrote:


No, I only have one RX channel at the moment.
--> One TX @ f and one RX @ 2f.
The phase relation between this TX+RX should stay constant/coherent once both 
TX+RX tune to a different f and back.

Let me know if the setup is clear, otherwise I'll try to draw a block 
diagram/equations or I can also send the GRC screenshots.

Thanks,
Luke



You code shows two RX channels:

now = self.uhd_usrp_sink_0.get_time_now()
 self.uhd_usrp_sink_0.set_command_time(now + uhd.time_spec(1))
 self.uhd_usrp_source_0.set_command_time(now + uhd.time_spec(1))

 self.uhd_usrp_source_0.set_center_freq(2*self.fcenter, 0)
 self.uhd_usrp_source_0.set_center_freq(2*self.fcenter, 1)
 self.uhd_usrp_sink_0.set_center_freq(self.fcenter, 0)

 self.uhd_usrp_source_0.clear_command_time()
 self.uhd_usrp_sink_0.clear_command_time()

So, you're measuring the phase-offset between the TX side and the RX 
side at the 2nd harmonic, and expecting that phase relationship to be

  the same across re-tunes?   I'm not sure that's possible.





___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Phase relation between RX/TX LO

[Lukas Haase via USRP-users]

Hi Marcus,

> Von: "Marcus D. Leech" 
>
> On 12/09/2019 03:11 PM, Lukas Haase wrote:
> >
> > No, I only have one RX channel at the moment.
> > --> One TX @ f and one RX @ 2f.
> > The phase relation between this TX+RX should stay constant/coherent once 
> > both TX+RX tune to a different f and back.
> >
> > Let me know if the setup is clear, otherwise I'll try to draw a block 
> > diagram/equations or I can also send the GRC screenshots.
> >
> > Thanks,
> > Luke
> >
> >
> You code shows two RX channels:
>
>  now = self.uhd_usrp_sink_0.get_time_now()
>   self.uhd_usrp_sink_0.set_command_time(now + uhd.time_spec(1))
>   self.uhd_usrp_source_0.set_command_time(now + uhd.time_spec(1))
>
>   self.uhd_usrp_source_0.set_center_freq(2*self.fcenter, 0)
>   self.uhd_usrp_source_0.set_center_freq(2*self.fcenter, 1)
>   self.uhd_usrp_sink_0.set_center_freq(self.fcenter, 0)
>
>   self.uhd_usrp_source_0.clear_command_time()
>   self.uhd_usrp_sink_0.clear_command_time()

Sorry for the confusion.
You are right, there are 2 RX channels but I only use one of them.

> So, you're measuring the phase-offset between the TX side and the RX
> side at the 2nd harmonic, and expecting that phase relationship to be
>the same across re-tunes?

Yes, this is exactly what I want.

> I'm not sure that's possible.

Why not?

Conceptually it must be possible: The phase offset is only defined by the 
*relative* phase between RX/TX-LO.

Let's assume that both RX + TX mixer are driven by the *same* LO but the RX 
side has an additional frequency doubler.
Then the phase relationship is ALWAYS constant. By construction.

The USRP just makes things complicated because RX and TX are driven by 
different PLLs and allow their LO to be retuned separately. But ultimately both 
PLLs are driven by the same reference (to which phase they lock) so there must 
be a way to have a constant phase relationship.

Thanks,
Luke



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Phase relation between RX/TX LO

[Marcus D. Leech via USRP-users]

On 12/09/2019 03:35 PM, Lukas Haase wrote:

Hi Marcus,


Von: "Marcus D. Leech" 

On 12/09/2019 03:11 PM, Lukas Haase wrote:

No, I only have one RX channel at the moment.
--> One TX @ f and one RX @ 2f.
The phase relation between this TX+RX should stay constant/coherent once both 
TX+RX tune to a different f and back.

Let me know if the setup is clear, otherwise I'll try to draw a block 
diagram/equations or I can also send the GRC screenshots.

Thanks,
Luke



You code shows two RX channels:

  now = self.uhd_usrp_sink_0.get_time_now()
   self.uhd_usrp_sink_0.set_command_time(now + uhd.time_spec(1))
   self.uhd_usrp_source_0.set_command_time(now + uhd.time_spec(1))

   self.uhd_usrp_source_0.set_center_freq(2*self.fcenter, 0)
   self.uhd_usrp_source_0.set_center_freq(2*self.fcenter, 1)
   self.uhd_usrp_sink_0.set_center_freq(self.fcenter, 0)

   self.uhd_usrp_source_0.clear_command_time()
   self.uhd_usrp_sink_0.clear_command_time()

Sorry for the confusion.
You are right, there are 2 RX channels but I only use one of them.


So, you're measuring the phase-offset between the TX side and the RX
side at the 2nd harmonic, and expecting that phase relationship to be
the same across re-tunes?

Yes, this is exactly what I want.


I'm not sure that's possible.

Why not?

Conceptually it must be possible: The phase offset is only defined by the 
*relative* phase between RX/TX-LO.

Let's assume that both RX + TX mixer are driven by the *same* LO but the RX 
side has an additional frequency doubler.
Then the phase relationship is ALWAYS constant. By construction.
But, that's not the situation we find ourselves in with the hardware 
(including FPGA) in front of us.


The USRP just makes things complicated because RX and TX are driven by 
different PLLs and allow their LO to be retuned separately. But ultimately both 
PLLs are driven by the same reference (to which phase they lock) so there must 
be a way to have a constant phase relationship.
Did you look at the reference I posted about Fractional-N vs Integer-N 
synthesis?  They behave very differently in this regard--the "phase reset"
  feature helps, but in this case, the UBX was never designed to 
maintain constant phase offsets between RX/TX (because this is a very very

  unusual case), PARTICULARLY ACROSS RETUNES.

Quite apart from what the PLL synthesizers are doing, there's the 
DDC/DUC within the FPGA, and they are driven by what amounts to a
  digital oscillator, and THOSE digital oscillators aren't shared, 
either.   Sharing phase constancy across TX/RX was never a design goal

  of the hardware.

Now, having said all that, it may be the case that there are specific 
configurations in which this can be made to work, and I'm in discussions
  with R&D about that.   Details like what the management policy is for 
the phase-accumulators in the DDC/DUC digital oscillators matters,
  along with hardware details like whether the RX and TX synthesizers 
shared a control bus or whether it's in parallel really matter, for example.





Thanks,
Luke





___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Phase relation between RX/TX LO

[Marcus D. Leech via USRP-users]

Something that MAY help here is to use integer_n tuning:

treq=uhd.tune_request(my_frequency)
treq.args=uhd.device_addr("mode_n=integer")

...

...set_center_freq(treq, 0)

This will force the PLL to use INTEGER_N tuning, which has more 
predictable phase behavior with respect to the reference.




___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] GPIOs timed commands

[Sam Reiter via USRP-users]

I believe this will work. It should just be a matter of setting the command
time before you send over a usrp->set_gpio_attr()

Sam Reiter
Ettus Research


On Thu, Dec 5, 2019 at 2:34 AM Emanuel via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi everybody,
>
>
>
> could the GPIOs, e.g., on a B200mini be set/unset precisely in time
> (limited to the sampling rate used)?
>
>
>
> Best regards,
>
> Emanuel
> ___
> 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] Error message: UHD: 1

[Sam Reiter via USRP-users]

Lukas,

You can test your hardware and software stack by running a couple UHD
shipping examples. Check out the examples here:
https://kb.ettus.com/Verifying_the_Operation_of_the_USRP_Using_UHD_and_GNU_Radio

You can also recompile UHD with the logging level set to trace in your
CMAKE flags: https://files.ettus.com/manual/page_logging.html

Best,

Sam Reiter
Ettus Research


On Fri, Dec 6, 2019 at 6:47 AM Lukas Buderath via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hey,
>
> we are utilizing the B210 with Amarisoft to emulate an LTE network. There
> are currently three PCs involved: One emulating the EPC, one emulating the
> eNB and one emulating the UE. We want the eNB and the UE to communicate via
> TDD on frequency band 38. However, when we adapt the Amarisoft config files
> to serve this purpose, the following (not very enlightening) error message
> appears:
> UHD: 1
> UHD: 1
> UHD: 1
> ...
>
> We have asked the Amarisoft support for help, but they claim this is a uhd
> related issue. Can somebody relate? Does anyone have any idea what this
> error message says?
>
> Kind regards,
> Lukas
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Time Synchronized Transmit with 2 USRPs

[Sam Reiter via USRP-users]

Hasan,

Are the USRPs sharing any kind of timing / clocking signals? Typically we
would recommend that you share a reference clock and PPS clock across all
devices, and from there you'd just need to coordinate timed commands. With
timed commands in UHD, you can tell each USRP to reset its internal sense
of time to 0 on the next rising PPS edge. Once they have agreed upon this
time, you should see them stay locked together as a shared reference clock
with prevent drift. One obstacle is ensuring that each terminal (are these
separate computers?) needs to send the "time reset" command to its USRPs
within a single PPS cycle. If your reset commands came on different PPS
cycles, you'd see your radios offset by 1 second. Here is the manual page
with the list of timed commands that you can use for this:

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

Can you also let us know what USRPs and version of UHD you're using?

Sam Reiter
Ettus Research

On Wed, Dec 4, 2019 at 4:03 AM Hasan Can Yildirim via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> *Here is the summary of my experimental setup:*
>
> 4 data receiving channels with 2 USRPs. Sampling rates are 100 Msps.
> 1 data transmitter with 1 USRP. Sampling rate is 100 Msps.
> 1 calibration transmitter with 1 USRP. Sampling rate is 50 Msps (or
> smaller, say 33.3 Msps).
>
> All the daughterboards are UBX160.
> The USRPs are connected through the 10Gbit/s ethernet connections.
> I am using a modified version of the C/C++ code with the uhd libraries.
> So, no gnu-radio etc.
>
> *The question in one sentence:*
>
> How can I start transmitting at the same time with 2 USRPs, that has two
> different sampling rates, and 'invoked' at two different terminals?
>
> *Here is the detailed explanation about what I want to achieve with this
> setup:*
>
> I want to use the calibration signal, to estimate the unknown
> delays/phases (introduced by the hardwares) on the receiver side, then use
> this calibration to apply angle-of-arrival algorithms on the received data.
> I know that I could transmit the calibration signal and the data signal,
> at the same time. Then apply a high-pass filter to separate the calibration
> signal, do the calibration, and so on...
> Instead, I would like to synchronize the data and calibration
> transmitters, so that they start transmitting at the same time. Receiver
> will receive continuously, for a long enough duration.
> In other words, the calibration signal will be a signal of N samples and M
> zeros. Mean while, the data will be N zeros, M data samples. So, during the
> first N samples, I will receive only the calibration signal, then during
> the next M samples, I will receive the data signal. To achieve this, the
> two transmitters have to start transmitting at the same time (maybe a small
> error with a few samples is acceptable). How can I achieve this?
>
>
> Thanks a lot for your advices.
>
> Cheers,
> Hasan
>
>
>
> ___
> 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] Libuhd issues - "uhd_find_devices: error while loading shared libraries"

[Saeid Hashemi via USRP-users]

Thank you for your advice Fabian!

It seems there is no package called libuhd, just the following versions:
libuhd003 libuhd3.14.0  libuhd-dev

So I did:

$ sudo dpkg -P libuhd3.14.0
(Reading database ... 291299 files and directories currently installed.)
Removing libuhd3.14.0:amd64 (3.14.0.0-0ubuntu1~trusty1) ...
Purging configuration files for libuhd3.14.0:amd64
(3.14.0.0-0ubuntu1~trusty1) ...
Processing triggers for libc-bin (2.19-0ubuntu6.15) ...
$ sudo apt-get install libuhd3.14.1

And now UHD tools work, also within the LTE software, but they won't find
my B210 saying:

[INFO] [UHD] linux; GNU C++ version 4.8.4; Boost_105400;
UHD_3.14.1.1-release
Error: LookupError: KeyError: No devices found for ->
Empty Device Address

Regards,
Saeid




On Fri, Dec 6, 2019 at 2:58 AM Fabian Schwartau via USRP-users <
usrp-users@lists.ettus.com> wrote:

> You have an old version of libuhd already installed. Uninstall it using:
> $ sudo dpkg -P libuhd
> Then retry installing it. Sometimes libraries are not found and you have
> to run
> $ sudo ldconfig
> but that is usually done by dpkg.
>
> Am 06.12.2019 um 00:31 schrieb Saeid Hashemi via USRP-users:
> > Hello everyone,
> >
> > I have an Intel NUC running Ubuntu 16.04 and a low latency kernel which
> > I use for OAI LTE software on top of UHD.
> >
> > After updating my system repositories, UHD broke somehow with the
> > following result:
> >
> > nuc8-3@nuc83-NUC8i7BEH:~$ uhd_find_devices
> > uhd_find_devices: error while loading shared libraries:
> > libuhd.so.3.14.1: cannot open shared object file: No such file or
> directory
> >
> > Attempting to manually install the version cited in the error gives me
> this:
> >
> > Unpacking libuhd3.14.1:amd64 (3.14.1.1-0ubuntu1~trusty1) ...
> > dpkg: error processing archive
> > /var/cache/apt/archives/libuhd3.14.1_3.14.1.1-0ubuntu1~trusty1_amd64.deb
> > (--unpack):
> >   trying to overwrite '/usr/share/uhd/rfnoc/blocks/keep_one_in_n.xml',
> > which is also in package libuhd3.14.0:amd64 3.14.0.0-0ubuntu1~trusty1
> > dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
> > Errors were encountered while processing:
> >
>  /var/cache/apt/archives/libuhd3.14.1_3.14.1.1-0ubuntu1~trusty1_amd64.deb
> > E: Sub-process /usr/bin/dpkg returned an error code (1)
> >
> >
> > Would anyone have any recommendations on what to do to make sure I have
> > the right version of everything present?
> >
> >
> > ___
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
> --
> --
> M.-Sc. Fabian Schwartau
> Technische Universität Braunschweig
> Institut für Hochfrequenztechnik
> Schleinitzstr. 22
> 38106 Braunschweig
> Germany
>
> Tel.:   +49-(0)531-391-2017
> Fax:+49-(0)531-391-2045
> Email:  fabian.schwar...@ihf.tu-bs.de
> WWW:http://www.tu-braunschweig.de/ihf
> --
>
> ___
> 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] DPDK build with N310

[Akis Kourtis via USRP-users]

Hello all,

 

I am trying to build the oai-5g-gNB. I have managed to build the DPDK with
uhd successfully, however when I run the probe command I receive the
following error.

 

EAL: Starting I/O threads!

[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
UHD_3.14.1.HEAD-0-g0347a6d8

[INFO] [MPMD] Initializing 1 device(s) in parallel with args:
mgmt_addr=10.30.0.218,type=n3xx,product=n310,serial=3177E48,claimed=False,ad
dr=192.168.20.2,second_addr=192.168.20.2,use_dpdk=1

[ERROR] [MPMD] No viable transport path found!

[ERROR] [MPMD] Failure during block enumeration: RuntimeError: No viable
transport path found!

[INFO] [MPM.PeriphManager] init() called with device args
`time_source=internal,clock_source=internal,second_addr=192.168.20.2,mgmt_ad
dr=10.30.0.218,product=n310,use_dpdk=1'.

[WARNING] [MPM.PeriphManager.UDP] Number of detected CHDR devices is
inconsistent. Dropped from 1 to 0.

[INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found!

Error: RuntimeError: Failed to run enumerate_rfnoc_blocks()

 

My guess from reading back posts from the forum, is that the proper DPDK
file is not read.

I can see a /etc/conf/uhd.conf file, but no /root/.uhd/uhd.conf file.

Am I in the right direction, and if so, how do I enable the user conf file?

 

If not, is there a direction I should head towards?

 

Thank you,

 

Akis

 

Akis Kourtis

M.Sc, Ph.D

Research Associate 

Media Networks Laboratory

Institute of Information & Telecommunications

National Centre for Scientific Research "DEMOKRITOS"

 

akis.kourtis@ iit.demokritos.gr

+306948386769



 

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] E312 RX_B issue

[Beeman, Isaac L. via USRP-users]

Hello group,

I have run into an issue with the RX_B port (channel 1) on the E312 that I 
haven't been able to make any sense of.

RX_A (channel 0) works great: I get clear in-phase and quadrature components 
that I have been able to graph. When I do the same 
thing with RX_B (channel 1), I get something completely 
unexpected. I am using the same rate (=0.5 Msps) 
frequency (=900 MHz), gain (=50 dB), bandwidth (=200 kHz) on each and have had 
this happen whether I use both channels at the same time or read from RX_B 
individually.

I haven't had anything like this happen when I transmit on both TX_A and TX_B, 
and I have tested this on multiple USRP E312 radios and 900 MHz antennas to 
make sure it wasn't something unrelated to the channel/port itself.

Does anyone know what could be happening?

-Isaac Beeman
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] transmitting on two channels with replay block

[Rob Kossler via USRP-users]

Apart from solving the underrun issue, there is also an issue with
synchronization.  The replay block doesn't presently support timed commands.

And, as a side note, the issue with streaming from the host is not just the
host.  The DMA FIFO has a maximum bandwidth of something like 600 MS/s
(combination of all inputs and outputs) that precludes streaming 400 MS/s
in and out of the block simultaneously.  So, even if the host could keep
up, the FIFO could not.
Rob

On Mon, Dec 9, 2019 at 4:34 AM Thomas Harder via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Sam,
>
> Thank you for your reply.
>
> This morning I set the MCR to 184.32 and I am still having continuous
> underruns using also
>
> replay_ctrl->get_record_fullness
>
> for both channels.
>
>
>
> But since I need the full bandwidth of 160MHz I would like implement a
> second replay block in my fpga image.
>
>
>
> Could anyone help me with this?
>
> I am really new in fpga programming and for the image with one replay
> block I was just following the instructions in
> https://kb.ettus.com/Using_the_RFNoC_Replay_Block.
>
> Thank you,
>
> Thomas
>
>
>
>
>
> *From: *Sam Reiter 
> *Sent: *Friday, December 6, 2019 10:23 PM
> *To: *Thomas Harder 
> *Cc: *usrp-users@lists.ettus.com
> *Subject: *Re: [USRP-users] transmitting on two channels with replay block
>
>
>
> Thomas,
>
>
>
> Upon further investigation, we may be running up to a practical limit of a
> single CHDR interface rather than an issue with your code. A single replay
> block servicing two radios will have a max (theoretical) rate of 187.5 MSPS
> on either channel. This means that you might be able to squeeze full rate
> out on 2 channels with an MCR of 184.32, but that's cutting it pretty
> close. Sounds like 2 channels at 200 MSPS with a replay setup will require
> 2 replay blocks serving each channel independently. If you end up trying
> either of the above out, I'd be curious to know what results you observe.
>
>
>
> Sam Reiter
>
> Ettus Research
>
>
>
>
>
> On Fri, Dec 6, 2019 at 2:38 PM Sam Reiter  wrote:
>
> Thomas,
>
>
>
> I'd need to set it up on my end, but I believe you can TX two distinct
> waveforms from a single replay block instance. You'd need to make sure that
> your adding your data to the buffer in separate locations and at an address
> that is a multiple of 8 bytes (which it looks like you're doing from the
> above snippets). Are you seeing continuous underruns, or just a handful at
> the beginning on the run? Does your duplicated code also use:
>
>
>
> replay_ctrl->get_record_fullness
>
>
>
> on both channels before kicking off the stream start?
>
>
>
> Sam Reiter
>
> Ettus Research
>
>
>
> On Wed, Dec 4, 2019 at 3:48 AM Thomas Harder via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hello everyone,
>
> Is it possible to transmit two different waveforms on the two channels of
> the USRP X310 with the two UBX-160 daughterboards?
>
> I want to transmit two different waveforms simultaneous (synchronized ) on
> the two channels of the USRP with the full sample rate of 200 MS/s. I tried
> already to do it with a dual 10Gbit-ethernet connection and I seemed to be
> limited by my computer. Now I am trying to do it with the replay block.
>
>
>
> I built the FPGA image with one Replay block as described in
> https://kb.ettus.com/Using_the_RFNoC_Replay_Block to run the example
> “replay_samples_from_file” and it is working fine if I transmit just on one
> channel. Now I was modifying the code by connecting the replay block to
> both channels:
>
>
> replay_graph->connect(replay_ctrl->get_block_id(),replay_chan,tx_blockid,tx_chan,replay_spp);
>
>
> replay_graph->connect(replay_ctrl->get_block_id(),replay_chan1,tx_blockid1,tx_chan,replay_spp);
>
>
>
> and writing the same waveform into another region of the DRAM-buffer:
>
> replay_ctrl->config_record(0,words_to_replay*replay_word_size,
> replay_chan);
>
> replay_ctrl->config_record(2,words_to_replay*replay_word_size,
> replay_chan1);
>
> and
>
> replay_ctrl->config_play(0,words_to_replay*replay_word_size, replay_chan);
>
> replay_ctrl->config_play(2,words_to_replay*replay_word_size,
> replay_chan1);
>
>
>
> where
>
> words_to_replay*replay_word_size=16000
>
> replay_chan=0
>
> replay_chan1=1
>
> tx_blockid=0/Radio_0
>
> tx_blockid=0/Radio_1
>
>
>
> then I stream my waveforms to the replay block as defined in the example
> and I start to replay the data:
>
> replay_ctrl->issue_stream_cmd(stream_cmd, replay_chan);
>
> replay_ctrl->issue_stream_cmd(stream_cmd, replay_chan1);
>
>
>
> It works but with plenty of Underflows!!
>
>
>
> So what does it mean when it says in the manual:
>
> “Note that the record and playback buffers do not need to the same,
> allowing a single Replay block to both record and playback to different
> regions of memory* simultaneously*.”
>
> (https://kb.ettus.com/Using_the_RFNoC_Replay_Block)?
>
>
>
> Because in the manual it says also:
>
> “The replay block has the following features: One input

Re: [USRP-users] Phase relation between RX/TX LO

[Lukas Haase via USRP-users]

Hi Marcus,

> Gesendet: Montag, 09. Dezember 2019 um 15:58 Uhr
>
> On 12/09/2019 03:35 PM, Lukas Haase wrote:
> > Hi Marcus,
> >
> >> Von: "Marcus D. Leech" 
> >>
> >> On 12/09/2019 03:11 PM, Lukas Haase wrote:
> >>> No, I only have one RX channel at the moment.
> >>> --> One TX @ f and one RX @ 2f.
> >>> The phase relation between this TX+RX should stay constant/coherent once 
> >>> both TX+RX tune to a different f and back.
> >>>
> >>> Let me know if the setup is clear, otherwise I'll try to draw a block 
> >>> diagram/equations or I can also send the GRC screenshots.
> >>>
> >>> Thanks,
> >>> Luke
> >>>
> >>>
> >> You code shows two RX channels:
> >>
> >>   now = self.uhd_usrp_sink_0.get_time_now()
> >>self.uhd_usrp_sink_0.set_command_time(now + uhd.time_spec(1))
> >>self.uhd_usrp_source_0.set_command_time(now + uhd.time_spec(1))
> >>
> >>self.uhd_usrp_source_0.set_center_freq(2*self.fcenter, 0)
> >>self.uhd_usrp_source_0.set_center_freq(2*self.fcenter, 1)
> >>self.uhd_usrp_sink_0.set_center_freq(self.fcenter, 0)
> >>
> >>self.uhd_usrp_source_0.clear_command_time()
> >>self.uhd_usrp_sink_0.clear_command_time()
> > Sorry for the confusion.
> > You are right, there are 2 RX channels but I only use one of them.
> >
> >> So, you're measuring the phase-offset between the TX side and the RX
> >> side at the 2nd harmonic, and expecting that phase relationship to be
> >> the same across re-tunes?
> > Yes, this is exactly what I want.
> >
> >> I'm not sure that's possible.
> > Why not?
> >
> > Conceptually it must be possible: The phase offset is only defined by the 
> > *relative* phase between RX/TX-LO.
> >
> > Let's assume that both RX + TX mixer are driven by the *same* LO but the RX 
> > side has an additional frequency doubler.
> > Then the phase relationship is ALWAYS constant. By construction.
> But, that's not the situation we find ourselves in with the hardware
> (including FPGA) in front of us.
> >
> > The USRP just makes things complicated because RX and TX are driven by 
> > different PLLs and allow their LO to be retuned separately. But ultimately 
> > both PLLs are driven by the same reference (to which phase they lock) so 
> > there must be a way to have a constant phase relationship.
> Did you look at the reference I posted about Fractional-N vs Integer-N
> synthesis?  They behave very differently in this regard--the "phase reset"
>feature helps, but in this case, the UBX was never designed to
> maintain constant phase offsets between RX/TX (because this is a very very
>unusual case), PARTICULARLY ACROSS RETUNES.

Yes, I reviewed it. Thanks for the reference, I did not know this about 
fractional-N PLLs.
Do you know by any chance if the phase reset feature is implemented by the USRP 
or not (initially you suggest it has, above you suggest it may not).

> Quite apart from what the PLL synthesizers are doing, there's the
> DDC/DUC within the FPGA, and they are driven by what amounts to a
>digital oscillator, and THOSE digital oscillators aren't shared,
> either.   Sharing phase constancy across TX/RX was never a design goal
>of the hardware.

That makes sense too. I am still wondering why phase constancy betwene TX/RX 
would be such a "weird" goal.
Yes, in many cases this phase rotation is readily divided out but in particular 
for fast frequency hopping systems it becomes hard. Or for phase based ranging 
systems. I mean, they exist, right?

I see that the DDC/DUC are not shared. At least in principle it should be easy 
to synchronize them ... the beauty of a digital system (their digital clocks 
are shared).

While I have worked with such systems in the past I am unfortunately new to 
gnuradio and USRP. Gnuradio is a steep learning curve on its own, these small 
details add significantly to my confusion.

> Now, having said all that, it may be the case that there are specific
> configurations in which this can be made to work, and I'm in discussions
> with R&D about that.   Details like what the management policy is for
> the phase-accumulators in the DDC/DUC digital oscillators matters,
> along with hardware details like whether the RX and TX synthesizers
> shared a control bus or whether it's in parallel really matter, for example.

Any possible help is greatly appreciated!

> Something that MAY help here is to use integer_n tuning:
>
>  treq=uhd.tune_request(my_frequency)
>  treq.args=uhd.device_addr("mode_n=integer")
>
>  ...
>
>  ...set_center_freq(treq, 0)


I translated this to gnuradio:

def set_fcenter(self, fcenter):
self.fcenter = fcenter

tune_resp_tx = self.uhd_usrp_sink_0.set_center_freq(fcenter, 0)
tune_resp_rx = self.uhd_usrp_source_0.set_center_freq(2*fcenter, 0)

tune_req_tx = uhd.tune_request(rf_freq=fcenter, 
rf_freq_policy=uhd.tune_request.POLICY_MANUAL,
   dsp_freq=tune_resp_tx.actual_dsp_freq, 
dsp_f

Re: [USRP-users] Phase relation between RX/TX LO

[Marcus D. Leech via USRP-users]

On 12/09/2019 11:03 PM, Lukas Haase wrote:

Hi Marcus,


Gesendet: Montag, 09. Dezember 2019 um 15:58 Uhr

On 12/09/2019 03:35 PM, Lukas Haase wrote:

Hi Marcus,


Von: "Marcus D. Leech" 

On 12/09/2019 03:11 PM, Lukas Haase wrote:

No, I only have one RX channel at the moment.
--> One TX @ f and one RX @ 2f.
The phase relation between this TX+RX should stay constant/coherent once both 
TX+RX tune to a different f and back.

Let me know if the setup is clear, otherwise I'll try to draw a block 
diagram/equations or I can also send the GRC screenshots.

Thanks,
Luke



You code shows two RX channels:

   now = self.uhd_usrp_sink_0.get_time_now()
self.uhd_usrp_sink_0.set_command_time(now + uhd.time_spec(1))
self.uhd_usrp_source_0.set_command_time(now + uhd.time_spec(1))

self.uhd_usrp_source_0.set_center_freq(2*self.fcenter, 0)
self.uhd_usrp_source_0.set_center_freq(2*self.fcenter, 1)
self.uhd_usrp_sink_0.set_center_freq(self.fcenter, 0)

self.uhd_usrp_source_0.clear_command_time()
self.uhd_usrp_sink_0.clear_command_time()

Sorry for the confusion.
You are right, there are 2 RX channels but I only use one of them.


So, you're measuring the phase-offset between the TX side and the RX
side at the 2nd harmonic, and expecting that phase relationship to be
 the same across re-tunes?

Yes, this is exactly what I want.


I'm not sure that's possible.

Why not?

Conceptually it must be possible: The phase offset is only defined by the 
*relative* phase between RX/TX-LO.

Let's assume that both RX + TX mixer are driven by the *same* LO but the RX 
side has an additional frequency doubler.
Then the phase relationship is ALWAYS constant. By construction.

But, that's not the situation we find ourselves in with the hardware
(including FPGA) in front of us.

The USRP just makes things complicated because RX and TX are driven by 
different PLLs and allow their LO to be retuned separately. But ultimately both 
PLLs are driven by the same reference (to which phase they lock) so there must 
be a way to have a constant phase relationship.

Did you look at the reference I posted about Fractional-N vs Integer-N
synthesis?  They behave very differently in this regard--the "phase reset"
feature helps, but in this case, the UBX was never designed to
maintain constant phase offsets between RX/TX (because this is a very very
unusual case), PARTICULARLY ACROSS RETUNES.

Yes, I reviewed it. Thanks for the reference, I did not know this about 
fractional-N PLLs.
Do you know by any chance if the phase reset feature is implemented by the USRP 
or not (initially you suggest it has, above you suggest it may not).


Quite apart from what the PLL synthesizers are doing, there's the
DDC/DUC within the FPGA, and they are driven by what amounts to a
digital oscillator, and THOSE digital oscillators aren't shared,
either.   Sharing phase constancy across TX/RX was never a design goal
of the hardware.

That makes sense too. I am still wondering why phase constancy betwene TX/RX would be 
such a "weird" goal.
Yes, in many cases this phase rotation is readily divided out but in particular 
for fast frequency hopping systems it becomes hard. Or for phase based ranging 
systems. I mean, they exist, right?

I see that the DDC/DUC are not shared. At least in principle it should be easy 
to synchronize them ... the beauty of a digital system (their digital clocks 
are shared).

While I have worked with such systems in the past I am unfortunately new to 
gnuradio and USRP. Gnuradio is a steep learning curve on its own, these small 
details add significantly to my confusion.


Now, having said all that, it may be the case that there are specific
configurations in which this can be made to work, and I'm in discussions
with R&D about that.   Details like what the management policy is for
the phase-accumulators in the DDC/DUC digital oscillators matters,
along with hardware details like whether the RX and TX synthesizers
shared a control bus or whether it's in parallel really matter, for example.

Any possible help is greatly appreciated!


Something that MAY help here is to use integer_n tuning:

  treq=uhd.tune_request(my_frequency)
  treq.args=uhd.device_addr("mode_n=integer")

  ...

  ...set_center_freq(treq, 0)


I translated this to gnuradio:

 def set_fcenter(self, fcenter):
 self.fcenter = fcenter

 tune_resp_tx = self.uhd_usrp_sink_0.set_center_freq(fcenter, 0)
 tune_resp_rx = self.uhd_usrp_source_0.set_center_freq(2*fcenter, 0)

 tune_req_tx = uhd.tune_request(rf_freq=fcenter, 
rf_freq_policy=uhd.tune_request.POLICY_MANUAL,
dsp_freq=tune_resp_tx.actual_dsp_freq, 
dsp_freq_policy=uhd.tune_request.POLICY_MANUAL)
 tune_req_rx = uhd.tune_request(rf_freq=2*fcenter, 
rf_freq_policy=uhd.tune_request.POLICY_MANUAL,
dsp_freq=tune_resp_rx.actual_dsp_freq,

Re: [USRP-users] Phase relation between RX/TX LO

[Lukas Haase via USRP-users]

Hi Marcus,


> Von: "Marcus D. Leech" 
> [...]
> >
> You're using the MANUAL policy for BOTH DSP and RF.  Let the automatic
> "stuff" do its thing, with the only difference being integer-N tuning.

Wow, this is all so black magic.
After a long time I figured out that I also have to supply int_n_step (I use 
int_n_step=100e3), as I randomly stumbled across in 
http://www.radio-science.net/2017/12/adventures-in-usrp-tuning.html.
The documentation does not even mention the existence of this parameter.

tune_req_tx = uhd.tune_request(target_freq=fcenter)
tune_req_rx = uhd.tune_request(target_freq=2*fcenter)
tune_req_rx.args=uhd.device_addr(','.join(["mode_n=integer", 
"int_n_step=100e3",]))
tune_req_tx.args=uhd.device_addr(','.join(["mode_n=integer", 
"int_n_step=100e3",]))
now = self.uhd_usrp_sink_0.get_time_now()
self.uhd_usrp_sink_0.set_command_time(  now + uhd.time_spec(1))
self.uhd_usrp_source_0.set_command_time(now + uhd.time_spec(1))
self.uhd_usrp_sink_0.set_center_freq(  tune_req_tx, 0)
self.uhd_usrp_source_0.set_center_freq(tune_req_rx, 0)
self.uhd_usrp_source_0.set_center_freq(tune_req_rx, 1)
self.uhd_usrp_source_0.clear_command_time()
self.uhd_usrp_sink_0.clear_command_time()

So now my RX/TX tune again (i.e., I get a signal other than noise). 
Unfortunately I run into the same issue that I had already some time at the 
beginning: My signal is frequency offset (*) - by an odd 2.5 kHz.
I set my clock explicitely to 200 MHz. A step size of 100kHz should be able to 
synthesize my even numbers (900 MHz) without issues. On the other hand, the 
frequency offset stays at 2.5kHz for different values of int_n_step...

Thanks,
Luke





(*) What I mean by that: I send a signal at "f+fif" and downconvert 
"2*(f+fif)". In gnuradio I multiply with exp(i*2*pi*fif*t). I expect my signal 
to be a DC signal (which it is in absence of the mode_n=integer). With 
frequency shift I mean that I see a frequency of 2.5 kHz instead of 0Hz.





___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com