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. RFNoC Data Streaming Pattern (Zhihong Luo)
2. Re: benchmark (Samy CHBINOU)
3. Regarding problem in USRP after power start, (Brijendra Sharma)
4. Re: benchmark (Laur Joost)
5. Re: Regarding problem in USRP after power start, (Marcus M?ller)
----------------------------------------------------------------------
Message: 1
Date: Sat, 25 Jun 2016 18:33:43 -0400
From: Zhihong Luo <[email protected]>
To: Jonathon Pendlum <[email protected]>, Zhihong Luo via
USRP-users <[email protected]>
Subject: [USRP-users] RFNoC Data Streaming Pattern
Message-ID:
<CAH4wXLox2QO4L+3XWJX-3PeZjbTQ0_yvnMxQ1a5Lt_1BU=6...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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/20160625/15a31208/attachment-0001.html>
------------------------------
Message: 2
Date: Sun, 26 Jun 2016 13:41:33 +0200
From: Samy CHBINOU <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] benchmark
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160626/24e2f241/attachment-0001.html>
------------------------------
Message: 3
Date: Sat, 25 Jun 2016 17:55:41 +0530
From: Brijendra Sharma <[email protected]>
To: [email protected]
Subject: [USRP-users] Regarding problem in USRP after power start,
Message-ID:
<CAOWb71Q3WOqxM6YLLDwTXQikDj=9+0hw7tosjbzhe4pb1zy...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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.
--
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/20160625/720e6135/attachment-0001.html>
------------------------------
Message: 4
Date: Sun, 26 Jun 2016 14:55:32 +0300
From: Laur Joost <[email protected]>
To: Samy CHBINOU <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: [USRP-users] benchmark
Message-ID:
<CAEe33U-R8S=azET4k3Gs=ms+fqkjn_cxgbmq5ni4sdausxq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
The processor will be the bottleneck in that particular case. There will be
interrupts from the USB associated with the traffic, and the more time the
processor spends on those, the less it will have available for your
application. So it becomes a tradeoff between processing complexity and
total bandwidth. Of course, at one point you will reach a limit where even
writing all received data to /dev/null will be too much to handle.
Laur
2016-06-26 14:41 GMT+03:00 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160626/13bed44a/attachment-0001.html>
------------------------------
Message: 5
Date: Sun, 26 Jun 2016 17:14:33 +0200
From: Marcus M?ller <[email protected]>
To: Brijendra Sharma <[email protected]>, Brijendra Sharma via
USRP-users <[email protected]>,
[email protected]
Subject: Re: [USRP-users] Regarding problem in USRP after power start,
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
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.
>
>--
>Thank You
>
>
>Brijendra Ku Sharma
>+919956796096
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>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/6a6b9847/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 27
******************************************
