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

2018-01-22 Thread Sarah Tran via USRP-users 
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.

Thank you!!
-Sarah Leony

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

Re: [USRP-users] CHDR packet in noc shell

2018-01-22 Thread Martin Braun via USRP-users 
On 01/15/2018 09:48 PM, Koyel Das wrote:
> Hi,
> 
> Actually I need to send data that accepts data in the form of vectors
> and has a 128 point FFT. What I am doing is first using packet resizer
> before my block. So could you please tell me if the size variable of
> packet resizer is in bytes or number of samples?

Koyel,

take a look at the FFT block, which does exactly this. It might give you
some inspiration.

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] VITA time in X310 FPGA

2018-01-22 Thread Martin Braun via USRP-users 
Hey Dmitry,

for the DDC case, we always use the timestamp for the first package. If
your decim is 2, then every other timestamp is effectively discarded.
The counter your referring to is thus more relevant for the DUC use case.

Cheers,
Martin

On 01/16/2018 01:51 AM, Дмитрий Михайличенко via USRP-users wrote:
> 2018-01-16 3:31 GMT+03:00 Martin Braun via USRP-users
> >:
> 
> On 01/11/2018 01:38 AM, Дмитрий Михайличенко via USRP-users wrote:
> > Hi,
> >
> > I am trying to understand timestamp tracking in FPGA and noticed one
> > possible issue in axi_rate_change.v module .
> >
> > VITA time in packet headers is counted in ticks of master clock
> > frequency, i.e. 200 MHz. For me it looks like axi_rate_change adjusts
> > time by adding time from the first packet in a group to number of
> > samples sent out which are actually downsampled in case of DDC and may
> > have lower sampling frequency. That is probably incorrect unless I
> > understand the code.  Does it only work because output packet always
> > starts from input packet boundary so vita_time_reg is never used?
> 
> Dmitry,
> 
> a couple of notes: axi_rate_change is used in modules such as the
> DDC/DUC blocks which don't actually run at the sample clock rate. So the
> only reference for time is the sample count, not a clock count.
> And yes, input/output packet boundaries are also matched. For
> interpolation by factor M, you will input 1 packet and get M packets of
> identical size.
> Also, the master clock rate (which is the 200 MHz clock in this case) is
> used as a timing reference.
> 
> Not sure if this answers your questions. Let us know if it doesn't!
> 
> -- M
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com 
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 
> 
> 
> 
> Hi Martin,
> 
> thank you for reply.
> 
> I understand that the time reference is the sample count. Let me clarify
> my question.
> Assume we have ADC running at 200 MHz and user app requests 20 MHz
> receive sampling rate. It means that DDC block will perform
> downconversion by 10 times.
> So for 10 input samples one output sample is produced by DDC. And in
> that case axi_rate_change block at line
> https://github.com/EttusResearch/fpga/blob/maint/usrp3/lib/rfnoc/axi_rate_change.v#L458
> 
> adds counter of 200 MHz samples (time from the header) to counter of 20
> MHz samples (produced by DDC). Is this correct?
> 
> thanks,
> Dmitry
> 
>  
> 
> 
> 
> ___
> 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-22 Thread Martin Braun via USRP-users 
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
> 
> 
> 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

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

2018-01-22 Thread Martin Braun via USRP-users 
Adam,

did you modify any of the UHD code controlling the radios? The tx_dsps
property subtree is created by the E310 radio RFNoC block in the radio,
and not used by that block after that.

-- M

