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: S printouts and then either U printouts (and fails/stops
transmitting) or seg fault with 4 USRPs (Pavan Yedavalli)
2. Re: Sampling with more than 50 MSps on N210 (Martin Braun)
3. Re: S printouts and then either U printouts (and fails/stops
transmitting) or seg fault with 4 USRPs ([email protected])
4. Re: Creating a custom RFNoC Block (El Ouni, Naceur (IntlAssoc))
5. Connecting B210 to UE emulator via cable (Dario Fertonani)
6. Re: S printouts and then either U printouts (and fails/stops
transmitting) or seg fault with 4 USRPs (Pavan Yedavalli)
7. Re: Connecting B210 to UE emulator via cable ([email protected])
8. Amarisoft using X310 as eNB, uhd error
(El Ouni, Naceur (IntlAssoc))
9. RFNoC gr-ettus rfnoc_fosphor not showing anything
(El Ouni, Naceur (IntlAssoc))
10. Re: S printouts and then either U printouts (and fails/stops
transmitting) or seg fault with 4 USRPs (Marcus M?ller)
11. Re: RFNoC gr-ettus rfnoc_fosphor not showing anything
([email protected])
12. Single radio implementation in rfnoc-radio-redo fails
uhd_usrp_probe (Swanson, Craig)
13. Re: RFNoC gr-ettus rfnoc_fosphor not showing anything
(El Ouni, Naceur (IntlAssoc))
14. Re: N200 RX center frequency changes ignored (Francisco Albani)
15. Re: S printouts and then either U printouts (and fails/stops
transmitting) or seg fault with 4 USRPs (Pavan Yedavalli)
16. Re: S printouts and then either U printouts (and fails/stops
transmitting) or seg fault with 4 USRPs (Marcus M?ller)
17. Re: RFNoC gr-ettus rfnoc_fosphor not showing anything
(Dave NotTelling)
18. Re: RFNoC gr-ettus rfnoc_fosphor not showing anything
([email protected])
19. Burning USRP N210 EEPROM with DHCP configuration (Pavan Yedavalli)
20. Re: Burning USRP N210 EEPROM with DHCP configuration (Matt Ettus)
21. Re: Burning USRP N210 EEPROM with DHCP configuration
(Pavan Yedavalli)
22. Re: Burning USRP N210 EEPROM with DHCP configuration
(Marcus D. Leech)
23. Re: S printouts and then either U printouts (and fails/stops
transmitting) or seg fault with 4 USRPs (Pavan Yedavalli)
24. Re: Amarisoft using X310 as eNB, uhd error (Lin HUANG)
25. Re: RFNoC gr-ettus rfnoc_fosphor not showing anything
(Sylvain Munaut)
26. Re: Single radio implementation in rfnoc-radio-redo fails
uhd_usrp_probe (Jonathon Pendlum)
27. Re: RFNoC Installation Problems (Jonathon Pendlum)
28. benchmark (Samy CHBINOU)
29. Re: Single radio implementation in rfnoc-radio-redo fails
uhd_usrp_probe (Swanson, Craig)
30. Re: benchmark ([email protected])
31. RFNoC Stream Tags (Sam Carey)
32. Re: RFNoC Stream Tags (Marcus M?ller)
----------------------------------------------------------------------
Message: 1
Date: Thu, 23 Jun 2016 09:40:37 -0700
From: Pavan Yedavalli <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] S printouts and then either U printouts (and
fails/stops transmitting) or seg fault with 4 USRPs
Message-ID:
<CACaX0_MichHdTA=n7y=gbh9j3kpltm-fkk9he3gvxasi+el...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Marcus,
Thanks for getting back to me. The following is the setup:
I have a Lenovo X1 Carbon with 7.6 GB of memory, Intel Core i7-4600U CPU @
2.10 GHz x 4, with a 32-bit OS and I believe 200 GB HD. I am using 4 USRP
N210s.
This laptop does *NOT* have an ethernet port built in - instead, I need to
use this adapter
<http://shop.lenovo.com/ae/en/itemdetails/4X90F84315/460/34285E7D99BB43138551449AD7C986A5>,
which I then connect to this TP-Link 8-Port Gigabit Ethernet switch
<https://www.amazon.com/TP-LINK-Gigabit-Ethernet-Desktop-TL-SG108/dp/B00A121WN6/186-5052592-5933742?ie=UTF8&keywords=gigabit%20ethernet%20switch&qid=1456432852&ref_=sr_1_3&sr=8-3>
.
>From here, I connect all 4 USRPs to the switch. To be more specific though,
I connect one USRP (master) directly to the switch, with another connected
via MIMO cable to that master USRP. Then, I connect two more directly to
the switch. I could change this configuration so that all 4, instead of 3,
are connected directly to the switch, but I had a MIMO cable, so I decided
to use it. All of the USRP N210s are connected to the same computer via
this switch and adapter.
I tried with just a simple flow graph sending a single tone with all 4
USRPs, as mentioned, and S appears almost immediately then too, but it
seems to stop after a bit and continues to transmit, with Us not appearing.
Once I use my block though, Ss and Us appear almost immediately and
everything halts.
Attached is probably a not so helpful image of the connection, but just to
get an idea.
--
Pavan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160623/c29cf64e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IMG_1849.PNG
Type: image/png
Size: 1919511 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160623/c29cf64e/attachment-0001.PNG>
------------------------------
Message: 2
Date: Thu, 23 Jun 2016 09:45:05 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Sampling with more than 50 MSps on N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
See the recent thread titled 'Size of TX Buffer on N210'.
M
On 06/23/2016 02:50 AM, Vladica Sark via USRP-users wrote:
> An BTW, is there a way to see the state of the buffer memory in the
> N210, before putting a new transmit burst in it? Just not to overfill it.
>
> BR,
> Vladica
>
>
> On 23.06.2016 11:21, Marcus M?ller via USRP-users wrote:
>> Hi Vladica,
>>
>> out of the box, this will be hard; I haven't checked if this actually
>> works, but I slightly doubt it ? the limiting factor is that you can't
>> pre-buffer that much on an N210, and that would limit the durations of
>> your bursts severely.
>>
>> On a different note: what's your use case? Aside from the filterless
>> BasicRX/TX, all daughterboards for the N210 have at most 40 MHz of
>> analog bandwidth - hence, your undecimated 100MS/s stream would carry no
>> more information than the same stream at 50MS/s.
>>
>> Best regards,
>> Marcus
>>
>> On 23.06.2016 11:04, Vladica Sark via USRP-users wrote:
>>> Hi folks,
>>>
>>> I was thinking if it is possible to sample with more than 50 MSps
>>> (i.e. 100 MSps) on the N210. I know the Gbit Ethernet is the
>>> bottleneck, but if I want to transmit only short bursts, and receive
>>> short bursts, it won't be a bottleneck anymore. For example, in a TDD
>>> mode, where I transmit 50 % of the time and I receive 50 % of the
>>> time, with 8 bit samples, and sample rate of 100 MSps, the Ethernet
>>> throughput would be exactly 1 Gbps in the both directions.
>>>
>>> Is this supported by UHD and the firmware?
>>>
>>> BR,
>>> Vladica
>>>
>>> _______________________________________________
>>> 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: 3
Date: Thu, 23 Jun 2016 12:51:47 -0400
From: [email protected]
To: Pavan Yedavalli <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] S printouts and then either U printouts (and
fails/stops transmitting) or seg fault with 4 USRPs
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
USB-to-1GiGe devices often have two serious problems:
(1) They re-order packets--this is fatal to a streaming UDP protocol
such as used by UHD
(2) They cannot possibly (for USB-2.0) support a 1GiGe average
throughput.
On 2016-06-23 12:40, Pavan Yedavalli via USRP-users wrote:
> Hi Marcus,
>
> Thanks for getting back to me. The following is the setup:
>
> I have a Lenovo X1 Carbon with 7.6 GB of memory, Intel Core i7-4600U CPU @
> 2.10 GHz x 4, with a 32-bit OS and I believe 200 GB HD. I am using 4 USRP
> N210s.
>
> This laptop does _NOT_ have an ethernet port built in - instead, I need to
> use this adapter [1], which I then connect to this TP-Link 8-Port Gigabit
> Ethernet switch [2].
>
> From here, I connect all 4 USRPs to the switch. To be more specific though, I
> connect one USRP (master) directly to the switch, with another connected via
> MIMO cable to that master USRP. Then, I connect two more directly to the
> switch. I could change this configuration so that all 4, instead of 3, are
> connected directly to the switch, but I had a MIMO cable, so I decided to use
> it. All of the USRP N210s are connected to the same computer via this switch
> and adapter.
>
> I tried with just a simple flow graph sending a single tone with all 4 USRPs,
> as mentioned, and S appears almost immediately then too, but it seems to stop
> after a bit and continues to transmit, with Us not appearing. Once I use my
> block though, Ss and Us appear almost immediately and everything halts.
>
> Attached is probably a not so helpful image of the connection, but just to
> get an idea.
> --
>
> Pavan
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Links:
------
[1]
http://shop.lenovo.com/ae/en/itemdetails/4X90F84315/460/34285E7D99BB43138551449AD7C986A5
[2]
https://www.amazon.com/TP-LINK-Gigabit-Ethernet-Desktop-TL-SG108/dp/B00A121WN6/186-5052592-5933742?ie=UTF8&keywords=gigabit%20ethernet%20switch&qid=1456432852&ref_=sr_1_3&sr=8-3
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160623/1ee1b4b8/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 23 Jun 2016 16:43:51 +0000
From: "El Ouni, Naceur (IntlAssoc)" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Creating a custom RFNoC Block
Message-ID:
<sn1pr09mb0925cbf9638ca4e1568445b59e...@sn1pr09mb0925.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
From: El Ouni, Naceur (IntlAssoc)
Sent: Thursday, June 23, 2016 12:41 PM
To: '[email protected]' <[email protected]>
Subject: Creating a custom RFNoC Block
Hello,
I am developping an RFNoC Block that receives N-vectors output from the RFNoC
FFT block and giving NBR_BINS param that it reads from Software
It bins those N vectors into NBR_BINS to output.
What I have done so far is develop:
* grc bindings and gr-ettus implemenation files:
gr-ettus/lib/rfnoc_bin_aggr_impl.cc
gr-ettus/lib/rfnoc_bin_aggr_impl.h
gr-ettus/Include/ettus/rfnoc_bin_aggr.h
gr-ettus/grc/uhd_rfnoc_bin_aggr.xml
* UHD block controller:
uhd/host/lib/rfnoc/bin_aggr_block_ctrl_impl.cpp
uhd/host/include/uhd/rfnoc/bin_aggr_block_ctrl_impl.hpp
uhd/host/include/uhd/rfnoc/blocks/bin_aggr.xml
* Verilog implementation files:
noc_block_bin_aggr.v
bin_aggr.v
And of course I modified accordingly: usrp3/top/x300/rfnoc_ce_auto_inst_x310.v
and usrp3/lib/rfnoc/Makefile.srcs
>From the gr-ettus xml file, I get the fft_size (my input vlen) nbr_bins (my
>output vlen) as params which I use in the make of
>ettus.rfnoc_bin_aggr($fft_size,$nbr_bins,...).
In gr-ettus/lib/rfnoc_bin_aggr_impl.cc, I call the contructor which I think
calls the bin_aggr_block_ctrl_impl of uhd.
There I call a function "set_bin_index" that creates a vector of indeces
"output_bin_index" needed later on in the verilog file.
void set_bin_index(const int fft_size, const int nbr_bins, const int
samp_rate, const int center_freq, const int bandwidth, const int channel_bw)
{
UHD_RFNOC_BLOCK_TRACE() << "bin_aggr_block::set_bin_index()" <<
std::endl;
float _start_freq = center_freq - bandwidth / 2.0;
float _stop_freq = _start_freq + bandwidth;
std::vector<unsigned int> _output_bin_index(fft_size,0);
std::cout << "fft_size = " << fft_size << std::endl;
float hz_per_bin = samp_rate / fft_size;
std::cout << "hz_per_bin= " << hz_per_bin << std::endl;
for (int j=0; j < fft_size; j++)
{
float fj = center_freq + hz_per_bin * (j - int(fft_size / 2)
- (int(fft_size) % 2));
std::cout << "fj[" << j << "]= "<< fj << std::endl;
if ((fj >= _start_freq) && (fj < _stop_freq))
{
unsigned int _channel_num = (floor((fj - _start_freq)
/ channel_bw)) + 1;
_output_bin_index[j] = _channel_num;
// Write bin indeces via the BIN_INDEX bus
UHD_MSG(status) << "output_bin_index[" << j << "]= "
<< _output_bin_index[j] << std::endl;
sr_write(AXIS_BIN_INDEX,
boost::uint32_t(_output_bin_index[j]));
// Assert tlast when sending the last index
sr_write(AXIS_BIN_INDEX_TLAST,
boost::uint32_t(_output_bin_index.back()));
sr_write(SR_FFT_SIZE, fft_size);
sr_write(SR_NBR_BINS, nbr_bins);
}
}
}
In the header of this block ctrl I do:
static const boost::uint32_t SR_FFT_SIZE = 131;
// Note: AXI config bus uses 129 & 130
static const boost::uint32_t SR_NBR_BINS = 132;
// Note: AXI config bus uses 129 & 130
static const boost::uint32_t AXIS_BIN_INDEX =
AXIS_CONFIG_BUS+0; // 2*0+0
static const boost::uint32_t AXIS_BIN_INDEX_TLAST = AXIS_CONFIG_BUS+1; //
2*0+1
noc_block_bin_aggr.v:
// AXI Wrapper
localparam NUM_AXI_CONFIG_BUS = 1;
....
//wire [FFT_SIZE:0] m_axis_config_tdata;
wire [31:0] m_axis_config_tdata; // should this be a wire of
[SR_FFT_SIZE-1:0] instead but the max len is 64 ?
wire m_axis_config_tvalid;
wire m_axis_config_tready;
...
.m_axis_config_tdata(m_axis_config_tdata),
.m_axis_config_tlast(m_axis_config_tlast),
.m_axis_config_tvalid(m_axis_config_tvalid),
.m_axis_config_tready(m_axis_config_tready));
// User code
...
localparam SR_FFT_SIZE = 131; // Note: AXI config bus in AXI wrapper
uses 129 & 130
localparam SR_NBR_BINS = 132;
bin_aggr #(
.SR_FFT_SIZE(SR_FFT_SIZE),
.SR_NBR_BINS(SR_NBR_BINS))
inst_bin_aggr (
.clk(ce_clk), .reset(ce_rst), //.clear(1'b0),
.m_axis_bin_index_tdata(m_axis_config_tdata[31:0]), //have to be 32 or
64 max len ??
.m_axis_bin_index_tlast(m_axis_config_tlast),
.m_axis_bin_index_tvalid(m_axis_config_tvalid),
.m_axis_bin_index_tready(m_axis_config_tready),
....
bin_aggr.v:
....
integer i;
initial begin
for (i=0; i<SR_FFT_SIZE; i=i+1)
begin
$display("m_axis_bin_index_tdata[i] = %d",
m_axis_bin_index_tdata[i]);
end
end
genvar _k;
generate
for (_k=0; _k<SR_FFT_SIZE; _k=_k+1)
always @(posedge clk)
begin
if (i_tvalid & i_tready & i_tlast &
((m_axis_bin_index_tdata[_k] > 0) && (m_axis_bin_index_tdata[_k] <=
SR_NBR_BINS)))
begin
out[SR_NBR_BINS +
m_axis_bin_index_tdata[_k] - 1] <= out[SR_NBR_BINS + m_axis_bin_index_tdata[_k]
- 1] + i_tdata[SR_FFT_SIZE + _k];
end
end
endgenerate
assign o_tdata = out; //FIXME
assign i_tready = o_tready;
assign o_tvalid = i_tvalid;
assign o_tlast = i_tlast;
First of all: the display command in verilog to check whether the vector is
being passed correctly is not executed even though at the software level the
verbose UHD_RFNOC_BLOCK_TRACE() is giving the expected values at console.
Please let me know if you need to know any other parts of my code and also let
me know what am I doing wrong in my Verilog/cpp code.
Thanks and Regards,
Naceur El Ouni
NIST - Wireless Networks Division (673)
100 Bureau Dr. Building 222-A218
Gaithersburg, MD 20899
(301) 975-3353
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160623/50e459bd/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 23 Jun 2016 09:52:25 -0700
From: Dario Fertonani <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Connecting B210 to UE emulator via cable
Message-ID:
<cajgedajdpmwnvj17w5opbz-yfouoatohma_yb8wjrxd1zau...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Any special caution needed for cabled connection between B210 and UE
emulators or other similar devices?
I'm assuming some sort of attenuator is needed to avoid frying the devices.
Any spec I should look at, besides the max power safely receivable by each
device?
Thanks,
Dario
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160623/e77d8d8a/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 23 Jun 2016 09:57:16 -0700
From: Pavan Yedavalli <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] S printouts and then either U printouts (and
fails/stops transmitting) or seg fault with 4 USRPs
Message-ID:
<CACaX0_MVWyP3qy+34zDii4Fc_Hu8=Quj=hne1byq8j1clic...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hmm, okay. Well, those are very serious. An alternative I have is to try a
desktop and try to connect the switch to the desktop's ethernet port and
connect the USRPs to the switch. Of course, I will have to configure the
desktop with Ubuntu and installing gnuradio and all of that, but I guess
that might be worth it? Trying to avoid the USB-to-1GiGe devices will
probably help in the long run?
On Thu, Jun 23, 2016 at 9:51 AM, <[email protected]> wrote:
> USB-to-1GiGe devices often have two serious problems:
>
> (1) They re-order packets--this is fatal to a streaming UDP protocol such
> as used by UHD
>
> (2) They cannot possibly (for USB-2.0) support a 1GiGe average throughput.
>
>
>
>
>
>
> On 2016-06-23 12:40, Pavan Yedavalli via USRP-users wrote:
>
> Hi Marcus,
>
> Thanks for getting back to me. The following is the setup:
>
> I have a Lenovo X1 Carbon with 7.6 GB of memory, Intel Core i7-4600U CPU @
> 2.10 GHz x 4, with a 32-bit OS and I believe 200 GB HD. I am using 4 USRP
> N210s.
>
> This laptop does *NOT* have an ethernet port built in - instead, I need
> to use this adapter
> <http://shop.lenovo.com/ae/en/itemdetails/4X90F84315/460/34285E7D99BB43138551449AD7C986A5>,
> which I then connect to this TP-Link 8-Port Gigabit Ethernet switch
> <https://www.amazon.com/TP-LINK-Gigabit-Ethernet-Desktop-TL-SG108/dp/B00A121WN6/186-5052592-5933742?ie=UTF8&keywords=gigabit%20ethernet%20switch&qid=1456432852&ref_=sr_1_3&sr=8-3>
> .
>
> From here, I connect all 4 USRPs to the switch. To be more specific
> though, I connect one USRP (master) directly to the switch, with another
> connected via MIMO cable to that master USRP. Then, I connect two more
> directly to the switch. I could change this configuration so that all 4,
> instead of 3, are connected directly to the switch, but I had a MIMO cable,
> so I decided to use it. All of the USRP N210s are connected to the same
> computer via this switch and adapter.
>
> I tried with just a simple flow graph sending a single tone with all 4
> USRPs, as mentioned, and S appears almost immediately then too, but it
> seems to stop after a bit and continues to transmit, with Us not appearing.
> Once I use my block though, Ss and Us appear almost immediately and
> everything halts.
>
> Attached is probably a not so helpful image of the connection, but just to
> get an idea.
>
> --
> Pavan
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
--
Pavan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160623/32593507/attachment-0001.html>
------------------------------
Message: 7
Date: Thu, 23 Jun 2016 12:59:05 -0400
From: [email protected]
To: Dario Fertonani <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Connecting B210 to UE emulator via cable
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
What is the max power output of the UE? Once you know that, and the
recommended -15dBm max input level of the USRP, you can calculate what
the minimum attenuation is that you need, although, I'd err on the side
of caution, and add another 15dB of attenuation.
On 2016-06-23 12:52, Dario Fertonani via USRP-users wrote:
> Any special caution needed for cabled connection between B210 and UE
> emulators or other similar devices?
>
> I'm assuming some sort of attenuator is needed to avoid frying the devices.
> Any spec I should look at, besides the max power safely receivable by each
> device?
>
> Thanks,
> Dario
> _______________________________________________
> 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/20160623/386b9514/attachment-0001.html>
------------------------------
Message: 8
Date: Thu, 23 Jun 2016 18:15:00 +0000
From: "El Ouni, Naceur (IntlAssoc)" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Amarisoft using X310 as eNB, uhd error
Message-ID:
<sn1pr09mb09256598a5bb15f3785b5b5d9e...@sn1pr09mb0925.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Hello usrp-users,
We have purchased an Amarisoft LTE license. It is working ok with the USRP N210.
However when I tried to run it with X310. I've been getting a trx_uhd_read:
error code = 0x1
lteenb version: 2015-01-20
OS: Ubuntu 14.04
UHD version: 003.007.000-0-g7fef199d
Mboard: X310
revision: 6
FW Version: 3.0
FPGA Version: 3.0
Daughterboard: SBX v5
Output of lteenb:
This software is licensed to NIST.
linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.007.000-0-g7fef199d
UHD: X300 initialization sequence...
UHD: Determining maximum frame size... UHD: 1472 bytes.
UHD: Setup basic communication...
UHD: Loading values from EEPROM...
UHD: Setup RF frontend clocking...
UHD: Radio 1x clock:184.32
UHD: Initialize Radio control...
UHD: Performing register loopback test... UHD: pass
UHD: Sync DAC's.
UHD: Performing register loopback test... UHD: pass
UHD: Sync DAC's.
UHD: Setting references to internal sources
sample_rate=11.520 MHz
RF0: dl_freq=2600.000 MHz ul_freq=2600.000 MHz (band 38) dl_ant=1 ul_ant=1
(enb) UHD: Loaded /home/nae/.uhd/cal/rx_iq_cal_v0.2_F554CC.csv
Chan Gain(dB) Freq(MHz)
TX1 15.0 2600.000000
RX1 20.0 2600.000000
UHD: 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
trx_uhd_read: error code = 0x1
PS: I already adapted all the configuration values to meet X310like:
"addr=192.168.10.2,send_frame_size=3972,recv_frame_size=3972,master_clock_rate=184.32e6,system_clock_rate=10e6",
n_rb_dl set to 50 fto monitor the 10MHz
I also tried to monitor the 5MHz LTE (and adapted the config file accordingly,
sample_rate: 5.76, n_rb_dl : 25, send/recv_frame_size=2000)
And the same way I tried also for 20MHz I am always getting that same
trx_uhd_read: error code = 0x1 error.
Did anyone ever encountered this type of error ?
Thanks and Regards,
Naceur El Ouni
NIST - Wireless Networks Division (673)
100 Bureau Dr. Building 222-A218
Gaithersburg, MD 20899
(301) 975-3353
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160623/10435357/attachment-0001.html>
------------------------------
Message: 9
Date: Thu, 23 Jun 2016 18:19:04 +0000
From: "El Ouni, Naceur (IntlAssoc)" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] RFNoC gr-ettus rfnoc_fosphor not showing
anything
Message-ID:
<sn1pr09mb09250200ca7e294c50276d0e9e...@sn1pr09mb0925.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Hello usrp-users,
I have tried to run the gr-ettus's example rfnoc_fosphor and on execute I get:
QPainter::begin: Paint device returned engine == 0, type: 2
QPainter::setPen: Painter not active
QPainter::setFont: Painter not active
Whatever I did to tweak the code (gr-ettus/lib/QFosphorSurface.cc) and
recompile to avoid having a null image:
The result is always the same, nothing show up
I am using:
Ubuntu 14.04, USRP X310,
GNU C++ version 4.8.4; Boost_105400; UHD_003.010.rfnoc-300-g74d178b5
gnuradio version: 3.7.10git-47-gbd69c31e
Thanks and Regards,
Naceur El Ouni
NIST - Wireless Networks Division (673)
100 Bureau Dr. Building 222-A218
Gaithersburg, MD 20899
(301) 975-3353
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160623/05c5b7f1/attachment-0001.html>
------------------------------
Message: 10
Date: Thu, 23 Jun 2016 20:23:41 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] S printouts and then either U printouts (and
fails/stops transmitting) or seg fault with 4 USRPs
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Pavan,
> Trying to avoid the USB-to-1GiGe devices will probably help in the
> long run?
Indeed. From a CPU perspective, handling much network data over USB is
also pretty undesirable.
For desktop PCs, Gigabit Ethernet network cards are cheap, and you even
get cards with multiple interfaces. If you channel all data through a
single Gigabit ethernet line, that will be saturated before the
cumulative rate of all RX or all TX streams reach 1Gb/s; ie. if using
four USRPs at the same sampling rate, you can't possibly do more than
100MS/s/14 ~= 7.14MS/s per USRP, under perfect circumstances. I'd rather
assume that 100MS/s / 16 would be what's actually possible.
Best regards,
Marcus
On 23.06.2016 18:57, Pavan Yedavalli via USRP-users wrote:
> Hmm, okay. Well, those are very serious. An alternative I have is to
> try a desktop and try to connect the switch to the desktop's ethernet
> port and connect the USRPs to the switch. Of course, I will have to
> configure the desktop with Ubuntu and installing gnuradio and all of
> that, but I guess that might be worth it? Trying to avoid the
> USB-to-1GiGe devices will probably help in the long run?
>
> On Thu, Jun 23, 2016 at 9:51 AM, <[email protected]
> <mailto:[email protected]>> wrote:
>
> USB-to-1GiGe devices often have two serious problems:
>
> (1) They re-order packets--this is fatal to a streaming UDP
> protocol such as used by UHD
>
> (2) They cannot possibly (for USB-2.0) support a 1GiGe average
> throughput.
>
>
>
>
>
>
>
> On 2016-06-23 12:40, Pavan Yedavalli via USRP-users wrote:
>
>> Hi Marcus,
>>
>> Thanks for getting back to me. The following is the setup:
>>
>> I have a Lenovo X1 Carbon with 7.6 GB of memory, Intel Core
>> i7-4600U CPU @ 2.10 GHz x 4, with a 32-bit OS and I believe 200
>> GB HD. I am using 4 USRP N210s.
>>
>> This laptop does /NOT/ have an ethernet port built in - instead,
>> I need to use this adapter
>>
>> <http://shop.lenovo.com/ae/en/itemdetails/4X90F84315/460/34285E7D99BB43138551449AD7C986A5>,
>> which I then connect to this TP-Link 8-Port Gigabit Ethernet
>> switch
>>
>> <https://www.amazon.com/TP-LINK-Gigabit-Ethernet-Desktop-TL-SG108/dp/B00A121WN6/186-5052592-5933742?ie=UTF8&keywords=gigabit%20ethernet%20switch&qid=1456432852&ref_=sr_1_3&sr=8-3>.
>>
>> From here, I connect all 4 USRPs to the switch. To be more
>> specific though, I connect one USRP (master) directly to the
>> switch, with another connected via MIMO cable to that master
>> USRP. Then, I connect two more directly to the switch. I could
>> change this configuration so that all 4, instead of 3, are
>> connected directly to the switch, but I had a MIMO cable, so I
>> decided to use it. All of the USRP N210s are connected to the
>> same computer via this switch and adapter.
>>
>> I tried with just a simple flow graph sending a single tone with
>> all 4 USRPs, as mentioned, and S appears almost immediately then
>> too, but it seems to stop after a bit and continues to transmit,
>> with Us not appearing. Once I use my block though, Ss and Us
>> appear almost immediately and everything halts.
>>
>> Attached is probably a not so helpful image of the connection,
>> but just to get an idea.
>>
>> --
>> Pavan
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> --
> Pavan
>
>
> _______________________________________________
> 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/20160623/7f0f0d5e/attachment-0001.html>
------------------------------
Message: 11
Date: Thu, 23 Jun 2016 14:40:00 -0400
From: [email protected]
To: "El Ouni, Naceur (IntlAssoc)" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] RFNoC gr-ettus rfnoc_fosphor not showing
anything
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Are you doing this from wihin a VM, or on a native Linux box?
On 2016-06-23 14:19, El Ouni, Naceur (IntlAssoc) via USRP-users wrote:
> Hello usrp-users,
>
> I have tried to run the gr-ettus's example rfnoc_fosphor and on execute I
> get:
>
> QPainter::begin: Paint device returned engine == 0, type: 2
> QPainter::setPen: Painter not active
> QPainter::setFont: Painter not active
>
> Whatever I did to tweak the code (gr-ettus/lib/QFosphorSurface.cc) and
> recompile to avoid having a null image:
> The result is always the same, nothing show up
>
> I am using:
>
> Ubuntu 14.04, USRP X310,
> GNU C++ version 4.8.4; Boost_105400; UHD_003.010.rfnoc-300-g74d178b5
> gnuradio version: 3.7.10git-47-gbd69c31e
>
> Thanks and Regards,
>
> Naceur El Ouni
>
> NIST - Wireless Networks Division (673)
>
> 100 Bureau Dr. Building 222-A218
>
> Gaithersburg, MD 20899
>
> (301) 975-3353
>
> _______________________________________________
> 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/20160623/766073ff/attachment-0001.html>
------------------------------
Message: 12
Date: Thu, 23 Jun 2016 20:02:35 +0000
From: "Swanson, Craig" <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: Marcus M?ller <[email protected]>, Martin Braun
<[email protected]>, "[email protected]"
<[email protected]>
Subject: [USRP-users] Single radio implementation in rfnoc-radio-redo
fails uhd_usrp_probe
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Jonathon,
I went into x300_core.v and changed the localparam from 2 to 1.
// Number of Radio Cores Instantiated
localparam NUM_RADIO_CORES = 1;
When I ran uhd_usrp_probe, I got the following results:
Power-cycle the USRP X310 to use the new image.
craig@craig-VirtualBox:~/uhd/fpga-src/usrp3/top/x300/Single_Radio/build
((detached from b62d96c))$ uhd_usrp_probe --init-only
linux; GNU C++ version 4.8.4; Boost_105400;
UHD_003.010.rfnoc-radio-redo-549-geb3036f6
-- X300 initialization sequence...
-- Determining maximum frame size... 1472 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Detecting internal GPSDO.... No GPSDO found
-- [RFNOC] ------- Block Setup -----------
-- SEND (SID: 00:68>02:30)...Setting up NoC-Shell Control for port #0 (SID:
00:68>02:30)...OK
-- Port 48: Found NoC-Block with ID 12AD100000000001.
-- base_path = "/usr/local/share/uhd/rfnoc"
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/radio_x300.xml
-- SEND (SID: 00:69>02:31)...Setting up NoC-Shell Control for port #1 (SID:
00:69>02:31)...OK
-- [RFNoC Factory] block_ctrl_base::make()
-- base_path = "/usr/local/share/uhd/rfnoc"
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/radio_x300.xml
-- [RFNoC Factory] Using controller key 'X300Radio' and block name 'Radio'
-- block_ctrl_base()
-- base_path = "/usr/local/share/uhd/rfnoc"
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/radio_x300.xml
-- Found valid blockdef
-- NOC ID: 0x12AD100000000001 Block ID: 0/Radio_0
-- [0/Radio_0] block_ctrl_base::clear()
-- node_ctrl_base::clear()
-- [0/Radio_0] block_ctrl_base::_clear()
-- [0/Radio_0] block_ctrl_base::_clear()
Error: EnvironmentError: IOError: [0/Radio_0] sr_read64() failed:
EnvironmentError: IOError: Radio ctrl (CE_00_Port_48) no response packet -
AssertionError: bool(buff)
in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
at /home/craig/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:203
craig@craig-VirtualBox:~/uhd/fpga-src/usrp3/top/x300/Single_Radio/build
((detached from b62d96c))$
?
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/20160623/3e6e8bfd/attachment-0001.html>
------------------------------
Message: 13
Date: Thu, 23 Jun 2016 20:39:49 +0000
From: "El Ouni, Naceur (IntlAssoc)" <[email protected]>
To: "[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNoC gr-ettus rfnoc_fosphor not showing
anything
Message-ID:
<sn1pr09mb092504e9fefbed8b4c1002859e...@sn1pr09mb0925.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Not at all I am doing this on a native Linux Box through ssh though.
From: [email protected] [mailto:[email protected]]
Sent: Thursday, June 23, 2016 2:40 PM
To: El Ouni, Naceur (IntlAssoc) <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] RFNoC gr-ettus rfnoc_fosphor not showing anything
Are you doing this from wihin a VM, or on a native Linux box?
On 2016-06-23 14:19, El Ouni, Naceur (IntlAssoc) via USRP-users wrote:
Hello usrp-users,
I have tried to run the gr-ettus's example rfnoc_fosphor and on execute I get:
QPainter::begin: Paint device returned engine == 0, type: 2
QPainter::setPen: Painter not active
QPainter::setFont: Painter not active
Whatever I did to tweak the code (gr-ettus/lib/QFosphorSurface.cc) and
recompile to avoid having a null image:
The result is always the same, nothing show up
I am using:
Ubuntu 14.04, USRP X310,
GNU C++ version 4.8.4; Boost_105400; UHD_003.010.rfnoc-300-g74d178b5
gnuradio version: 3.7.10git-47-gbd69c31e
Thanks and Regards,
Naceur El Ouni
NIST - Wireless Networks Division (673)
100 Bureau Dr. Building 222-A218
Gaithersburg, MD 20899
(301) 975-3353
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[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/20160623/6281c009/attachment-0001.html>
------------------------------
Message: 14
Date: Thu, 23 Jun 2016 17:43:38 -0300
From: Francisco Albani <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] N200 RX center frequency changes ignored
Message-ID:
<caagu92m7y17ntth2cny0fbfjuktcvo3+5k8h2obvrwkdmxn...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Just for the record...
2016-06-23 12:03 GMT-03:00 Marcus M?ller <[email protected]>:
> Resetting from software: Haven't tried that myself, but you could run
> 'uhd_image_loader --args "addr=xxx.xxx.xxx.xxx" --reset'.
I tried this with a 3rd N200, in other environment:
$ uhd_image_loader --args 'addr=192.168.10.2' --reset
linux; GNU C++ version 6.1.1 20160501; Boost_106000;
UHD_003.009.004-0-unknown
Error: unrecognised option '--reset'
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160623/ebb47da7/attachment-0001.html>
------------------------------
Message: 15
Date: Thu, 23 Jun 2016 13:44:55 -0700
From: Pavan Yedavalli <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] S printouts and then either U printouts (and
fails/stops transmitting) or seg fault with 4 USRPs
Message-ID:
<cacax0_p4kh3fj6zg4dvew9is5g3ufwyjwoohzbw+unyi0l1...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Marcus,
I am now porting everything to a desktop that will have direct Ethernet
ports, so I don't have to deal with the USB->GigE. Is it okay that I still
use the TP-Link switch though? (since I will be connecting multiple USRPs)
On Thu, Jun 23, 2016 at 9:57 AM, Pavan Yedavalli <[email protected]>
wrote:
> Hmm, okay. Well, those are very serious. An alternative I have is to try a
> desktop and try to connect the switch to the desktop's ethernet port and
> connect the USRPs to the switch. Of course, I will have to configure the
> desktop with Ubuntu and installing gnuradio and all of that, but I guess
> that might be worth it? Trying to avoid the USB-to-1GiGe devices will
> probably help in the long run?
>
> On Thu, Jun 23, 2016 at 9:51 AM, <[email protected]> wrote:
>
>> USB-to-1GiGe devices often have two serious problems:
>>
>> (1) They re-order packets--this is fatal to a streaming UDP protocol such
>> as used by UHD
>>
>> (2) They cannot possibly (for USB-2.0) support a 1GiGe average throughput.
>>
>>
>>
>>
>>
>>
>> On 2016-06-23 12:40, Pavan Yedavalli via USRP-users wrote:
>>
>> Hi Marcus,
>>
>> Thanks for getting back to me. The following is the setup:
>>
>> I have a Lenovo X1 Carbon with 7.6 GB of memory, Intel Core i7-4600U CPU
>> @ 2.10 GHz x 4, with a 32-bit OS and I believe 200 GB HD. I am using 4 USRP
>> N210s.
>>
>> This laptop does *NOT* have an ethernet port built in - instead, I need
>> to use this adapter
>> <http://shop.lenovo.com/ae/en/itemdetails/4X90F84315/460/34285E7D99BB43138551449AD7C986A5>,
>> which I then connect to this TP-Link 8-Port Gigabit Ethernet switch
>> <https://www.amazon.com/TP-LINK-Gigabit-Ethernet-Desktop-TL-SG108/dp/B00A121WN6/186-5052592-5933742?ie=UTF8&keywords=gigabit%20ethernet%20switch&qid=1456432852&ref_=sr_1_3&sr=8-3>
>> .
>>
>> From here, I connect all 4 USRPs to the switch. To be more specific
>> though, I connect one USRP (master) directly to the switch, with another
>> connected via MIMO cable to that master USRP. Then, I connect two more
>> directly to the switch. I could change this configuration so that all 4,
>> instead of 3, are connected directly to the switch, but I had a MIMO cable,
>> so I decided to use it. All of the USRP N210s are connected to the same
>> computer via this switch and adapter.
>>
>> I tried with just a simple flow graph sending a single tone with all 4
>> USRPs, as mentioned, and S appears almost immediately then too, but it
>> seems to stop after a bit and continues to transmit, with Us not appearing.
>> Once I use my block though, Ss and Us appear almost immediately and
>> everything halts.
>>
>> Attached is probably a not so helpful image of the connection, but just
>> to get an idea.
>>
>> --
>> Pavan
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
> --
> Pavan
>
--
Pavan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160623/be0a590d/attachment-0001.html>
------------------------------
Message: 16
Date: Thu, 23 Jun 2016 22:52:03 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] S printouts and then either U printouts (and
fails/stops transmitting) or seg fault with 4 USRPs
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
As I explained, you will be bandwidth limited. Other than that, you
should be OK, if the IP addresses of your USRPs don't clash.
Best regards,
Marcus
On 23.06.2016 22:44, Pavan Yedavalli via USRP-users wrote:
> Hi Marcus,
>
> I am now porting everything to a desktop that will have direct
> Ethernet ports, so I don't have to deal with the USB->GigE. Is it okay
> that I still use the TP-Link switch though? (since I will be
> connecting multiple USRPs)
>
> On Thu, Jun 23, 2016 at 9:57 AM, Pavan Yedavalli <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hmm, okay. Well, those are very serious. An alternative I have is
> to try a desktop and try to connect the switch to the desktop's
> ethernet port and connect the USRPs to the switch. Of course, I
> will have to configure the desktop with Ubuntu and installing
> gnuradio and all of that, but I guess that might be worth it?
> Trying to avoid the USB-to-1GiGe devices will probably help in the
> long run?
>
> On Thu, Jun 23, 2016 at 9:51 AM, <[email protected]
> <mailto:[email protected]>> wrote:
>
> USB-to-1GiGe devices often have two serious problems:
>
> (1) They re-order packets--this is fatal to a streaming UDP
> protocol such as used by UHD
>
> (2) They cannot possibly (for USB-2.0) support a 1GiGe average
> throughput.
>
>
>
>
>
>
>
> On 2016-06-23 12:40, Pavan Yedavalli via USRP-users wrote:
>
>> Hi Marcus,
>>
>> Thanks for getting back to me. The following is the setup:
>>
>> I have a Lenovo X1 Carbon with 7.6 GB of memory, Intel Core
>> i7-4600U CPU @ 2.10 GHz x 4, with a 32-bit OS and I believe
>> 200 GB HD. I am using 4 USRP N210s.
>>
>> This laptop does /NOT/ have an ethernet port built in -
>> instead, I need to use this adapter
>>
>> <http://shop.lenovo.com/ae/en/itemdetails/4X90F84315/460/34285E7D99BB43138551449AD7C986A5>,
>> which I then connect to this TP-Link 8-Port Gigabit Ethernet
>> switch
>>
>> <https://www.amazon.com/TP-LINK-Gigabit-Ethernet-Desktop-TL-SG108/dp/B00A121WN6/186-5052592-5933742?ie=UTF8&keywords=gigabit%20ethernet%20switch&qid=1456432852&ref_=sr_1_3&sr=8-3>.
>>
>> From here, I connect all 4 USRPs to the switch. To be more
>> specific though, I connect one USRP (master) directly to the
>> switch, with another connected via MIMO cable to that master
>> USRP. Then, I connect two more directly to the switch. I
>> could change this configuration so that all 4, instead of 3,
>> are connected directly to the switch, but I had a MIMO cable,
>> so I decided to use it. All of the USRP N210s are connected
>> to the same computer via this switch and adapter.
>>
>> I tried with just a simple flow graph sending a single tone
>> with all 4 USRPs, as mentioned, and S appears almost
>> immediately then too, but it seems to stop after a bit and
>> continues to transmit, with Us not appearing. Once I use my
>> block though, Ss and Us appear almost immediately and
>> everything halts.
>>
>> Attached is probably a not so helpful image of the
>> connection, but just to get an idea.
>>
>> --
>> Pavan
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> --
> Pavan
>
>
>
>
> --
> Pavan
>
>
> _______________________________________________
> 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/20160623/6ad89fe9/attachment-0001.html>
------------------------------
Message: 17
Date: Thu, 23 Jun 2016 17:12:53 -0400
From: Dave NotTelling <[email protected]>
To: "El Ouni, Naceur (IntlAssoc)" <[email protected]>
Cc: "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNoC gr-ettus rfnoc_fosphor not showing
anything
Message-ID:
<CAK6GVuPKzs_GbQrmEJppbF4feK+Wvz=yydr1qn2jybc7n8i...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Might be a dumb question: Have you resized the window? That threw me for a
loop. Launched and saw just the sliders with no fosphor display. Learned
at the Boston SDR con that you just need to maximize the window.
On Thu, Jun 23, 2016 at 4:39 PM, El Ouni, Naceur (IntlAssoc) via USRP-users
<[email protected]> wrote:
> Not at all I am doing this on a native Linux Box through ssh though.
>
>
>
> *From:* [email protected] [mailto:[email protected]]
> *Sent:* Thursday, June 23, 2016 2:40 PM
> *To:* El Ouni, Naceur (IntlAssoc) <[email protected]>
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] RFNoC gr-ettus rfnoc_fosphor not showing
> anything
>
>
>
> Are you doing this from wihin a VM, or on a native Linux box?
>
>
>
>
>
>
>
> On 2016-06-23 14:19, El Ouni, Naceur (IntlAssoc) via USRP-users wrote:
>
> Hello usrp-users,
>
>
>
> I have tried to run the gr-ettus's example rfnoc_fosphor and on execute I
> get:
>
> *QPainter::begin: Paint device returned engine == 0, type: 2*
>
> * QPainter::setPen: Painter not active QPainter::setFont: Painter not
> active*
>
> Whatever I did to tweak the code (gr-ettus/lib/QFosphorSurface.cc) and
> recompile to avoid having a null image:
> The result is always the same, nothing show up
>
> I am using:
>
> Ubuntu 14.04, USRP X310,
> GNU C++ version 4.8.4; Boost_105400; UHD_003.010.rfnoc-300-g74d178b5
> gnuradio version: 3.7.10git-47-gbd69c31e
>
>
>
> Thanks and Regards,
>
>
>
> Naceur El Ouni
>
> NIST - Wireless Networks Division (673)
>
> 100 Bureau Dr. Building 222-A218
>
> Gaithersburg, MD 20899
>
> (301) 975-3353
>
>
>
>
>
> _______________________________________________
> 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/20160623/fca46178/attachment-0001.html>
------------------------------
Message: 18
Date: Thu, 23 Jun 2016 17:19:24 -0400
From: [email protected]
To: Dave NotTelling <[email protected]>
Cc: "El Ouni, Naceur (IntlAssoc)" <[email protected]>,
[email protected]
Subject: Re: [USRP-users] RFNoC gr-ettus rfnoc_fosphor not showing
anything
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
I'm not any kind of expert on how gr-fosphor works, but I don't think
any of that GPU stuff is carried properly over an X connection--it has
to be done on a "local" display. I could be wrong but my experience
with GL things has been that they aren't reliably over an X
connection--you *need* a local GPU-based "canvas" upon which to draw.
On 2016-06-23 17:12, Dave NotTelling wrote:
> Might be a dumb question: Have you resized the window? That threw me for a
> loop. Launched and saw just the sliders with no fosphor display. Learned at
> the Boston SDR con that you just need to maximize the window.
>
> On Thu, Jun 23, 2016 at 4:39 PM, El Ouni, Naceur (IntlAssoc) via USRP-users
> <[email protected]> wrote:
>
> Not at all I am doing this on a native Linux Box through ssh though.
>
> FROM: [email protected] [mailto:[email protected]]
> SENT: Thursday, June 23, 2016 2:40 PM
> TO: El Ouni, Naceur (IntlAssoc) <[email protected]>
> CC: [email protected]
> SUBJECT: Re: [USRP-users] RFNoC gr-ettus rfnoc_fosphor not showing anything
>
> Are you doing this from wihin a VM, or on a native Linux box?
>
> On 2016-06-23 14:19, El Ouni, Naceur (IntlAssoc) via USRP-users wrote:
>
> Hello usrp-users,
>
> I have tried to run the gr-ettus's example rfnoc_fosphor and on execute I
> get:
>
> QPAINTER::BEGIN: PAINT DEVICE RETURNED ENGINE == 0, TYPE: 2
> QPAINTER::SETPEN: PAINTER NOT ACTIVE
> QPAINTER::SETFONT: PAINTER NOT ACTIVE
>
> Whatever I did to tweak the code (gr-ettus/lib/QFosphorSurface.cc) and
> recompile to avoid having a null image:
> The result is always the same, nothing show up
>
> I am using:
>
> Ubuntu 14.04, USRP X310,
> GNU C++ version 4.8.4; Boost_105400; UHD_003.010.rfnoc-300-g74d178b5
> gnuradio version: 3.7.10git-47-gbd69c31e
>
> Thanks and Regards,
>
> Naceur El Ouni
>
> NIST - Wireless Networks Division (673)
>
> 100 Bureau Dr. Building 222-A218
>
> Gaithersburg, MD 20899
>
> (301) 975-3353 [1]
>
> _______________________________________________
> 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
Links:
------
[1] tel:%28301%29%20975-3353
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160623/2b67cc00/attachment-0001.html>
------------------------------
Message: 19
Date: Thu, 23 Jun 2016 17:39:10 -0700
From: Pavan Yedavalli <[email protected]>
To: [email protected]
Subject: [USRP-users] Burning USRP N210 EEPROM with DHCP configuration
Message-ID:
<cacax0_mzsf0f0gy3vvjaavu_cai-h2jnldeedv02auwxvpq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I previously burned static IP addresses onto each of my USRPs (using
./usrp_burn_mb_eeprom --args=<optional device args>
--values="ip-addr=192.168.10.X"), but now I am part of a network
configuration in which each USRP was given a different IP address. Do I
have to burn that IP address onto the board or is there a way I can
configure flash so that it takes from DHCP (which is what the sys admins
want it to do, since they assigned the USRPs particular IPs based on the
MAC addresses). I suppose I can burn those IP addresses onto the boards,
but they don't want me to do that.
How can I burn into the USRP that it should take the address from DHCP now
instead of its previous static address? Thanks for the help.
--
Pavan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160623/76e628fc/attachment-0001.html>
------------------------------
Message: 20
Date: Thu, 23 Jun 2016 17:43:24 -0700
From: Matt Ettus <[email protected]>
To: Pavan Yedavalli <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Burning USRP N210 EEPROM with DHCP
configuration
Message-ID:
<CAN=1kn-Kiug2Vb0=86fago0vxmdi9f0c1j_j1ddzwba8mcy...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
The N210 does not do DHCP. You need to give it a static address.
Typically, USRPs are connected to a separate network, direct to a computer,
so that it has dedicated bandwidth. You can use a shared network, but you
will need to assign static addresses.
Matt
On Thu, Jun 23, 2016 at 5:39 PM, Pavan Yedavalli via USRP-users <
[email protected]> wrote:
> Hi,
>
> I previously burned static IP addresses onto each of my USRPs (using
> ./usrp_burn_mb_eeprom --args=<optional device args>
> --values="ip-addr=192.168.10.X"), but now I am part of a network
> configuration in which each USRP was given a different IP address. Do I
> have to burn that IP address onto the board or is there a way I can
> configure flash so that it takes from DHCP (which is what the sys admins
> want it to do, since they assigned the USRPs particular IPs based on the
> MAC addresses). I suppose I can burn those IP addresses onto the boards,
> but they don't want me to do that.
>
> How can I burn into the USRP that it should take the address from DHCP now
> instead of its previous static address? Thanks for the help.
>
> --
> Pavan
>
> _______________________________________________
> 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/20160623/80625e10/attachment-0001.html>
------------------------------
Message: 21
Date: Thu, 23 Jun 2016 17:45:44 -0700
From: Pavan Yedavalli <[email protected]>
To: Matt Ettus <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Burning USRP N210 EEPROM with DHCP
configuration
Message-ID:
<CACaX0_MZkUgK6U16ZT0=wGCGNtyDxiE=lrq-+_vq92h1o4j...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Matt,
Thank you for the quick response. I will tell that to our sysadmins -
hopefully they're okay with that. Thanks.
On Thu, Jun 23, 2016 at 5:43 PM, Matt Ettus <[email protected]> wrote:
>
>
> The N210 does not do DHCP. You need to give it a static address.
> Typically, USRPs are connected to a separate network, direct to a computer,
> so that it has dedicated bandwidth. You can use a shared network, but you
> will need to assign static addresses.
>
> Matt
>
> On Thu, Jun 23, 2016 at 5:39 PM, Pavan Yedavalli via USRP-users <
> [email protected]> wrote:
>
>> Hi,
>>
>> I previously burned static IP addresses onto each of my USRPs (using
>> ./usrp_burn_mb_eeprom --args=<optional device args>
>> --values="ip-addr=192.168.10.X"), but now I am part of a network
>> configuration in which each USRP was given a different IP address. Do I
>> have to burn that IP address onto the board or is there a way I can
>> configure flash so that it takes from DHCP (which is what the sys admins
>> want it to do, since they assigned the USRPs particular IPs based on the
>> MAC addresses). I suppose I can burn those IP addresses onto the boards,
>> but they don't want me to do that.
>>
>> How can I burn into the USRP that it should take the address from DHCP
>> now instead of its previous static address? Thanks for the help.
>>
>> --
>> Pavan
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
--
Pavan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160623/d0797542/attachment-0001.html>
------------------------------
Message: 22
Date: Thu, 23 Jun 2016 20:55:09 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Burning USRP N210 EEPROM with DHCP
configuration
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 06/23/2016 08:45 PM, Pavan Yedavalli via USRP-users wrote:
> Hi Matt,
>
> Thank you for the quick response. I will tell that to our sysadmins -
> hopefully they're okay with that. Thanks.
I'll point out, for the sake of completeness, that add-on 1GiGe network
cards of reasonable quality and performance are available for
under $30.00. If this is a "lab" desktop computer that'll be talking
to the USRP, a 2nd ethernet card dedicated to the USRP would not
be prohibitively expensive. Less than a weeks worth of visits to
Starbucks :) :)
>
> On Thu, Jun 23, 2016 at 5:43 PM, Matt Ettus <[email protected]
> <mailto:[email protected]>> wrote:
>
>
>
> The N210 does not do DHCP. You need to give it a static address.
> Typically, USRPs are connected to a separate network, direct to a
> computer, so that it has dedicated bandwidth. You can use a
> shared network, but you will need to assign static addresses.
>
> Matt
>
> On Thu, Jun 23, 2016 at 5:39 PM, Pavan Yedavalli via USRP-users
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> Hi,
>
> I previously burned static IP addresses onto each of my USRPs
> (using
> ./usrp_burn_mb_eeprom --args=<optional device args>
> --values="ip-addr=192.168.10.X"), but now I am part of a
> network configuration in which each USRP was given a different
> IP address. Do I have to burn that IP address onto the board
> or is there a way I can configure flash so that it takes from
> DHCP (which is what the sys admins want it to do, since they
> assigned the USRPs particular IPs based on the MAC addresses).
> I suppose I can burn those IP addresses onto the boards, but
> they don't want me to do that.
>
> How can I burn into the USRP that it should take the address
> from DHCP now instead of its previous static address? Thanks
> for the help.
>
> --
> Pavan
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
> --
> Pavan
>
>
> _______________________________________________
> 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/20160623/3d787ceb/attachment-0001.html>
------------------------------
Message: 23
Date: Thu, 23 Jun 2016 19:24:19 -0700
From: Pavan Yedavalli <[email protected]>
To: [email protected], GNURadio Discussion List
<[email protected]>
Subject: Re: [USRP-users] S printouts and then either U printouts (and
fails/stops transmitting) or seg fault with 4 USRPs
Message-ID:
<CACaX0_P23UtVZxvZuvwEy6uaG591=++yh9xh7pfnu+vdef7...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Just an update on this:
I switched everything to a desktop with a dedicated ethernet port, and
connected all 4 USRPs to a switch, which is then directly connected via
ethernet to the computer. This has eliminated the Us, which means that it
is actually working decently (and not crapping out). Thanks to all who
advised with that. However, multiple Ss still get printed out at basically
every transmission. In addition, there are sometimes warnings that say:
SSSSSSSSSSS
UHD Error:
Control packet attempt 0, sequence number 452:
RuntimeError: no control response, possible packet loss
This happens occasionally, but the Ss get printed out every time. While it
isn't blocking, since I am actually getting transmissions and it is not
crashing, I am still curious about how to solve this S problem. Thanks
again!
--
Pavan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160623/d099714b/attachment-0001.html>
------------------------------
Message: 24
Date: Fri, 24 Jun 2016 14:17:05 +0800
From: Lin HUANG <[email protected]>
To: "El Ouni, Naceur (IntlAssoc)" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Amarisoft using X310 as eNB, uhd error
Message-ID:
<CAP2dER3w7DeBCz1To_xyR9zbLjLT1HfzsZ5=3brzpmm+qdf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Firstly you should test the UHD by 'benchmark' to make sure it has no
overflow and underflow.
You may remove the 'send_frame_size=3972,recv_frame_size=3972,', then have
a try.
Lin
2016-06-24 2:15 GMT+08:00 El Ouni, Naceur (IntlAssoc) via USRP-users <
[email protected]>:
> Hello usrp-users,
>
>
>
> We have purchased an Amarisoft LTE license. It is working ok with the USRP
> N210.
>
> However when I tried to run it with X310. I?ve been getting a *trx_uhd_read:
> error code = 0x1*
>
>
>
> lteenb version: 2015-01-20
>
> OS: Ubuntu 14.04
>
> UHD version: 003.007.000-0-g7fef199d
>
> Mboard: X310
>
> revision: 6
>
> FW Version: 3.0
>
> FPGA Version: 3.0
>
> Daughterboard: SBX v5
>
>
>
> Output of lteenb:
>
> This software is licensed to NIST.
>
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.007.000-0-g7fef199d
>
>
>
> UHD: X300 initialization sequence...
>
> UHD: Determining maximum frame size... UHD: 1472 bytes.
>
> UHD: Setup basic communication...
>
> UHD: Loading values from EEPROM...
>
> UHD: Setup RF frontend clocking...
>
> UHD: Radio 1x clock:184.32
>
> UHD: Initialize Radio control...
>
> UHD: Performing register loopback test... UHD: pass
>
> UHD: Sync DAC's.
>
> UHD: Performing register loopback test... UHD: pass
>
> UHD: Sync DAC's.
>
> UHD: Setting references to internal sources
>
> sample_rate=11.520 MHz
>
> RF0: dl_freq=2600.000 MHz ul_freq=2600.000 MHz (band 38) dl_ant=1 ul_ant=1
>
> (enb) UHD: Loaded /home/nae/.uhd/cal/rx_iq_cal_v0.2_F554CC.csv
>
> Chan Gain(dB) Freq(MHz)
>
> TX1 15.0 2600.000000
>
> RX1 20.0 2600.000000
>
> UHD: 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
>
> *trx_uhd_read: error code = 0x1*
>
>
>
> PS: I already adapted all the configuration values to meet X310like:
>
>
> "addr=192.168.10.2,send_frame_size=3972,recv_frame_size=3972,master_clock_rate=184.32e6,system_clock_rate=10e6",
>
> n_rb_dl set to 50 fto monitor the 10MHz
>
>
>
> I also tried to monitor the 5MHz LTE (and adapted the config file
> accordingly, sample_rate: 5.76, n_rb_dl : 25, send/recv_frame_size=2000)
>
> And the same way I tried also for 20MHz I am always getting that same
> *trx_uhd_read:
> error code = 0x1* error.
>
>
>
> Did anyone ever encountered this type of error ?
>
>
>
> Thanks and Regards,
>
>
>
> Naceur El Ouni
>
> NIST - Wireless Networks Division (673)
>
> 100 Bureau Dr. Building 222-A218
>
> Gaithersburg, MD 20899
>
> (301) 975-3353
>
>
>
> _______________________________________________
> 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/20160624/1c9548f8/attachment-0001.html>
------------------------------
Message: 25
Date: Fri, 24 Jun 2016 09:44:39 +0200
From: Sylvain Munaut <[email protected]>
To: "El Ouni, Naceur (IntlAssoc)" <[email protected]>
Cc: "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNoC gr-ettus rfnoc_fosphor not showing
anything
Message-ID:
<cahl+j09rmn66j-ra_kabw6hxs-ywzfbgfjb54-h3vtth-0h...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
> Not at all I am doing this on a native Linux Box through ssh though.
Won't work.
The screen is rendered via OpenGL, that doesn't work over forwarded X
connections.
To view rfnoc-fosphor remotely you need to split the flowgraph in two
(one remote part and one local) and forward the data over ZMQ.
Cheers,
Sylvain
------------------------------
Message: 26
Date: Fri, 24 Jun 2016 09:08:48 -0500
From: Jonathon Pendlum <[email protected]>
To: "Swanson, Craig" <[email protected]>
Cc: Marcus M?ller <[email protected]>, Martin Braun
<[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] Single radio implementation in
rfnoc-radio-redo fails uhd_usrp_probe
Message-ID:
<CAGdo0uRqNYwL2He04X1V=5zbpbuzb8yvwpqcmanocx8gb-6...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Craig,
We are focusing on getting radio-redo merged into rfnoc-devel. For now, you
cannot remove one of the radio cores and we'll look into that after the
merge.
Jonathon
On Thu, Jun 23, 2016 at 3:02 PM, Swanson, Craig <
[email protected]> wrote:
> Jonathon,
>
> I went into x300_core.v and changed the localparam from 2 to 1.
> // Number of Radio Cores Instantiated
> localparam NUM_RADIO_CORES = 1;
>
> When I ran uhd_usrp_probe, I got the following results:
>
> Power-cycle the USRP X310 to use the new image.
> craig@craig-VirtualBox:~/uhd/fpga-src/usrp3/top/x300/Single_Radio/build
> ((detached from b62d96c))$ uhd_usrp_probe --init-only
> linux; GNU C++ version 4.8.4; Boost_105400;
> UHD_003.010.rfnoc-radio-redo-549-geb3036f6
>
> -- X300 initialization sequence...
> -- Determining maximum frame size... 1472 bytes.
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> -- Detecting internal GPSDO.... No GPSDO found
> -- [RFNOC] ------- Block Setup -----------
> -- SEND (SID: 00:68>02:30)...Setting up NoC-Shell Control for port #0
> (SID: 00:68>02:30)...OK
> -- Port 48: Found NoC-Block with ID 12AD100000000001.
> -- base_path = "/usr/local/share/uhd/rfnoc"
> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/radio_x300.xml
> -- SEND (SID: 00:69>02:31)...Setting up NoC-Shell Control for port #1
> (SID: 00:69>02:31)...OK
> -- [RFNoC Factory] block_ctrl_base::make()
> -- base_path = "/usr/local/share/uhd/rfnoc"
> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/radio_x300.xml
> -- [RFNoC Factory] Using controller key 'X300Radio' and block name 'Radio'
> -- block_ctrl_base()
> -- base_path = "/usr/local/share/uhd/rfnoc"
> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/radio_x300.xml
> -- Found valid blockdef
> -- NOC ID: 0x12AD100000000001 Block ID: 0/Radio_0
> -- [0/Radio_0] block_ctrl_base::clear()
> -- node_ctrl_base::clear()
> -- [0/Radio_0] block_ctrl_base::_clear()
> -- [0/Radio_0] block_ctrl_base::_clear()
> Error: EnvironmentError: IOError: [0/Radio_0] sr_read64() failed:
> EnvironmentError: IOError: Radio ctrl (CE_00_Port_48) no response packet -
> AssertionError: bool(buff)
> in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
> at /home/craig/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:203
>
> craig@craig-VirtualBox:~/uhd/fpga-src/usrp3/top/x300/Single_Radio/build
> ((detached from b62d96c))$
>
> ?
>
>
>
>
>
> *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 <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/20160624/0aa6645a/attachment-0001.html>
------------------------------
Message: 27
Date: Fri, 24 Jun 2016 09:28:17 -0500
From: Jonathon Pendlum <[email protected]>
To: "Yin, Charles - 0665 - MITLL" <[email protected]>
Cc: Neel Pandeya <[email protected]>, "Chibane, Cherif - 0665 -
MITLL" <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] RFNoC Installation Problems
Message-ID:
<CAGdo0uQvP26vi9xz7LyEzudPXg45O88txh6EAK0NOnOs+=2=o...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Charles,
Can you provide the cmake command you are using for your build?
Jonathon
On Thu, Jun 23, 2016 at 6:07 AM, Yin, Charles - 0665 - MITLL via USRP-users
<[email protected]> wrote:
> Neel,
>
>
>
> Thank you very much. I had allocated 16GB of RAM for my VM originally,
> but Martin recommended me to increase my swap space to 32GB, and that fixed
> the problem. I am, running into another problem when trying to build
> GR-Ettus. I am using the devel branch of
> https://github.com/ettusresearch/gr-ettus and I am get the following
> error message when running cmake:
>
>
>
> CMake Error at
> /local_disk/e310_gr_3.7.9.2/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake:4
> (string):
>
> string sub-command REGEX, mode MATCH needs at least 5 arguments total to
>
> command.
>
> Call Stack (most recent call first):
>
> build/CMakeFiles/2.8.12.2/CMakeSystem.cmake:6 (include)
>
> CMakeLists.txt:24 (project)
>
>
>
>
>
> CMake Error at
> /local_disk/e310_gr_3.7.9.2/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake:5
> (string):
>
> string sub-command REGEX, mode REPLACE needs at least 6 arguments total
> to
>
> command.
>
> Call Stack (most recent call first):
>
> build/CMakeFiles/2.8.12.2/CMakeSystem.cmake:6 (include)
>
> CMakeLists.txt:24 (project)
>
>
>
>
>
> -- The CXX compiler identification is GNU 4.8.4
>
> -- The C compiler identification is GNU 4.8.4
>
> -- Check for working CXX compiler: /usr/bin/c++
>
> CMake Error at
> /local_disk/e310_gr_3.7.9.2/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake:4
> (string):
>
> string sub-command REGEX, mode MATCH needs at least 5 arguments total to
>
> command.
>
> Call Stack (most recent call first):
>
> /local_disk/e310_gr_3.7.9.2/src/gr-ettus/build/CMakeFiles/
> 2.8.12.2/CMakeSystem.cmake:6 (include)
>
> CMakeLists.txt:2 (PROJECT)
>
>
>
>
>
> CMake Error at
> /local_disk/e310_gr_3.7.9.2/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake:5
> (string):
>
> string sub-command REGEX, mode REPLACE needs at least 6 arguments total
> to
>
> command.
>
> Call Stack (most recent call first):
>
> /local_disk/e310_gr_3.7.9.2/src/gr-ettus/build/CMakeFiles/
> 2.8.12.2/CMakeSystem.cmake:6 (include)
>
> CMakeLists.txt:2 (PROJECT)
>
>
>
>
>
> CMake Error: Internal CMake error, TryCompile configure of cmake failed
>
> -- Check for working CXX compiler: /usr/bin/c++ -- broken
>
> CMake Error at /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake:54
> (message):
>
> The C++ compiler "/usr/bin/c++" is not able to compile a simple test
>
> program.
>
>
>
> It fails with the following output:
>
>
>
>
>
>
>
>
>
>
>
> CMake will not be able to correctly generate this project.
>
> Call Stack (most recent call first):
>
> CMakeLists.txt:24 (project)
>
>
>
>
>
> -- Configuring incomplete, errors occurred!
>
> See also
> "/local_disk/e310_gr_3.7.9.2/src/gr-ettus/build/CMakeFiles/CMakeOutput.log".
>
> See also
> "/local_disk/e310_gr_3.7.9.2/src/gr-ettus/build/CMakeFiles/CMakeError.log".
>
>
>
>
>
>
>
> I?m guessing it?s another really small problem that I am missing again.
> Please let me know if you think of anything. Thanks!
>
>
>
> Charles
>
>
>
>
>
> *From:* Neel Pandeya [mailto:[email protected]]
> *Sent:* Wednesday, June 22, 2016 12:17 PM
> *To:* Yin, Charles - 0665 - MITLL
> *Cc:* [email protected]; Chibane, Cherif - 0665 - MITLL
> *Subject:* Re: [USRP-users] RFNoC Installation Problems
>
>
>
> Hello Charles:
>
> It looks like you're running in a Virtual Machine, and it's run out of
> memory. See the line in the output:
>
> virtual memory exhausted: Cannot allocate memory
>
> Try increasing the memory for the VM to 4 GB, and re-building.
>
> Please let us know if you're able to make any further progress.
>
>
>
> --Neel Pandeya
>
>
>
> On 21 June 2016 at 13:24, Yin, Charles - 0665 - MITLL via USRP-users <
> [email protected]> wrote:
>
> Hi Neel and Jonathon,
>
>
>
> I am having problems building RFNoC with GNU Radio. I am using GNU Radio
> Version 3.9.7.2 on Ubuntu 14.04. You mentioned to check for the swig
> package, and I can confirm that it is there. The error from the build
> process is as follows:
>
>
>
> Linking CXX executable test-gr-blocks
>
> [ 67%] Built target test-gr-blocks
>
> Scanning dependencies of target _blocks_swig3
>
> [ 67%] Building CXX object
> gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/blocks_swig3PYTHON_wrap.cxx.o
>
> {standard input}: Assembler messages:
>
> {standard input}:380989: Warning: end of file not at end of a line;
> newline inserted
>
> {standard input}:381666: Error: invalid operands (*UND* and .ARM.extab
> sections) for `-'
>
> {standard input}:381669: Error: invalid operands (*UND* and .ARM.extab
> sections) for `-'
>
> arm-oe-linux-gnueabi-g++: internal compiler error: Killed (program cc1plus)
>
> Please submit a full bug report,
>
> with preprocessed source if appropriate.
>
> See <http://gcc.gnu.org/bugs.html> for instructions.
>
> make[2]: ***
> [gr-blocks/swig/CMakeFiles/_blocks_swig2.dir/blocks_swig2PYTHON_wrap.cxx.o]
> Error 4
>
> make[1]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig2.dir/all] Error 2
>
> make[1]: *** Waiting for unfinished jobs....
>
> virtual memory exhausted: Cannot allocate memory
>
> {standard input}: Assembler messages:
>
> {standard input}:1273004: Warning: end of file not at end of a line;
> newline inserted
>
> {standard input}:1274439: Error: unknown pseudo-op: `.'
>
> make[2]: ***
> [gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/blocks_swig0PYTHON_wrap.cxx.o]
> Error 1
>
> make[1]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/all] Error 2
>
> {standard input}: Error: open CFI at the end of file; missing .cfi_endproc
> directive
>
> arm-oe-linux-gnueabi-g++: internal compiler error: Killed (program cc1plus)
>
> Please submit a full bug report,
>
> with preprocessed source if appropriate.
>
> See <http://gcc.gnu.org/bugs.html> for instructions.
>
> make[2]: ***
> [gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/blocks_swig3PYTHON_wrap.cxx.o]
> Error 4
>
> make[1]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/all] Error 2
>
> Linking CXX shared module _blocks_swig1.so
>
> [ 67%] Built target _blocks_swig1
>
> make: *** [all] Error 2
>
>
>
>
>
>
>
> I?m not entirely sure what I am missing. Please let me know if you find
> anything. Thanks!
>
>
>
> Charles Yin
>
>
>
>
> _______________________________________________
> 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/20160624/190e9f30/attachment-0001.html>
------------------------------
Message: 28
Date: Fri, 24 Jun 2016 16:30:17 +0200
From: Samy CHBINOU <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] benchmark
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hello,
I did some benchmark on the USRP B205mini on USB3 on linux, ARM. Over
8MSps I have some overflows and underflows.
Is this value 8MSps considered high? low?
Which system/kernel parameters can I tweak to get better results?
performance mode? taskset on good CPU?...
Samy
------------------------------
Message: 29
Date: Fri, 24 Jun 2016 14:31:21 +0000
From: "Swanson, Craig" <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: Marcus M?ller <[email protected]>, Martin Braun
<[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] Single radio implementation in
rfnoc-radio-redo fails uhd_usrp_probe
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Jonathon,
This is currently not an urgent issue with me. I just wanted to do a test to
see if it worked to tell upper management.
Until a month ago I was doing all my development on the E310 and running out of
room. Doing development on the E310 up to this point has been an unpleasant
experience. I am suspecting it is because of the Zynq on the E310 compared to
the 7K410 on the X310. The lack on room on the E310, because it is embedded,
and chipscope acting very unreliable, made my development very slow.
I am happy with developing on the X310 and wish I would have done it sooner.
I will need to revisit the E310 several months from now when it will need to
fly my X310 algorithm on an airborne platform. I am really hoping in the near
future you will have a new product that is flyable with a much larger FPGA. I
thought there was some news that came out a VaTech several weeks ago that Ettus
was moving in that direction.
For now, here are my utilization numbers for the X310 rfnoc-radio-redo. As you
can see that there is not much improvement which is surprising. I am assuming
it is because the single radio is broken.
Single Radio:
+----------------------------+-------+-----------+-------+
| Site Type | Used | Available | Util% |
+----------------------------+-------+-----------+-------+
| Slice LUTs | 67685 | 254200 | 26.63 |
| LUT as Logic | 53136 | 254200 | 20.90 |
| LUT as Memory | 14549 | 90600 | 16.06 |
| LUT as Distributed RAM | 2076 | | |
| LUT as Shift Register | 12473 | | |
| Slice Registers | 75651 | 508400 | 14.88 |
| Register as Flip Flop | 75651 | 508400 | 14.88 |
| Register as Latch | 0 | 508400 | 0.00 |
| F7 Muxes | 722 | 127100 | 0.57 |
| F8 Muxes | 9 | 63550 | 0.01 |
+----------------------------+-------+-----------+-------+
Dual Radio:
+----------------------------+-------+-----------+-------+
| Site Type | Used | Available | Util% |
+----------------------------+-------+-----------+-------+
| Slice LUTs | 74989 | 254200 | 29.50 |
| LUT as Logic | 58142 | 254200 | 22.87 |
| LUT as Memory | 16847 | 90600 | 18.59 |
| LUT as Distributed RAM | 2274 | | |
| LUT as Shift Register | 14573 | | |
| Slice Registers | 84625 | 508400 | 16.65 |
| Register as Flip Flop | 84625 | 508400 | 16.65 |
| Register as Latch | 0 | 508400 | 0.00 |
| F7 Muxes | 811 | 127100 | 0.64 |
| F8 Muxes | 9 | 63550 | 0.01 |
+----------------------------+-------+-----------+-------+?
Craig
________________________________
From: Jonathon Pendlum <[email protected]>
Sent: Friday, June 24, 2016 10:08 AM
To: Swanson, Craig
Cc: Marcus M?ller; Martin Braun; [email protected]
Subject: Re: Single radio implementation in rfnoc-radio-redo fails
uhd_usrp_probe
Hi Craig,
We are focusing on getting radio-redo merged into rfnoc-devel. For now, you
cannot remove one of the radio cores and we'll look into that after the merge.
Jonathon
On Thu, Jun 23, 2016 at 3:02 PM, Swanson, Craig
<[email protected]<mailto:[email protected]>> wrote:
Jonathon,
I went into x300_core.v and changed the localparam from 2 to 1.
// Number of Radio Cores Instantiated
localparam NUM_RADIO_CORES = 1;
When I ran uhd_usrp_probe, I got the following results:
Power-cycle the USRP X310 to use the new image.
craig@craig-VirtualBox:~/uhd/fpga-src/usrp3/top/x300/Single_Radio/build
((detached from b62d96c))$ uhd_usrp_probe --init-only
linux; GNU C++ version 4.8.4; Boost_105400;
UHD_003.010.rfnoc-radio-redo-549-geb3036f6
-- X300 initialization sequence...
-- Determining maximum frame size... 1472 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Detecting internal GPSDO.... No GPSDO found
-- [RFNOC] ------- Block Setup -----------
-- SEND (SID: 00:68>02:30)...Setting up NoC-Shell Control for port #0 (SID:
00:68>02:30)...OK
-- Port 48: Found NoC-Block with ID 12AD100000000001.
-- base_path = "/usr/local/share/uhd/rfnoc"
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/radio_x300.xml
-- SEND (SID: 00:69>02:31)...Setting up NoC-Shell Control for port #1 (SID:
00:69>02:31)...OK
-- [RFNoC Factory] block_ctrl_base::make()
-- base_path = "/usr/local/share/uhd/rfnoc"
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/radio_x300.xml
-- [RFNoC Factory] Using controller key 'X300Radio' and block name 'Radio'
-- block_ctrl_base()
-- base_path = "/usr/local/share/uhd/rfnoc"
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/radio_x300.xml
-- Found valid blockdef
-- NOC ID: 0x12AD100000000001 Block ID: 0/Radio_0
-- [0/Radio_0] block_ctrl_base::clear()
-- node_ctrl_base::clear()
-- [0/Radio_0] block_ctrl_base::_clear()
-- [0/Radio_0] block_ctrl_base::_clear()
Error: EnvironmentError: IOError: [0/Radio_0] sr_read64() failed:
EnvironmentError: IOError: Radio ctrl (CE_00_Port_48) no response packet -
AssertionError: bool(buff)
in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
at /home/craig/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:203
craig@craig-VirtualBox:~/uhd/fpga-src/usrp3/top/x300/Single_Radio/build
((detached from b62d96c))$
?
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160624/3afe45c1/attachment-0001.html>
------------------------------
Message: 30
Date: Fri, 24 Jun 2016 10:37:29 -0400
From: [email protected]
To: Samy CHBINOU <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] benchmark
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Which ARM platform--that's actually pretty-good.
If you change to using 8-bit samples OTW, you can sometimes get better
performance, if that's enough dynamic range for your application.
Much depends on exactly *what* you're doing with the samples.
I have an interferometer application that runs 2 x 12.5Msps from a B210
on an Odroid XU3, but I had to strip it down to the bare minimum to get
it to work without overruns, and I had to use 8-bit samples.
On 2016-06-24 10:30, Samy CHBINOU via USRP-users wrote:
> Hello,
>
> I did some benchmark on the USRP B205mini on USB3 on linux, ARM. Over 8MSps I
> have some overflows and underflows.
>
> Is this value 8MSps considered high? low?
>
> Which system/kernel parameters can I tweak to get better results? performance
> mode? taskset on good CPU?...
>
> Samy
>
> _______________________________________________
> 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/20160624/96530f19/attachment-0001.html>
------------------------------
Message: 31
Date: Fri, 24 Jun 2016 11:34:22 -0400
From: Sam Carey <[email protected]>
To: [email protected]
Subject: [USRP-users] RFNoC Stream Tags
Message-ID:
<CAP85vD-FOUGAa3ZAbZJ8cfL+=nt9x_cb_y_+2ir7z12kkis...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Howdy,
Is it possible to inject tags into streams between RFNoC blocks?
For example, if I want an RFNoC block to precisely mark a stream with
timestamps, burst locations, center frequencies, etc.
Is there an example for this?
Thanks,
Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160624/d3d0ae45/attachment-0001.html>
------------------------------
Message: 32
Date: Fri, 24 Jun 2016 17:51:51 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] RFNoC Stream Tags
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Not at all. Tags are a GNU Radio host side concept. The USRP itself has
no notion of things like center frequencies.
However, RFNoC is based on the compressed Vita packet format, and that
does carry information like time stamps.
Best regards,
Marcus
On 06/24/2016 05:34 PM, Sam Carey via USRP-users wrote:
> Howdy,
>
> Is it possible to inject tags into streams between RFNoC blocks?
> For example, if I want an RFNoC block to precisely mark a stream with
> timestamps, burst locations, center frequencies, etc.
> Is there an example for this?
>
> Thanks,
> Sam
>
>
> _______________________________________________
> 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/20160624/977cb3d0/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 25
******************************************
