Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Custom UHD Program terminate during set_clock_ref
(Martin Braun)
2. Re: Not sure how to remove tuser CHDR header control and data
from m_axis_data_tdata and s_axis_data_tdata in noc_block
(Martin Braun)
3. Detailed RX/TX Filter Bank Specifications for E310/312
(Zhongren Cao)
4. Filter Bank Specifications for E310 (Zhongren Cao)
5. rfnoc-radio-redo and RX path (Nick Foster)
6. Re: Custom Board (Matt Ettus)
7. Limited success with sending packets out from an SC16 file
(Swanson, Craig)
8. Re: Filter Bank Specifications for E310 (Marcus M?ller)
9. rfnoc-radio-redo DDC block test (Nick Foster)
10. Re: Custom UHD Program terminate during set_clock_ref
(Patrick Berger)
11. Modelsim errors when running noc_block_conv_encoder_qpsk_tb
in rfnoc-radio-redo branch (Swanson, Craig)
12. Error when running noc_block_fir_filter_tb in Modelsim in
rfnoc-radio-redo branch : cannot open wave.do file (Swanson, Craig)
13. Re: ??RE: B210 not recognized over USB 3 in Windows 7
(Marcus M?ller)
14. Knowledge Base ([email protected])
----------------------------------------------------------------------
Message: 1
Date: Thu, 9 Jun 2016 09:10:24 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Custom UHD Program terminate during
set_clock_ref
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
My first guess is ABI mismatch. You're segfaulting when you mean to call
usrp->set_clock_source(ref);, but your segfault happens in
get_fe_rx_freq_range(). After that, all bets are off. I recommend
checking the version you linked against is the version you're running.
Also, do you have multiple threads in this app?
M
On 06/09/2016 06:58 AM, Patrick Berger via USRP-users wrote:
> Hi
>
> I've managed to set breakpoints inside the function:
>
>
> With a breakpoint on usrp->get_rx_freq() I could inspect the usrp pointer.
> usrp @0x10148b0
> uhd::usrp::multi_usrp::sptr
> data @0x1015280
> boost::shared_ptr<uhd::usrp::multi_usrp>::element_type
> usecoutnt 1 int
> weadkcount 1 int
>
> Checking the pointer against NULL is successful (so that isn't the problem).
>
> If I try to step over this function call the app crashes, or debuging is
> terminated with following error message. Against my programming
> expierence this indicates a bad pointer or something like this.
> The inferior stopped because it received a signal from the Operating System.
> Signal name: SIGSEGV
> Signal meaning: Segmentation fault
>
> During stepping through the instruction code in the disassembler, I get
> till the function _ZN15multi_usrp_impl14rx_chan_to_mcpEm:
> Function: _ZN15multi_usrp_impl14rx_chan_to_mcpEm
> 0x7f649e20a14c <+0x003c> movl $0x0,0x8(%rsp)
> 0x7f649e20a154 <+0x0044> mov %rax,0x20(%rsp)
> 0x7f649e20a159 <+0x0049> nopl 0x0(%rax)
> 0x7f649e20a160 <+0x0050> mov (%r15),%rax
> On the last line I get the segmentation fault! So I think there is
> something inside the uhd library wrong (accessing protected memory).
>
> The stack view at the crash moment looks like this:
> Level Function
> 0 multi_usrp_impl::rx_chan_to_mcp(unsinged long)
> 1 multi_usrp_impl::rx_rf_fe_roo(unsinged long)
> 2 multi_usrp_impl::get_fe_rx_freq_range(unsigned long)
> 3 USDP_SDR::Init_USRP
> 4 main
>
> So there must be something wrong in the function *rx_chan_to_mcp*
>
> Platform is Linux Mint 17.2, IDE is Qt Creator, linked UHD version is
> 3.9.1 (what I have to use for communicate also with matlab)
>
> Best regards
> Patrick
>
>
>> Date: Wed, 8 Jun 2016 09:28:45 -0700
>> To: [email protected]
>> Subject: Re: [USRP-users] Custom UHD Program terminate during
> set_clock_ref
>> From: [email protected]
>> CC: [email protected]
>>
>> Patrick,
>>
>> Is 'ref' being properly set before it is called in
> usrp->set_clock_source(ref) ? A simple sanity check is to print it out
> before it is called:
>>
>> std::cout << boost::format("Lock mboard clocks: %f") % ref << std::endl;
>> usrp->set_clock_source(ref);
>>
>>
>> - Nate
>>
>> > On Jun 8, 2016, at 9:05 AM, Martin Braun via USRP-users
> <[email protected]> wrote:
>> >
>> > Patrick,
>> >
>> > I have a hunch something is hiding some error message, and that error
>> > message would clue us in. The last line ("Press Return") is coming from
>> > where exactly? Is it your dev environment? Maybe there's a hidden
>> > segfault there. GRC is a bit like that, too.
>> >
>> > M
>> >
>> > On 06/08/2016 12:17 AM, Patrick Berger via USRP-users wrote:
>> >> Hi all
>> >>
>> >> I'm trying to create my own program to communicate with an X310 USRP.
>> >> Host is Linux (Mint 17.2) with uhd version 3.9.1 and boost 1.57.0
>> >>
>> >> During the build process in Qt Creator I've no errors or warnings
>> >> (libraries are all correct linked). The device is correctly found and
>> >> the initialization with uhd::usrp::multi_usrp::make(dev_adr) works
> also.
>> >> In the second step I would set the mboard clocks, but there is
> something
>> >> going bad.
>> >>
>> >> This is my current code (cross-checked with rx_samples_to_file,
>> >> rx_samples_to_udp, rx_ascii_art_dft):
>> >> int USRP_SDR::Init_USRP()
>> >> {
>> >> //create a usrp device
>> >> uhd::device_addr_t dev_adr;
>> >> dev_adr.set("addr", addr);
>> >> usrp = uhd::usrp::multi_usrp::make(dev_adr);
>> >>
>> >> std::cout << "Hallo1" << std::endl;
>> >> //Lock mboard clocks
>> >> usrp->set_clock_source(ref);
>> >> std::cout << "Hallo2" << std::endl;
>> >>
>> >> //always select the subdevice first, the channel mapping affects the
>> >> other settings
>> >> if (vm.count("subdev")) usrp->set_rx_subdev_spec(subdev);
>> >>
>> >> std::cout << boost::format("Using Device: %s") %
>> >> usrp->get_pp_string() << std::endl;
>> >>
>> >> //set the sample rate
>> >> if (rate <= 0.0){
>> >> std::cerr << "Please specify a valid sample rate" << std::endl;
>> >> return 0;
>> >> }
>> >> std::cout << boost::format("Setting RX Rate: %f Msps...") %
>> >> (rate/1e6) << std::endl;
>> >> usrp->set_rx_rate(rate);
>> >> std::cout << boost::format("Actual RX Rate: %f Msps...") %
>> >> (usrp->get_rx_rate()/1e6) << std::endl << std::endl;
>> >>
>> >> return 1;
>> >> }
>> >>
>> >> And this is the resulting terminal output (the Hello2 is missing, and
>> >> also the rest of the initialization process):
>> >> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.009.001-0-unknown
>> >>
>> >> UHD Warning:
>> >> Unable to set the thread priority. Performance may be negatively
>> >> affected.
>> >> Please see the general application notes in the manual for
> instructions.
>> >> EnvironmentError: OSError: error in pthread_setschedparam
>> >> -- X300 initialization sequence...
>> >> -- Determining maximum frame size... 1472 bytes.
>> >> -- Setup basic communication...
>> >> -- Loading values from EEPROM...
>> >> -- Setup RF frontend clocking...
>> >> -- Radio 1x clock:200
>> >> -- Initialize Radio0 control...
>> >> -- Performing register loopback test... pass
>> >> -- Initialize Radio1 control...
>> >> -- Performing register loopback test... pass
>> >> Hallo1
>> >> Press <RETURN> to close this window...
>> >>
>> >> Does anyone see the fault?
>> >>
>> >> Best regards
>> >> Patrick
>> >>
>> >>
>> >> _______________________________________________
>> >> USRP-users mailing list
>> >> [email protected]
>> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >>
>> >
>> >
>> > _______________________________________________
>> > USRP-users mailing list
>> > [email protected]
>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 2
Date: Thu, 9 Jun 2016 09:13:17 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Not sure how to remove tuser CHDR header
control and data from m_axis_data_tdata and s_axis_data_tdata in
noc_block
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
Craig,
there's nothing special about the GNU Radio 'file format', it's just raw
binary data. On the FPGA, data is typically sc16, i.e. 16-bit integers
I, 16-bit Q, etc.
M
On 06/08/2016 03:25 PM, Swanson, Craig via USRP-users wrote:
> ?Jonathon,
>
> Would it be difficult to modify Test 5 -- Test Sequence in
> noc_block_skeleton_tb.sv to send a file sink of SC16 data that was
> generated in gnuradio?
>
>
> Craig
>
>
> *Craig F. Swanson*
> */Research Engineer II
> /*
> */Information and Communications Laboratory/*
> */Communications, Systems, and Spectrum Division/*
> /Georgia Tech Research Institute/
> /Room 560
> 250 14th St NW
> /
> /Atlanta, GA 30318/
> /Cell: 770.298.9156/
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
> ------------------------------------------------------------------------
> *From:* Jonathon Pendlum <[email protected]>
> *Sent:* Wednesday, June 8, 2016 2:24 PM
> *To:* Swanson, Craig
> *Subject:* Re: Not sure how to remove tuser CHDR header control and data
> from m_axis_data_tdata and s_axis_data_tdata in noc_block
>
> If you are interfacing with the top level I/O, then your test bench will
> have to handle things such as flow control, setting up noc shell,
> control packets, etc. There isn't much I can do to help you with that
> other than pointing you to our existing code. That is why I suggest
> using the test bench infrastructure since it handles all that for you.
> If you want to give it another try, check out noc_block_skeleton.v and
> the associated test bench. That block is intended as a starting point
> for new blocks.
>
> On Wed, Jun 8, 2016 at 11:41 AM, Swanson, Craig
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> ?Jonathon,
>
> Yes.
>
> I would prefer to use your testbench but I don't know it well enough
> yet. I simply want to send it a file in modelsim that was produced
> in gnuradio as a file sink. Do you have a testbench with fairly
> good documentation that will allow me to do this? I am not an
> expert in system verilog, but if it is simple enough I think I can
> understand it.
>
>
> My cocotb testbench is using python to write scripts that send and
> receive data directly from my noc_block_Receiver.v which currently
> has the AGC in it.
>
>
> Craig
>
>
> *Craig F. Swanson*
> */Research Engineer II
> /*
> */Information and Communications Laboratory/*
> */Communications, Systems, and Spectrum Division/*
> /Georgia Tech Research Institute/
> /Room 560
> 250 14th St NW
> /
> /Atlanta, GA 30318/
> /Cell: 770.298.9156 <tel:770.298.9156>/
> http://www.gtri.gatech.edu
>
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
> ------------------------------------------------------------------------
> *From:* Jonathon Pendlum <[email protected]
> <mailto:[email protected]>>
> *Sent:* Wednesday, June 8, 2016 12:29 PM
> *To:* Swanson, Craig
> *Cc:* Martin Braun; Marcus M?ller; [email protected]
> <mailto:[email protected]>
> *Subject:* Re: Not sure how to remove tuser CHDR header control and
> data from m_axis_data_tdata and s_axis_data_tdata in noc_block
>
> Craig,
>
> Are you only simulating your AGC noc block and is your cocotb
> testbench directly interfacing its top level I/O (i.e. i_tdata,
> o_tdata, etc)?
>
>
>
> Jonathon
>
> On Tue, Jun 7, 2016 at 9:26 PM, Swanson, Craig
> <[email protected]
> <mailto:[email protected]>> wrote:
>
> Jonathon,____
>
> I am in the process of creating my own noc_block_Receiver.v
> which currently is acting as an AGC. When I run my own Modelsim
> testbench I am having undesired effects of the header requests
> and reply mingled in with my AGC data. I am not sure how to
> make sure that none of the header information for data, flow
> control, command or response be included in with what is going
> in or out of my AGC noc block.____
>
> It appears that the only signals I have access to are m_axis and
> s_axis tdata, tlast, tvalid, and tready. How would you suggest
> I go about making sure only pure data enters and leaves the AGC
> when communicating with my cocotb testbench or
> gnuradio-companion? I have not looked at how the moving_avg
> deals with this.____
>
> __ __
>
> Craig____
>
> __ __
>
> *Craig F. Swanson____*
>
> *Research Engineer II____*
>
> *Information and Communications Laboratory____*
>
> *Communications, Systems, and Spectrum Division____*
>
> Georgia Tech Research Institute____
>
> Room 560____
>
> 250 14^th Street NW____
>
> Atlanta, GA 30318____
>
> Cell: 770-298-9156 <tel:770-298-9156>____
>
> http://www.gtri.gatech.edu____
>
> __ __
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 3
Date: Thu, 9 Jun 2016 14:06:39 -0400
From: Zhongren Cao <[email protected]>
To: Emanuel via USRP-users <[email protected]>
Subject: [USRP-users] Detailed RX/TX Filter Bank Specifications for
E310/312
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi,
The E310/312 Data Sheet has a coarse illustration of the characteristics of the
TX/RX front end filter banks, which only shows 6 dB of attenuation. Do you have
a more detailed presentation, which shows detailed frequency vs. attenuation in
the scale of 30-50 dB range?
For example, for the RX FB-5 & FB-6, where is the cut-off? What?s the response
in 2.1G, 2.5G, respectively?
Thanks,
Zhongren
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160609/5693dc38/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 9 Jun 2016 14:14:38 -0400
From: Zhongren Cao <[email protected]>
To: [email protected]
Subject: [USRP-users] Filter Bank Specifications for E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi,
The E310/312 Data Sheet has a coarse illustration of the characteristics of the
TX/RX front end filter banks, which only shows 6 dB of attenuation. Do you have
a more detailed presentation, which shows detailed frequency vs. attenuation in
the scale of 30-50 dB range?
For example, for the RX FB-5 & FB-6, where is the cut-off? What?s the response
in 2.1G, 2.5G, respectively?
Thanks,
Zhongren
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160609/ac809d22/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 09 Jun 2016 18:24:39 +0000
From: Nick Foster <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] rfnoc-radio-redo and RX path
Message-ID:
<CA+JMMq_pNPSQRQ1H_qPoVQvbw=EEQyK7eHRVM9qZ_3=zebj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi guys,
Having some trouble on rfnoc-radio-redo trying to simply receive something
with a WBX.
FG just looks like this:
[image: pasted1]
?
Only receiving very low-level noise on the output. No indication of signal
(flat spectrum, faint DC offset), though there is CW being put into the
front end. The output appears independent of both gain and frequency
setting in the RFNoC Radio block. I don't even care about the integrity of
the signal -- obviously Keep 1 in N isn't going to do me any favors there.
Just trying to prove I'm hearing anything at all with this simple flowgraph.
Any hints?
--n
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160609/735241ed/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pasted1
Type: image/png
Size: 30626 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160609/735241ed/attachment-0001.png>
------------------------------
Message: 6
Date: Thu, 9 Jun 2016 11:38:41 -0700
From: Matt Ettus <[email protected]>
To: Joshua Monson <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Custom Board
Message-ID:
<CAN=1kn-WbEXUuRz_o=v0spf9u4emxte058bw53g+4rqcrom...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Joshua,
While you are welcome to try this, you have chosen an extremely difficult
path. There is a lot of complexity in a board like this. You would be far
better off if you started with our top level design an removed the parts
you don't want, rather than try to recreate everything in a vacuum.
Otherwise, you'll need to look at the schematics to make sure every pin is
driven properly.
Matt
On Thu, Jun 9, 2016 at 8:43 AM, Joshua Monson via USRP-users <
[email protected]> wrote:
> Hi,
>
>
>
> We?re developing a custom bare-metal FPGA design for the USRP E310. The
> plan is to have the FPGA configured with this design via an SDCard image
> when the board powers up. To begin our development we?d like to start with
> minimal FPGA design that can bring the board up safely without damaging the
> other components. To this end I?ve created an initial design in Xilinx
> Vivado by importing the PS configurations (presets) from the E3XX_idle
> design in UHD. On the FPGA side (PL), I?ve imported and integrated the AXI
> PMU and constant logic values connected to external I/O (also from
> E3XX_idle). I?ve also imported the constraint files from E3XX_idle to
> ensure the I/O voltage levels are configured properly.
>
>
>
> Is there anything else that I need to do to ensure that the board and FPGA
> powers on properly?
>
>
>
> Thanks,
>
>
>
> Josh
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160609/6cb1f6af/attachment-0001.html>
------------------------------
Message: 7
Date: Thu, 9 Jun 2016 20:31:06 +0000
From: "Swanson, Craig" <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: [USRP-users] Limited success with sending packets out from an
SC16 file
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Jonathon,
I ran your noc_block_skeleton_tb.v testbench and made changes to Test 5 to be
able to send SC16 data from a file. It seems to work partially but only sends
out about 1/8 of the data in the file, then quits. I am not sure why.
Here are snippits of my code. It would be great if you could add a section in
the testbench that correctly reads in SC16 or FC32 data from a file and runs it
through as payload in the noc_block_skeleton.v file.
Craig
localparam FILENAME =
"/home/craig/modelsim_four_interleave_amplitude_variation_x310.dat";
....
reg [63:0] mem[0:65535];
integer file, file_length;
reg [15:0] index;
....
initial
begin
file = $fopen(FILENAME, "r");
file_length = $fread(mem,file);
$display("Read %d lines", file_length);
end
....
/********************************************************
** Test 5 -- Test sequence
********************************************************/
// Skeleton's user code is a loopback, so we should receive
// back exactly what we send
`TEST_CASE_START("Test sequence");
fork
begin
cvita_payload_t send_payload;
for (int j = 12; j < 21; j++) begin
for (int i = 0; i < SPP/2; i++) begin
send_payload.push_back(mem[i+((SPP/2)*j)]);
$display("Data is %d, %h", (i+((SPP/2)*j)), mem[i+((SPP/2)*j)]);
tb_streamer.send(send_payload);
end
end
end
begin
cvita_payload_t recv_payload;
cvita_metadata_t md;
logic [63:0] expected_value;
tb_streamer.recv(recv_payload,md);
for (int j = 12; j < 21; j++) begin
for (int i = 0; i < SPP/2; i++) begin
expected_value = mem[i+((SPP/2)*j)];
$sformat(s, "Incorrect value received! Expected: %0h, Received: %0h",
expected_value, recv_payload[i+((SPP/2)*j)]);
`ASSERT_ERROR(recv_payload[i+((SPP/2)*j)] == expected_value, s);
end
end
end
?
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160609/7d8c6863/attachment-0001.html>
------------------------------
Message: 8
Date: Thu, 9 Jun 2016 22:54:15 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Filter Bank Specifications for E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
For those information, you should just look up the datasheets of the
minicircuits filter components we use. Their exact designation is in the
schematics.
Also note that this all happening on a single board, so if filter
suppression is above let's say >60dB, crosstalk effects come into play.
Best regards,
Marcus
On 09.06.2016 20:14, Zhongren Cao via USRP-users wrote:
> Hi,
>
> The E310/312 Data Sheet has a coarse illustration of the characteristics of
> the TX/RX front end filter banks, which only shows 6 dB of attenuation. Do
> you have a more detailed presentation, which shows detailed frequency vs.
> attenuation in the scale of 30-50 dB range?
>
> For example, for the RX FB-5 & FB-6, where is the cut-off? What?s the
> response in 2.1G, 2.5G, respectively?
>
> Thanks,
> Zhongren
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160609/0b481716/attachment-0001.html>
------------------------------
Message: 9
Date: Fri, 10 Jun 2016 03:06:07 +0000
From: Nick Foster <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] rfnoc-radio-redo DDC block test
Message-ID:
<CA+JMMq9tHuCg2B6PzGcQyLbXX8NJhXAPuZxmvvUN=zqyppx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Trying to get the gr-ettus/examples/rfnoc_ddc.grc example working, and
getting the following:
-- [RFNOC] ------- Block Setup -----------
-- SEND (SID: 00:1f>02:a0)...Setting up NoC-Shell Control for port #0 (SID:
00:1f>02:a0)...OK
-- Port 160: Found NoC-Block with ID DDC0000000000000.
-- base_path = "/home/nick/clabs/target/share/uhd/rfnoc"
-- Reading XML file: /home/nick/clabs/target/share/uhd/rfnoc/blocks/ddc.xml
-- SEND (SID: 00:20>02:a1)...Setting up NoC-Shell Control for port #1 (SID:
00:20>02:a1)...OK
-- [RFNoC Factory] block_ctrl_base::make()
-- base_path = "/home/nick/clabs/target/share/uhd/rfnoc"
-- Reading XML file: /home/nick/clabs/target/share/uhd/rfnoc/blocks/ddc.xml
-- [RFNoC Factory] Using controller key 'DDC' and block name 'DDC'
-- block_ctrl_base()
-- base_path = "/home/nick/clabs/target/share/uhd/rfnoc"
-- Reading XML file: /home/nick/clabs/target/share/uhd/rfnoc/blocks/ddc.xml
-- Found valid blockdef
-- NOC ID: 0xDDC0000000000000 Block ID: 0/DDC_0
-- [0/DDC_0] block_ctrl_base::clear()
-- node_ctrl_base::clear()
-- [0/DDC_0] block_ctrl_base::_clear()
-- [0/DDC_0] block_ctrl_base::_clear()
Traceback (most recent call last):
File "/home/nick/clabs/clabs_15/gr-ettus/examples/rfnoc/rfnoc_ddc.py",
line 281, in <module>
main()
File "/home/nick/clabs/clabs_15/gr-ettus/examples/rfnoc/rfnoc_ddc.py",
line 269, in main
tb = top_block_cls()
File "/home/nick/clabs/clabs_15/gr-ettus/examples/rfnoc/rfnoc_ddc.py",
line 66, in __init__
self.device3 = device3 = ettus.device3(uhd.device_addr_t(
",".join(("type=x300", "")) ))
File
"/home/nick/clabs/target/lib/python2.7/dist-packages/ettus/ettus_swig.py",
line 1855, in make
return _ettus_swig.device3_make(*args, **kwargs)
RuntimeError: EnvironmentError: IOError: [0/DDC_0] sr_read64() failed:
EnvironmentError: IOError: Radio ctrl (CE_07_Port_160) no response packet -
AssertionError: bool(buff)
in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
at
/home/nick/clabs/clabs_15/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:203
The DDC is a fairly complex block -- any ideas where to look for this one?
--n
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160610/0dc2fab6/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 10 Jun 2016 08:25:13 +0200
From: Patrick Berger <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Custom UHD Program terminate during
set_clock_ref
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Martin
No, there is actualy only one thread (the main app). All other stuff is removed.
Mhm, it could be that there is also the rfnoc version from uhd parallel to
version 3.9.1 on the system. Is there a proper way to remove all uhd stuff for
a clean reinstall, without to setup a clean linux?
Best regards
Patrick
> To: [email protected]
> Date: Thu, 9 Jun 2016 09:10:24 -0700
> Subject: Re: [USRP-users] Custom UHD Program terminate during set_clock_ref
> From: [email protected]
>
> My first guess is ABI mismatch. You're segfaulting when you mean to call
> usrp->set_clock_source(ref);, but your segfault happens in
> get_fe_rx_freq_range(). After that, all bets are off. I recommend
> checking the version you linked against is the version you're running.
>
> Also, do you have multiple threads in this app?
>
> M
>
>
> On 06/09/2016 06:58 AM, Patrick Berger via USRP-users wrote:
> > Hi
> >
> > I've managed to set breakpoints inside the function:
> >
> >
> > With a breakpoint on usrp->get_rx_freq() I could inspect the usrp pointer.
> > usrp @0x10148b0
> > uhd::usrp::multi_usrp::sptr
> > data @0x1015280
> > boost::shared_ptr<uhd::usrp::multi_usrp>::element_type
> > usecoutnt 1 int
> > weadkcount 1 int
> >
> > Checking the pointer against NULL is successful (so that isn't the problem).
> >
> > If I try to step over this function call the app crashes, or debuging is
> > terminated with following error message. Against my programming
> > expierence this indicates a bad pointer or something like this.
> > The inferior stopped because it received a signal from the Operating System.
> > Signal name: SIGSEGV
> > Signal meaning: Segmentation fault
> >
> > During stepping through the instruction code in the disassembler, I get
> > till the function _ZN15multi_usrp_impl14rx_chan_to_mcpEm:
> > Function: _ZN15multi_usrp_impl14rx_chan_to_mcpEm
> > 0x7f649e20a14c <+0x003c> movl $0x0,0x8(%rsp)
> > 0x7f649e20a154 <+0x0044> mov %rax,0x20(%rsp)
> > 0x7f649e20a159 <+0x0049> nopl 0x0(%rax)
> > 0x7f649e20a160 <+0x0050> mov (%r15),%rax
> > On the last line I get the segmentation fault! So I think there is
> > something inside the uhd library wrong (accessing protected memory).
> >
> > The stack view at the crash moment looks like this:
> > Level Function
> > 0 multi_usrp_impl::rx_chan_to_mcp(unsinged long)
> > 1 multi_usrp_impl::rx_rf_fe_roo(unsinged long)
> > 2 multi_usrp_impl::get_fe_rx_freq_range(unsigned long)
> > 3 USDP_SDR::Init_USRP
> > 4 main
> >
> > So there must be something wrong in the function *rx_chan_to_mcp*
> >
> > Platform is Linux Mint 17.2, IDE is Qt Creator, linked UHD version is
> > 3.9.1 (what I have to use for communicate also with matlab)
> >
> > Best regards
> > Patrick
> >
> >
> >> Date: Wed, 8 Jun 2016 09:28:45 -0700
> >> To: [email protected]
> >> Subject: Re: [USRP-users] Custom UHD Program terminate during
> > set_clock_ref
> >> From: [email protected]
> >> CC: [email protected]
> >>
> >> Patrick,
> >>
> >> Is 'ref' being properly set before it is called in
> > usrp->set_clock_source(ref) ? A simple sanity check is to print it out
> > before it is called:
> >>
> >> std::cout << boost::format("Lock mboard clocks: %f") % ref << std::endl;
> >> usrp->set_clock_source(ref);
> >>
> >>
> >> - Nate
> >>
> >> > On Jun 8, 2016, at 9:05 AM, Martin Braun via USRP-users
> > <[email protected]> wrote:
> >> >
> >> > Patrick,
> >> >
> >> > I have a hunch something is hiding some error message, and that error
> >> > message would clue us in. The last line ("Press Return") is coming from
> >> > where exactly? Is it your dev environment? Maybe there's a hidden
> >> > segfault there. GRC is a bit like that, too.
> >> >
> >> > M
> >> >
> >> > On 06/08/2016 12:17 AM, Patrick Berger via USRP-users wrote:
> >> >> Hi all
> >> >>
> >> >> I'm trying to create my own program to communicate with an X310 USRP.
> >> >> Host is Linux (Mint 17.2) with uhd version 3.9.1 and boost 1.57.0
> >> >>
> >> >> During the build process in Qt Creator I've no errors or warnings
> >> >> (libraries are all correct linked). The device is correctly found and
> >> >> the initialization with uhd::usrp::multi_usrp::make(dev_adr) works
> > also.
> >> >> In the second step I would set the mboard clocks, but there is
> > something
> >> >> going bad.
> >> >>
> >> >> This is my current code (cross-checked with rx_samples_to_file,
> >> >> rx_samples_to_udp, rx_ascii_art_dft):
> >> >> int USRP_SDR::Init_USRP()
> >> >> {
> >> >> //create a usrp device
> >> >> uhd::device_addr_t dev_adr;
> >> >> dev_adr.set("addr", addr);
> >> >> usrp = uhd::usrp::multi_usrp::make(dev_adr);
> >> >>
> >> >> std::cout << "Hallo1" << std::endl;
> >> >> //Lock mboard clocks
> >> >> usrp->set_clock_source(ref);
> >> >> std::cout << "Hallo2" << std::endl;
> >> >>
> >> >> //always select the subdevice first, the channel mapping affects the
> >> >> other settings
> >> >> if (vm.count("subdev")) usrp->set_rx_subdev_spec(subdev);
> >> >>
> >> >> std::cout << boost::format("Using Device: %s") %
> >> >> usrp->get_pp_string() << std::endl;
> >> >>
> >> >> //set the sample rate
> >> >> if (rate <= 0.0){
> >> >> std::cerr << "Please specify a valid sample rate" << std::endl;
> >> >> return 0;
> >> >> }
> >> >> std::cout << boost::format("Setting RX Rate: %f Msps...") %
> >> >> (rate/1e6) << std::endl;
> >> >> usrp->set_rx_rate(rate);
> >> >> std::cout << boost::format("Actual RX Rate: %f Msps...") %
> >> >> (usrp->get_rx_rate()/1e6) << std::endl << std::endl;
> >> >>
> >> >> return 1;
> >> >> }
> >> >>
> >> >> And this is the resulting terminal output (the Hello2 is missing, and
> >> >> also the rest of the initialization process):
> >> >> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.009.001-0-unknown
> >> >>
> >> >> UHD Warning:
> >> >> Unable to set the thread priority. Performance may be negatively
> >> >> affected.
> >> >> Please see the general application notes in the manual for
> > instructions.
> >> >> EnvironmentError: OSError: error in pthread_setschedparam
> >> >> -- X300 initialization sequence...
> >> >> -- Determining maximum frame size... 1472 bytes.
> >> >> -- Setup basic communication...
> >> >> -- Loading values from EEPROM...
> >> >> -- Setup RF frontend clocking...
> >> >> -- Radio 1x clock:200
> >> >> -- Initialize Radio0 control...
> >> >> -- Performing register loopback test... pass
> >> >> -- Initialize Radio1 control...
> >> >> -- Performing register loopback test... pass
> >> >> Hallo1
> >> >> Press <RETURN> to close this window...
> >> >>
> >> >> Does anyone see the fault?
> >> >>
> >> >> Best regards
> >> >> Patrick
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> USRP-users mailing list
> >> >> [email protected]
> >> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > USRP-users mailing list
> >> > [email protected]
> >> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>
> >>
> >> _______________________________________________
> >> USRP-users mailing list
> >> [email protected]
> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected]
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160610/539cc4bc/attachment-0001.html>
------------------------------
Message: 11
Date: Fri, 10 Jun 2016 12:46:21 +0000
From: "Swanson, Craig" <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: [USRP-users] Modelsim errors when running
noc_block_conv_encoder_qpsk_tb in rfnoc-radio-redo branch
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
?Jonathon,
Jonathon,
Here are the errors:
Model Technology ModelSim DE vlog 10.4c Compiler 2015.07 Jul 19 2015
Start time: 08:40:25 on Jun 10,2016
vlog -incr -sv -work work
"+define+WORKING_DIR=/home/craig/uhd/fpga-src/usrp3/lib/rfnoc/noc_block_conv_encoder_qpsk_tb"
"+incdir+../../../../../../radio" "+incdir+../../../../../"
"+incdir+../../../../../../../sim/general"
"+incdir+../../../../../../../sim/axi"
"+incdir+../../../../../../../sim/control"
"+incdir+../../../../../../../sim/rfnoc"
../../../../noc_block_conv_encoder_qpsk_tb.sv
** Error: ../../../../noc_block_conv_encoder_qpsk_tb.sv(10): Cannot find
`include file "sim_rfnoc_lib.vh" in directories:
../../../../../../radio, ../../../../../, ../../../../../../../sim/general,
../../../../../../../sim/axi, ../../../../../../../sim/control,
../../../../../../../sim/rfnoc
** Error: ../../../../noc_block_conv_encoder_qpsk_tb.sv(14): (vlog-2163) Macro
`RFNOC_SIM_INIT is undefined.
** Error: (vlog-13069) ../../../../noc_block_conv_encoder_qpsk_tb.sv(14): near
"(": syntax error, unexpected '('.
** Error: ../../../../noc_block_conv_encoder_qpsk_tb.sv(15): (vlog-2163) Macro
`RFNOC_ADD_BLOCK is undefined.
** Error: ../../../../noc_block_conv_encoder_qpsk_tb.sv(47): (vlog-2730)
Undefined variable: 'bus_rst'.
** Error: ../../../../noc_block_conv_encoder_qpsk_tb.sv(47): (vlog-2730)
Undefined variable: 'bus_clk'.
** Error: ../../../../noc_block_conv_encoder_qpsk_tb.sv(48): (vlog-2730)
Undefined variable: 'ce_rst'.
** Error: ../../../../noc_block_conv_encoder_qpsk_tb.sv(48): (vlog-2730)
Undefined variable: 'ce_clk'.
** Error: ../../../../noc_block_conv_encoder_qpsk_tb.sv(64): (vlog-2730)
Undefined variable: 'bus_rst'.
** Error: ../../../../noc_block_conv_encoder_qpsk_tb.sv(64): (vlog-2730)
Undefined variable: 'bus_clk'.
** Error: ../../../../noc_block_conv_encoder_qpsk_tb.sv(65): (vlog-2730)
Undefined variable: 'ce_rst'.
** Error: ../../../../noc_block_conv_encoder_qpsk_tb.sv(65): (vlog-2730)
Undefined variable: 'ce_clk'.
** Error: ../../../../noc_block_conv_encoder_qpsk_tb.sv(70): (vlog-2163) Macro
`RFNOC_CONNECT is undefined.
** Error: (vlog-13069) ../../../../noc_block_conv_encoder_qpsk_tb.sv(70): near
"(": syntax error, unexpected '('.
** Error: ../../../../noc_block_conv_encoder_qpsk_tb.sv(71): (vlog-2163) Macro
`RFNOC_CONNECT is undefined.
** Error: ../../../../noc_block_conv_encoder_qpsk_tb.sv(76): (vlog-2730)
Undefined variable: 'header'.
?Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160610/0af0a272/attachment-0001.html>
------------------------------
Message: 12
Date: Fri, 10 Jun 2016 13:01:03 +0000
From: "Swanson, Craig" <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: [USRP-users] Error when running noc_block_fir_filter_tb in
Modelsim in rfnoc-radio-redo branch : cannot open wave.do file
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Jonathon,
When I run the simulation, it gets far enough to open Modelsim but errors out
here:
Time: 0 ps Iteration: 0 Instance:
/noc_block_fir_filter_tb/noc_block_fir_filter/inst_axi_round_and_clip/split
File: ../../../../../split_complex.v
# ** Warning: (vsim-3722) ../../../../../axi_round_and_clip_complex.v(20):
[TFMPC] - Missing connection for port 'error'.
# ** Warning: (vsim-3017) ../../../../../axi_round_and_clip_complex.v(35):
[TFMPC] - Too few port connections. Expected 13, found 12.
# Time: 0 ps Iteration: 0 Instance:
/noc_block_fir_filter_tb/noc_block_fir_filter/inst_axi_round_and_clip/join_complex
File: ../../../../../join_complex.v
# ** Warning: (vsim-3722) ../../../../../axi_round_and_clip_complex.v(35):
[TFMPC] - Missing connection for port 'error'.
# .main_pane.wave.interior.cs.body.pw.wf
# .main_pane.structure.interior.cs.body.struct
# .main_pane.objects.interior.cs.body.tree
# ** Error: Cannot open macro file:
/home/craig/uhd/fpga-src/usrp3/lib/rfnoc/noc_block_fir_filter_tb/wave.do
# Error in macro ./noc_block_fir_filter_tb_simulate.do line 19
# Cannot open macro file:
/home/craig/uhd/fpga-src/usrp3/lib/rfnoc/noc_block_fir_filter_tb/wave.do
# while executing
# "do
{/home/craig/uhd/fpga-src/usrp3/lib/rfnoc/noc_block_fir_filter_tb/wave.do}"
?Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160610/dfecd3a2/attachment-0001.html>
------------------------------
Message: 13
Date: Fri, 10 Jun 2016 16:46:49 +0200
From: Marcus M?ller <[email protected]>
To: ???? <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] ??RE: B210 not recognized over USB 3 in
Windows 7
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Roy,
I'll have to ask specifically for make and model. Not all xHCI are made
equal :/
Best regards,
Marcus
On 08.06.2016 14:47, ???? wrote:
> Hi Marcus,
>
> Thanks for the prompt response.
> The USB 3 host controller is xHCI, and the USB 2 host controller is EHCI.
>
> Thanks,
> Roy
> ------------------------------------------------------------------------
> *?:*??USRP-users ?[[email protected]]? ??? Marcus
> M?ller via USRP-users ?[[email protected]]?
> *??????:* ??? ????? 08 ???? 2016 12:34
> *
> *????:* [email protected]
> **
> *??????:* Re: [USRP-users] B210 not recognized over USB 3 in Windows 7
> *
>
> Hello Roy,
>
> which USB host controller are you using?
> We know that some work better than others, and some even don't work at
> all with our absolutely normal USB3 devices.
> The problem here is that UHD itself is not involved at all in the
> decision whether the connection is a USB3 or USB2 connection; it just
> uses libUSB / winUSB to request a device handle, and get and send USB
> bulk data packets. The driver you have to install under windows is not
> made by us ? it's just the generic "this is a bulk device, so just
> give the USB packets to user programs" driver.
> What can be an issue, however, is that for signal integrity reasons,
> devices work more reliably when first connected to external power and
> then to the USB port; however, I've only seen voltage drops on the USB
> bus disturb running operation, not a USB3->USB2 "downgrade" so far.
>
> Best regards,
> Marcus
>
> On 08.06.2016 10:21, ???? via USRP-users wrote:
>> Hi,
>>
>> I'm having trouble working with the B210 on computers with USB 3
>> ports and Windows 7 operating system.
>> To be more precise, I tried working with two computers and had a
>> slightly different problem with each one.
>> On both computers I've downloaded winusb and UHD drivers
>> from http://files.ettus.com/binaries/.
>>
>> * Computer 1: When I connect the B210 to a USB 3 port, the hardware
>> is detected ("Ettus Research LLC B200/B210" in device manager).
>> However, when running "uhd_find_devices" I get "No UHD Device
>> Found". It should be mentioned that when switching to a USB 2
>> port, the device is found.
>> * Computer 2: Hardware is detected and device is found, but when
>> running an example program like "rx_samples_to_file" the UI
>> prints "Operating over USB 2", although the ports is USB 3 SS.
>>
>> Is there something extra required for working over USB 3 connection
>> in Windows?
>>
>> Best regards,
>> Roy
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160610/8d8f4223/attachment-0001.html>
------------------------------
Message: 14
Date: Fri, 10 Jun 2016 15:37:48 +0000 (UTC)
From: [email protected]
To: usrp-users <[email protected]>
Subject: [USRP-users] Knowledge Base
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Just wanted to say that I have been poking around the knowledge base the past
few days and it is great!!!
The organization is well done and having links to all the components within a
particular product is super awesome!!!
*2 Thumbs Up*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160610/15b1a9db/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 70, Issue 10
******************************************