On 01/22/2018 11:29 AM, Adam Kurisko via USRP-users wrote:
> Hello,
> 
> 
> I am in the final stretch of implementing my custom RFNoC onto the E310,
> and I ran into the following error while running uhd_usrp_probe:
> 
> 
> root@ettus-e3xx-sg1:~/localinstall/usr/share/uhd/images# uhd_usrp_probe
> --args="fpga=/home/root/localinstall/usr/share/uhd/images/usrp_e310_fpga_RFNOC.bit"[INFO]
> [UHDlinux; GNU C++ version 4.9.2; Boost_105700;
> UHD_4.0.0.rfnoc-devel-403-g12a34d6e] 
> [INFO] [E300] Loading FPGA image:
> /home/root/localinstall/usr/share/uhd/images/usrp_e310_fpga_RFNOC.bit...
> [INFO] [E300] FPGA image loaded
> [INFO] [E300] Detecting internal GPS 
>  [INFO] [E300] GPSDO found
> [INFO] [E300] Initializing core control (global registers)...
> 
> [INFO] [E300] Performing register loopback test... 
> [INFO] [E300] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> terminate called after throwing an instance of 'uhd::lookup_error'
>   what():  LookupError: Path not found in tree: /mboards/0/tx_dsps/0
> Aborted
> 
> I believe I created and edited all the necessary files in order to get
> it working and simulation of my custom block in Vivado shows that the
> block is functioning correctly.
> 
> 
> Could this be an issue with the .cpp/.hpp/.xml files I created?
> 
> And if so, what can I change to correct this?
> 
> 
> Thank you,
> 
> Adam Kurisko
> 
> 
> P.S.   Just as some supplemental info, I was receiving the following
> errors prior to the one I am currently dealing with, but I corrected the
> error by running the error-stated commands "sysctl -w
> net.core.wmem_max=288000" and "sysctl -w net.core.rmem_max=288000"
> 
> 
> root@ettus-e3xx-sg1:~/localinstall/usr/share/uhd/images# uhd_usrp_probe
> --args="type=e3x0,addr=10.1.16.47,fpga=/home/root/localinstall/usr/share/uhd/images/usrp_e310_fpga_RFNOC.bit,fw=/home/root/localinstall/usr/share/uhd/images/usrp_e310_fpga_RFNOC.bin"
> [INFO] [UHDlinux; GNU C++ version 4.9.2; Boost_105700;
> UHD_4.0.0.rfnoc-devel-403-g12a34d6e] 
> [WARNING] [UDP] The recv buffer could not be resized sufficiently.
> Target sock buff size: 288000 bytes.
> Actual sock buff size: 163840 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.rmem_max=288000
> [WARNING] [UDP] The send buffer could not be resized sufficiently.
> Target sock buff size: 288000 bytes.
> Actual sock buff size: 163840 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.wmem_max=288000
> [WARNING] [UDP] The recv buffer could not be resized sufficiently.
> Target sock buff size: 288000 bytes.
> Actual sock buff size: 163840 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.rmem_max=288000
> [WARNING] [UDP] The send buffer could not be resized sufficiently.
> Target sock buff size: 288000 bytes.
> Actual sock buff size: 163840 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.wmem_max=288000
> [WARNING] [UDP] The recv buffer could not be resized sufficiently.
> Target sock buff size: 288000 bytes.
> Actual sock buff size: 163840 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.rmem_max=288000
> [WARNING] [UDP] The send buffer could not be resized sufficiently.
> Target sock buff size: 288000 bytes.
> Actual sock buff size: 163840 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.wmem_max=288000
> Error: i2c_zc_impl recv timeout
> 
> 
> 
> ___
> 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] UHD Converter for X310 series with unsupported data format

2018-01-22 Thread Martin Braun via USRP-users 
s32 is unusual, as Jeff mentions. s16 -> f32 are already available.

-- M

On 01/22/2018 03:35 PM, Jeff Long via USRP-users wrote:
> Maybe start here:
> 
> https://files.ettus.com/manual/page_converters.html
> 
> Adding new formats to the host software should be easy, but adding new
> formats to the FPGA is more work. Why do you want s32 OTW?
> 
> On Mon, Jan 22, 2018 at 3:11 PM, Kei Nguyen via USRP-users
> > wrote:
> 
> Hello,
> 
> I'm very new to UHD and USRP stuff. I want to ask if it is possible
> to integrate a converter with format unsupported by UHD, for
> example, s32 on device (otw) and f32 on host (cpu)? Also, is there
> any explicit document for how I can do this?
> Sorry if my question is rather unclear because I'm really unfamiliar
> with UHD yet.
> 
> Thanks,
> Hai
> 
> ___
> 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] DDC Software (Linux/Ettus X300/GNU Radio: UHD)

2018-01-22 Thread Martin Braun via USRP-users 
Taylor,

