Re: [USRP-users] Siggen not working in E310

[Tom Bereknyei via USRP-users]

My experiments with SIGGEN on the E310 were similar. At the moment my
workaround is to just send noise or burst samples from the CPU exactly when
needed. I would be interested in a way to use siggen. I am also working on
a siggen-like block which will hop frequencies. I am interested in any
design considerations, thoughts, or advice on the design of the block. If
it can be general enough it can be pushed to upstream.

On Mon, Sep 25, 2017 at 18:04 John Medrano via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> I have been working on getting Siggen working under E310. I built RFNOC
> image with siggen for E310. I have been able to use that image to generate
> a signal from RFNOC_SIGGEN -> HOST, but when I try to rung RFNOC_SIGGEN ->
> RFNOC_DUC -> RFNOC_RADIO I received an error. The error I received goes
> away if I start with siggen enable = FALSE.
>
> See below, the script was modified to enable siggen after 2 seconds, and
> again it does not complain, but I get absolutely no output.
>
> Following are script and original error that I receive.
>
> Please advise,
> John
>
> #!/usr/bin/env python2
> # -*- coding: utf-8 -*-
> ##
> # GNU Radio Python Flow Graph
> # Title: Rfnoc Sin Radio E310
> # Generated: Thu Sep 21 14:12:08 2017
> ##
>
> from gnuradio import eng_notation
> from gnuradio import gr
> from gnuradio import uhd
> from gnuradio.eng_option import eng_option
> from gnuradio.filter import firdes
> from optparse import OptionParser
> import ettus
>
>
> class RFNoc_Sin_Radio_e310(gr.top_block):
>
> def __init__(self):
> gr.top_block.__init__(self, "Rfnoc Sin Radio E310")
>
> ##
> # Variables
> ##
> self.samp_rate = samp_rate = 2e6
> self.device3 = variable_uhd_device3_0 =
> ettus.device3(uhd.device_addr_t( ",".join(('type=e3x0',
> "fpga=/home/root/rfnoc/usr/share
> /uhd/images/usrp_e310_fpga_RFNOC_sg3.bit")) ))
> self.up_rate = up_rate = 12e6
> self.gain = gain = 0.5
> self.freq = freq = samp_rate/10
> self.enable = enable = False
> self.ampl_q = ampl_q = 1
> self.ampl_i = ampl_i = 1
>
> ##
> # Blocks
> ##
> self.uhd_rfnoc_streamer_siggen_0 = ettus.rfnoc_generic(
> self.device3,
> uhd.stream_args( # TX Stream Args
> cpu_format="fc32", # TODO: This must be made an option
> otw_format="sc16",
> args="",
> ),
> uhd.stream_args( # RX Stream Args
> cpu_format="fc32", # TODO: This must be made an option
> otw_format="sc16",
> args="",
> ),
> "SigGen", -1, -1,
> )
> self.uhd_rfnoc_streamer_siggen_0.set_arg("spp",  364)
> self.uhd_rfnoc_streamer_siggen_0.set_arg("frequency",
> ((2*freq)/samp_rate))
> self.uhd_rfnoc_streamer_siggen_0.set_arg("waveform", "SINE_WAVE")
> self.uhd_rfnoc_streamer_siggen_0.set_arg("gain", gain)
> self.uhd_rfnoc_streamer_siggen_0.set_arg("enable", enable)
> self.uhd_rfnoc_streamer_siggen_0.set_arg("amplitude_i",
> complex(ampl_i , ampl_q).real)
> self.uhd_rfnoc_streamer_siggen_0.set_arg("amplitude_q",
> complex(ampl_i , ampl_q).imag)
>
> self.uhd_rfnoc_streamer_radio_0 = ettus.rfnoc_radio(
> self.device3,
> uhd.stream_args( # Tx Stream Args
> cpu_format="fc32",
> otw_format="sc16",
> args='',
> ),
> uhd.stream_args( # Rx Stream Args
> cpu_format="fc32",
> otw_format="sc16",
> args="", # empty
> ),
> 0, -1
> )
> self.uhd_rfnoc_streamer_radio_0.set_rate(up_rate)
> for i in xrange(1):
> self.uhd_rfnoc_streamer_radio_0.set_tx_freq(1.0e9, i)
> self.uhd_rfnoc_streamer_radio_0.set_tx_gain(20, i)
> self.uhd_rfnoc_streamer_radio_0.set_tx_dc_offset(True, i)
>
> self.uhd_rfnoc_streamer_radio_0.set_tx_antenna("TX/RX", 0)
>
> self.uhd_rfnoc_streamer_fifo_0 = ettus.rfnoc_generic(
> self.device3,
> uhd.stream_args( # TX Stream Args
> cpu_format="fc32",
> otw_format="sc16",
> args="gr_vlen={0},{1}".format(1, "" if 1 == 1 else
> "spp={0}".format(1)),
> ),
> uhd.stream_args( # RX Stream Args
> cpu_format="fc32",
> otw_format="sc16",
> args="gr_vlen={0},{1}".format(1, "" if 1 == 1 else
> "spp={0}".format(1)),
> ),
> "FIFO", -1, -1,
>  

[USRP-users] Siggen not working in E310

[John Medrano via USRP-users]

Hello,

I have been working on getting Siggen working under E310. I built RFNOC
image with siggen for E310. I have been able to use that image to generate
a signal from RFNOC_SIGGEN -> HOST, but when I try to rung RFNOC_SIGGEN ->
RFNOC_DUC -> RFNOC_RADIO I received an error. The error I received goes
away if I start with siggen enable = FALSE.

See below, the script was modified to enable siggen after 2 seconds, and
again it does not complain, but I get absolutely no output.

Following are script and original error that I receive.

Please advise,
John

#!/usr/bin/env python2
# -*- coding: utf-8 -*-
##
# GNU Radio Python Flow Graph
# Title: Rfnoc Sin Radio E310
# Generated: Thu Sep 21 14:12:08 2017
##

from gnuradio import eng_notation
from gnuradio import gr
from gnuradio import uhd
from gnuradio.eng_option import eng_option
from gnuradio.filter import firdes
from optparse import OptionParser
import ettus


class RFNoc_Sin_Radio_e310(gr.top_block):

def __init__(self):
gr.top_block.__init__(self, "Rfnoc Sin Radio E310")

##
# Variables
##
self.samp_rate = samp_rate = 2e6
self.device3 = variable_uhd_device3_0 =
ettus.device3(uhd.device_addr_t( ",".join(('type=e3x0',
"fpga=/home/root/rfnoc/usr/share
/uhd/images/usrp_e310_fpga_RFNOC_sg3.bit")) ))
self.up_rate = up_rate = 12e6
self.gain = gain = 0.5
self.freq = freq = samp_rate/10
self.enable = enable = False
self.ampl_q = ampl_q = 1
self.ampl_i = ampl_i = 1

##
# Blocks
##
self.uhd_rfnoc_streamer_siggen_0 = ettus.rfnoc_generic(
self.device3,
uhd.stream_args( # TX Stream Args
cpu_format="fc32", # TODO: This must be made an option
otw_format="sc16",
args="",
),
uhd.stream_args( # RX Stream Args
cpu_format="fc32", # TODO: This must be made an option
otw_format="sc16",
args="",
),
"SigGen", -1, -1,
)
self.uhd_rfnoc_streamer_siggen_0.set_arg("spp",  364)
self.uhd_rfnoc_streamer_siggen_0.set_arg("frequency",
((2*freq)/samp_rate))
self.uhd_rfnoc_streamer_siggen_0.set_arg("waveform", "SINE_WAVE")
self.uhd_rfnoc_streamer_siggen_0.set_arg("gain", gain)
self.uhd_rfnoc_streamer_siggen_0.set_arg("enable", enable)
self.uhd_rfnoc_streamer_siggen_0.set_arg("amplitude_i",
complex(ampl_i , ampl_q).real)
self.uhd_rfnoc_streamer_siggen_0.set_arg("amplitude_q",
complex(ampl_i , ampl_q).imag)

self.uhd_rfnoc_streamer_radio_0 = ettus.rfnoc_radio(
self.device3,
uhd.stream_args( # Tx Stream Args
cpu_format="fc32",
otw_format="sc16",
args='',
),
uhd.stream_args( # Rx Stream Args
cpu_format="fc32",
otw_format="sc16",
args="", # empty
),
0, -1
)
self.uhd_rfnoc_streamer_radio_0.set_rate(up_rate)
for i in xrange(1):
self.uhd_rfnoc_streamer_radio_0.set_tx_freq(1.0e9, i)
self.uhd_rfnoc_streamer_radio_0.set_tx_gain(20, i)
self.uhd_rfnoc_streamer_radio_0.set_tx_dc_offset(True, i)

self.uhd_rfnoc_streamer_radio_0.set_tx_antenna("TX/RX", 0)

self.uhd_rfnoc_streamer_fifo_0 = ettus.rfnoc_generic(
self.device3,
uhd.stream_args( # TX Stream Args
cpu_format="fc32",
otw_format="sc16",
args="gr_vlen={0},{1}".format(1, "" if 1 == 1 else
"spp={0}".format(1)),
),
uhd.stream_args( # RX Stream Args
cpu_format="fc32",
otw_format="sc16",
args="gr_vlen={0},{1}".format(1, "" if 1 == 1 else
"spp={0}".format(1)),
),
"FIFO", -1, -1,
)
self.uhd_rfnoc_streamer_duc_0 = ettus.rfnoc_generic(
self.device3,
uhd.stream_args( # TX Stream Args
cpu_format="fc32", # TODO: This must be made an option
otw_format="sc16",

args="input_rate={},output_rate={},fullscale={},freq={}".format(samp_rate,
up_rate, 1.0, 0.0),
),
uhd.stream_args( # RX Stream Args
cpu_format="fc32", # TODO: This must be made an option
otw_format="sc16",
args="",
),
"DUC", -1, -1,
)

##
# Connections
##
self.devi

Re: [USRP-users] rfnoc block with two inputs

[Dario Pennisi via USRP-users]

Hi Nick,
Thank you for your feedback. I didn't notice src and data Sid are per input 
however looking at code I don't think this is the problem. My understanding is 
that src Sid is used to form cvita packet going out of the block. In simple 
mode axis wrapper doesn't seem to use while it is used by cvita encoder used 
for tuser. In my case I have 2 inputs and 1 output. I am using Sid form channel 
0 to create cvita header for the output.
Since I don't have a second output it seems to me src and day Sid for 2nd input 
are not used anyway...
For the rest there doesn't seem to be any other connection.
Am I missing something?

Btw is there any example of a block with 2 in and 1 out? I found only addsub 
which has 2 out and is not even using axis wrapper...
Thanks

Dario Pennisi








On Mon, Sep 25, 2017 at 9:28 PM +0200, "Nick Foster" 
mailto:bistrom...@gmail.com>> wrote:

Couple of problems just offhand.

* src_sid is a one-per-input signal. See noc_shell.v for details.
* Settings buses and readback buses are one-per (max(input, output)). Again, 
see noc_shell.v. I don't think this is a problem for you, though.

You should be getting errors in simulation (or warnings in synthesis) right 
now. Look very carefully through these warnings to see which signals are 
undriven. My guess is src_sid is undriven on the top 16 bits and so you can't 
set src_sid correctly for input 1.

Nick

On Mon, Sep 25, 2017 at 12:00 PM Dario Pennisi 
mailto:da...@iptronix.com>> wrote:
Hi,
It’s quite complex and long… posting the initial part with shell and wrappers

module noc_block_demod #(
  parameter NOC_ID = 64'h1408E12980FDE75E,
  parameter MAX_PACKET_SIZE = 64)
(
  input bus_clk, input bus_rst,
  input ce_clk, input ce_rst,
  input  [63:0] i_tdata, input  i_tlast, input  i_tvalid, output i_tready,
  output [63:0] o_tdata, output o_tlast, output o_tvalid, input  o_tready,
  output [63:0] debug
);

  
  //
  // RFNoC Shell
  //
  
  wire [31:0] set_data;
  wire [7:0]  set_addr;
  wireset_stb;
  reg rb_stb;
  reg  [63:0] rb_data;
  wire [7:0]  rb_addr;

  wire [63:0] cmdout_tdata, ackin_tdata;
  wirecmdout_tlast, cmdout_tvalid, cmdout_tready, ackin_tlast, 
ackin_tvalid, ackin_tready;

  wire [2*64-1:0] str_sink_tdata;
  wire [1:0]   str_sink_tlast, str_sink_tvalid, str_sink_tready;

  wire [63:0] str_src_tdata;
  wirestr_src_tlast, str_src_tvalid, str_src_tready;

  wire [15:0] src_sid;
  wire [15:0] next_dst_sid, resp_out_dst_sid;
  wire [15:0] resp_in_dst_sid;

  wireclear_tx_seqnum;

  noc_shell #(
.NOC_ID(NOC_ID),
.INPUT_PORTS(2)
)
  noc_shell (
.bus_clk(bus_clk), .bus_rst(bus_rst),
.i_tdata(i_tdata), .i_tlast(i_tlast), .i_tvalid(i_tvalid), 
.i_tready(i_tready),
.o_tdata(o_tdata), .o_tlast(o_tlast), .o_tvalid(o_tvalid), 
.o_tready(o_tready),
// Computer Engine Clock Domain
.clk(ce_clk), .reset(ce_rst),
// Control Sink
.set_data(set_data), .set_addr(set_addr), .set_stb(set_stb),
.rb_stb(rb_stb), .rb_data(rb_data), .rb_addr(rb_addr),
// Control Source
.cmdout_tdata(cmdout_tdata), .cmdout_tlast(cmdout_tlast), 
.cmdout_tvalid(cmdout_tvalid), .cmdout_tready(cmdout_tready),
.ackin_tdata(ackin_tdata), .ackin_tlast(ackin_tlast), 
.ackin_tvalid(ackin_tvalid), .ackin_tready(ackin_tready),
// Stream Sink
.str_sink_tdata(str_sink_tdata), .str_sink_tlast(str_sink_tlast), 
.str_sink_tvalid(str_sink_tvalid), .str_sink_tready(str_sink_tready),
// Stream Source
.str_src_tdata(str_src_tdata), .str_src_tlast(str_src_tlast), 
.str_src_tvalid(str_src_tvalid), .str_src_tready(str_src_tready),
// Stream IDs set by host
.src_sid(src_sid),   // SID of this block
.next_dst_sid(next_dst_sid), // Next destination SID
.resp_in_dst_sid(resp_in_dst_sid),   // Response destination SID for input 
stream responses / errors
.resp_out_dst_sid(resp_out_dst_sid), // Response destination SID for output 
stream responses / errors
// Misc
.vita_time('d0), .clear_tx_seqnum(clear_tx_seqnum),
.debug(debug));

  
  //
  // AXI Wrapper
  // Convert RFNoC Shell interface into AXI stream interface
  //
  
  wire [31:0]  m_axis0_data_tdata;
  wire m_axis0_data_tlast;
  wire m_axis0_data_tvalid;
  wire m_axis0_data_tready;
  wire [127:0] m_axis0_data_tuser;

  wire [31:0]  m_axis1_data_tdata;
  wire m_axis1_data_tlast;
  wire m_axis1_data_tvalid;
  wire m_axis1_data_tready;
  wire [127:0] m_axis1_data_tuser;

  wire [31:0]  s_axis0_data_tdata;
  wire s_axis0_data_tlast;
  wire s_axis0_data_tvalid;
  wire s_axis0_data_tready;
  wire [127:0] s_axis0_data_tuser;

  wire [31:0]  s_axis1_data_tdata;
  

[USRP-users] Inserting custom DSP code in B200mini, CODEC loopback test failing

[Shoorveer Singh via USRP-users]

Hi all,

I am using USRP B200mini/B205 to develop a custom DSP. For that purpose, I am 
trying to find an insertion point in the Ettus FPGA code.
 I started with modifying the code in b205.v by tying RX and TX to a constant 
value and expecting to see the same value when running SDR. The code compiles 
and I am able to generate the FPGA bit file, but when I try to run SDR, I get 
the following error:

Detected Device: B200mini
-- Loading FPGA image: /usr/local/share/uhd/images/usrp_b200mini_fpga.bin... 
done
-- Operating over USB 3.
-- Initialize CODEC control...
-- Initialize Radio control...
-- Performing register loopback test... pass
-- Performing CODEC loopback test... fail
Traceback (most recent call last):
  File "/home/nev/AuesLayer1Stuff/importantGRC/top_block.py", line 292, in 

main()
  File "/home/nev/AuesLayer1Stuff/importantGRC/top_block.py", line 286, in main
tb = top_block_cls()
  File "/home/nev/AuesLayer1Stuff/importantGRC/top_block.py", line 199, in 
__init__
channels=range(1),
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line 
122, in constructor_interceptor
return old_constructor(*args)
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line 
2681, in make
return _uhd_swig.usrp_source_make(*args)
RuntimeError: RuntimeError: CODEC loopback test failed.

How can I bypass this error? And where should I look in the Ettus FPGA code if 
I want to modify captured data.

--
Thanks and Regards
Shoor



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

Re: [USRP-users] Trying to build v. 003.010 Win64

[Vladimir via USRP-users]

BTW, I indeed forgot to mention that we use X300 over 10G interface, of course 
without usb.
Vladimir понедельник, 25 сентября 2017г., 20:28 +03:00 от Josh Sendall  
jsend...@csir.co.za :

>Hi Vladimir,
>
>You need to link with libusb. It seems to be needed regardless of whether you 
>enable the sub module or not. 
>
>Kind regards,
>Joshua Sendall 
>
>On 25 Sep 2017 6:18 PM, Vladimir via USRP-users < usrp-users@lists.ettus.com > 
>wrote:
>>[The e-mail server of the sender could not be verified (SPF Record)]
>> Hello USRP team!
>>
>>In our Linux application for quite a while we use some��3.10 version of UHD 
>>(which requires FPGA ver. 33) and it works fine. Now we want to use the same 
>>version in Windows app, to match the FPGA ver. But trying to build any of 
>>3.10 versions in MS Visual Studio 2013 (Release x64 cfg) I'm getting two 
>>strange linking errors:
>>
>>Error ��500 ��error LNK2019: unresolved external symbol "public: 
>>virtual __cdecl uhd::transport::usb_device_handle::~usb_device_handle(void)" 
>>(??1usb_device_handle@transport@uhd@@UEAA@XZ) referenced in function "public: 
>>virtual void * __cdecl uhd::transport::usb_device_handle::`vector deleting 
>>destructor'(unsigned int)" (??_Eusb_device_handle@transport@uhd@@UEAAPEAXI@Z)
>>
>>Error ��501 ��error LNK2019: unresolved external symbol "public: 
>>virtual __cdecl uhd::transport::usb_zero_copy::~usb_zero_copy(void)" 
>>(??1usb_zero_copy@transport@uhd@@UEAA@XZ) referenced in function "public: 
>>void __cdecl uhd::transport::usb_zero_copy::`vbase destructor'(void)" 
>>(??_Dusb_zero_copy@transport@uhd@@QEAAXXZ)
>>
>>in file D:\VS\uhd\host\build\lib\usb_dummy_impl.obj
>>
>>Looks like it's related with boost libs, which I'm not familiar with. I 
>>switched to last boost 1.65.1 (started with 1.60 with the sme results), tried 
>>UHD 3.10.0.0, 3.10.2.0 and some one in between like 3.10.1.0 - all the same. 
>>Ver. 3.9.7 builds OK.
>>
>>BTW, I use the following sequence to build boost:
>>
>>bootstrap
>>b2 toolset=msvc-12.0 address-model=64
>>b2 toolset=msvc-12.0 address-model=64 --with-test link=shared As I see you 
>>have binaries for VC2013 available, obviously it should build correctly. Do 
>>you have any idea of what could be the problem here? I use MS Visual Studio 
>>2013 Ultimate with Update 5.
>>
>>Thank you!
>>Vladimir Pavlenko
>>
>>
>>
>>
>>
>>
>>
>>
>
>--
>This message is subject to the CSIR's copyright terms and conditions, e-mail 
>legal notice, and implemented Open Document Format (ODF) standard.
>The full disclaimer details can be found at  
>http://www.csir.co.za/disclaimer.html .
>
>Please consider the environment before printing this email.___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] rfnoc block with two inputs

[Nick Foster via USRP-users]

Couple of problems just offhand.

* src_sid is a one-per-input signal. See noc_shell.v for details.
* Settings buses and readback buses are one-per (max(input, output)).
Again, see noc_shell.v. I don't think this is a problem for you, though.

You should be getting errors in simulation (or warnings in synthesis) right
now. Look very carefully through these warnings to see which signals are
undriven. My guess is src_sid is undriven on the top 16 bits and so you
can't set src_sid correctly for input 1.

Nick

On Mon, Sep 25, 2017 at 12:00 PM Dario Pennisi  wrote:

> Hi,
>
> It’s quite complex and long… posting the initial part with shell and
> wrappers
>
>
>
> module noc_block_demod #(
>
>   parameter NOC_ID = 64'h1408E12980FDE75E,
>
>   parameter MAX_PACKET_SIZE = 64)
>
> (
>
>   input bus_clk, input bus_rst,
>
>   input ce_clk, input ce_rst,
>
>   input  [63:0] i_tdata, input  i_tlast, input  i_tvalid, output i_tready,
>
>   output [63:0] o_tdata, output o_tlast, output o_tvalid, input  o_tready,
>
>   output [63:0] debug
>
> );
>
>
>
>   
>
>   //
>
>   // RFNoC Shell
>
>   //
>
>   
>
>   wire [31:0] set_data;
>
>   wire [7:0]  set_addr;
>
>   wireset_stb;
>
>   reg rb_stb;
>
>   reg  [63:0] rb_data;
>
>   wire [7:0]  rb_addr;
>
>
>
>   wire [63:0] cmdout_tdata, ackin_tdata;
>
>   wirecmdout_tlast, cmdout_tvalid, cmdout_tready, ackin_tlast,
> ackin_tvalid, ackin_tready;
>
>
>
>   wire [2*64-1:0] str_sink_tdata;
>
>   wire [1:0]   str_sink_tlast, str_sink_tvalid, str_sink_tready;
>
>
>
>   wire [63:0] str_src_tdata;
>
>   wirestr_src_tlast, str_src_tvalid, str_src_tready;
>
>
>
>   wire [15:0] src_sid;
>
>   wire [15:0] next_dst_sid, resp_out_dst_sid;
>
>   wire [15:0] resp_in_dst_sid;
>
>
>
>   wireclear_tx_seqnum;
>
>
>
>   noc_shell #(
>
> .NOC_ID(NOC_ID),
>
> .INPUT_PORTS(2)
>
> )
>
>   noc_shell (
>
> .bus_clk(bus_clk), .bus_rst(bus_rst),
>
> .i_tdata(i_tdata), .i_tlast(i_tlast), .i_tvalid(i_tvalid),
> .i_tready(i_tready),
>
> .o_tdata(o_tdata), .o_tlast(o_tlast), .o_tvalid(o_tvalid),
> .o_tready(o_tready),
>
> // Computer Engine Clock Domain
>
> .clk(ce_clk), .reset(ce_rst),
>
> // Control Sink
>
> .set_data(set_data), .set_addr(set_addr), .set_stb(set_stb),
>
> .rb_stb(rb_stb), .rb_data(rb_data), .rb_addr(rb_addr),
>
> // Control Source
>
> .cmdout_tdata(cmdout_tdata), .cmdout_tlast(cmdout_tlast),
> .cmdout_tvalid(cmdout_tvalid), .cmdout_tready(cmdout_tready),
>
> .ackin_tdata(ackin_tdata), .ackin_tlast(ackin_tlast),
> .ackin_tvalid(ackin_tvalid), .ackin_tready(ackin_tready),
>
> // Stream Sink
>
> .str_sink_tdata(str_sink_tdata), .str_sink_tlast(str_sink_tlast),
> .str_sink_tvalid(str_sink_tvalid), .str_sink_tready(str_sink_tready),
>
> // Stream Source
>
> .str_src_tdata(str_src_tdata), .str_src_tlast(str_src_tlast),
> .str_src_tvalid(str_src_tvalid), .str_src_tready(str_src_tready),
>
> // Stream IDs set by host
>
> .src_sid(src_sid),   // SID of this block
>
> .next_dst_sid(next_dst_sid), // Next destination SID
>
> .resp_in_dst_sid(resp_in_dst_sid),   // Response destination SID for
> input stream responses / errors
>
> .resp_out_dst_sid(resp_out_dst_sid), // Response destination SID for
> output stream responses / errors
>
> // Misc
>
> .vita_time('d0), .clear_tx_seqnum(clear_tx_seqnum),
>
> .debug(debug));
>
>
>
>   
>
>   //
>
>   // AXI Wrapper
>
>   // Convert RFNoC Shell interface into AXI stream interface
>
>   //
>
>   
>
>   wire [31:0]  m_axis0_data_tdata;
>
>   wire m_axis0_data_tlast;
>
>   wire m_axis0_data_tvalid;
>
>   wire m_axis0_data_tready;
>
>   wire [127:0] m_axis0_data_tuser;
>
>
>
>   wire [31:0]  m_axis1_data_tdata;
>
>   wire m_axis1_data_tlast;
>
>   wire m_axis1_data_tvalid;
>
>   wire m_axis1_data_tready;
>
>   wire [127:0] m_axis1_data_tuser;
>
>
>
>   wire [31:0]  s_axis0_data_tdata;
>
>   wire s_axis0_data_tlast;
>
>   wire s_axis0_data_tvalid;
>
>   wire s_axis0_data_tready;
>
>   wire [127:0] s_axis0_data_tuser;
>
>
>
>   wire [31:0]  s_axis1_data_tdata;
>
>   wire s_axis1_data_tlast;
>
>   wire s_axis1_data_tvalid;
>
>   wire s_axis1_data_tready;
>
>   wire [127:0] s_axis1_data_tuser;
>
>   wire [63:0]  vita_time_in;
>
>   wire [63:0]  vita_time_out;
>
> //  reg  [11:0]  seq_num;
>
>
>
>   axi_wrapper #(
>
> .SIMPLE_MODE(0))
>
>   axi_wrapper0 (
>
> .clk(ce_clk), .reset(ce_rst),
>
> .clear_tx_seqnum(clear_tx_seqnum),
>
> .next_dst(next_dst_sid),
>
> .set_stb(set_stb), .set_addr(set_addr), .set_data(set_data),
>
> .i_tdata(str_sink_tdata[6

Re: [USRP-users] Trying to build v. 003.010 Win64

[Vladimir via USRP-users]

Joshua,
Thanks for your reply! It was my first thought too. But 1) ver 3.9.7 as I wrote 
builds w/o a glitch, and 2) looking at the error messages it's not obvious how 
libusb could help here. Those functions that it misses are compiler-generated 
helper-funcs for uhd::... class(es), so I doubt it will find them in libusb... 
May be I don't see something, but it would be good if someone from USRP team 
confirmed that libusb is absolutely required here (starting from v. 3.10.0.0).
Vladimir понедельник, 25 сентября 2017г., 20:28 +03:00 от Josh Sendall  
jsend...@csir.co.za :

>Hi Vladimir,
>
>You need to link with libusb. It seems to be needed regardless of whether you 
>enable the sub module or not. 
>
>Kind regards,
>Joshua Sendall 
>
>On 25 Sep 2017 6:18 PM, Vladimir via USRP-users < usrp-users@lists.ettus.com > 
>wrote:
>>[The e-mail server of the sender could not be verified (SPF Record)]
>> Hello USRP team!
>>
>>In our Linux application for quite a while we use some��3.10 version of UHD 
>>(which requires FPGA ver. 33) and it works fine. Now we want to use the same 
>>version in Windows app, to match the FPGA ver. But trying to build any of 
>>3.10 versions in MS Visual Studio 2013 (Release x64 cfg) I'm getting two 
>>strange linking errors:
>>
>>Error ��500 ��error LNK2019: unresolved external symbol "public: 
>>virtual __cdecl uhd::transport::usb_device_handle::~usb_device_handle(void)" 
>>(??1usb_device_handle@transport@uhd@@UEAA@XZ) referenced in function "public: 
>>virtual void * __cdecl uhd::transport::usb_device_handle::`vector deleting 
>>destructor'(unsigned int)" (??_Eusb_device_handle@transport@uhd@@UEAAPEAXI@Z)
>>
>>Error ��501 ��error LNK2019: unresolved external symbol "public: 
>>virtual __cdecl uhd::transport::usb_zero_copy::~usb_zero_copy(void)" 
>>(??1usb_zero_copy@transport@uhd@@UEAA@XZ) referenced in function "public: 
>>void __cdecl uhd::transport::usb_zero_copy::`vbase destructor'(void)" 
>>(??_Dusb_zero_copy@transport@uhd@@QEAAXXZ)
>>
>>in file D:\VS\uhd\host\build\lib\usb_dummy_impl.obj
>>
>>Looks like it's related with boost libs, which I'm not familiar with. I 
>>switched to last boost 1.65.1 (started with 1.60 with the sme results), tried 
>>UHD 3.10.0.0, 3.10.2.0 and some one in between like 3.10.1.0 - all the same. 
>>Ver. 3.9.7 builds OK.
>>
>>BTW, I use the following sequence to build boost:
>>
>>bootstrap
>>b2 toolset=msvc-12.0 address-model=64
>>b2 toolset=msvc-12.0 address-model=64 --with-test link=shared As I see you 
>>have binaries for VC2013 available, obviously it should build correctly. Do 
>>you have any idea of what could be the problem here? I use MS Visual Studio 
>>2013 Ultimate with Update 5.
>>
>>Thank you!
>>Vladimir Pavlenko
>>
>>
>>
>>
>>
>>
>>
>>
>
>--
>This message is subject to the CSIR's copyright terms and conditions, e-mail 
>legal notice, and implemented Open Document Format (ODF) standard.
>The full disclaimer details can be found at  
>http://www.csir.co.za/disclaimer.html .
>
>Please consider the environment before printing this email.___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] rfnoc block with two inputs

[Dario Pennisi via USRP-users]

Hi,
It’s quite complex and long… posting the initial part with shell and wrappers

module noc_block_demod #(
  parameter NOC_ID = 64'h1408E12980FDE75E,
  parameter MAX_PACKET_SIZE = 64)
(
  input bus_clk, input bus_rst,
  input ce_clk, input ce_rst,
  input  [63:0] i_tdata, input  i_tlast, input  i_tvalid, output i_tready,
  output [63:0] o_tdata, output o_tlast, output o_tvalid, input  o_tready,
  output [63:0] debug
);

  
  //
  // RFNoC Shell
  //
  
  wire [31:0] set_data;
  wire [7:0]  set_addr;
  wireset_stb;
  reg rb_stb;
  reg  [63:0] rb_data;
  wire [7:0]  rb_addr;

  wire [63:0] cmdout_tdata, ackin_tdata;
  wirecmdout_tlast, cmdout_tvalid, cmdout_tready, ackin_tlast, 
ackin_tvalid, ackin_tready;

  wire [2*64-1:0] str_sink_tdata;
  wire [1:0]   str_sink_tlast, str_sink_tvalid, str_sink_tready;

  wire [63:0] str_src_tdata;
  wirestr_src_tlast, str_src_tvalid, str_src_tready;

  wire [15:0] src_sid;
  wire [15:0] next_dst_sid, resp_out_dst_sid;
  wire [15:0] resp_in_dst_sid;

  wireclear_tx_seqnum;

  noc_shell #(
.NOC_ID(NOC_ID),
.INPUT_PORTS(2)
)
  noc_shell (
.bus_clk(bus_clk), .bus_rst(bus_rst),
.i_tdata(i_tdata), .i_tlast(i_tlast), .i_tvalid(i_tvalid), 
.i_tready(i_tready),
.o_tdata(o_tdata), .o_tlast(o_tlast), .o_tvalid(o_tvalid), 
.o_tready(o_tready),
// Computer Engine Clock Domain
.clk(ce_clk), .reset(ce_rst),
// Control Sink
.set_data(set_data), .set_addr(set_addr), .set_stb(set_stb),
.rb_stb(rb_stb), .rb_data(rb_data), .rb_addr(rb_addr),
// Control Source
.cmdout_tdata(cmdout_tdata), .cmdout_tlast(cmdout_tlast), 
.cmdout_tvalid(cmdout_tvalid), .cmdout_tready(cmdout_tready),
.ackin_tdata(ackin_tdata), .ackin_tlast(ackin_tlast), 
.ackin_tvalid(ackin_tvalid), .ackin_tready(ackin_tready),
// Stream Sink
.str_sink_tdata(str_sink_tdata), .str_sink_tlast(str_sink_tlast), 
.str_sink_tvalid(str_sink_tvalid), .str_sink_tready(str_sink_tready),
// Stream Source
.str_src_tdata(str_src_tdata), .str_src_tlast(str_src_tlast), 
.str_src_tvalid(str_src_tvalid), .str_src_tready(str_src_tready),
// Stream IDs set by host
.src_sid(src_sid),   // SID of this block
.next_dst_sid(next_dst_sid), // Next destination SID
.resp_in_dst_sid(resp_in_dst_sid),   // Response destination SID for input 
stream responses / errors
.resp_out_dst_sid(resp_out_dst_sid), // Response destination SID for output 
stream responses / errors
// Misc
.vita_time('d0), .clear_tx_seqnum(clear_tx_seqnum),
.debug(debug));

  
  //
  // AXI Wrapper
  // Convert RFNoC Shell interface into AXI stream interface
  //
  
  wire [31:0]  m_axis0_data_tdata;
  wire m_axis0_data_tlast;
  wire m_axis0_data_tvalid;
  wire m_axis0_data_tready;
  wire [127:0] m_axis0_data_tuser;

  wire [31:0]  m_axis1_data_tdata;
  wire m_axis1_data_tlast;
  wire m_axis1_data_tvalid;
  wire m_axis1_data_tready;
  wire [127:0] m_axis1_data_tuser;

  wire [31:0]  s_axis0_data_tdata;
  wire s_axis0_data_tlast;
  wire s_axis0_data_tvalid;
  wire s_axis0_data_tready;
  wire [127:0] s_axis0_data_tuser;

  wire [31:0]  s_axis1_data_tdata;
  wire s_axis1_data_tlast;
  wire s_axis1_data_tvalid;
  wire s_axis1_data_tready;
  wire [127:0] s_axis1_data_tuser;
  wire [63:0]  vita_time_in;
  wire [63:0]  vita_time_out;
//  reg  [11:0]  seq_num;

  axi_wrapper #(
.SIMPLE_MODE(0))
  axi_wrapper0 (
.clk(ce_clk), .reset(ce_rst),
.clear_tx_seqnum(clear_tx_seqnum),
.next_dst(next_dst_sid),
.set_stb(set_stb), .set_addr(set_addr), .set_data(set_data),
.i_tdata(str_sink_tdata[63:0]), .i_tlast(str_sink_tlast[0]), 
.i_tvalid(str_sink_tvalid[0]), .i_tready(str_sink_tready[0]),
.o_tdata(str_src_tdata), .o_tlast(str_src_tlast), 
.o_tvalid(str_src_tvalid), .o_tready(str_src_tready),
.m_axis_data_tdata(m_axis0_data_tdata),
.m_axis_data_tlast(m_axis0_data_tlast),
.m_axis_data_tvalid(m_axis0_data_tvalid),
.m_axis_data_tready(m_axis0_data_tready),
.m_axis_data_tuser(m_axis0_data_tuser),
.s_axis_data_tdata(s_axis0_data_tdata),
.s_axis_data_tlast(s_axis0_data_tlast),
.s_axis_data_tvalid(s_axis0_data_tvalid),
.s_axis_data_tready(s_axis0_data_tready),
.s_axis_data_tuser(s_axis0_data_tuser),
.m_axis_config_tdata(),
.m_axis_config_tlast(),
.m_axis_config_tvalid(),
.m_axis_config_tready(),
.m_axis_pkt_len_tdata(),
.m_axis_pkt_len_tvalid(),
.m_axis_pkt_len_tready());

  axi_wrapper #(
.SIMPLE_MODE(0))
  axi_wrapper1 (
.clk(ce_clk), .reset(ce_rst),
.clear_tx_seqnum(clear_tx_seqnum),
.next_dst(next_d

Re: [USRP-users] rfnoc block with two inputs

[Nick Foster via USRP-users]

Dario,

Can you post your RFNoC block Verilog code?

Nick

On Mon, Sep 25, 2017 at 11:38 AM Dario Pennisi via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> We are developing a block which needs two inputs from the two radios. The
> block works with one input but when adding the second one only the first
> input is fed with data.
>
> Block has noc_shell instantiated with INPUT_PORTS(2) and its str_data
> output bus is connected to two axi_wrappers. Adding ILA shows that ready is
> always high on both sides but only the first side ever gets valid data.
>
>
>
> In the gnuradio xml initialization is done like this:
>
>
>
>  iptronix.block(
>
> self.device3,
>
>   uhd.stream_args( # TX Stream Args
>
> cpu_format="sc16",
>
> otw_format="sc16",
>
> channels=(0,1),
>
> args="",
>
>   ),
>
>   uhd.stream_args( # RX Stream Args
>
> cpu_format="sc16",
>
> otw_format="sc16",
>
> args=""
>
>   ),
>
>   $block_index,
>
>   $device_index
>
> )
>
> 
>
> …
>
>   
>
> in
>
> fc32
>
> $grvlen
>
> rfnoc
>
> 2
>
>   
>
>
>
> Whereas in the rfnoc block definition we added the following:
>
>
>
>   
>
> 
>
>  in_0
>
>  sc16
>
>
>
> 
>
>  ini_1
>
>  sc16
>
> 
>
> 
>
>  out0
>
>  sc16
>
> 
>
>   
>
>
>
> Is there anything we’re not doing correctly? I could not find any example
> other than addsub that shows how to set up a rfnoc block with two inputs
> and one output…
>
> Thanks,
>
>
>
> Dario Pennisi
>
>
> ___
> 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 block with two inputs

[Dario Pennisi via USRP-users]

Hi,
We are developing a block which needs two inputs from the two radios. The block 
works with one input but when adding the second one only the first input is fed 
with data.
Block has noc_shell instantiated with INPUT_PORTS(2) and its str_data output 
bus is connected to two axi_wrappers. Adding ILA shows that ready is always 
high on both sides but only the first side ever gets valid data.

In the gnuradio xml initialization is done like this:

 iptronix.block(
self.device3,
  uhd.stream_args( # TX Stream Args
cpu_format="sc16",
otw_format="sc16",
channels=(0,1),
args="",
  ),
  uhd.stream_args( # RX Stream Args
cpu_format="sc16",
otw_format="sc16",
args=""
  ),
  $block_index,
  $device_index
)

...
  
in
fc32
$grvlen
rfnoc
2
  

Whereas in the rfnoc block definition we added the following:

  

 in_0
 sc16
   

 ini_1
 sc16


 out0
 sc16

  

Is there anything we're not doing correctly? I could not find any example other 
than addsub that shows how to set up a rfnoc block with two inputs and one 
output...
Thanks,

Dario Pennisi

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

Re: [USRP-users] E310 "subdev spec" equivalent in RFNoC?

[EJ Kreinar via USRP-users]

Hello again,

Wanted to send some more results in case anyone is following...

I narrowed the problem down to a few lines in gr-ettus's rfnoc_block_impl
that specifically overrides the block_port for each channel; the
"block_port" stream_args in device->get_rx_stream(stream_args) function was
coerced to equal the port of the gnuradio flowgraph.  (See code here:
https://github.com/EttusResearch/gr-ettus/blob/814a7de651cd4c5595ff66a0326e0f2927d2baef/lib/rfnoc_block_impl.cc#L334
)

I have a suggested change on on a PR that's available on my fork of
gr-ettus: https://github.com/ejk43/gr-ettus/tree/ejk/rfnoc-port-edit

Essentially this fix will NOT override any block_portX stream args you
specify in the stream args.

So we should be able to do this to target channel 1 of the E300: (note the
Stream args where block_port0=1)

[image: Inline image 1]

That does the trick for me. Hope this helps!
EJ



On Mon, Sep 25, 2017 at 9:38 AM, EJ Kreinar  wrote:

> Hi all,
>
> On further inspection, I've had no more luck using python RFNoC to record
> on channel 1 (channel B)...
>
> Sadly, manually editing the stream args in the rfnoc radio did not appear
> to have any effect (see below). And, editing the "connect" in python
> command still errors out as per Test 3 of my original email.
>
> self.uhd_rfnoc_streamer_radio_0 = ettus.rfnoc_radio(
> self.device3,
> uhd.stream_args( # Tx Stream Args
> cpu_format="fc32",
> otw_format="sc16",
> args="block_port=1",
> ),
> uhd.stream_args( # Rx Stream Args
> cpu_format="fc32",
> otw_format="sc16",
> args="block_port=1",
> ),
> 0, -1
> )
>
> It appears that the rfnoc_rx_to_file takes a far more manual approach to
> running the application, rather than using gnuradio-- the rfnoc_rx_to_file
> creates the rfnoc graph and then calls the recv function in a loop, and
> does not use GR to link up to a file sink, as in the python flowgraph.
>
> Any other ideas? I'm currently leaning towards the conclusion that
> switching the receive channel is simply not currently supported with Rfnoc
> + Gnuradio.  Agreed??
>
> EJ
>
> On Mon, Sep 25, 2017 at 9:11 AM, EJ Kreinar  wrote:
>
>> Thanks Tom, Quick update here...
>>
>> I've found a set of options that will control the E300 receive channel
>> using rfnoc software:
>>
>> rfnoc_rx_to_file --freq  --rate  --ant TX/RX
>> --radio-chan 0
>> rfnoc_rx_to_file --freq  --rate  --ant RX2
>> --radio-chan 0
>> rfnoc_rx_to_file --freq  --rate  --ant TX/RX
>> --radio-chan 1
>> rfnoc_rx_to_file --freq  --rate  --ant RX2
>> --radio-chan 1
>>
>>
>> Tracking where/how rfnoc_rx_to_file sets the appropriate channel, it
>> appears that it simply sets the "block_port" streamer args:
>>
>> streamer_args["block_port"] = str(boost::format("%d") %
>> radio_chan);
>>
>>
>> Or, alternatively, if there's a block inserted via the command line, then
>> the correct port is connected in the rx_graph:
>>
>> rx_graph->connect(radio_ctrl_id, radio_chan,
>> blk_ctrl->get_block_id(), uhd::rfnoc::ANY_PORT);
>>
>> Interestingly, this seems to suggest an approach closest to my "test 3"
>> earlier. I'll look for how this can tie into python rfnoc software now...
>>
>>
>> EJ
>>
>>
>> On Thu, Sep 21, 2017 at 4:24 PM, Tom Bereknyei  wrote:
>>
>>> EJ,
>>>
>>> I went through that same sequence of attempts and never got a solution
>>> other than using TX/RX and RX2 on the same A channel.
>>>
>>> On Thu, Sep 21, 2017 at 14:05 EJ Kreinar via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Hi all,

 I'm trying to specify exactly which channel to record from an RFNoC
 flowgraph on the E310, but I cant seem to get this to work

 Typically, in non-RFNoC applications, or in the "legacy_compat" mode,
 you can use the following options:

 uhd_rx_cfile -r  -f  -A TX/RX --spec=A:A
 recording.c32
 uhd_rx_cfile -r  -f  -A RX2 --spec=A:A
 recording.c32
 uhd_rx_cfile -r  -f  -A TX/RX --spec=A:B
 recording.c32
 uhd_rx_cfile -r  -f  -A RX2 --spec=A:B
 recording.c32

 And each option, in turn, records data from a different receive port on
 the E310.


 But, I cant figure out the correct combination to get the rfnoc_radio
 software to support recording on channel B. A few things I've tried:

 1. Changing the rfnoc_radio dropdown to "Radio Select = B". This errors
 like this:

 Traceback (most recent call last):
   File "/home/root/test_rx.py", line 138, in 
 main()
   File "/home/root/test_rx.py", line 127, in main
 tb = top_block_cls(args=options.args, freq=options.freq,
 gain=options.gain, rate=options.rate)
   File "/home/root/test_rx.py", line 52, in __init__
 1, -1
   File "/usr/lib/python2.7/site-packages/ettus/ettus_swig.py", line
 1980, in 

Re: [USRP-users] warning on UDP buffer size when using Python API

[Osvaldo Alcala (Ozzie) via USRP-users]

Im just running the sample python API script to capture samples from the 
receiver. Im using an X310.

I tried running the script directly from command line to make sure nothing was 
changed and I still got the same warning. It’s a bit strange that when I change 
the buffer size to what is requested, it still asks for different buffer size. 
Something changes, but not sure why, as I try to keep everything exactly the 
same in the system.

Any other ideas would be useful

Thank yoU!

O

-Original Message-
From: Andrej Rode [mailto:m...@andrejro.de] 
Sent: Friday, September 22, 2017 1:56 PM
To: Osvaldo Alcala (Ozzie) 
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] warning on UDP buffer size when using Python API

Hi, 

On Fri, Sep 22, 2017 at 08:38:32PM +, Osvaldo Alcala (Ozzie) wrote:
> Thank you. I should have said that I did try the command that shows in the 
> screenshot, but the required buffer size keeps changing: thus I get the same 
> error every time.

So maybe in your script/application you have increasing buffer sizes and thus 
the uhd send()/recv() calls try to send bigger buffers?

But that's just guessing. An explanation what you are trying to do with the 
Python API would be helpful, so the root cause (either in UHD or your 
application can be identified)

Cheers,
Andrej

--
Andrej Rode
GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Trying to build v. 003.010 Win64

[Josh Sendall via USRP-users]

Hi Vladimir,
You need to link with libusb. It seems to be needed regardless of whether you 
enable the sub module or not. 

Kind regards,
Joshua Sendall 


On 25 Sep 2017 6:18 PM, Vladimir via USRP-users  
wrote:[The e-mail server of the sender could not be verified (SPF Record)]Hello 
USRP team!

In our Linux application for quite a while we use some 3.10 version of UHD 
(which requires FPGA ver. 33) and it works fine. Now we want to use the same 
version in Windows app, to match the FPGA ver. But trying to build any of 3.10 
versions in MS Visual Studio 2013 (Release x64 cfg) I'm getting two strange 
linking errors:

Error500error LNK2019: unresolved external symbol "public: virtual 
__cdecl uhd::transport::usb_device_handle::~usb_device_handle(void)" 
(??1usb_device_handle@transport@uhd@@UEAA@XZ) referenced in 
function "public: virtual void * __cdecl 
uhd::transport::usb_device_handle::`vector deleting 
destructor'(unsigned int)" 
(??_Eusb_device_handle@transport@uhd@@UEAAPEAXI@Z)

Error501error LNK2019: unresolved external symbol "public: virtual 
__cdecl uhd::transport::usb_zero_copy::~usb_zero_copy(void)" 
(??1usb_zero_copy@transport@uhd@@UEAA@XZ) referenced in 
function "public: void __cdecl uhd::transport::usb_zero_copy::`vbase 
destructor'(void)" 
(??_Dusb_zero_copy@transport@uhd@@QEAAXXZ)

in file D:\VS\uhd\host\build\lib\usb_dummy_impl.obj

Looks like it's related with boost libs, which I'm not familiar with. I 
switched to last boost 1.65.1 (started with 1.60 with the sme results), tried 
UHD 3.10.0.0, 3.10.2.0 and some one in between like 3.10.1.0 - all the same. 
Ver. 3.9.7 builds OK.

BTW, I use the following sequence to build boost:

bootstrap

b2 toolset=msvc-12.0 address-model=64

b2 toolset=msvc-12.0 address-model=64 --with-test link=shared

As I see you have binaries for VC2013 available, obviously it should build 
correctly. Do you have any idea of what could be the problem here? I use MS 
Visual Studio 2013 Ultimate with Update 5.

Thank you!
Vladimir Pavlenko











--

This message is subject to the CSIR's copyright terms and conditions, e-mail 
legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at 
http://www.csir.co.za/disclaimer.html. 

Please consider the environment before printing this email. ___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Trying to build v. 003.010 Win64

[Vladimir via USRP-users]

Hello USRP team!

In our Linux application for quite a while we use some 3.10 version of UHD 
(which requires FPGA ver. 33) and it works fine. Now we want to use the same 
version in Windows app, to match the FPGA ver. But trying to build any of 3.10 
versions in MS Visual Studio 2013 (Release x64 cfg) I'm getting two strange 
linking errors:

Error    500    error LNK2019: unresolved external symbol "public: virtual 
__cdecl uhd::transport::usb_device_handle::~usb_device_handle(void)" 
(??1usb_device_handle@transport@uhd@@UEAA@XZ) referenced in function "public: 
virtual void * __cdecl uhd::transport::usb_device_handle::`vector deleting 
destructor'(unsigned int)" (??_Eusb_device_handle@transport@uhd@@UEAAPEAXI@Z)

Error    501    error LNK2019: unresolved external symbol "public: virtual 
__cdecl uhd::transport::usb_zero_copy::~usb_zero_copy(void)" 
(??1usb_zero_copy@transport@uhd@@UEAA@XZ) referenced in function "public: void 
__cdecl uhd::transport::usb_zero_copy::`vbase destructor'(void)" 
(??_Dusb_zero_copy@transport@uhd@@QEAAXXZ)

in file D:\VS\uhd\host\build\lib\usb_dummy_impl.obj

Looks like it's related with boost libs, which I'm not familiar with. I 
switched to last boost 1.65.1 (started with 1.60 with the sme results), tried 
UHD 3.10.0.0, 3.10.2.0 and some one in between like 3.10.1.0 - all the same. 
Ver. 3.9.7 builds OK.

BTW, I use the following sequence to build boost:

bootstrap
b2 toolset=msvc-12.0  address - model = 64
b2 toolset=msvc-12.0  address - model = 64 --with-test link=shared As I see you 
have binaries for VC2013 available, obviously it should build correctly. Do you 
have any idea of what could be the problem here? I use MS Visual Studio 2013 
Ultimate with Update 5.

Thank you!
Vladimir Pavlenko








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

[USRP-users] uhd_usrp message return and Comms issues

[Mark Koenig via USRP-users]

When I run the “uhd_usrp_probe” command I receive an interesting message prior 
to getting all of the information returned.  It is listed below.  I am having 
communication issues with the USRP X310 when changing frequencies, as it is 
taking much longer to retask the X310 than I would assume and therefor during 
my scan some frequencies are being missed.  I am using the 10gig bit Ethernet 
port, with a Chelsio card on a server running CentOS 6.5 with UHD rev 
003.008.004.

Any suggestions would be much appreciated.

Thanks

UHD  Error:
X300 Network discovery error send_to:  Network is unreachable

UHD  Error:
X300 Network discovery error send_to:  Network is unreachable

UHD  Error:
USRP2 Network discovery error send_to:  Network is unreachable

UHD  Error:
USRP2 Network discovery error send_to:  Network is unreachable
-- X300 initiallization sequence…

Then the rest of the output is the usrp and daughtercard information, which is 
all correct.


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

Re: [USRP-users] E310 "subdev spec" equivalent in RFNoC?

[EJ Kreinar via USRP-users]

Hi all,

On further inspection, I've had no more luck using python RFNoC to record
on channel 1 (channel B)...

Sadly, manually editing the stream args in the rfnoc radio did not appear
to have any effect (see below). And, editing the "connect" in python
command still errors out as per Test 3 of my original email.

self.uhd_rfnoc_streamer_radio_0 = ettus.rfnoc_radio(
self.device3,
uhd.stream_args( # Tx Stream Args
cpu_format="fc32",
otw_format="sc16",
args="block_port=1",
),
uhd.stream_args( # Rx Stream Args
cpu_format="fc32",
otw_format="sc16",
args="block_port=1",
),
0, -1
)

It appears that the rfnoc_rx_to_file takes a far more manual approach to
running the application, rather than using gnuradio-- the rfnoc_rx_to_file
creates the rfnoc graph and then calls the recv function in a loop, and
does not use GR to link up to a file sink, as in the python flowgraph.

Any other ideas? I'm currently leaning towards the conclusion that
switching the receive channel is simply not currently supported with Rfnoc
+ Gnuradio.  Agreed??

EJ

On Mon, Sep 25, 2017 at 9:11 AM, EJ Kreinar  wrote:

> Thanks Tom, Quick update here...
>
> I've found a set of options that will control the E300 receive channel
> using rfnoc software:
>
> rfnoc_rx_to_file --freq  --rate  --ant TX/RX
> --radio-chan 0
> rfnoc_rx_to_file --freq  --rate  --ant RX2
> --radio-chan 0
> rfnoc_rx_to_file --freq  --rate  --ant TX/RX
> --radio-chan 1
> rfnoc_rx_to_file --freq  --rate  --ant RX2
> --radio-chan 1
>
>
> Tracking where/how rfnoc_rx_to_file sets the appropriate channel, it
> appears that it simply sets the "block_port" streamer args:
>
> streamer_args["block_port"] = str(boost::format("%d") %
> radio_chan);
>
>
> Or, alternatively, if there's a block inserted via the command line, then
> the correct port is connected in the rx_graph:
>
> rx_graph->connect(radio_ctrl_id, radio_chan,
> blk_ctrl->get_block_id(), uhd::rfnoc::ANY_PORT);
>
> Interestingly, this seems to suggest an approach closest to my "test 3"
> earlier. I'll look for how this can tie into python rfnoc software now...
>
>
> EJ
>
>
> On Thu, Sep 21, 2017 at 4:24 PM, Tom Bereknyei  wrote:
>
>> EJ,
>>
>> I went through that same sequence of attempts and never got a solution
>> other than using TX/RX and RX2 on the same A channel.
>>
>> On Thu, Sep 21, 2017 at 14:05 EJ Kreinar via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi all,
>>>
>>> I'm trying to specify exactly which channel to record from an RFNoC
>>> flowgraph on the E310, but I cant seem to get this to work
>>>
>>> Typically, in non-RFNoC applications, or in the "legacy_compat" mode,
>>> you can use the following options:
>>>
>>> uhd_rx_cfile -r  -f  -A TX/RX --spec=A:A
>>> recording.c32
>>> uhd_rx_cfile -r  -f  -A RX2 --spec=A:A
>>> recording.c32
>>> uhd_rx_cfile -r  -f  -A TX/RX --spec=A:B
>>> recording.c32
>>> uhd_rx_cfile -r  -f  -A RX2 --spec=A:B
>>> recording.c32
>>>
>>> And each option, in turn, records data from a different receive port on
>>> the E310.
>>>
>>>
>>> But, I cant figure out the correct combination to get the rfnoc_radio
>>> software to support recording on channel B. A few things I've tried:
>>>
>>> 1. Changing the rfnoc_radio dropdown to "Radio Select = B". This errors
>>> like this:
>>>
>>> Traceback (most recent call last):
>>>   File "/home/root/test_rx.py", line 138, in 
>>> main()
>>>   File "/home/root/test_rx.py", line 127, in main
>>> tb = top_block_cls(args=options.args, freq=options.freq,
>>> gain=options.gain, rate=options.rate)
>>>   File "/home/root/test_rx.py", line 52, in __init__
>>> 1, -1
>>>   File "/usr/lib/python2.7/site-packages/ettus/ettus_swig.py", line
>>> 1980, in make
>>> return _ettus_swig.rfnoc_radio_make(*args, **kwargs)
>>> RuntimeError: Cannot find a block for ID: Radio_1
>>> -- Loading FPGA image: /boot/system_top.bit... done
>>>
>>>
>>> 2. Adding a FIFO to the FPGA on the second channel, and "dropping" the
>>> samples from the first channel.
>>> [image: Inline image 1]
>>>
>>> But this fails like so:
>>>
>>> -- [0/FIFO_0] source_node_ctrl::set_rx_streamer() 0 -> 1
>>> -- [0/Radio_0] radio_ctrl_impl::set_rx_streamer() 1 -> 1
>>> -- [0/Radio_0] e3xx_radio_ctrl_impl::_update_enables()
>>> -- [0/Radio_0] e3xx_radio_ctrl_impl::_update_gpio_state()
>>> -- [Device3] updating RX streamer to RX Terminator 0
>>> --   New tick_rate == 25  New samp_rate == 25 New scaling ==
>>> 3.05185e-05
>>> -- [0/FIFO_0] source_block_ctrl_base::issue_stream_cmd()
>>> -- [0/Radio_0] radio_ctrl_impl::issue_stream_cmd() 0 a
>>> -- [0/Radio_0] radio_ctrl_impl::issue_stream_cmd() called on inactive
>>> channel. Skipping.
>>> timeout on chan 0
>>> timeout on chan 0
>>>
>>> And no data is recorded.
>>>
>>> 3. I also tried (foolishly) manually editing the generated

Re: [USRP-users] USRP's B210 sluggish start of transmission

[Piotr Krysik via USRP-users]

Hi all,

For comparison: screenshot of much more "civilized" behavior of USRP
X310 in the same situation.

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

Re: [USRP-users] E310 "subdev spec" equivalent in RFNoC?

[EJ Kreinar via USRP-users]

Thanks Tom, Quick update here...

I've found a set of options that will control the E300 receive channel
using rfnoc software:

rfnoc_rx_to_file --freq  --rate  --ant TX/RX
--radio-chan 0
rfnoc_rx_to_file --freq  --rate  --ant RX2
--radio-chan 0
rfnoc_rx_to_file --freq  --rate  --ant TX/RX
--radio-chan 1
rfnoc_rx_to_file --freq  --rate  --ant RX2
--radio-chan 1


Tracking where/how rfnoc_rx_to_file sets the appropriate channel, it
appears that it simply sets the "block_port" streamer args:

streamer_args["block_port"] = str(boost::format("%d") % radio_chan);


Or, alternatively, if there's a block inserted via the command line, then
the correct port is connected in the rx_graph:

rx_graph->connect(radio_ctrl_id, radio_chan,
blk_ctrl->get_block_id(), uhd::rfnoc::ANY_PORT);

Interestingly, this seems to suggest an approach closest to my "test 3"
earlier. I'll look for how this can tie into python rfnoc software now...


EJ


On Thu, Sep 21, 2017 at 4:24 PM, Tom Bereknyei  wrote:

> EJ,
>
> I went through that same sequence of attempts and never got a solution
> other than using TX/RX and RX2 on the same A channel.
>
> On Thu, Sep 21, 2017 at 14:05 EJ Kreinar via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi all,
>>
>> I'm trying to specify exactly which channel to record from an RFNoC
>> flowgraph on the E310, but I cant seem to get this to work
>>
>> Typically, in non-RFNoC applications, or in the "legacy_compat" mode, you
>> can use the following options:
>>
>> uhd_rx_cfile -r  -f  -A TX/RX --spec=A:A
>> recording.c32
>> uhd_rx_cfile -r  -f  -A RX2 --spec=A:A
>> recording.c32
>> uhd_rx_cfile -r  -f  -A TX/RX --spec=A:B
>> recording.c32
>> uhd_rx_cfile -r  -f  -A RX2 --spec=A:B
>> recording.c32
>>
>> And each option, in turn, records data from a different receive port on
>> the E310.
>>
>>
>> But, I cant figure out the correct combination to get the rfnoc_radio
>> software to support recording on channel B. A few things I've tried:
>>
>> 1. Changing the rfnoc_radio dropdown to "Radio Select = B". This errors
>> like this:
>>
>> Traceback (most recent call last):
>>   File "/home/root/test_rx.py", line 138, in 
>> main()
>>   File "/home/root/test_rx.py", line 127, in main
>> tb = top_block_cls(args=options.args, freq=options.freq,
>> gain=options.gain, rate=options.rate)
>>   File "/home/root/test_rx.py", line 52, in __init__
>> 1, -1
>>   File "/usr/lib/python2.7/site-packages/ettus/ettus_swig.py", line
>> 1980, in make
>> return _ettus_swig.rfnoc_radio_make(*args, **kwargs)
>> RuntimeError: Cannot find a block for ID: Radio_1
>> -- Loading FPGA image: /boot/system_top.bit... done
>>
>>
>> 2. Adding a FIFO to the FPGA on the second channel, and "dropping" the
>> samples from the first channel.
>> [image: Inline image 1]
>>
>> But this fails like so:
>>
>> -- [0/FIFO_0] source_node_ctrl::set_rx_streamer() 0 -> 1
>> -- [0/Radio_0] radio_ctrl_impl::set_rx_streamer() 1 -> 1
>> -- [0/Radio_0] e3xx_radio_ctrl_impl::_update_enables()
>> -- [0/Radio_0] e3xx_radio_ctrl_impl::_update_gpio_state()
>> -- [Device3] updating RX streamer to RX Terminator 0
>> --   New tick_rate == 25  New samp_rate == 25 New scaling ==
>> 3.05185e-05
>> -- [0/FIFO_0] source_block_ctrl_base::issue_stream_cmd()
>> -- [0/Radio_0] radio_ctrl_impl::issue_stream_cmd() 0 a
>> -- [0/Radio_0] radio_ctrl_impl::issue_stream_cmd() called on inactive
>> channel. Skipping.
>> timeout on chan 0
>> timeout on chan 0
>>
>> And no data is recorded.
>>
>> 3. I also tried (foolishly) manually editing the generated python to
>> connect the File Sink to port 1 of the rfnoc_radio, rather than port 0.
>>
>> I used this flowgraph:
>> [image: Inline image 3]
>> And then I manually changed the following lines:
>>
>> self.connect((self.uhd_rfnoc_streamer_radio_0, 0),
>> (self.blocks_file_sink_0_0, 0))
>> =becomes==>
>> self.connect((self.uhd_rfnoc_streamer_radio_0, 1),
>> (self.blocks_file_sink_0_0, 0))
>>
>> I was hopeful that port 1 actually existed and was initialized correctly
>> in UHD, but alas, port 1 clearly does not exist for me to attach the file
>> sink to:
>>
>> Traceback (most recent call last):
>>   File "/home/root/test_rx.py", line 138, in 
>> main()
>>   File "/home/root/test_rx.py", line 128, in main
>> tb.start()
>>   File "/usr/lib/python2.7/site-packages/gnuradio/gr/top_block.py", line
>> 109, in start
>> top_block_start_unlocked(self._impl, max_noutput_items)
>>   File "/usr/lib/python2.7/site-packages/gnuradio/gr/runtime_swig.py",
>> line 3671, in top_block_start_unlocked
>> return _runtime_swig.top_block_start_unlocked(*args, **kwargs)
>> RuntimeError: rfnoc_radio(1): missing connection from output port 0
>> -- Loading FPGA image: /boot/system_top.bit... done
>>
>>
>> I cant seem to figure this out.. Any suggestions?? Am I missing something
>> obvious, or is RFNoC missing this support?
>>
>> (by the way, I am admittedly still behind on my UHD version. So perhaps
>> there

Re: [USRP-users] C674 fail on B210 rev 4

[Billy Jones via USRP-users]

Matt,

Thanks for the tips on the power supply.  I was worried that the quality of the 
wall wart may have played a part in this – unfortunately I don’t have the 
equipment necessary to inspect its output closely.  I’ve also seen incidents of 
tantalum capacitors  that have almost seemingly spontaneously combusted before 
with little or no evidence of a poor operating environment, so who knows.

Thanks again,
Billy

From: Radio User [mailto:radiogeek...@gmail.com]
Sent: Saturday, September 23, 2017 10:08 PM
To: usrp-users@lists.ettus.com; Billy Jones; Robin Coxe
Subject: Re: [USRP-users] C674 fail on B210 rev 4

 Billy,

On Fri, Sep 22, 2017 at 8:23 PM, Billy Jones via USRP-users <
usrp-users@lists.ettus.com> wrote:
snip
> I'm using Rev 4 of the B210, and I have a GPSDO-TCXO module installed.  I
> was using a 9V, 1.5A wall wart as the power supply and had the USB3 cable
> connected to my PC.
>
> Thanks,
> Billy

It is possible that the cap failure is "just one of those things" but your 
comment about the 9V wall wart may be important.

There are some pretty gross wall warts out there.  Some even manage to produce 
not-very-good-almost-DC with lots of hash.  Others have poor isolation between 
one of the output terminals and the input (mains) connection.  The UL or CE tag 
on the case may just mean that Uncle Larry or Cousin Eddie signed their names 
to it.

I long ago avoided the problem for my N200 (6V DC) with a very high quality 
DC/DC converter driven either by a not-so-portable battery or by a lab power 
supply. I often run my B210 from a 12V linear bench supply.

I'm assuming your 9V wall wart was supposed to produce DC.

It is likely a switcher.  (Designing an affordable well regulated linear DC 
supply that can source 1.5A is hard if it has to stick to the wall socket.)  
Switchers are fine -- when they are well designed. In fact page 7/8 (the last 
page in the B200 drawing set) shows two very nicely designed switching 
converters to generate the 1.2 and 1.8 volt supplies for the FPGAs.

Badly designed or cheaply made switching regulators, however, are noise 
generators, and not very good at that.  They have spectral peaks all over the 
place, the spikes up and down in frequency, and they are dirty, wide, and rich 
in noxious harmonics.

So, unless your 9V wall wart was particularly clean, you might try a good bench 
supply or a stout battery.  You'll get a cleaner RF environment and may even 
save some wear-and-tear on the input filter caps.

matt

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

Re: [USRP-users] C674 fail on B210 rev 4

[Billy Jones via USRP-users]

Robin,

Thank you for the info and the link - I hadn’t realized that the EDA files were 
available publicly.

-Billy

From: Robin Coxe [mailto:robin.c...@ettus.com]
Sent: Friday, September 22, 2017 3:43 PM
To: Billy Jones
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] C674 fail on B210 rev 4

Hi Billy.  C674 is Kemet T495C107K016ATE200  CAP,SM,100UF,16V,10%,TANTALUM,6032.

Schematics for the B210 are available here: 
http://files.ettus.com/schematics/b200/b210.pdf

-Robin



On Fri, Sep 22, 2017 at 8:23 PM, Billy Jones via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
I have been using a B210 board for about a week now to run OpenBTS and 
OpenBTS-UMTS.  I left the board powered on in its enclosure overnight, and when 
I arrived in the morning discovered it not working, the power led flickering, 
and my computer alerting that there was a USB power surge.  I took the board 
out of its enclosure and discovered capacitor C674 had completely burned up.

Has anyone else encountered a hardware failure as catastrophic as this with the 
power supply?

Does anyone know the specs on that capacitor (capacitance, voltage rating, 
etc.) so I can possibly replace it on the board myself?

I'm using Rev 4 of the B210, and I have a GPSDO-TCXO module installed.  I was 
using a 9V, 1.5A wall wart as the power supply and had the USB3 cable connected 
to my PC.

Thanks,
Billy

___
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