Re: [USRP-users] sc12 on B2xx

[RizThon via USRP-users]

Thanks again Marcus,

Just to be clear, when you say I can stream at 56MS/s on a single channel,
is it in sc16, sc12 or sc8?

I tried on a different machine, with i7-8550U and 8 or 16GB of RAM.

On Windows, I'm getting the same as before, ie lots of overflows, with
rx_samples_to_file.exe.

On Linux (from the Gnu Radio Live Environment), I installed UHD v3.13.0.1,
With rx_samples_to_file, I still can't choose sc12:

Error: LookupError: KeyError: Cannot find a conversion routine for
> conversion ID
>   Input format:  sc12_item32_le
>   Num inputs:1
>   Output format: sc16
>   Num outputs:   1

What does that mean exactly? The B210 can send the data over USB in sc12,
but then UHD doesn't have a method to convert to sc16?
Is this a limitation to rx_samples_to_file, or I'll get the same error if I
make my own C++ program?

I also tried benchmark_rate. In random mode, I have no overflow in sc8, but
in sc16 I have lots of overflows and error messages. Without the random
mode, I can go up to 36MS/s in sc16, and 56MS/s in sc12! So for some reason
it seems I can use sc12 with benchmark_rate but not rx_samples_to_file. I'm
a bit loss.


On Wed, Sep 5, 2018 at 3:09 AM Martin Braun via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 09/03/2018 07:50 PM, Marcus D. Leech via USRP-users wrote:
> > On 09/03/2018 12:15 AM, Marcus D. Leech via USRP-users wrote:
> >> On 09/03/2018 12:11 AM, RizThon wrote:
> >>> Thanks, I'll try to run it on some intel hardware ("Ettus Research
> >>> recommends using the Intel Series 7, 8, and 9 USB controllers.") as
> >>> well as on Linux.
> >>>
> >>> Concerning my question on SC12, namely which UHD version can I use,
> >>> does anyone know?
> >> SC12, SC16, SC8 should all work at least up to 3.10 or so.  I haven't
> >> tried very-latest-master in the lab, but I'll check on it tomorrow.
> >>   R&D at Ettus are out until Tuesday.
> >>
> > I can report that I ran into NO issues with SC12 at the max rate of my
> > USB 2.0 connection (10e6 SPS) with:
>
> Marcus, thanks for running these tests. We fixed a bunch of sc12-related
> issues in the 3.13 release.
>
> -- M
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Problems to use two B210 in same laptop

[Paula Taboada Troitiño via USRP-users]

Hi,
I am trying to connect two B210 in my laptop to use four RX channels. My
problem is that I can not create the two usrp objects with multi_usrp
function. I am using the following code:

std::string args1, args2;

args1 = "serial=XX;
args2 = "serial=YY";

*((uhd::usrp::multi_usrp::sptr*) usrp1) =
uhd::usrp::multi_usrp::make(args1);
*((uhd::usrp::multi_usrp::sptr*) usrp2) =
uhd::usrp::multi_usrp::make(args2);

Where XX and YY are the serial numbers of my usrps. Other option I
tried was to use a multiple string with both serial numbers:

std::string args1, args2, type, ref;

args = "serial=XX","serial=YY";
*((uhd::usrp::multi_usrp::sptr*) usrp) = uhd::usrp::multi_usrp::make(args);

In both cases I obtain a "Segment Fault" error. Could you help me?

Paula


-- 

[image: logo_170x100px.png] 



Paula Taboada Troitiño
Investigadora - Desarrolladora | Área de Comunicaciones Avanzadas
Researcher - Developer | Advanced Communications Department



Ph. (+34) 986 120 430  Ext. 3016

ptabo...@gradiant.org | www.gradiant.org

[image: Iconos Redes Sociales GRD Firma email-01]
  [image: Iconos Redes Sociales GRD
Firma email-02]   [image: Iconos Redes
Sociales GRD Firma email-03] 
 [image: Iconos Redes Sociales GRD Firma email-04]