this error message means your UHD is from master branch. If your
uhd_images_download is trying to install 3.9.7 images, the most likely
explanation is that may you have an older version somewhere on your
system -- the download URL is baked into the tool on installation.

Here's what uhd_images_downloader --help looks like on my computer:

```
Usage: uhd_images_downloader [options]

Options:
  -h, --helpshow this help message and exit
  -i INSTALL_LOCATION, --install-location=INSTALL_LOCATION
Set custom install location for images
[default=/home/mbr0wn/.usrlocal-uhd-
master/share/uhd/images]
  --buffer-size=BUFFER_SIZE
Set download buffer size [default=8192]
  -b BASE_URL, --base-url=BASE_URL
Set base URL for images download location
[default=http://files.ettus.com/binaries/images/]
  -f FILENAME, --filename=FILENAME
Set images archive filename [default=uhd-
images_3.11.0.git-227-g9277fc58.zip]
  -c CHECKSUM, --checksum=CHECKSUM
Validate images archive against this checksum (blank
to skip) [default=6fc29c5c141e8f3faec6189ab07e458d]
  -t CHECKSUM_TYPE, --checksum-type=CHECKSUM_TYPE
Select checksum hash function (options: md5)
[default=md5]
  -k, --keepDo not clear images directory before extracting new
files [default=False]
  -v, --verbose Enable verbose output [default=False]
  --force-deleteDelete all files in the target images directory
without prompting [default=False]
```

Note the defaults for -f and -c. Do you see the same?

One thing you can try is running uhd_images_downloader with -f and -c
and copy the values from above. However, if it's an old tool it might
also copy the downloaded files into the wrong location. But, one step at
a time.

-- M

On 01/22/2018 01:31 PM, Taylor Eisman via USRP-users wrote:
> Hey guys,
> 
> I've used the uhd_images_downloader and the uhd_image_loader as per
> Nicolas's suggestion and altered the buffer size to 576,000 as Jose
> suggested. Neither of these attempts worked! The uhd_images_downloader
> installed 003.009.007-r onto the USRP. Is there any other way to change
> the DDC software or overcome this flag? See the attached image for the
> latest diagnostic screen shot.
> 
> Thanks,
> 
> Taylor
> 
> On Mon, Jan 22, 2018 at 9:52 AM, Nicolas Cuervo
> > wrote:
> 
> Dear Taylor,
> 
> Please try to update your FPGA images by running the
> uhd_image_downloader to get the latest image that corresponds to the
> code base that you are running. Let us know if still face this issue
> after loading the latest version of the images. If you are using the
> X3X0 device, the procedure for loading the FPGA images is described
> here
> .
> 
> Regards,
> - Nicolas
> 
> On Sat, Jan 20, 2018 at 8:40 PM, Taylor Eisman via USRP-users
> > wrote:
> 
>  Hey all,
> 
> I've recently installed GNU Radio on a new computer. The program
> I've been running runs on every other system in the room, but
> this one throws a RunTimeError. It states "DDC software is too
> new for this hardware. Please downgrade to a driver that
> supports hardware revision 0."  I've tried googling the issue,
> but it comes up with HVAC maintenance websites and what-not and
> there aren't really any other good resources for this error. Has
> anybody encountered this error before and what did you do to fix
> it?
> 
> -- 
> Thanks,
> 
> Taylor
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com 
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 
> 
> 
> 
> 
> 
> -- 
> Thanks,
> 
> Taylor Eisman
> Graduate Researcher
> University of Texas at San Antonio
> 
> 
> ___
> 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] Help on UHD Python API installation

2018-01-22 Thread Zhongyuan Zhao via USRP-users 
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


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

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

2018-01-22 Thread Jeff Long via USRP-users 
Maybe start here:

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

Adding new formats to the host software should be easy, but adding new
formats to the FPGA is more work. Why do you want s32 OTW?

