[USRP-users] USRP with different GPSDO

2018-01-23 Thread Ali via USRP-users 
Hi to all,

Is it possible to use different GPSDO (more accurate) than the one that
Ettus sells? The device is X310. Can you suggest any brand or model?

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

Re: [USRP-users] Passing Messages as Commands to UHD Sink

2018-01-23 Thread Martin Braun via USRP-users 
On Tue, Jan 23, 2018 at 02:11:21AM +, Sarah Tran via USRP-users wrote:
>Hi All,
> 
>I would like to change the center freq of my UHD Sink depending on who the
>receiver is. So I wrote a custom block that will read what the destination
>mac address is for a packet, and send a message to change the center freq
>based on what destination address it is. This is the format for how I
>write the message:
> 
>{
>   message_port_register_out(PDU_PORT_ID);
>}
>   command = pmt::make_dict();
>   command = pmt::dict_add(command, pmt::mp(“freq”),
>pmt::mp(2.412e9));
>   command = pmt::dict_add(command, pmt::mp(“chan”),
>pmt::mp(0));
>   message_port_pub(PDU_PORT_ID, command);
> 
>I saw from other mailing list posts, that this was the syntax they used,
>but I can’t get it to actually the center frequency. Is there something I
>am doing wrong? I am using uhd version 3.10 and GRC version 3.7.11.1.

Sarah,

this looks fine. Are you sure the messages are being received? Do you
see any log statements to that effect?

-- Martin


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

Re: [USRP-users] Using both sides of an NI USRP-2953R

2018-01-23 Thread Martin Braun via USRP-users 
On Tue, Jan 23, 2018 at 12:27:23PM -0500, Daryl Lee via USRP-users wrote:
> I've been using an NI USRP-2953R for several months with a trivial
> configuration: sending and receiving in "half-duplex" mode on the "RF 0"
> receive and transmit antennas.  Now I need to try using the RF 0 RX antenna
> and the RF 1 TX antenna.  I'm using this terminology because I'm a bit
> uncertain about the other terminology (daugherboard, front-end, sub-device,
> channel, port, ...).  I found the application note "Frontends, Sub-Device
> Specifications, and Antenna Port Selection", which is very helpful, but
> having an example would be efven more helpful.  The UHD library distribution
> example "txrx_loopback_to_file" leads me to believe that I need a separate
> multi_usrp object for each direction (tx_usrp, rx_usrp), but I also need to
> work out the correct sub-device specification "X:Y" to pass in the arg
> string.
> 
> Can anyone point me to other documents/tutorials/examples of such a
> configuration?

Daryl,

you don't need several multi_usrp instantiations (and in fact, they
would point to the same underlying device due to some device caching).

There are multiple ways to achieve this:

1. Set RX subdev spec to "A:0", and TX subdev spec to "B:0". This will
select the A-side for RX, and the B-side for TX. Then, create one
streamer on channel 0 for each direction (call get_rx_stream() and
get_tx_stream() with default args).


2. Set the RX and TX subdev spec both to "A:0 B:0" (this is the
default). Then, call get_rx_stream() with channels = [0] and
get_tx_stream() with channels = [1] (both are vectors of length one).

Both will achieve the same effect. The difference is when calling other
multi_usrp calls such as set_rx_freq() or set_tx_freq(). The channel
indexing is relative to the subdev spec.


-- Martin




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

Re: [USRP-users] use 2 DDC chain of N210 with SBX

2018-01-23 Thread Martin Braun via USRP-users 
On Mon, Jan 22, 2018 at 03:01:14PM +0330, omid saeedy via USRP-users wrote:
>Hi
>I am a master student and my thesis needs N210.
>I want to use 2 DDC chains as 2 channels with SBX.
>But I can't edit UHD due to this.
>When I want to change subdev_spec GNURadio warn me only [A:0] is valid.

Does "A:0 A:0" not work as subdev spec?

-- Martin


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

Re: [USRP-users] Help on UHD Python API installation

2018-01-23 Thread Zhongyuan Zhao via USRP-users 
CMAKE list Python API as disabled,