Take care of the environment. Try not to print this email.
The information contained in this email message may be confidential
information, and may also be the subject of legal professional privilege.
If you are not the intended recipient, any use, interference with,
disclosure or copying of this material is unauthorized and prohibited.
Please inform us immediately and destroy the email. Thank you for your
cooperation.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] sc12 on B2xx

[Marcus D. Leech via USRP-users]

On 09/05/2018 07:06 AM, RizThon wrote:

Thanks again Marcus,

Just to be clear, when you say I can stream at 56MS/s on a single 
channel, is it in sc16, sc12 or sc8?
Over USB3, it shouldn't matter, except that in reality, on an actual 
computer, with an actual controller, and actual operating system,

  the bandwidth that the host machine is being asked to handle does matter.

Furthermore it matters *A LOT* exactly what your host machine is doing 
with the samples.   Discarding them is less work than just writing them
  to a file, which is less work than doing DSP operations on them, etc, 
etc.





I tried on a different machine, with i7-8550U and 8 or 16GB of RAM.

On Windows, I'm getting the same as before, ie lots of overflows, with 
rx_samples_to_file.exe.


On Linux (from the Gnu Radio Live Environment), I installed UHD v3.13.0.1,
With rx_samples_to_file, I still can't choose sc12:

Error: LookupError: KeyError: Cannot find a conversion routine for
conversion ID
  Input format:  sc12_item32_le
  Num inputs:1
  Output format: sc16
  Num outputs:   1 

What does that mean exactly? The B210 can send the data over USB in 
sc12, but then UHD doesn't have a method to convert to sc16?
Is this a limitation to rx_samples_to_file, or I'll get the same error 
if I make my own C++ program?
It may be the case that there isn't a converter from sc12 to sc16 within 
UHD.  My tests were all done with floating-point on the host side.





I also tried benchmark_rate. In random mode, I have no overflow in 
sc8, but in sc16 I have lots of overflows and error messages. Without 
the random mode, I can go up to 36MS/s in sc16, and 56MS/s in sc12! So 
for some reason it seems I can use sc12 with benchmark_rate but not 
rx_samples_to_file. I'm a bit loss.
That just means that the implementation of the random function on 
Windows is probably rather slow.


I'm going to use an analogy here.Consider something like Niagara 
Falls.   It dumps however many billions of litres per hour over the side.
  If your bucket isn't wide/deep enough, there's no way for you to 
capture all of that.The USRP hardware is capable of 56Msps--it is the

  Niagara Falls.  Your computer is the bucket.


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

Re: [USRP-users] sc12 on B2xx

[Martin Braun via USRP-users]

On Wed, Sep 05, 2018 at 11:01:18AM -0400, Marcus D. Leech wrote:
>  I also tried benchmark_rate. In random mode, I have no overflow in sc8,
>  but in sc16 I have lots of overflows and error messages. Without the
>  random mode, I can go up to 36MS/s in sc16, and 56MS/s in sc12! So for
>  some reason it seems I can use sc12 with benchmark_rate but not
>  rx_samples_to_file. I'm a bit loss.
> 
>That just means that the implementation of the random function on Windows
>is probably rather slow.
>

If I may add some comments: We *do* have converters from sc12 to sc16,
so I'm not sure what's up with that. If you have a modern computer, 56
Msps isn't considered a massive amount (GNU Radio, for example, should
have no issues chomping away that much on a modern PC).
I suspect you might have stumbled across some corner-case bug, although
it's interesting that we haven't seen this more often.

With a single channel, you should be able to go all the way up to 61.44
Msps over USB3. If you do dual-channel full-duplex, the interface
between the FX3 and the FPGA can't handle that much data unless you drop
down to sc12.

-- Martin


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

Re: [USRP-users] E310 'make' error while trying to build UHD for RFNoC

[Jason Matusiak via USRP-users]

I know that this is an old thread from Dec 2017, but I see the same issues.  I 
am running Centos now, and I am thinking that this is related to that (old 
kernels, etc.).
 