On Mon, Jan 22, 2018 at 3:11 PM, Kei Nguyen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> I'm very new to UHD and USRP stuff. I want to ask if it is possible to
> integrate a converter with format unsupported by UHD, for example, s32 on
> device (otw) and f32 on host (cpu)? Also, is there any explicit document
> for how I can do this?
> Sorry if my question is rather unclear because I'm really unfamiliar with
> UHD yet.
>
> Thanks,
> Hai
>
> ___
> 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] use 2 DDC chain of N210 with SBX

2018-01-22 Thread omid saeedy via USRP-users 
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.
Can you help me?
Thanks,
Bests,
Laura
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

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

2018-01-22 Thread Kei Nguyen via USRP-users 
Hello,

I'm very new to UHD and USRP stuff. I want to ask if it is possible to
integrate a converter with format unsupported by UHD, for example, s32 on
device (otw) and f32 on host (cpu)? Also, is there any explicit document
for how I can do this?
Sorry if my question is rather unclear because I'm really unfamiliar with
UHD yet.

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

Re: [USRP-users] x310 simulating RFNoC block with Xilinx IP

2018-01-22 Thread Dang tien Vo-Huu via USRP-users 
Hi EJ,
It works! Now I am able to simulate the custom block with IP in both cases.
Just another small question, can we simulate the built-in RFNoC block? I
see the simulate file (for example noc_block_fft_tb.sv) but not sure how to
run it..
Thank you very much for the help.

Best,
Tien


On Mon, Jan 22, 2018 at 10:55 AM, EJ Kreinar  wrote:

> Hi Tien,
>
> If the Xilinx IP is included in the uhd-fpga/usrp3/lib repo, you can
> follow the example provided in the Makefile for the noc_block_fft_tb:
> https://github.com/EttusResearch/fpga/blob/rfnoc-devel/usrp3/lib/rfnoc/
> noc_block_fft_tb/Makefile
>
> Note the three steps:
> 1. set LIB_IP_DIR
> 2. Include the Makefile.inc associated with the Xilinx IP
> 3. Append generated IP to the DESIGN_SRCS
>
> If the Xilinx IP you want to use is contained in an OOT repo, then you
> would want to follow the Makefile.inc process of including the OOT repo:
> https://github.com/ejk43/rfnoc-ootexample
>
> The "noc_block_complextomagphase_tb" example shows an example of how to
> include and simulate Xilinx IP inside an OOT repo:
> https://github.com/ejk43/rfnoc-ootexample/blob/master/
> rfnoc/testbenches/noc_block_complextomagphase_tb/Makefile
>
> For another example, this repo with a polyphase channelizer also shows how
> to include and simulate Xilinx IP in an OOT repo: https://github.com/e33b1
> 711/rfnoc-ppchan
>
> Hope this helps,
> EJ
>
> On Fri, Jan 19, 2018 at 10:28 PM, Dang tien Vo-Huu via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi all,
>> I have this error when trying to simulate a custom RFNoC block in an OOT
>> module:
>>
>> $ make noc_block_hbFilter_tb
>> .
>> .
>> Starting static elaboration
>> ERROR: [VRFC 10-2063] Module  not found while processing
>> module instance  [/home/tienvh/workspace/rfnoc/
>> src/rfnoc-filters/rfnoc/fpga-src/noc_block_hbFilter.v:179]
>> ERROR: [XSIM 43-3322] Static elaboration of top level Verilog design
>> unit(s) in library work failed.
>> INFO: [USF-XSim-99] Step results log file:'/home/tienvh/workspace/r
>> fnoc/src/rfnoc-filters/rfnoc/testbenches/noc_block_hbFilter_
>> tb/xsim_proj/xsim_proj.sim/sim_1/behav/elaborate.log'
>> ERROR: [USF-XSim-62] 'elaborate' step failed with error(s). Please check
>> the Tcl console output or '/home/tienvh/workspace/rfnoc/
>> src/rfnoc-filters/rfnoc/testbenches/noc_block_hbFilter_tb/xs
>> im_proj/xsim_proj.sim/sim_1/behav/elaborate.log' file for more
>> information.
>> .
>> .
>>
>> I can build an FPGA image with the custom RFNoC block following the
>> instruction here: http://www.synchronouslabs.com/blog/creating-a-custom-
>> rfnoc-block-with-using-xillinx-ip
>> but I haven't found a way to simulate this block.
>> Is there any way to run the simulation in this situation? Otherwise it
>> would be difficult to debug if anything goes wrong..
>>
>> Thanks in advance.
>>
>> Best,
>> Tien
>>
>> ___
>> 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] [RFNoC] uhd_usrp_probe fails and throws uhd::lookup_error