Moreover,
Dependency PythonLibs_FOUND =
Disabling LibUHD - Python API support.

Zhongyuan Zhao

PhD Candidate,
Department of Computer Science & Engineering,
University of Nebraska-Lincoln
Office Hour: WF 9:30-10:00am, Avery Hall 12,
Suite 117, Schorr Center,
Lincoln, Nebraska 68588-0115


On Tue, Jan 23, 2018 at 12:47 AM, Martin Braun via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Zhao,
>
> you need to first install Boost, then UHD. When you run CMake on UHD,
> does it list the Python API as an enabled component?
>
> -- M
>
> On 01/22/2018 02:43 PM, Zhongyuan Zhao via USRP-users wrote:
> > Could anyone provide a complete guidance of installation of UHD Python
> > API on Ubuntu?
> >
> > I cloned the python api repo, and followed this installation of UHD from
> > source
> >  USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux>
> >
> > Then I installed Boost.Python followed here
> > , with these
> > commands
> >
> > |cd path/to/boost_1_66_0 ./bootstrap.sh --help ./bootstrap.sh
> > --prefix=/usr/local/lib/boost --with-libraries=python |
> >
> > However, when I run 'import uhd' in python, it says 'no module named
> > uhd'. The OS is Ubuntu running on a Mac Mini.
> >
> > 1. The source is python-api branch,
> >
> > 2. Build and installed successfully
> >
> > 3. PYTHONPATH: I use cmake ../ to installed on default directory
> > (/usr/local/), and I put '/usr/local/bin/' to PYTHONPATH in .bashrc file
> >
> >
> > Thank you!
> >
> > Zhao
> >
> >
> >
> > ___
> > 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] Help on UHD Python API installation

2018-01-23 Thread Zhongyuan Zhao via USRP-users 
Hi,

The CMAKE shows that Python API is disabled,

I was unable to enable it. It shows
Dependency PythonLibs_FOUND =

Is there anything missing?

Zhongyuan Zhao

PhD Candidate,
Department of Computer Science & Engineering,
University of Nebraska-Lincoln
Office Hour: WF 9:30-10:00am, Avery Hall 12,
Suite 117, Schorr Center,
Lincoln, Nebraska 68588-0115


On Tue, Jan 23, 2018 at 12:47 AM, Martin Braun via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Zhao,
>
> you need to first install Boost, then UHD. When you run CMake on UHD,
> does it list the Python API as an enabled component?
>
> -- M
>
> On 01/22/2018 02:43 PM, Zhongyuan Zhao via USRP-users wrote:
> > Could anyone provide a complete guidance of installation of UHD Python
> > API on Ubuntu?
> >
> > I cloned the python api repo, and followed this installation of UHD from
> > source
> >  USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux>
> >
> > Then I installed Boost.Python followed here
> > , with these
> > commands
> >
> > |cd path/to/boost_1_66_0 ./bootstrap.sh --help ./bootstrap.sh
> > --prefix=/usr/local/lib/boost --with-libraries=python |
> >
> > However, when I run 'import uhd' in python, it says 'no module named
> > uhd'. The OS is Ubuntu running on a Mac Mini.
> >
> > 1. The source is python-api branch,
> >
> > 2. Build and installed successfully
> >
> > 3. PYTHONPATH: I use cmake ../ to installed on default directory
> > (/usr/local/), and I put '/usr/local/bin/' to PYTHONPATH in .bashrc file
> >
> >
> > Thank you!
> >
> > Zhao
> >
> >
> >
> > ___
> > 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] Using both sides of an NI USRP-2953R

2018-01-23 Thread Daryl Lee via USRP-users 
I've been using an NI USRP-2953R for several months with a trivial  
configuration: sending and receiving in "half-duplex" mode on the "RF  
0" receive and transmit antennas.  Now I need to try using the RF 0 RX  
antenna and the RF 1 TX antenna.  I'm using this terminology because  
I'm a bit uncertain about the other terminology (daugherboard,  
front-end, sub-device, channel, port, ...).  I found the application  
note "Frontends, Sub-Device Specifications, and Antenna Port  
Selection", which is very helpful, but having an example would be  
efven more helpful.  The UHD library distribution example  
"txrx_loopback_to_file" leads me to believe that I need a separate  
multi_usrp object for each direction (tx_usrp, rx_usrp), but I also  
need to work out the correct sub-device specification "X:Y" to pass in  
the arg string.