The error I see when I do the make is:
[ 39%] Building CXX object 
lib/CMakeFiles/uhd.dir/usrp/e300/e300_sysfs_hooks.cpp.o
[ 39%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/e300/e300_network.cpp.o
[ 39%] Building CXX object 
lib/CMakeFiles/uhd.dir/usrp/e300/e300_global_regs.cpp.o
[ 40%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/e300/e300_spi.cpp.o
/opt/gnuradio/v3.7.12.0_rfnoc/src/uhd/host/lib/usrp/e300/e300_spi.cpp: In 
member function 'virtual uint32_t 
uhd::usrp::e300::spidev_impl::transact_spi(int, const uhd::spi_config_t&, 
uint32_t, size_t, bool)':
/opt/gnuradio/v3.7.12.0_rfnoc/src/uhd/host/lib/usrp/e300/e300_spi.cpp:86:12: 
error: 'struct spi_ioc_transfer' has no member named 'tx_nbits'
 tr.tx_nbits = 1;
 ^
/opt/gnuradio/v3.7.12.0_rfnoc/src/uhd/host/lib/usrp/e300/e300_spi.cpp:87:12: 
error: 'struct spi_ioc_transfer' has no member named 'rx_nbits'
 tr.rx_nbits = 1;
 ^
make[2]: *** [lib/CMakeFiles/uhd.dir/usrp/e300/e300_spi.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [lib/CMakeFiles/uhd.dir/all] Error 2
make: *** [all] Error 2
 
Any idea how to get beyond this so that I can build E310 again with RFNoC?
 
 
- Original Message -  Hello,
 
 
 I am attempting to set up my E310 for RFNoC development and I have run into 
the following error while trying to build UHD from source.
 
 
 
 Any ideas on what went wrong? And how to fix this?
 
 
 Thanks in Advance,
 
 Adam Kurisko
 
 
 [ 51%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/e300/e300_spi.cpp.o
 [ 52%] Building CXX object 
lib/CMakeFiles/uhd.dir/usrp/e300/e300_sensor_manager.cpp.o
 /home/dynetics/rfnoc/uhd/host/lib/usrp/e300/e300_spi.cpp: In member function 
'virtual uint32_t uhd::usrp::e300::spidev_impl::transact_spi(int, const 
uhd::spi_config_t&, uint32_t, size_t, bool)':
 /home/dynetics/rfnoc/uhd/host/lib/usrp/e300/e300_spi.cpp:96:12: error: 'struct 
spi_ioc_transfer' has no member named 'tx_nbits'
 tr.tx_nbits = 1;
 ^
 /home/dynetics/rfnoc/uhd/host/lib/usrp/e300/e300_spi.cpp:97:12: error: 'struct 
spi_ioc_transfer' has no member named 'rx_nbits'
 tr.rx_nbits = 1;
 ^
 make[2]: *** [lib/CMakeFiles/uhd.dir/usrp/e300/e300_spi.cpp.o] Error 1
 make[2]: *** Waiting for unfinished jobs
 make[1]: *** [lib/CMakeFiles/uhd.dir/all] Error 2
 make: *** [all] Error 2 
 ___
 USRP-users mailing list
 USRP-users@lists.ettus.com
 http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] sc12 on B2xx

[Marcus D. Leech via USRP-users]

On 09/05/2018 11:19 AM, Martin Braun via USRP-users wrote:


If I may add some comments: We *do* have converters from sc12 to sc16,
so I'm not sure what's up with that. If you have a modern computer, 56
Msps isn't considered a massive amount (GNU Radio, for example, should
have no issues chomping away that much on a modern PC).
I suspect you might have stumbled across some corner-case bug, although
it's interesting that we haven't seen this more often.

For certain values of "modern", and again I'll point out
  *depending on what you're doing with the samples*.

It's one thing to chew on a large amount of bandwidth doing a "stuttered"
  FFT implementation (which is what GR does for the FFT sink, BTW).

It's quite another to be paying attention and "doing things" to every 
last sample

  at the input sample rate.

There can be differences of one or two orders of magnitude depending on 
exactly what

  you're doing with the samples.

Doing writes to the file-system at high input rates is another issue 
where CPU beefiness is only
  part of the picture--your drives and PCI subsystem have to be up to 
snuff as well.


I'll use another of my famous analogies, because I just love them so much :)

You buy a car capable of doing 300km/h without any issue.  But ignoring 
legal issues for the moment, you don't
  seem to be able to find any streets for which you're able to achieve 
that without having a fiery crash...




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

Re: [USRP-users] Issues installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)