2018-01-22 Thread Adam Kurisko via USRP-users 
Hello,


I am in the final stretch of implementing my custom RFNoC onto the E310, and I 
ran into the following error while running uhd_usrp_probe:


root@ettus-e3xx-sg1:~/localinstall/usr/share/uhd/images# uhd_usrp_probe 
--args="fpga=/home/root/localinstall/usr/share/uhd/images/usrp_e310_fpga_RFNOC.bit"[INFO]
 [UHDlinux; GNU C++ version 4.9.2; Boost_105700; 
UHD_4.0.0.rfnoc-devel-403-g12a34d6e]
[INFO] [E300] Loading FPGA image: 
/home/root/localinstall/usr/share/uhd/images/usrp_e310_fpga_RFNOC.bit...
[INFO] [E300] FPGA image loaded
[INFO] [E300] Detecting internal GPS
 [INFO] [E300] GPSDO found
[INFO] [E300] Initializing core control (global registers)...

[INFO] [E300] Performing register loopback test...
[INFO] [E300] Register loopback test passed
[INFO] [RFNOC RADIO] Register loopback test passed
[INFO] [RFNOC RADIO] Register loopback test passed
terminate called after throwing an instance of 'uhd::lookup_error'
  what():  LookupError: Path not found in tree: /mboards/0/tx_dsps/0
Aborted

I believe I created and edited all the necessary files in order to get it 
working and simulation of my custom block in Vivado shows that the block is 
functioning correctly.


Could this be an issue with the .cpp/.hpp/.xml files I created?

And if so, what can I change to correct this?


Thank you,

Adam Kurisko


P.S.   Just as some supplemental info, I was receiving the following errors 
prior to the one I am currently dealing with, but I corrected the error by 
running the error-stated commands "sysctl -w net.core.wmem_max=288000" and 
"sysctl -w net.core.rmem_max=288000"


root@ettus-e3xx-sg1:~/localinstall/usr/share/uhd/images# uhd_usrp_probe 
--args="type=e3x0,addr=10.1.16.47,fpga=/home/root/localinstall/usr/share/uhd/images/usrp_e310_fpga_RFNOC.bit,fw=/home/root/localinstall/usr/share/uhd/images/usrp_e310_fpga_RFNOC.bin"
[INFO] [UHDlinux; GNU C++ version 4.9.2; Boost_105700; 
UHD_4.0.0.rfnoc-devel-403-g12a34d6e]
[WARNING] [UDP] The recv buffer could not be resized sufficiently.
Target sock buff size: 288000 bytes.
Actual sock buff size: 163840 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.rmem_max=288000
[WARNING] [UDP] The send buffer could not be resized sufficiently.
Target sock buff size: 288000 bytes.
Actual sock buff size: 163840 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.wmem_max=288000
[WARNING] [UDP] The recv buffer could not be resized sufficiently.
Target sock buff size: 288000 bytes.
Actual sock buff size: 163840 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.rmem_max=288000
[WARNING] [UDP] The send buffer could not be resized sufficiently.
Target sock buff size: 288000 bytes.
Actual sock buff size: 163840 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.wmem_max=288000
[WARNING] [UDP] The recv buffer could not be resized sufficiently.
Target sock buff size: 288000 bytes.
Actual sock buff size: 163840 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.rmem_max=288000
[WARNING] [UDP] The send buffer could not be resized sufficiently.
Target sock buff size: 288000 bytes.
Actual sock buff size: 163840 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.wmem_max=288000
Error: i2c_zc_impl recv timeout

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

Re: [USRP-users] x310 simulating RFNoC block with Xilinx IP

2018-01-22 Thread EJ Kreinar via USRP-users 
Hi Tien,

