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: benchmark (Marcus M?ller)
2. Re: benchmark (Samy CHBINOU)
3. Re: benchmark (Marcus M?ller)
4. Re: benchmark (Marcus D. Leech)
5. Calibration of a B210 (Javier Coronel (Expo Impex, S.L.))
6. Re: Calibration of a B210 (Marcus M?ller)
7. Re: RFNoC Data Streaming Pattern (Jonathon Pendlum)
8. Re: Regarding problem in USRP after power start,
(Brijendra Sharma)
9. Re: benchmark (Ian Buckley)
10. Re: Regarding problem in USRP after power start,
(Brijendra Sharma)
11. BER VS SNR
(Prativadi Bhayankaram, Narasimha Anirudh Srinivas (UMKC-Student))
12. benchmark_rate problem ([email protected])
13. Re: Regarding problem in USRP after power start, (Marcus M?ller)
14. Re: benchmark_rate problem ([email protected])
15. Re: RFNoC Installation Problems (devin kelly)
----------------------------------------------------------------------
Message: 1
Date: Sun, 26 Jun 2016 19:16:05 +0200
From: Marcus M?ller <[email protected]>
To: Samy CHBINOU <[email protected]>, Samy CHBINOU via
USRP-users <[email protected]>, [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] benchmark
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
As a comment: "8 bit in the wire" means 8 bit per real and 8 bit imaginary
part, so 8 MS/s implies a data rate of 128 Mb/s, excluding overhead.
Best regards,
Marcus
Am 26. Juni 2016 13:41:33 MESZ, schrieb Samy CHBINOU via USRP-users
<[email protected]>:
>Hello,
>
>It is an Odroid XUA4. 8MSps with 8bits means 64Mbits/s bandwith? I
>thought that usb3 could go up to 5Gbit/s... that's why I foind this
>value really low...
>
>
>Le 24/06/2016 ? 16:37, [email protected] a ?crit :
>>
>> 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] <mailto:[email protected]>
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>--
>Best Regards - Cordialement
>GreenFLOPS? EURL
>Samy CHBINOU
>Software Engineer - Managing Partner
>T?l. 06.67.89.55.87 www.greenflops.com
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>USRP-users mailing list
>[email protected]
>http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160626/fec8a83e/attachment-0001.html>
------------------------------
Message: 2
Date: Sun, 26 Jun 2016 19:49:16 +0200
From: Samy CHBINOU <[email protected]>
To: Marcus M?ller <[email protected]>, Samy CHBINOU via
USRP-users <[email protected]>, [email protected]
Subject: Re: [USRP-users] benchmark
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Oh, ok. I didn't know that. It's the double then. I did a
./benchmark_rate --args="master_clock_rate=30.72e6" --rx_rate=8e6
--tx_rate=8e6
I dont understand what is the default sample size of sc16? 16, 32?
Le 26/06/2016 ? 19:16, Marcus M?ller a ?crit :
> As a comment: "8 bit in the wire" means 8 bit per real and 8 bit
> imaginary part, so 8 MS/s implies a data rate of 128 Mb/s, excluding
> overhead.
>
> Best regards,
> Marcus
>
> Am 26. Juni 2016 13:41:33 MESZ, schrieb Samy CHBINOU via USRP-users
> <[email protected]>:
>
> Hello,
>
> It is an Odroid XUA4. 8MSps with 8bits means 64Mbits/s bandwith? I
> thought that usb3 could go up to 5Gbit/s... that's why I foind
> this value really low...
>
>
> Le 24/06/2016 ? 16:37, [email protected] a ?crit :
>>
>> 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] <mailto:[email protected]>
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> --
> Best Regards - Cordialement
> GreenFLOPS? EURL
> Samy CHBINOU
> Software Engineer - Managing Partner
> T?l. 06.67.89.55.87www.greenflops.com
>
> ------------------------------------------------------------------------
>
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
Best Regards - Cordialement
GreenFLOPS? EURL
Samy CHBINOU
Software Engineer - Managing Partner
T?l. 06.67.89.55.87 www.greenflops.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160626/eebbfefb/attachment-0001.html>
------------------------------
Message: 3
Date: Sun, 26 Jun 2016 20:05:29 +0200
From: Marcus M?ller <[email protected]>
To: Samy CHBINOU <[email protected]>, Samy CHBINOU via
USRP-users <[email protected]>, [email protected]
Subject: Re: [USRP-users] benchmark
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Samy,
>
> ./benchmark_rate --args="master_clock_rate=30.72e6" --rx_rate=8e6
> --tx_rate=8e6
>
That won't work. The master clock rate must be a multiple of the
sampling rates. Since you've first fixed the master clock rate to 30.72
MHz, UHD will try to chose the closest RX and TX rates, which probably
are 30.72/4 MS/s.
> I dont understand what is the default sample size of sc16? 16, 32?
First of all, let's justify SC16 as default format: It is a good choice
in general, seeing that the 12 bit ADC signal sees some bit
widening/accuracy gain/quantization noise suppression in the DSP chain
(due to the master clock rate/f_sample oversampling!).
So, SC16 means "Signed integer Complex 16 bit", which means each sample
contains 16 bit real, 16 bit imag, leading to 32 bit for the whole sample.
Best regards,
Marcus
On 06/26/2016 07:49 PM, Samy CHBINOU wrote:
>
> Oh, ok. I didn't know that. It's the double then. I did a
>
> ./benchmark_rate --args="master_clock_rate=30.72e6" --rx_rate=8e6
> --tx_rate=8e6
>
> I dont understand what is the default sample size of sc16? 16, 32?
>
>
> Le 26/06/2016 ? 19:16, Marcus M?ller a ?crit :
>> As a comment: "8 bit in the wire" means 8 bit per real and 8 bit
>> imaginary part, so 8 MS/s implies a data rate of 128 Mb/s, excluding
>> overhead.
>>
>> Best regards,
>> Marcus
>>
>> Am 26. Juni 2016 13:41:33 MESZ, schrieb Samy CHBINOU via USRP-users
>> <[email protected]>:
>>
>> Hello,
>>
>> It is an Odroid XUA4. 8MSps with 8bits means 64Mbits/s bandwith?
>> I thought that usb3 could go up to 5Gbit/s... that's why I foind
>> this value really low...
>>
>>
>> Le 24/06/2016 ? 16:37, [email protected] a ?crit :
>>>
>>> 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
>>
>> --
>> Best Regards - Cordialement
>> GreenFLOPS? EURL
>> Samy CHBINOU
>> Software Engineer - Managing Partner
>> T?l. 06.67.89.55.87 www.greenflops.com
>>
>> ------------------------------------------------------------------------
>>
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
> --
> Best Regards - Cordialement
> GreenFLOPS? EURL
> Samy CHBINOU
> Software Engineer - Managing Partner
> T?l. 06.67.89.55.87 www.greenflops.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160626/025df7e2/attachment-0001.html>
------------------------------
Message: 4
Date: Sun, 26 Jun 2016 14:16:53 -0400
From: "Marcus D. Leech" <[email protected]>
To: Marcus M?ller <[email protected]>, Samy CHBINOU
<[email protected]>, Samy CHBINOU via USRP-users
<[email protected]>
Subject: Re: [USRP-users] benchmark
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 06/26/2016 02:05 PM, Marcus M?ller wrote:
> Hi Samy,
>>
>> ./benchmark_rate --args="master_clock_rate=30.72e6" --rx_rate=8e6
>> --tx_rate=8e6
>>
> That won't work. The master clock rate must be a multiple of the
> sampling rates. Since you've first fixed the master clock rate to
> 30.72 MHz, UHD will try to chose the closest RX and TX rates, which
> probably are 30.72/4 MS/s.
>
>> I dont understand what is the default sample size of sc16? 16, 32?
> First of all, let's justify SC16 as default format: It is a good
> choice in general, seeing that the 12 bit ADC signal sees some bit
> widening/accuracy gain/quantization noise suppression in the DSP chain
> (due to the master clock rate/f_sample oversampling!).
>
> So, SC16 means "Signed integer Complex 16 bit", which means each
> sample contains 16 bit real, 16 bit imag, leading to 32 bit for the
> whole sample.
>
> Best regards,
> Marcus
>
As a tangential remark, I've found that using sc8 over-the-wire format
and using num_recv_frames=128 on the XU3/XU4 to be very helpful
in sustaining higher rates on RX.
Keep in mind that these ARM-based boards, even the "high end" ones,
barely compete, computationally, with low-end X86 systems. While
they offer USB-3.0, there's almost no way you'll see maximum USB-3.0
rates being sustained on these boards, and that's ignoring the
computational burden of whatever it is that you're doing with the
samples.
>
> On 06/26/2016 07:49 PM, Samy CHBINOU wrote:
>>
>> Oh, ok. I didn't know that. It's the double then. I did a
>>
>> ./benchmark_rate --args="master_clock_rate=30.72e6" --rx_rate=8e6
>> --tx_rate=8e6
>>
>> I dont understand what is the default sample size of sc16? 16, 32?
>>
>>
>> Le 26/06/2016 ? 19:16, Marcus M?ller a ?crit :
>>> As a comment: "8 bit in the wire" means 8 bit per real and 8 bit
>>> imaginary part, so 8 MS/s implies a data rate of 128 Mb/s, excluding
>>> overhead.
>>>
>>> Best regards,
>>> Marcus
>>>
>>> Am 26. Juni 2016 13:41:33 MESZ, schrieb Samy CHBINOU via USRP-users
>>> <[email protected]>:
>>>
>>> Hello,
>>>
>>> It is an Odroid XUA4. 8MSps with 8bits means 64Mbits/s bandwith?
>>> I thought that usb3 could go up to 5Gbit/s... that's why I foind
>>> this value really low...
>>>
>>>
>>> Le 24/06/2016 ? 16:37, [email protected] a ?crit :
>>>>
>>>> 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
>>>
>>> --
>>> Best Regards - Cordialement
>>> GreenFLOPS? EURL
>>> Samy CHBINOU
>>> Software Engineer - Managing Partner
>>> T?l. 06.67.89.55.87www.greenflops.com
>>>
>>> ------------------------------------------------------------------------
>>>
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
>> --
>> Best Regards - Cordialement
>> GreenFLOPS? EURL
>> Samy CHBINOU
>> Software Engineer - Managing Partner
>> T?l. 06.67.89.55.87www.greenflops.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160626/eb438558/attachment-0001.html>
------------------------------
Message: 5
Date: Sun, 26 Jun 2016 21:09:18 +0200
From: "Javier Coronel (Expo Impex, S.L.)" <[email protected]>
To: [email protected]
Subject: [USRP-users] Calibration of a B210
Message-ID:
<cahnh2rjm7ubufxxuhttmtxq5pc7rsq1+uyh3i5p3hlebbeb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi everyone,
I have read in another post that there is no way of auto-calibrate a B210
board using *uhd_cal_xx*. But is there any standard procedure to do a
calibration using some setup?
By now I am doing a zero-setting and maximum power received by doing some
initial measurements before start scanning, but I am not sure if I am doing
well.
My aim is no to get an equivalent value in dBm or something, but only to
get a zero setting and maximum level setting.
Thanks a lot.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160626/aca1a051/attachment-0001.html>
------------------------------
Message: 6
Date: Sun, 26 Jun 2016 21:38:00 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Calibration of a B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Javier,
the calibration in the uhd_cal*_iq_balance calibrates IQ imbalance,
uhd_cal_tx_offset calibrates the DC offset. The B210 does that
internally, so the uhd_cal programs have no meaning for it.
The calibration you're mentioning is completely different ? but I'm not
overly sure I understand what you want to meausure, either. Could you
elaborate on what you mean with "zero-setting" and "maximum power" in
this context, maybe with an example?
Best regards,
Marcus
On 06/26/2016 09:09 PM, Javier Coronel (Expo Impex, S.L.) via USRP-users
wrote:
> Hi everyone,
>
> I have read in another post that there is no way of auto-calibrate a
> B210 board using *uhd_cal_xx*. But is there any standard procedure to
> do a calibration using some setup?
>
> By now I am doing a zero-setting and maximum power received by doing
> some initial measurements before start scanning, but I am not sure if
> I am doing well.
>
> My aim is no to get an equivalent value in dBm or something, but only
> to get a zero setting and maximum level setting.
>
> Thanks a lot.
>
>
>
> _______________________________________________
> 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/20160626/47d7e6bd/attachment-0001.html>
------------------------------
Message: 7
Date: Sun, 26 Jun 2016 15:28:02 -0500
From: Jonathon Pendlum <[email protected]>
To: Zhihong Luo <[email protected]>
Cc: Zhihong Luo via USRP-users <[email protected]>
Subject: Re: [USRP-users] RFNoC Data Streaming Pattern
Message-ID:
<cagdo0usf0qqw5uku5rq0+tsndy10m+2wqrdd01hrwwh5unt...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
Yes, this is implementable. As long as your block follows AXI-Stream's
rules then you can take as many clock cycles as you want before outputting
the data. You will need to still follow AXI-Stream's flow control rules:
data is consumed when both tvalid and tready are asserted. In your case,
when your block outputs data on s_axis_data_tdata it needs to assert
s_axis_data_tvalid. It also needs to watch s_axis_data_tready and not
change s_axis_data_tdata until it is asserted. If your block generates
another output but the previous has not be consumed yet
(i.e. s_axis_data_tvalid is asserted but s_axis_data_tready hasn't asserted
yet), then it needs to store that value somewhere (like a FIFO) or better
yet it should throttle the input data by deasserting m_axis_data_tready.
Also, in most cases packet size is not a concern. If you need to, you can
control the packet size in your block's Noc script XML description.
Jonathon
On Sat, Jun 25, 2016 at 5:33 PM, Zhihong Luo <[email protected]> wrote:
> Hi Jonathon,
>
> In my block, it takes several cycles to finish operation of one valid
> sample. Usually this is done by pipelining it. However, my block only needs
> to work at low sample rate (like 5MS/s), and it will take a lot more
> resources to make it pipelining.
>
> So I am thinking about put a FIFO on the valid input data, and then the
> block processes the data one by one. So it will generate valid data with
> constant interval. Because the sample rate is slow, it should be able to
> finish the processing of one valid data packet before the next come.
>
> Do you think it is implementable? My main concern is that: 1. how large
> one data packet is? Because the fifo should be able to hold one packet. 2.
> Because the output valid data is not continuous, how should I configure the
> packet (valid, ready signal, etc).
>
> Any help will be much appreciated. Thanks a lot.
>
> Zhihong
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160626/d560dcaf/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 27 Jun 2016 07:29:31 +0530
From: Brijendra Sharma <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: Brijendra Sharma via USRP-users <[email protected]>
Subject: Re: [USRP-users] Regarding problem in USRP after power start,
Message-ID:
<CAOWb71RSK7mLq9i+W+XP+975FyA1POe3mV-yxHzFY4=tgpc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks a lot sir for replying.
But sir it was in working since last 15 days. It was nicely working on FM
receiver. I run 2 programm on USRP N210 properly with working. but now
these days i am getting problem. I am getting what should i do exactly for
resolving problem.
Sir I am User of USRP N210 device.
On 26 June 2016 at 20:44, Marcus M?ller <[email protected]> wrote:
> You're using a very old version of UHD. It will not recognise most b2xx or
> x3xx or e3xx devices.
>
> You need to uninstall both GNU Radio and UHD, install a recent version of
> UHD, and build GNU Radio to link against that version of UHD. I guess
> you've installed GNU Radio and UHD through your Linux distribution's
> package manager, which contains these obsolete versions. You must not
> install GNU Radio from that package manager again, or it will install and
> use the obsolete UHD.
>
> Best regards,
> Marcus
>
> PS: there's ladies on this list, too :) a simple "hello" is formal enough
> to address this list, IMHO.
>
> Am 25. Juni 2016 14:25:41 MESZ, schrieb Brijendra Sharma via USRP-users <
> [email protected]>:
>>
>> Dear Sir,
>> Sir I am new one for USRP. Now these days i am facing a problem
>> in USRP.
>> \
>>
>> Generating: "/home/dsplab/Desktop/BRIJENDRA/top_block.py"
>>
>> Executing: "/home/dsplab/Desktop/BRIJENDRA/top_block.py"
>>
>> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.005.005-0-unknown
>>
>> fft_impl_fftw: /home/dsplab/.gr_fftw_wisdom: Permission denied
>> Using Volk machine: sse4_2_32_orc
>> Traceback (most recent call last):
>> File "/home/dsplab/Desktop/BRIJENDRA/top_block.py", line 189, in
>> <module>
>> tb = top_block()
>> File "/home/dsplab/Desktop/BRIJENDRA/top_block.py", line 112, in
>> __init__
>> channels=range(1),
>> File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line
>> 122, in constructor_interceptor
>> return old_constructor(*args)
>> File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line
>> 1737, in make
>> return _uhd_swig.usrp_source_make(*args)
>> RuntimeError: LookupError: KeyError: No devices found for ----->
>> Empty Device Address
>>
>>
>> Please help me.
>>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
--
Thank You
Brijendra Ku Sharma
+919956796096
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160627/a5559e8b/attachment-0001.html>
------------------------------
Message: 9
Date: Sun, 26 Jun 2016 21:09:14 -0700
From: Ian Buckley <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: Marcus M?ller <[email protected]>, Samy CHBINOU
<[email protected]>, Samy CHBINOU via USRP-users
<[email protected]>
Subject: Re: [USRP-users] benchmark
Message-ID:
<cam_0oce+otrft3ucr5-umw8o+fc7v0mg7fyttbrcwv-kdyt...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
One thing to have in mind with the XU4, and probably many of the other
platforms is that the USB3 interface may be doing more than it seems, the
ethernet interface in this case is actually provided using a USB3<->
ethernet chip and a USB3 bridge all to the single USB3 port on the
host....these are cell phone application processors that have been
repurposed. FWIW I have had stuff running on the XU4 in the 20+MSPS range
with some tweaking
On Sun, Jun 26, 2016 at 11:16 AM, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> On 06/26/2016 02:05 PM, Marcus M?ller wrote:
>
> Hi Samy,
>
> ./benchmark_rate --args="master_clock_rate=30.72e6" --rx_rate=8e6
> --tx_rate=8e6
>
> That won't work. The master clock rate must be a multiple of the sampling
> rates. Since you've first fixed the master clock rate to 30.72 MHz, UHD
> will try to chose the closest RX and TX rates, which probably are 30.72/4
> MS/s.
>
> I dont understand what is the default sample size of sc16? 16, 32?
>
> First of all, let's justify SC16 as default format: It is a good choice in
> general, seeing that the 12 bit ADC signal sees some bit widening/accuracy
> gain/quantization noise suppression in the DSP chain (due to the master
> clock rate/f_sample oversampling!).
>
> So, SC16 means "Signed integer Complex 16 bit", which means each sample
> contains 16 bit real, 16 bit imag, leading to 32 bit for the whole sample.
>
> Best regards,
> Marcus
>
> As a tangential remark, I've found that using sc8 over-the-wire format and
> using num_recv_frames=128 on the XU3/XU4 to be very helpful
> in sustaining higher rates on RX.
>
>
> Keep in mind that these ARM-based boards, even the "high end" ones, barely
> compete, computationally, with low-end X86 systems. While
> they offer USB-3.0, there's almost no way you'll see maximum USB-3.0
> rates being sustained on these boards, and that's ignoring the
> computational burden of whatever it is that you're doing with the
> samples.
>
>
>
>
> On 06/26/2016 07:49 PM, Samy CHBINOU wrote:
>
> Oh, ok. I didn't know that. It's the double then. I did a
>
> ./benchmark_rate --args="master_clock_rate=30.72e6" --rx_rate=8e6
> --tx_rate=8e6
>
> I dont understand what is the default sample size of sc16? 16, 32?
>
> Le 26/06/2016 ? 19:16, Marcus M?ller a ?crit :
>
> As a comment: "8 bit in the wire" means 8 bit per real and 8 bit imaginary
> part, so 8 MS/s implies a data rate of 128 Mb/s, excluding overhead.
>
> Best regards,
> Marcus
>
> Am 26. Juni 2016 13:41:33 MESZ, schrieb Samy CHBINOU via USRP-users
> <[email protected]> <[email protected]>:
>>
>> Hello,
>>
>> It is an Odroid XUA4. 8MSps with 8bits means 64Mbits/s bandwith? I
>> thought that usb3 could go up to 5Gbit/s... that's why I foind this value
>> really low...
>>
>> Le 24/06/2016 ? 16:37, [email protected] a ?crit :
>>
>> 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
>>
>>
>> --
>> Best Regards - Cordialement
>> GreenFLOPS? EURL
>> Samy CHBINOU
>> Software Engineer - Managing Partner
>> T?l. 06.67.89.55.87 www.greenflops.com
>>
>> ------------------------------
>>
>> USRP-users mailing
>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> --
> Best Regards - Cordialement
> GreenFLOPS? EURL
> Samy CHBINOU
> Software Engineer - Managing Partner
> T?l. 06.67.89.55.87 www.greenflops.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/20160626/c1d9f8b3/attachment-0001.html>
------------------------------
Message: 10
Date: Mon, 27 Jun 2016 10:08:54 +0530
From: Brijendra Sharma <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: Brijendra Sharma via USRP-users <[email protected]>
Subject: Re: [USRP-users] Regarding problem in USRP after power start,
Message-ID:
<caowb71tldkwnqbf2omfgnodnvdrdbzp16c_xk0arxo53ox-...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks a lot sir for replying.
But sir it was in working since last 15 days. It was nicely working on FM
receiver. I run 2 programm on USRP N210 properly with working. but now
these days i am getting problem. I am getting what should i do exactly for
resolving problem.
Sir I am User of USRP N210 device.
Also in starting all led blinks but after 15 second latter LED A,B,C,E are
not blinking. And only D and F are glowing.
please help me as soon as possible.
On 27 June 2016 at 07:29, Brijendra Sharma <[email protected]> wrote:
> Thanks a lot sir for replying.
> But sir it was in working since last 15 days. It was nicely working on FM
> receiver. I run 2 programm on USRP N210 properly with working. but now
> these days i am getting problem. I am getting what should i do exactly for
> resolving problem.
> Sir I am User of USRP N210 device.
>
>
> On 26 June 2016 at 20:44, Marcus M?ller <[email protected]> wrote:
>
>> You're using a very old version of UHD. It will not recognise most b2xx
>> or x3xx or e3xx devices.
>>
>> You need to uninstall both GNU Radio and UHD, install a recent version of
>> UHD, and build GNU Radio to link against that version of UHD. I guess
>> you've installed GNU Radio and UHD through your Linux distribution's
>> package manager, which contains these obsolete versions. You must not
>> install GNU Radio from that package manager again, or it will install and
>> use the obsolete UHD.
>>
>> Best regards,
>> Marcus
>>
>> PS: there's ladies on this list, too :) a simple "hello" is formal enough
>> to address this list, IMHO.
>>
>> Am 25. Juni 2016 14:25:41 MESZ, schrieb Brijendra Sharma via USRP-users <
>> [email protected]>:
>>>
>>> Dear Sir,
>>> Sir I am new one for USRP. Now these days i am facing a
>>> problem in USRP.
>>> \
>>>
>>> Generating: "/home/dsplab/Desktop/BRIJENDRA/top_block.py"
>>>
>>> Executing: "/home/dsplab/Desktop/BRIJENDRA/top_block.py"
>>>
>>> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.005.005-0-unknown
>>>
>>> fft_impl_fftw: /home/dsplab/.gr_fftw_wisdom: Permission denied
>>> Using Volk machine: sse4_2_32_orc
>>> Traceback (most recent call last):
>>> File "/home/dsplab/Desktop/BRIJENDRA/top_block.py", line 189, in
>>> <module>
>>> tb = top_block()
>>> File "/home/dsplab/Desktop/BRIJENDRA/top_block.py", line 112, in
>>> __init__
>>> channels=range(1),
>>> File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line
>>> 122, in constructor_interceptor
>>> return old_constructor(*args)
>>> File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line
>>> 1737, in make
>>> return _uhd_swig.usrp_source_make(*args)
>>> RuntimeError: LookupError: KeyError: No devices found for ----->
>>> Empty Device Address
>>>
>>>
>>> Please help me.
>>>
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
>
>
>
> --
> Thank You
>
>
> Brijendra Ku Sharma
> +919956796096
>
>
>
>
--
Thank You
With Regards!
*Brijendra Ku Sharma*
+919956796096
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160627/3c657120/attachment-0001.html>
------------------------------
Message: 11
Date: Mon, 27 Jun 2016 04:00:30 +0000
From: "Prativadi Bhayankaram, Narasimha Anirudh Srinivas
(UMKC-Student)" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] BER VS SNR
Message-ID:
<cy1pr0101mb087598fa9ed15c975a84bc85ba...@cy1pr0101mb0875.prod.exchangelabs.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello folks ,I have been using the USRP for my research project. My main aim
is to find trade off between BER and distance for different modulation schemes.
i just wanted to know is there anyway we can do the snr vs ber simulation
using the bench marking option ?
Regards,
Anirudh.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160627/4de9a45a/attachment-0001.html>
------------------------------
Message: 12
Date: Mon, 27 Jun 2016 07:29:20 +0000
From: "[email protected]" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] benchmark_rate problem
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
Have N200 (w/gpsdo and SBX) on it's own GigE controller card and it
works fine using simple_ra etc. at sample rate of 5e6.
When I give the following command to benchmark_rate:
benchmark_rate --rx_rate 1e6 --args="addr=192.168.10.2"
--duration 10
I get:
linux; GNU C++ version 4.8.4; Boost_105400;
UHD_003.010.git-216-gb1c2d4bb
Creating the usrp device with: addr=192.168.10.2...
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
-- Detecting internal GPSDO.... Found an internal GPSDO
-- Setting references to the internal GPSDO
Using Device: Single USRP:
Device: USRP2 / N-Series Device
Mboard 0: N200r4
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: SBXv3 RX
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: SBXv3 TX
Setting device timestamp to 0...
Testing receive rate 1.000000 Msps on 1 channels
and things go quiet for the 'duration' i.e. 10 seconds and then:
Receiver error: Unknown error code: 0x10
Unexpected error on recv, continuing...
repeated forever (it seems)
I can get benchmark_rate to work with a USRP/tvrx on USB so think the
software is good.
I wonder(ed) if the GPSDO is causing some issue but varying the --ref
and --pps parameters doesn't appear to alter the outcome :(
Any advice on what I am doing wrong?
Kind Regards,
John
------------------------------
Message: 13
Date: Mon, 27 Jun 2016 14:53:28 +0200
From: Marcus M?ller <[email protected]>
To: Brijendra Sharma <[email protected]>
Cc: Brijendra Sharma via USRP-users <[email protected]>
Subject: Re: [USRP-users] Regarding problem in USRP after power start,
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Aha! That's a lot of relevant information.
It's very probable that somehow, the FPGA image got corrupted. That's
not good, but it's easily repaired.
You can boot the N210 into safe mode by pressing the S2 button while
powering on. For more information, please refer to
http://files.ettus.com/manual/page_usrp2.html#usrp2_loadflash_brick
Best regards,
Marcus
On 06/27/2016 06:38 AM, Brijendra Sharma wrote:
> Thanks a lot sir for replying.
> But sir it was in working since last 15 days. It was nicely working on
> FM receiver. I run 2 programm on USRP N210 properly with working. but
> now these days i am getting problem. I am getting what should i do
> exactly for resolving problem.
> Sir I am User of USRP N210 device.
> Also in starting all led blinks but after 15 second latter LED A,B,C,E
> are not blinking. And only D and F are glowing.
> please help me as soon as possible.
>
> On 27 June 2016 at 07:29, Brijendra Sharma <[email protected]
> <mailto:[email protected]>> wrote:
>
> Thanks a lot sir for replying.
> But sir it was in working since last 15 days. It was nicely
> working on FM receiver. I run 2 programm on USRP N210 properly
> with working. but now these days i am getting problem. I am
> getting what should i do exactly for resolving problem.
> Sir I am User of USRP N210 device.
>
>
> On 26 June 2016 at 20:44, Marcus M?ller <[email protected]
> <mailto:[email protected]>> wrote:
>
> You're using a very old version of UHD. It will not recognise
> most b2xx or x3xx or e3xx devices.
>
> You need to uninstall both GNU Radio and UHD, install a recent
> version of UHD, and build GNU Radio to link against that
> version of UHD. I guess you've installed GNU Radio and UHD
> through your Linux distribution's package manager, which
> contains these obsolete versions. You must not install GNU
> Radio from that package manager again, or it will install and
> use the obsolete UHD.
>
> Best regards,
> Marcus
>
> PS: there's ladies on this list, too :) a simple "hello" is
> formal enough to address this list, IMHO.
>
> Am 25. Juni 2016 14:25:41 MESZ, schrieb Brijendra Sharma via
> USRP-users <[email protected]
> <mailto:[email protected]>>:
>
> Dear Sir,
> Sir I am new one for USRP. Now these days i am
> facing a problem in USRP.
> \
>
> Generating: "/home/dsplab/Desktop/BRIJENDRA/top_block.py"
>
> Executing: "/home/dsplab/Desktop/BRIJENDRA/top_block.py"
>
> linux; GNU C++ version 4.8.2; Boost_105400;
> UHD_003.005.005-0-unknown
>
> fft_impl_fftw: /home/dsplab/.gr_fftw_wisdom: Permission denied
> Using Volk machine: sse4_2_32_orc
> Traceback (most recent call last):
> File "/home/dsplab/Desktop/BRIJENDRA/top_block.py", line
> 189, in <module>
> tb = top_block()
> File "/home/dsplab/Desktop/BRIJENDRA/top_block.py", line
> 112, in __init__
> channels=range(1),
> File
> "/usr/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
> line 122, in constructor_interceptor
> return old_constructor(*args)
> File
> "/usr/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> line 1737, in make
> return _uhd_swig.usrp_source_make(*args)
> RuntimeError: LookupError: KeyError: No devices found for
> ----->
> Empty Device Address
>
>
> Please help me.
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my
> brevity.
>
>
>
>
> --
> Thank You
>
>
> Brijendra Ku Sharma
> +919956796096
>
>
>
>
>
>
> --
> Thank You
>
> With Regards!
>
> *Brijendra Ku Sharma*
> +919956796096
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160627/3f37babe/attachment-0001.html>
------------------------------
Message: 14
Date: Mon, 27 Jun 2016 10:12:14 -0400
From: [email protected]
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] benchmark_rate problem
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
That's a bit odd.
What specific manufacturer/part-number ethernet controller do you have?
You can use 'lspci -v' to see details of the various controllers on your
PCI bus, including your ethernet controller.
On 2016-06-27 03:29, john.shields--- via USRP-users wrote:
> Hi,
> Have N200 (w/gpsdo and SBX) on it's own GigE controller card and it works
> fine using simple_ra etc. at sample rate of 5e6.
>
> When I give the following command to benchmark_rate:
>
> benchmark_rate --rx_rate 1e6 --args="addr=192.168.10.2" --duration 10
>
> I get:
>
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-216-gb1c2d4bb
>
> Creating the usrp device with: addr=192.168.10.2...
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
> -- Detecting internal GPSDO.... Found an internal GPSDO
> -- Setting references to the internal GPSDO
> Using Device: Single USRP:
> Device: USRP2 / N-Series Device
> Mboard 0: N200r4
> RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: SBXv3 RX
> TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: SBXv3 TX
>
> Setting device timestamp to 0...
> Testing receive rate 1.000000 Msps on 1 channels
>
> and things go quiet for the 'duration' i.e. 10 seconds and then:
>
> Receiver error: Unknown error code: 0x10
> Unexpected error on recv, continuing...
>
> repeated forever (it seems)
>
> I can get benchmark_rate to work with a USRP/tvrx on USB so think the
> software is good.
> I wonder(ed) if the GPSDO is causing some issue but varying the --ref and
> --pps parameters doesn't appear to alter the outcome :(
>
> Any advice on what I am doing wrong?
>
> Kind Regards,
>
> John
>
> _______________________________________________
> 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/20160627/77c5cbb9/attachment-0001.html>
------------------------------
Message: 15
Date: Mon, 27 Jun 2016 10:12:10 -0400
From: devin kelly <[email protected]>
To: usrp-users <[email protected]>
Subject: Re: [USRP-users] RFNoC Installation Problems
Message-ID:
<CAANLyub5PrrWFd1DiPAOhNq+qHPMVdXMJ0pMOxk-ESZoB0i=q...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
This is for the E310 - Charles and I are working on this together. I've
run into a separate problem when compiling gr-ettus (sorry, I'm not in a
state where I can post the problem but will do that as soon as I can.) I
have a few questions:
1) Which branch should we be using radio-redo or rfnoc-devel?
2) Can you complete the instructions below for the gr-ettus module:
https://kb.ettus.com/Software_Development_on_the_E310_and_E312
All the sections before gr-ettus have worked really well for me.
3) Are there instructions anywhere that will tell me how to build my own
RFNOC FPGA images? We have access to Vivado and all that - I just don't
have any experience with FPGAs.
Thanks for the help!
Devin
On Fri, Jun 24, 2016 at 1:44 PM, Martin Braun via USRP-users <
[email protected]> wrote:
> And are you crosscompiling, or native compiling (e.g. for X310)?
>
> M
>
> On 06/24/2016 07:28 AM, Jonathon Pendlum via USRP-users wrote:
> > 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]
> > <mailto:[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
> > <http://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
> > <http://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
> > <http://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
> > <http://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]
> > <mailto:[email protected]>]
> > *Sent:* Wednesday, June 22, 2016 12:17 PM
> > *To:* Yin, Charles - 0665 - MITLL
> > *Cc:* [email protected]
> > <mailto:[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] <mailto:[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] <mailto:[email protected]>
> >
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com____
> >
> > __ __
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected] <mailto:[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/20160627/40fe3a27/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 28
******************************************