[Jason Matusiak via USRP-users]

Philip, I know I am digging this up from early in the year, but I didn't see an 
answer.  I am having the exact same issue with the six package.  Were you ever 
able to fix this?
 
 
- Original Message -On 04/02/2018 06:58 PM, Marcus D. Leech 
wrote:
 > On 04/02/2018 06:09 PM, Philip Balister wrote:
 >> On 04/02/2018 05:01 PM, MASDR GS wrote:
 >>> I'm having issues with installing GNU radio using PYBOMBS. It
 >>> successfully
 >>> installs the SDK and UHD but once it reaches to GNU Radio I receive a
 >>> missing python six message. I have been using this guide from Ettus for
 >>> reference.
 >>>
 >>> https://kb.ettus.com/Software_Development_on_the_E310_and_E312#Preparation_using_PyBOMBS
 >>>
 >>>
 >>>
 >>> -- Python checking for six - python 2 and 3 compatibility library - not
 >>> found
 >>> CMake Error at volk/CMakeLists.txt:93 (message):
 >>>six - python 2 and 3 compatibility library required to build VOLK
 >>>
 >> Looks like the volk added a dependency on python-six and the E300 image
 >> doesn't have it. Ettus needs to create a new file system image with that
 >> package installed.
 >>
 >> Philip
 > WHile that is actually, true, in this case the user is doing
 > cross-builds on their PC host, and had installed python-six into their
 > cross-build
 >   environment, and still no joy.
 
 Adding python-six-native cleared up my build issue. Likely the real
 solution is regenerate the sdk including the native-sdk version of
 python-six.
 
 I'll poke meta-sdr for this soon to cover other users.
 
 Philip
 
 >
 >
 >>
 >>> -- Configuring incomplete, errors occurred!
 >>>
 >>>
 >>> Someone also posted the same issue but I couldn't find a response to his
 >>> question along with how  to bypass this error. I've tried installing the
 >>> lastest version of  python six-1.11.0 onto my local computer still but
 >>> having no luck. Any guidance or help is appreciated.
 >>>
 >>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-February/023677.html
 >>>
 >>>
 >>>
 >>>
 >>> ___
 >>> Discuss-gnuradio mailing list
 >>> address@hidden
 >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 >>>
 >> ___
 >> Discuss-gnuradio mailing list
 >> address@hidden
 >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 >
 >
 > ___
 > Discuss-gnuradio mailing list
 > address@hidden
 > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 >
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Issues installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)

[Philip Balister via USRP-users]

On 09/05/2018 03:25 PM, Jason Matusiak via USRP-users wrote:
> Philip, I know I am digging this up from early in the year, but I didn't see 
> an answer.  I am having the exact same issue with the six package.  Were you 
> ever able to fix this?

Pretty sure the sdk from here is fixed:

https://www.dropbox.com/sh/4w19l8ixwm2ke24/AAB3aGPAkjqe9SvG32TsyK5Ia?dl=0

These are newer images based of rocko I ended creating out of another
job. Posted in case others find them useful.

Philip