Can anyone point me to other documents/tutorials/examples of such a  
configuration?


--
Daryl Lee


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

Re: [USRP-users] UHD Converter for X310 series with unsupported data format

2018-01-23 Thread Martin Braun via USRP-users 
On Tue, Jan 23, 2018 at 12:13:48PM -0500, Kei Nguyen via USRP-users wrote:
>I mean s16 -> f32 not sc16 -> fc32, which is already implemented.
>I looked through the document but it's not clear to me. I'm not sure about
>UHD code structure. Could you explain in more details?
>Sorry for any confusion.

Like I said, s16 -> fc32 is already implemented. Assuming your FPGA code
produces real samples (s16), you then select f32 as your output format.
Select appropriate values in your uhd::stream_args_t struct.

Cheers,
Martin


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

Re: [USRP-users] USRP with different GPSDO

2018-01-23 Thread Martin Braun via USRP-users 
On Tue, Jan 23, 2018 at 01:47:57PM +0300, Ali via USRP-users wrote:
>Hi to all,
>Is it possible to use different GPSDO (more accurate) than the one that
>Ettus sells? The device is X310. Can you suggest any brand or model?
>Best,

Ali,

if you find a pin- and API-compatible GPSDO, you can give it a try, but
keep in mind that's outside of what warranty and support covers.

-- Martin


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

Re: [USRP-users] UHD Converter for X310 series with unsupported data format

2018-01-23 Thread Kei Nguyen via USRP-users 
I mean s16 -> f32 not sc16 -> fc32, which is already implemented.
I looked through the document but it's not clear to me. I'm not sure about
UHD code structure. Could you explain in more details?

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

Re: [USRP-users] Help on UHD Python API installation

2018-01-23 Thread Martin Braun via USRP-users 
On Tue, Jan 23, 2018 at 04:36:13PM +, Zhongyuan Zhao wrote:
>Hi, 
>The CMAKE shows that Python API is disabled,
>I was unable to enable it. It shows 
>Dependency PythonLibs_FOUND =
>Is there anything missing? 

You need Python development libraries, e.g., python2.7-dev if you're on
Ubuntu.

-- Martin



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

Re: [USRP-users] [RFNoC] uhd_usrp_probe fails and throws uhd::lookup_error

2018-01-23 Thread Adam Kurisko via USRP-users 
Hi Martin,


I am unsure if I had edited the property subtrees, however I decided to fresh 
install UHD to see if that might fix the problem. I will let you know if I 
experience similar errors.


In the mean time while it is installing, could you explain the process for 
implementing the block using UHD without GNU Radio.


I have my block made and it simulates/synths/impls in Vivado.

I changed the Makefile.srcs in ..lib/rfnoc to include my custom block.

I changed rfnoc_ce_auto_inst.v in ..top/e300 to instantiate my block.

I run 'make E310_RFNOC' to generate a bitstream.

I then secure copy the generated bitstream into the correct images directory on 
my board

and finally run 'uhd_usrp_probe' with my custom .bit file.


Does all that seem correct or am I missing a vital step in there somewhere?

I read in one of your slide shows that I may also need to create a .xml file, 
but is this solely for GNU Radio or do I need to do this for UHD as well?


Thank you for your help,

Adam




From: Martin Braun 
Sent: Tuesday, January 23, 2018 5:12:09 PM
To: Adam Kurisko; usrp-users@lists.ettus.com
Subject: Re: [RFNoC] uhd_usrp_probe fails and throws uhd::lookup_error

On 01/23/2018 10:35 AM, Adam Kurisko wrote:
> Hi Martin,
>
>
> I apologize for the late response, but your reply, unfortunately, was
> not delivered to my inbox yesterday. To answer your question, I don't
> believe I modified any of the UHD source code from github, but just to
> be sure I will investigate further. Also, are you referring to the
> tx_dsp_core* files, because if so, then I am pretty sure I haven't
> touched those.