If the Xilinx IP is included in the uhd-fpga/usrp3/lib repo, you can follow
the example provided in the Makefile for the noc_block_fft_tb: https://
github.com/EttusResearch/fpga/blob/rfnoc-devel/usrp3/lib/
rfnoc/noc_block_fft_tb/Makefile

Note the three steps:
1. set LIB_IP_DIR
2. Include the Makefile.inc associated with the Xilinx IP
3. Append generated IP to the DESIGN_SRCS

If the Xilinx IP you want to use is contained in an OOT repo, then you
would want to follow the Makefile.inc process of including the OOT repo:
https://github.com/ejk43/rfnoc-ootexample

The "noc_block_complextomagphase_tb" example shows an example of how to
include and simulate Xilinx IP inside an OOT repo: https://github.com/
ejk43/rfnoc-ootexample/blob/master/rfnoc/testbenches/noc_
block_complextomagphase_tb/Makefile

For another example, this repo with a polyphase channelizer also shows how
to include and simulate Xilinx IP in an OOT repo: https://github.com/
e33b1711/rfnoc-ppchan

Hope this helps,
EJ

On Fri, Jan 19, 2018 at 10:28 PM, Dang tien Vo-Huu via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
> I have this error when trying to simulate a custom RFNoC block in an OOT
> module:
>
> $ make noc_block_hbFilter_tb
> .
> .
> Starting static elaboration
> ERROR: [VRFC 10-2063] Module  not found while processing
> module instance  [/home/tienvh/workspace/rfnoc/
> src/rfnoc-filters/rfnoc/fpga-src/noc_block_hbFilter.v:179]
> ERROR: [XSIM 43-3322] Static elaboration of top level Verilog design
> unit(s) in library work failed.
> INFO: [USF-XSim-99] Step results log file:'/home/tienvh/workspace/r
> fnoc/src/rfnoc-filters/rfnoc/testbenches/noc_block_hbFilter_
> tb/xsim_proj/xsim_proj.sim/sim_1/behav/elaborate.log'
> ERROR: [USF-XSim-62] 'elaborate' step failed with error(s). Please check
> the Tcl console output or '/home/tienvh/workspace/rfnoc/
> src/rfnoc-filters/rfnoc/testbenches/noc_block_hbFilter_tb/
> xsim_proj/xsim_proj.sim/sim_1/behav/elaborate.log' file for more
> information.
> .
> .
>
> I can build an FPGA image with the custom RFNoC block following the
> instruction here: http://www.synchronouslabs.com/blog/creating-a-custom-
> rfnoc-block-with-using-xillinx-ip
> but I haven't found a way to simulate this block.
> Is there any way to run the simulation in this situation? Otherwise it
> would be difficult to debug if anything goes wrong..
>
> Thanks in advance.
>
> Best,
> Tien
>
> ___
> 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] DDC Software (Linux/Ettus X300/GNU Radio: UHD)

2018-01-22 Thread Nicolas Cuervo via USRP-users 
Dear Taylor,

Please try to update your FPGA images by running the uhd_image_downloader
to get the latest image that corresponds to the code base that you are
running. Let us know if still face this issue after loading the latest
version of the images. If you are using the X3X0 device, the procedure for
loading the FPGA images is described here
.

Regards,
- Nicolas

On Sat, Jan 20, 2018 at 8:40 PM, Taylor Eisman via USRP-users <
usrp-users@lists.ettus.com> wrote:

>  Hey all,
>
> I've recently installed GNU Radio on a new computer. The program I've been
> running runs on every other system in the room, but this one throws a
> RunTimeError. It states "DDC software is too new for this hardware. Please
> downgrade to a driver that supports hardware revision 0."  I've tried
> googling the issue, but it comes up with HVAC maintenance websites and
> what-not and there aren't really any other good resources for this error.
> Has anybody encountered this error before and what did you do to fix it?
>
> --
> Thanks,
>
> Taylor
>
> ___
> 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] sending sine wave, but created another unwanted frequency component

2018-01-22 Thread Yang Liu via USRP-users 
Hi Dmitry,

I did more tests today, found that the these two frequency components are
not symmetric, and the distance between these two is 5e6 (sampling rate at
the transmitter side). If I set the tx sampling rate to be 10e6, and
waveform frequency to be 4.8e6 (close to 10e6/2.0), then the distance
between two signals are 10e6.