>  
>  
> - Original Message -On 04/02/2018 06:58 PM, Marcus D. 
> Leech wrote:
>  > On 04/02/2018 06:09 PM, Philip Balister wrote:
>  >> On 04/02/2018 05:01 PM, MASDR GS wrote:
>  >>> I'm having issues with installing GNU radio using PYBOMBS. It
>  >>> successfully
>  >>> installs the SDK and UHD but once it reaches to GNU Radio I receive a
>  >>> missing python six message. I have been using this guide from Ettus for
>  >>> reference.
>  >>>
>  >>> 
> https://kb.ettus.com/Software_Development_on_the_E310_and_E312#Preparation_using_PyBOMBS
>  >>>
>  >>>
>  >>>
>  >>> -- Python checking for six - python 2 and 3 compatibility library - not
>  >>> found
>  >>> CMake Error at volk/CMakeLists.txt:93 (message):
>  >>>six - python 2 and 3 compatibility library required to build VOLK
>  >>>
>  >> Looks like the volk added a dependency on python-six and the E300 image
>  >> doesn't have it. Ettus needs to create a new file system image with that
>  >> package installed.
>  >>
>  >> Philip
>  > WHile that is actually, true, in this case the user is doing
>  > cross-builds on their PC host, and had installed python-six into their
>  > cross-build
>  >   environment, and still no joy.
>  
>  Adding python-six-native cleared up my build issue. Likely the real
>  solution is regenerate the sdk including the native-sdk version of
>  python-six.
>  
>  I'll poke meta-sdr for this soon to cover other users.
>  
>  Philip
>  
>  >
>  >
>  >>
>  >>> -- Configuring incomplete, errors occurred!
>  >>>
>  >>>
>  >>> Someone also posted the same issue but I couldn't find a response to his
>  >>> question along with how  to bypass this error. I've tried installing the
>  >>> lastest version of  python six-1.11.0 onto my local computer still but
>  >>> having no luck. Any guidance or help is appreciated.
>  >>>
>  >>> 
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-February/023677.html
>  >>>
>  >>>
>  >>>
>  >>>
>  >>> ___
>  >>> Discuss-gnuradio mailing list
>  >>> address@hidden
>  >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>  >>>
>  >> ___
>  >> Discuss-gnuradio mailing list
>  >> address@hidden
>  >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>  >
>  >
>  > ___
>  > Discuss-gnuradio mailing list
>  > address@hidden
>  > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>  >
> 
> 
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 

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

Re: [USRP-users] About the PCIe connection and drivers

[ALEJANDRO BLANCO PIZARRO via USRP-users]

Hi all,

I am really happy about the upgrading of the NI RIO drivers. Up to what
Ubuntu Kernel Will be?

By the way, the GitHub link in the previous email does not work.

I am looking forward to new information.

Best,
Alejandro


El mar., 4 sept. 2018 21:24, Martin Braun via USRP-users <
usrp-users@lists.ettus.com> escribió:

> On Mon, Sep 03, 2018 at 11:39:56AM +, Peng Wang via USRP-users wrote:
> >Hi all,
> >
> >I have couple of USRP X310 and also the PCIe connectivity kit.
> However, I
> >found that the driver [1] says that it can only support up to kernel
> >version 4.2.x. Since I am using ubuntu 18.04 with much newer kernel
> so I
> >cannot install the driver. My questions would be:
> >
> >1. What is the status of the new driver? It is going to be updated to
> >support newer Linux kernel soon?
> >
> >2. Is it possible to install the 4.2.x kernel in Ubuntu 18.04? I am
> not an
> >expert in Linux and my test failed in waiting for "Loading initial
> >ramdisk" after installing the kernel 4.2.8.
>
>
> We very recently updated; the current public manual is still lagging
> master branch, but you can see this page for reference:
>
> https://github.com/EttusResearch/uhddev/blob/master/host/docs/ni_rio_kernel.dox
>
> Drivers:
> http://files.ettus.com/binaries/niusrprio/niusrprio-installer-18.0.0.tar.gz
>
> -- M
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] About the PCIe connection and drivers

[Robin Coxe via USRP-users]