Hey Adam,

no, I was referring to the 'tx_dsps' property subtrees.

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

Re: [USRP-users] [RFNoC] uhd_usrp_probe fails and throws uhd::lookup_error

2018-01-23 Thread Martin Braun via USRP-users 
On 01/23/2018 03:01 PM, Adam Kurisko wrote:
> I am unsure if I had edited the property subtrees, however I decided to
> fresh install UHD to see if that might fix the problem. I will let you
> know if I experience similar errors.
> 
> 
> In the mean time while it is installing, could you explain the process
> for implementing the block using UHD without GNU Radio.
> 
> 
> I have my block made and it simulates/synths/impls in Vivado.
> 
> I changed the Makefile.srcs in ..lib/rfnoc to include my custom block.
> 
> I changed rfnoc_ce_auto_inst.v in ..top/e300 to instantiate my block.
> 
> I run 'make E310_RFNOC' to generate a bitstream. 
> 
> I then secure copy the generated bitstream into the correct images
> directory on my board 

...this all looks good...
> 
> and finally run 'uhd_usrp_probe' with my custom .bit file.

...and this should now list your block. Does it?

> Does all that seem correct or am I missing a vital step in there somewhere?
> 
> I read in one of your slide shows that I may also need to create a .xml
> file, but is this solely for GNU Radio or do I need to do this for UHD
> as well?

If you change nothing on the software side, your block will be listed as
"Block_0". You need one XML for UHD and GNU Radio each (so 2 total if
you want to use GNU Radio, but at least 1).

You can start by literally hacking up an XML file and copying it into
the XML directory, on the E310 it's under
/usr/share/uhd/rfnoc/blocks/*.xml. Also check out our knowledge base
articles on RFNoC block writing.

Cheers,
Martin





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

[USRP-users] [UHD] Changes to uhd_images_downloader

2018-01-23 Thread Martin Braun via USRP-users 
For the next UHD version, we will be updating uhd_images_downloader. The
problem with the old uhd_images_downloader is that it refers to one big
zip file for all the images. As we add more and more devices, we not
only have to update the zip file more often, it also becomes bigger and
bigger. If you're running uhd_images_downloader on an E310, it's most
likely that you only want the E310 images, and not the megabytes of
other FPGA images.

The new tool fixes all those issues by breaking up the zip file into
more, smaller zip files. On top of that, the new tool has a bunch of
other improvements:

- It maintains an inventory of downloaded files, and skips downloading
them again if they didn't change. This means if we roll out a fix for
the X300 only, and you run uhd_images_downloader without any arguments,
it won't try and update anything else. Should you delete the inventory,
it'll simply get everything, like it did before.
- You can now filter by type. Use the -t switch to match against a
regular expression, e.g. '-t b200mini' will only download a b200mini file.
- We'll be adding more image types soon that are not FPGA images, such
as filesystem updates.
- 'uhd_images_downloader -l' will list all the targets you can download.

In general, this should improve things and make other things easier.
However, since we had to basically rewrite the tool, which had otherwise
matured, it's likely that the new tool has shortcomings. We'd like to
hear from you regarding those.

There are a few problems we are already tracking:
- We currently have no archives other than zip files. We're intending to
add .tar.xz in the future, and you will be able to use
uhd_images_downloader to fetch those (assuming your system can unzip xz
archives)
- The tool output changed, and we're still fine tuning the output.


If you're a package maintainer, you probably hard-coded the URL for the
FPGA images in your package creation script.
We track the URLs of the individual archives, along with their SHA256
hash, in a manifest that is checked into git:
https://github.com/EttusResearch/uhddev/blob/master/images/manifest.txt

The base URL for all those is http://files.ettus.com/binaries/cache, so
http://files.ettus.com/binaries/cache/usrp1/fpga-6bea23d/usrp1_usrp1_fpga_default.zip
will fetch the USRP1 FPGA images.

We're happy for any feedback -- ideally before we release the next version.

Cheers,
Martin

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