If this problem is caused by not enough attenuation, why as I moved the
sine wave to the center frequency, the second component disappeared? I feel
confused about this.

I am thinking that maybe it is caused by incorrect sampling rate at the
transmitter side, if I want to let the sine wave move from -5e6/2.0 to
5e6/2.0, should I set the sampling rate at tx higher than 5e6?

Thanks a lot for your help,
Yang

On Mon, Jan 22, 2018 at 3:48 AM, Дмитрий Михайличенко via USRP-users <
usrp-users@lists.ettus.com> wrote:

>
>
> 2018-01-21 20:55 GMT+03:00 Yang Liu via USRP-users <
> usrp-users@lists.ettus.com>:
>
>> Dear all,
>>
>> In this application, I am trying to send a sine wave at a specific
>> frequency to usrp x310:
>>   sine wave generator ---> usrpx310
>>
>> For the sine wave generator, I use blocks.sig_source_c from gnuradio. The
>> parameters at the transmitter are in the following:
>> center frequency: 1e9 (usrp tuning frequency)
>> sampling_rate: 5e6
>> waveform frequency:  -2.4193125e6 (at the boundary of this frequency
>> band).
>>
>> At the receiver side, I tuned the usrp to 1e9, and used 10e6 to sample
>> the received data. According to the spectrum I observed, there are two
>> frequency components, one is at -2.4193125e6, another one is around at
>> -2.4193125e6 + 5e6 (not very sure if they are exactly symmetric). Actually,
>> this happens when the sine wave is very close to the boundary (near -2.5e6
>> or 2.5e6). As I moved the waveform frequency to the center (1e9), the
>> second frequency disappeared.  Firstly, I thought that it is the power
>> issue, however, after I decreased power level, the second component is
>> still there.
>>
>> According to the function (blocks.sig_source_c), what it generates is a
>> exp(j*2*pi*f_waveform/f_s). Therefore, there should not exist any second
>> frequency component. I feel very confused about why this can happen.
>>
>> Any thoughts about this will be greatly appreciated!
>>
>> Best,
>> Yang
>>
>>
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
> What you see is perhaps image of original frequency. It should be missed
> in an ideal world but in real world there is imbalance of quadrature
> channels as well as filters used during downsampling have limited stop band
> attenuation.
>
> thanks,
> Dmitry
>
>
> ___
> 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] sending sine wave, but created another unwanted frequency component

2018-01-22 Thread Дмитрий Михайличенко via USRP-users 
2018-01-21 20:55 GMT+03:00 Yang Liu via USRP-users <
usrp-users@lists.ettus.com>:

> Dear all,
>
> In this application, I am trying to send a sine wave at a specific
> frequency to usrp x310:
>   sine wave generator ---> usrpx310
>
> For the sine wave generator, I use blocks.sig_source_c from gnuradio. The
> parameters at the transmitter are in the following:
> center frequency: 1e9 (usrp tuning frequency)
> sampling_rate: 5e6
> waveform frequency:  -2.4193125e6 (at the boundary of this frequency band).
>
> At the receiver side, I tuned the usrp to 1e9, and used 10e6 to sample the
> received data. According to the spectrum I observed, there are two
> frequency components, one is at -2.4193125e6, another one is around at
> -2.4193125e6 + 5e6 (not very sure if they are exactly symmetric). Actually,
> this happens when the sine wave is very close to the boundary (near -2.5e6
> or 2.5e6). As I moved the waveform frequency to the center (1e9), the
> second frequency disappeared.  Firstly, I thought that it is the power
> issue, however, after I decreased power level, the second component is
> still there.
>
> According to the function (blocks.sig_source_c), what it generates is a
> exp(j*2*pi*f_waveform/f_s). Therefore, there should not exist any second
> frequency component. I feel very confused about why this can happen.
>
> Any thoughts about this will be greatly appreciated!
>
> Best,
> Yang
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
What you see is perhaps image of original frequency. It should be missed in
an ideal world but in real world there is imbalance of quadrature channels
as well as filters used during downsampling have limited stop band
attenuation.

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