Minor typo in the link.  Try this one!
https://github.com/EttusResearch/uhd/blob/master/host/docs/ni_rio_kernel.dox



On Wed, Sep 5, 2018 at 12:36 PM, ALEJANDRO BLANCO PIZARRO via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I am really happy about the upgrading of the NI RIO drivers. Up to what
> Ubuntu Kernel Will be?
>
> By the way, the GitHub link in the previous email does not work.
>
> I am looking forward to new information.
>
> Best,
> Alejandro
>
>
> El mar., 4 sept. 2018 21:24, Martin Braun via USRP-users <
> usrp-users@lists.ettus.com> escribió:
>
>> On Mon, Sep 03, 2018 at 11:39:56AM +, Peng Wang via USRP-users wrote:
>> >Hi all,
>> >
>> >I have couple of USRP X310 and also the PCIe connectivity kit.
>> However, I
>> >found that the driver [1] says that it can only support up to kernel
>> >version 4.2.x. Since I am using ubuntu 18.04 with much newer kernel
>> so I
>> >cannot install the driver. My questions would be:
>> >
>> >1. What is the status of the new driver? It is going to be updated to
>> >support newer Linux kernel soon?
>> >
>> >2. Is it possible to install the 4.2.x kernel in Ubuntu 18.04? I am
>> not an
>> >expert in Linux and my test failed in waiting for "Loading initial
>> >ramdisk" after installing the kernel 4.2.8.
>>
>>
>> We very recently updated; the current public manual is still lagging
>> master branch, but you can see this page for reference:
>> https://github.com/EttusResearch/uhddev/blob/master/host/docs/ni_rio_
>> kernel.dox
>>
>> Drivers:
>> http://files.ettus.com/binaries/niusrprio/niusrprio-
>> installer-18.0.0.tar.gz
>>
>> -- M
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Issues installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)

[Andrew Danowitz via USRP-users]

Forgot to reply all, but see below:

On Wed, Sep 5, 2018 at 12:57 PM, Andrew Danowitz  wrote:

> I've worked around this by:
> 1) going into the prefix directory
> 2) source environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi (this sets
> your environment to use the built in python)
> 3) download and unzip the six library from pypi
> 4) navigate to the directory with the uncompressed six and run "python
> setup.py install"
> 5) Open a new terminal
> 6) Go back to your prefix directory and source setup_env.sh
> 7) Run pybombs rebuild gnuradio
> 8) Run pybombs install gr-ettus
>
> On Wed, Sep 5, 2018 at 12:35 PM, Philip Balister via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 09/05/2018 03:25 PM, Jason Matusiak via USRP-users wrote:
>> > Philip, I know I am digging this up from early in the year, but I
>> didn't see an answer.  I am having the exact same issue with the six
>> package.  Were you ever able to fix this?
>>
>> Pretty sure the sdk from here is fixed:
>>
>> https://www.dropbox.com/sh/4w19l8ixwm2ke24/AAB3aGPAkjqe9SvG32TsyK5Ia?dl=0
>>
>> These are newer images based of rocko I ended creating out of another
>> job. Posted in case others find them useful.
>>
>> Philip
>>
>> >
>> >
>> > - Original Message -On 04/02/2018 06:58 PM, Marcus
>> D. Leech wrote:
>> >  > On 04/02/2018 06:09 PM, Philip Balister wrote:
>> >  >> On 04/02/2018 05:01 PM, MASDR GS wrote:
>> >  >>> I'm having issues with installing GNU radio using PYBOMBS. It
>> >  >>> successfully
>> >  >>> installs the SDK and UHD but once it reaches to GNU Radio I
>> receive a
>> >  >>> missing python six message. I have been using this guide from
>> Ettus for
>> >  >>> reference.
>> >  >>>
>> >  >>> https://kb.ettus.com/Software_Development_on_the_E310_and_E3
>> 12#Preparation_using_PyBOMBS
>> >  >>>
>> >  >>>
>> >  >>>
>> >  >>> -- Python checking for six - python 2 and 3 compatibility library
>> - not
>> >  >>> found
>> >  >>> CMake Error at volk/CMakeLists.txt:93 (message):
>> >  >>>six - python 2 and 3 compatibility library required to build
>> VOLK
>> >  >>>
>> >  >> Looks like the volk added a dependency on python-six and the E300
>> image
>> >  >> doesn't have it. Ettus needs to create a new file system image with
>> that
>> >  >> package installed.
>> >  >>
>> >  >> Philip
>> >  > WHile that is actually, true, in this case the user is doing
>> >  > cross-builds on their PC host, and had installed python-six into
>> their
>> >  > cross-build
>> >  >   environment, and still no joy.
>> >
>> >  Adding python-six-native cleared up my build issue. Likely the real
>> >  solution is regenerate the sdk including the native-sdk version of
>> >  python-six.
>> >
>> >  I'll poke meta-sdr for this soon to cover other users.
>> >
>> >  Philip
>> >
>> >  >
>> >  >
>> >  >>
>> >  >>> -- Configuring incomplete, errors occurred!
>> >  >>>
>> >  >>>
>> >  >>> Someone also posted the same issue but I couldn't find a response
>> to his
>> >  >>> question along with how  to bypass this error. I've tried
>> installing the
>> >  >>> lastest version of  python six-1.11.0 onto my local computer still
>> but
>> >  >>> having no luck. Any guidance or help is appreciated.
>> >  >>>
>> >  >>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/
>> 2017-February/023677.html
>> >  >>>
>> >  >>>
>> >  >>>
>> >  >>>
>> >  >>> ___
>> >  >>> Discuss-gnuradio mailing list
>> >  >>> address@hidden
>> >  >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >  >>>
>> >  >> ___
>> >  >> Discuss-gnuradio mailing list
>> >  >> address@hidden
>> >  >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >  >
>> >  >
>> >  > ___
>> >  > Discuss-gnuradio mailing list
>> >  > address@hidden
>> >  > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >  >
>> >
>> >
>> >
>> > ___
>> > USRP-users mailing list
>> > USRP-users@lists.ettus.com
>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>

-- 

Information contained, linked, or attached to this email and all verbal 
communications from WhiteFox Defense to your entity in the prior 30 days 
constitute proprietary and confidential information unless otherwise 
indicated and is therefore subject to obligations in any executed 
confidentiality agreements. Further, this email is intended solely for the 
use of the individual or entity to whom they are addressed. If you are not 
the intended recipient and this message has been addressed to you in error, 
please promptly notify i...@whitefoxdefense.com 
 and destroy all copies of the message and 
any attachme

Re: [USRP-users] Transmit Thread Stuck Receiving Tx Flow Control Packets

[Alan Conrad via USRP-users]

I tried Brian’s suggestion to rebuild UHD and the FPGA off of the commits he 
suggested (thanks Brian).  However, with this combination I am getting 
significantly more underruns than I did previously, even with the benchmark 
rate program.  Here’s the output of benchmark_rate that I got originally with 
UHD 4.0.0.rfnoc-devel-788-g1f8463cc.

./benchmark_rate --rx_rate 100e6 --tx_rate 100e6 --channels="0,1"

Benchmark rate summary:
  Num received samples: 2016651900
  Num dropped samples:  0
  Num overruns detected:0
  Num transmitted samples:  2005972016
  Num sequence errors (Tx): 0
  Num sequence errors (Rx): 0
  Num underruns detected:   562
  Num late commands:0
  Num timeouts (Tx):0
  Num timeouts (Rx):0

And now I get this with UHD 3.14.0.HEAD-31-g98057752.

Benchmark rate summary:
  Num received samples: 2001309816
  Num dropped samples:  0
  Num overruns detected:0
  Num transmitted samples:  1841996424
  Num sequence errors (Tx): 0
  Num sequence errors (Rx): 0
  Num underruns detected:   353655
  Num late commands:0
  Num timeouts (Tx):0
  Num timeouts (Rx):0

One difference I did notice between these two versions of UHD is the maximum 
samples per packet returned from the get_max_num_samps() function for both the 
Rx and Tx streams.  With the version from the rfnoc-devel branch, I get 1996 
samples for both the Rx and Tx streams.  But, the UHD 3.14.0 version gives 1996 
samples for the Rx stream but only 996 samples for the Tx stream.  I’m not sure 
if this is causing the additional underruns.

In any case, was a change made to limit the number of transmit samples per 
packet?  Are there additional network configurations that I need to make to 
increase the maximum samples per packet for the Tx stream or to limit the 
underruns with these versions of UHD and the FPGA firmware?  BTW, setting “spp” 
in the transmit stream args does not allow more than the 996 samples per packet.

Thanks,

Alan


From: Brian Padalino 
Sent: Tuesday, August 28, 2018 8:57 PM
To: Alan Conrad 
Cc: USRP-users@lists.ettus.com
Subject: Re: [USRP-users] Transmit Thread Stuck Receiving Tx Flow Control 
Packets


On Tue, Aug 28, 2018 at 4:02 PM Alan Conrad via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
Hi All,

I’ve been working on an application that requires two receive streams and two 
transmit streams, written using the C++ API.  I have run into a problem when 
transmitting packets and I am hoping that someone has seen something similar 
and/or may be able to shed some light on this.

My application is streaming two receive and two transmit channels, each at 100 
Msps over dual 10GigE interfaces (NIC is Intel X520-DA2).  I have two receive 
threads, each calling recv() on separate receive streams, and two transmit 
threads each calling send(), also on separate transmit streams.  Each receive 
thread copies samples into a large circular buffer.  Each transmit thread reads 
samples from the buffer to be sent in the send() call.  So, each receive thread 
is paired with a transmit thread through a shared circular buffer with some 
mutex locking to prevent simultaneous access to shared circular buffer memory.

I did read in the UHD manual that recv() is not thread safe.  I assumed that 
this meant that recv() is not thread safe when called on the same rx_streamer 
from two different threads but would be ok when called on different 
rx_streamers.  If this is not the case, please let me know.

On to my problem…

After running for several minutes, one of the transmit threads will get stuck 
in the send() call.  Using strace to monitor the system calls it appears that 
the thread is in a loop continuously calling the
poll() and recvfrom() system calls from within the UHD API.  Here’s the output 
of strace attached to one of the transmit threads after this has occurred.  
These are the only two system calls that get logged for the transmit thread 
once this problem occurs.

11:19:04.564078 poll([{fd=62, events=POLLIN}], 1, 100) = 0 (Timeout)
11:19:04.664276 recvfrom(62, 0x5619724e90c0, 1472, MSG_DONTWAIT, NULL, NULL) = 
-1 EAGAIN (Resource temporarily unavailable)
11:19:04.664381 poll([{fd=62, events=POLLIN}], 1, 100) = 0 (Timeout)
11:19:04.764600 recvfrom(62, 0x5619724e90c0, 1472, MSG_DONTWAIT, NULL, NULL) = 
-1 EAGAIN (Resource temporarily unavailable)
11:19:04.764699 poll([{fd=62, events=POLLIN}], 1, 100) = 0 (Timeout)
11:19:04.864906 recvfrom(62, 0x5619724e90c0, 1472, MSG_DONTWAIT, NULL, NULL) = 
-1 EAGAIN (Resource temporarily unavailable)

This partial stack trace shows that the transmit thread is stuck in the while 
loop in the tx_flow_ctrl() function.  I think this is happening due to missed 
or missing TX flow control packets.

#0  0x7fdb8fe4fbf9 in __GI___poll (fds=fds@entry=0x7fdb167fb510, 
nfds=nfds@entry=1, timeout=timeout@entry=100) at 
../sysdeps/unix/sysv/linux/poll.c:29
#1  0x7fdb9186de45 in poll (__timeout=100, __nfds=1, _