Re: [USRP-users] Multiple TX streams

[Vladica Sark via USRP-users]

Hi,

Here is the output from the tx_timed_samples when it fails. Anyway, it 
does not fail always. Sometimes everything works fine.


tx_timed_samples --args "addr0=192.168.130.2,addr1=192.168.50.2"

Creating the usrp device with: addr0=192.168.130.2,addr1=192.168.50.2...
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501; 
UHD_3.13.0.HEAD-0-gf114cfa0

[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 1472 bytes.
[INFO] [X300] Maximum frame size: 1472 bytes.
[INFO] [X300] Radio 1x clock: 200 MHz
[INFO] [1/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D000)
[INFO] [1/DmaFIFO_0] BIST passed (Throughput: 1304 MB/s)
[INFO] [1/DmaFIFO_0] BIST passed (Throughput: 1322 MB/s)
[INFO] [1/Radio_0] Initializing block control (NOC ID: 0x12AD1001)
[INFO] [1/Radio_1] Initializing block control (NOC ID: 0x12AD1001)
[INFO] [1/DDC_0] Initializing block control (NOC ID: 0xDDC0)
[INFO] [1/DDC_1] Initializing block control (NOC ID: 0xDDC0)
[INFO] [1/DUC_0] Initializing block control (NOC ID: 0xD0C0)
[INFO] [1/DUC_1] Initializing block control (NOC ID: 0xD0C0)
[INFO] [X300] Radio 1x clock: 200 MHz
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D000)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1319 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1306 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1001)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD1001)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0)
Using Device: Multi USRP:
  Device: X-Series Device
  Mboard 0: X310
  Mboard 1: X310
  RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: UBX RX
  RX Channel: 1
RX DSP: 0
RX Dboard: B
RX Subdev: UBX RX
  RX Channel: 2
RX DSP: 0
RX Dboard: A
RX Subdev: UBX RX
  RX Channel: 3
RX DSP: 0
RX Dboard: B
RX Subdev: UBX RX
  TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: UBX TX
  TX Channel: 1
TX DSP: 0
TX Dboard: B
TX Subdev: UBX TX
  TX Channel: 2
TX DSP: 0
TX Dboard: A
TX Subdev: UBX TX
  TX Channel: 3
TX DSP: 0
TX Dboard: B
TX Subdev: UBX TX

Setting TX Rate: 6.25 Msps...
Actual TX Rate: 6.25 Msps...

Setting device timestamp to 0...
Sent packet: 364 samples
Sent packet: 364 samples
Sent packet: 364 samples
Sent packet: 364 samples
Sent packet: 364 samples
Sent packet: 364 samples
Sent packet: 364 samples
Sent packet: 364 samples
Sent packet: 364 samples
Sent packet: 364 samples
Sent packet: 364 samples
Sent packet: 364 samples
Sent packet: 364 samples
Sent packet: 364 samples
Sent packet: 364 samples
Sent packet: 364 samples
Sent packet: 364 samples
Sent packet: 364 samples
Sent packet: 364 samples
Sent packet: 364 samples
Sent packet: 364 samples
Sent packet: 364 samples
Sent packet: 364 samples
Sent packet: 364 samples
Sent packet: 364 samples
Sent packet: 364 samples
Sent packet: 364 samples
Sent packet: 172 samples

Waiting for async burst ACK... fail

Done!

On 23.05.19 19:09, Marcus D. Leech wrote:

On 05/23/2019 01:02 PM, Vladica Sark wrote:
I am using 1 Gb ETH interface. The sample rate is the default for 
tx_timed_samples, i.e. 6.25 MSps. I am getting no underrun indication.
The tx_timed_samples sends the samples to the radio and schedules the 
transmission 1.5 seconds in future. If I put only 1 radio, i.e. one IP 
address, everything works perfect.
With 2 IP addresses (two radios), sometimes reports success sometimes 
fail. It seems completely undetermined.

Could you share the error output with us when you use tx_timed_samples?




BR,
Vladica


On 23.05.19 17:47, Marcus D. Leech via USRP-users wrote:

On 05/23/2019 05:39 AM, Vladica Sark via USRP-users wrote:

Hi again,

I found an easy way to reproduce the problem. I use two x310's and 
run the tx_timed_samples as:


tx_timed_samples --args "addr0=192.168.50.2,addr1=192.168.130.2" 
--secs 0.5 --nsamps 100


sometimes it fails, sometimes it works. I use larger number of 
samples to be able to notice the LED blinking.


BR,
Vladica
Are you getting any under-run indication?  What type of ethernet 
interface are you using, and at what sample rates?






On 23.05.19 08:36, Vladica Sark wrote:

Hi folks,

I have 2x X310 connected to Octoclock (10 MHz + PPS), each with 2x 
UBX frontends. I control them from a C/C++ program. Since there are 
4 channels, I create 4 tx streamers in order to transmit timed 
samples on each of them. The transmissions are not at the same time 
and this is the reason for using 4 tx streamers. The problem is 
that when I schedule timed transmissions on all of the channels (at 
the same time for test), sometimes I do n

Re: [USRP-users] Introducing Theseus Cores: Open source FPGA cores for DSP and SDR

[EJ Kreinar via USRP-users]

Hi Robert,

Thanks for the feedback!

> Do you plan to provide pre-built FPGA images containing Theseus Cores in
the future for certain USRP devices? I guess this would make it even easier
for first time users and would well suit the "batteries included" concept.

I've been considering this idea for a while now. I really like the concept
of having a few prebuilt bitstreams available, especially for usrp users
who maybe haven't gotten into rfnoc or FPGA builds.

On the other hand, I'd need a license to build images for the relevant
targets, and I'm afraid I don't have access to a license I can use in that
capacity. Also the permutations of cores and devices gets pretty large to
support.

So before I chase this idea down any further, I'm curious if there's
broader interest in having prebuilt downloadable bitstreams with a wider
selection of rfnoc cores... As a quick audience poll: anyone interested?
And what devices/configurations would you most like to see?

EJ

On Thu, May 2, 2019, 10:24 AM Robert via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi!
>
> I agree with Johannes that Schmidl&Cox OFDM sync would be a nice
> extension.
>
> Do you plan to provide pre-built FPGA images containing Theseus Cores in
> the future for certain USRP devices? I guess this would make it even easier
> for first time users and would well suit the "batteries included" concept.
>
> Cheers
> Robert
>
> -Original Message-
> From: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] On Behalf Of
> Johannes Demel via USRP-users
> Sent: Thursday, May 02, 2019 9:55 AM
> To: usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] Introducing Theseus Cores: Open source FPGA
> cores for DSP and SDR
>
> Hi EJ,
>
> this sounds like a very interesting project. Since you asked for ideas,
> I guess it would be nice to have a Schmidl&Cox style OFDM
> synchronization block.
>
> Cheers
> Johannes
>
> Am 29.04.19 um 02:00 schrieb EJ Kreinar via USRP-users:
> > Hi all,
> >
> > I'm very happy to announce the (very modest) release of the Theseus
> > Cores project: https://gitlab.com/theseus-cores/theseus-cores
> >
> > Theseus Cores is designed to provide open source FPGA cores for digital
> > signal processing and software defined radio, plus the means to *use*
> > the FPGA cores in real life In practice, that mostly means FPGA code
> > propagates up through RFNoC blocks which have both UHD and Gnuradio
> > software hooks for users to attach to. In the future it would be great
> > to support other FPGA platforms if there's interest too.
> >
> > So far, Theseus Cores provides the following RFNoC FPGA blocks and
> > corresponding software:
> > - *Polyphase M/2 Channelizer*: A polyphase channelizer where each
> > channel outputs 2x sample rate and is compatible with
> > perfect-reconstruction. Thanks to Phil Vallance for re-implementing the
> > channelizer described in his GRCon 2017 presentation-- it works!
> > - *"1-to-N" DDC Chain*: Parameterized instantiations of "N" independent
> > DDCs, where each DDC is connected to the *first* input (a very basic,
> > brute force channelizer). Note I've seen several mailing list
> > discussions in the past year about 1-to-4 or 1-to-8 DDC channelizers --
> > this block provides the generalized version of that scenario.
> > - *DUC + DDC Rational Resampler*: A "hacked" rational resampler,
> > consisting of a DUC and a DDC back-to-back. It's not pretty, but it can
> > occasionally be helpful.
> >
> > Furthermore, in an effort to TRY to create an open source FPGA project
> > that doesnt catastrophically break on a regular basis, we've set up
> > continuous integration tests for both software and FPGA. Dockerfiles are
> > provided here (https://gitlab.com/theseus-cores/theseus-docker). Theseus
>
> > Cores also pushes tagged docker images for various versions of UHD and
> > Gnuradio, where the branches for UHD-3.13, UHD-3.14, UHD's master, and
> > gnuradio's maint-3.7 are rebuilt weekly. This may be of auxiliary use to
> > people building UHD and gnuradio in a CI scenario:
> > https://hub.docker.com/u/theseuscores
> > 
> > *What's next??* It's a modest list of features so far, but I'm sure we
> > can all sympathize that things move slowly when developing FPGA code.
> > Here's a quick rundown of a few ideas on the horizon:
> > - Arbitrary resampling
> > - Channel downselection for the M/2 channelizer (currently all channels
> > must be output... it's far more useful to select a subset of channels to
> > return and just grab those)
> > - Channel reconsonstruction *after* the M/2 channelizer (maybe)
> > - OFDM receiver (maybe)
> >
> > We need more ideas and contributors! Now that this thing exists, I would
> > LOVE to see Theseus Cores fill itself out with some of the more common
> > DSP utilities that really should be available as open-source... it would
> > be absolutely amazing to provide a library of components and
> > applications for FPGA develope

Re: [USRP-users] GR in the E320

[Jason Matusiak via USRP-users]

I am on sumo.  That was the version of everything that Ettus recommended for 
their stuff.



From: Philip Balister 
Sent: Thursday, May 23, 2019 3:40 PM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] GR in the E320

Which branch of meta-sdr are you using? GNURadio 3.7 is python2 only.
The master branch works with python3.

It looks like you have numpy for both verions, but the config is
different or something, I've never run into this problem.

Philip

On 05/23/2019 03:16 PM, Jason Matusiak via USRP-users wrote:
> Here is what I get:
> root@ni-neon-rev2-mender:~# python
> Python 2.7.15 (default, May 17 2019, 15:52:34)
> [GCC 7.3.0] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
 import numbers
> Traceback (most recent call last):
>   File "", line 1, in 
> ImportError: No module named numbers

>
>
> But python3.5 does work.
> root@ni-neon-rev2-mender:~# python3.5
> Python 3.5.5 (default, May 17 2019, 15:48:40)
> [GCC 7.3.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
 import numbers

>
>
> 
> From: Philip Balister 
> Sent: Thursday, May 23, 2019 1:45 PM
> To: Jason Matusiak; Ettus Mail List
> Subject: Re: [USRP-users] GR in the E320
>
> On 05/23/2019 12:25 PM, Jason Matusiak via USRP-users wrote:
>> OK, I've actually done that before, but when I boot up and run this command, 
>> it isn't happy:
>> root@ni-neon-rev2-mender:/usr/share/gnuradio/examples/analog# python 
>> ./fmtest.py
>> Traceback (most recent call last):
>>   File "./fmtest.py", line 23, in 
>> from gnuradio import gr
>>   File "/usr/lib/python2.7/site-packages/gnuradio/gr/__init__.py", line 44, 
>> in 
>> from top_block import *
>>   File "/usr/lib/python2.7/site-packages/gnuradio/gr/top_block.py", line 30, 
>> in 
>> from hier_block2 import hier_block2
>>   File "/usr/lib/python2.7/site-packages/gnuradio/gr/hier_block2.py", line 
>> 25, in 
>> import pmt
>>   File "/usr/lib/python2.7/site-packages/pmt/__init__.py", line 58, in 
>> 
>> from pmt_to_python import pmt_to_python as to_python
>>   File "/usr/lib/python2.7/site-packages/pmt/pmt_to_python.py", line 22, in 
>> 
>> import numpy
>>   File "/usr/lib/python2.7/site-packages/numpy/__init__.py", line 142, in 
>> 
>> from . import add_newdocs
>>   File "/usr/lib/python2.7/site-packages/numpy/add_newdocs.py", line 13, in 
>> 
>> from numpy.lib import add_newdoc
>>   File "/usr/lib/python2.7/site-packages/numpy/lib/__init__.py", line 8, in 
>> 
>> from .type_check import *
>>   File "/usr/lib/python2.7/site-packages/numpy/lib/type_check.py", line 11, 
>> in 
>> import numpy.core.numeric as _nx
>>   File "/usr/lib/python2.7/site-packages/numpy/core/__init__.py", line 35, 
>> in 
>> from . import _internal  # for freeze programs
>>   File "/usr/lib/python2.7/site-packages/numpy/core/_internal.py", line 18, 
>> in 
>> from .numerictypes import object_
>>   File "/usr/lib/python2.7/site-packages/numpy/core/numerictypes.py", line 
>> 87, in 
>> import numbers
>> ImportError: No module named numbers
>
>
> Run python and then try "import numbers". See that fail :)
>
> Now try to figure what package provides numbers. I'm busy on a
> non-gnuradio thing at them moment, but will try and make sure this isn't
> a problem with the numpy recipe.
>
> Philip
>
>>
>>
>> 
>> From: Philip Balister 
>> Sent: Thursday, May 23, 2019 12:04 PM
>> To: Jason Matusiak; Ettus Mail List
>> Subject: Re: [USRP-users] GR in the E320
>>
>> On 05/23/2019 11:54 AM, Jason Matusiak via USRP-users wrote:
>>> OK, thanks Philip,
>>>
>>> This is all a little new/different for me.
>>>
>>> So once I've added in meta-sdr, all I should need to do is run 
>>> gnuradio-demo-image?
>>>
>>> also, would I need to modify the following environment variables since I am 
>>> building something out of meta-sdr?
>>>
>>> $ TEMPLATECONF=$(pwd)/meta-ettus//conf
>>> $ source ./oe-core/oe-init-build-env ./build ./bitbake
>>
>> My email fu is terrible today 
>>
>> Probably use the templates for the E320 build then add meta-sdr by hand,
>> I'd build dev image first, it doesn't have an x server.
>>
>> And once again, I do contract work to make this stuff work, beyond the
>> cases I can play with personally.
>>
>> Philip
>>
>>
>>>
>>>
>>> 
>>> From: Philip Balister 
>>> Sent: Thursday, May 23, 2019 11:43 AM
>>> To: Jason Matusiak; Ettus Mail List
>>> Subject: Re: [USRP-users] GR in the E320
>>>
>>> Oops, replied to copy in my inbox ...
>>>
>>> Adding meta-sdr to pick up gnuradio shouldn't have changed any machine
>>> specific config.
>>>
>>> Regarding mender, it is great if you have a rack of usrp's to update,
>>> but if you are working with one, I'd skip it and write cards by hand.
>>> >From what I understand this would be much quicker.
>>>
>>> I don't have an E320, 

Re: [USRP-users] GR in the E320

[Philip Balister via USRP-users]

Which branch of meta-sdr are you using? GNURadio 3.7 is python2 only.
The master branch works with python3.

It looks like you have numpy for both verions, but the config is
different or something, I've never run into this problem.

Philip

On 05/23/2019 03:16 PM, Jason Matusiak via USRP-users wrote:
> Here is what I get:
> root@ni-neon-rev2-mender:~# python
> Python 2.7.15 (default, May 17 2019, 15:52:34)
> [GCC 7.3.0] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
 import numbers
> Traceback (most recent call last):
>   File "", line 1, in 
> ImportError: No module named numbers

> 
> 
> But python3.5 does work.
> root@ni-neon-rev2-mender:~# python3.5
> Python 3.5.5 (default, May 17 2019, 15:48:40)
> [GCC 7.3.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
 import numbers

> 
> 
> 
> From: Philip Balister 
> Sent: Thursday, May 23, 2019 1:45 PM
> To: Jason Matusiak; Ettus Mail List
> Subject: Re: [USRP-users] GR in the E320
> 
> On 05/23/2019 12:25 PM, Jason Matusiak via USRP-users wrote:
>> OK, I've actually done that before, but when I boot up and run this command, 
>> it isn't happy:
>> root@ni-neon-rev2-mender:/usr/share/gnuradio/examples/analog# python 
>> ./fmtest.py
>> Traceback (most recent call last):
>>   File "./fmtest.py", line 23, in 
>> from gnuradio import gr
>>   File "/usr/lib/python2.7/site-packages/gnuradio/gr/__init__.py", line 44, 
>> in 
>> from top_block import *
>>   File "/usr/lib/python2.7/site-packages/gnuradio/gr/top_block.py", line 30, 
>> in 
>> from hier_block2 import hier_block2
>>   File "/usr/lib/python2.7/site-packages/gnuradio/gr/hier_block2.py", line 
>> 25, in 
>> import pmt
>>   File "/usr/lib/python2.7/site-packages/pmt/__init__.py", line 58, in 
>> 
>> from pmt_to_python import pmt_to_python as to_python
>>   File "/usr/lib/python2.7/site-packages/pmt/pmt_to_python.py", line 22, in 
>> 
>> import numpy
>>   File "/usr/lib/python2.7/site-packages/numpy/__init__.py", line 142, in 
>> 
>> from . import add_newdocs
>>   File "/usr/lib/python2.7/site-packages/numpy/add_newdocs.py", line 13, in 
>> 
>> from numpy.lib import add_newdoc
>>   File "/usr/lib/python2.7/site-packages/numpy/lib/__init__.py", line 8, in 
>> 
>> from .type_check import *
>>   File "/usr/lib/python2.7/site-packages/numpy/lib/type_check.py", line 11, 
>> in 
>> import numpy.core.numeric as _nx
>>   File "/usr/lib/python2.7/site-packages/numpy/core/__init__.py", line 35, 
>> in 
>> from . import _internal  # for freeze programs
>>   File "/usr/lib/python2.7/site-packages/numpy/core/_internal.py", line 18, 
>> in 
>> from .numerictypes import object_
>>   File "/usr/lib/python2.7/site-packages/numpy/core/numerictypes.py", line 
>> 87, in 
>> import numbers
>> ImportError: No module named numbers
> 
> 
> Run python and then try "import numbers". See that fail :)
> 
> Now try to figure what package provides numbers. I'm busy on a
> non-gnuradio thing at them moment, but will try and make sure this isn't
> a problem with the numpy recipe.
> 
> Philip
> 
>>
>>
>> 
>> From: Philip Balister 
>> Sent: Thursday, May 23, 2019 12:04 PM
>> To: Jason Matusiak; Ettus Mail List
>> Subject: Re: [USRP-users] GR in the E320
>>
>> On 05/23/2019 11:54 AM, Jason Matusiak via USRP-users wrote:
>>> OK, thanks Philip,
>>>
>>> This is all a little new/different for me.
>>>
>>> So once I've added in meta-sdr, all I should need to do is run 
>>> gnuradio-demo-image?
>>>
>>> also, would I need to modify the following environment variables since I am 
>>> building something out of meta-sdr?
>>>
>>> $ TEMPLATECONF=$(pwd)/meta-ettus//conf
>>> $ source ./oe-core/oe-init-build-env ./build ./bitbake
>>
>> My email fu is terrible today 
>>
>> Probably use the templates for the E320 build then add meta-sdr by hand,
>> I'd build dev image first, it doesn't have an x server.
>>
>> And once again, I do contract work to make this stuff work, beyond the
>> cases I can play with personally.
>>
>> Philip
>>
>>
>>>
>>>
>>> 
>>> From: Philip Balister 
>>> Sent: Thursday, May 23, 2019 11:43 AM
>>> To: Jason Matusiak; Ettus Mail List
>>> Subject: Re: [USRP-users] GR in the E320
>>>
>>> Oops, replied to copy in my inbox ...
>>>
>>> Adding meta-sdr to pick up gnuradio shouldn't have changed any machine
>>> specific config.
>>>
>>> Regarding mender, it is great if you have a rack of usrp's to update,
>>> but if you are working with one, I'd skip it and write cards by hand.
>>> >From what I understand this would be much quicker.
>>>
>>> I don't have an E320, so pretty much flying blind regarding hardware issues.
>>>
>>> Philip
>>>
>>> On 05/23/2019 11:16 AM, Jason Matusiak via USRP-users wrote:
 Philip, before building one of your images, does anything need to be done 
 to get ethernet to work?  It s

Re: [USRP-users] GR in the E320

[Jason Matusiak via USRP-users]

Here is what I get:
root@ni-neon-rev2-mender:~# python
Python 2.7.15 (default, May 17 2019, 15:52:34)
[GCC 7.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numbers
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named numbers
>>>


But python3.5 does work.
root@ni-neon-rev2-mender:~# python3.5
Python 3.5.5 (default, May 17 2019, 15:48:40)
[GCC 7.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numbers
>>>



From: Philip Balister 
Sent: Thursday, May 23, 2019 1:45 PM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] GR in the E320

On 05/23/2019 12:25 PM, Jason Matusiak via USRP-users wrote:
> OK, I've actually done that before, but when I boot up and run this command, 
> it isn't happy:
> root@ni-neon-rev2-mender:/usr/share/gnuradio/examples/analog# python 
> ./fmtest.py
> Traceback (most recent call last):
>   File "./fmtest.py", line 23, in 
> from gnuradio import gr
>   File "/usr/lib/python2.7/site-packages/gnuradio/gr/__init__.py", line 44, 
> in 
> from top_block import *
>   File "/usr/lib/python2.7/site-packages/gnuradio/gr/top_block.py", line 30, 
> in 
> from hier_block2 import hier_block2
>   File "/usr/lib/python2.7/site-packages/gnuradio/gr/hier_block2.py", line 
> 25, in 
> import pmt
>   File "/usr/lib/python2.7/site-packages/pmt/__init__.py", line 58, in 
> 
> from pmt_to_python import pmt_to_python as to_python
>   File "/usr/lib/python2.7/site-packages/pmt/pmt_to_python.py", line 22, in 
> 
> import numpy
>   File "/usr/lib/python2.7/site-packages/numpy/__init__.py", line 142, in 
> 
> from . import add_newdocs
>   File "/usr/lib/python2.7/site-packages/numpy/add_newdocs.py", line 13, in 
> 
> from numpy.lib import add_newdoc
>   File "/usr/lib/python2.7/site-packages/numpy/lib/__init__.py", line 8, in 
> 
> from .type_check import *
>   File "/usr/lib/python2.7/site-packages/numpy/lib/type_check.py", line 11, 
> in 
> import numpy.core.numeric as _nx
>   File "/usr/lib/python2.7/site-packages/numpy/core/__init__.py", line 35, in 
> 
> from . import _internal  # for freeze programs
>   File "/usr/lib/python2.7/site-packages/numpy/core/_internal.py", line 18, 
> in 
> from .numerictypes import object_
>   File "/usr/lib/python2.7/site-packages/numpy/core/numerictypes.py", line 
> 87, in 
> import numbers
> ImportError: No module named numbers


Run python and then try "import numbers". See that fail :)

Now try to figure what package provides numbers. I'm busy on a
non-gnuradio thing at them moment, but will try and make sure this isn't
a problem with the numpy recipe.

Philip

>
>
> 
> From: Philip Balister 
> Sent: Thursday, May 23, 2019 12:04 PM
> To: Jason Matusiak; Ettus Mail List
> Subject: Re: [USRP-users] GR in the E320
>
> On 05/23/2019 11:54 AM, Jason Matusiak via USRP-users wrote:
>> OK, thanks Philip,
>>
>> This is all a little new/different for me.
>>
>> So once I've added in meta-sdr, all I should need to do is run 
>> gnuradio-demo-image?
>>
>> also, would I need to modify the following environment variables since I am 
>> building something out of meta-sdr?
>>
>> $ TEMPLATECONF=$(pwd)/meta-ettus//conf
>> $ source ./oe-core/oe-init-build-env ./build ./bitbake
>
> My email fu is terrible today 
>
> Probably use the templates for the E320 build then add meta-sdr by hand,
> I'd build dev image first, it doesn't have an x server.
>
> And once again, I do contract work to make this stuff work, beyond the
> cases I can play with personally.
>
> Philip
>
>
>>
>>
>> 
>> From: Philip Balister 
>> Sent: Thursday, May 23, 2019 11:43 AM
>> To: Jason Matusiak; Ettus Mail List
>> Subject: Re: [USRP-users] GR in the E320
>>
>> Oops, replied to copy in my inbox ...
>>
>> Adding meta-sdr to pick up gnuradio shouldn't have changed any machine
>> specific config.
>>
>> Regarding mender, it is great if you have a rack of usrp's to update,
>> but if you are working with one, I'd skip it and write cards by hand.
>> >From what I understand this would be much quicker.
>>
>> I don't have an E320, so pretty much flying blind regarding hardware issues.
>>
>> Philip
>>
>> On 05/23/2019 11:16 AM, Jason Matusiak via USRP-users wrote:
>>> Philip, before building one of your images, does anything need to be done 
>>> to get ethernet to work?  It seems like after using mender to setup a new 
>>> image and rebooting, I cannot bring up sfp0 to save my life.  It won't work 
>>> until I reboot again, but I think that that drops the mender image reverts 
>>> to the old one since I didn't commit it.   Any steps I am missing?
>>>
>>>
>>> 
>>> From: Jason Matusiak
>>> Sent: Tuesday, May 21, 2019 11:18 AM
>>> To: Philip Balister; Ettus Mail List
>>> Subject: Re: [USRP-users] GR in the E320
>

Re: [USRP-users] GR in the E320

[Philip Balister via USRP-users]

On 05/23/2019 12:25 PM, Jason Matusiak via USRP-users wrote:
> OK, I've actually done that before, but when I boot up and run this command, 
> it isn't happy:
> root@ni-neon-rev2-mender:/usr/share/gnuradio/examples/analog# python 
> ./fmtest.py
> Traceback (most recent call last):
>   File "./fmtest.py", line 23, in 
> from gnuradio import gr
>   File "/usr/lib/python2.7/site-packages/gnuradio/gr/__init__.py", line 44, 
> in 
> from top_block import *
>   File "/usr/lib/python2.7/site-packages/gnuradio/gr/top_block.py", line 30, 
> in 
> from hier_block2 import hier_block2
>   File "/usr/lib/python2.7/site-packages/gnuradio/gr/hier_block2.py", line 
> 25, in 
> import pmt
>   File "/usr/lib/python2.7/site-packages/pmt/__init__.py", line 58, in 
> 
> from pmt_to_python import pmt_to_python as to_python
>   File "/usr/lib/python2.7/site-packages/pmt/pmt_to_python.py", line 22, in 
> 
> import numpy
>   File "/usr/lib/python2.7/site-packages/numpy/__init__.py", line 142, in 
> 
> from . import add_newdocs
>   File "/usr/lib/python2.7/site-packages/numpy/add_newdocs.py", line 13, in 
> 
> from numpy.lib import add_newdoc
>   File "/usr/lib/python2.7/site-packages/numpy/lib/__init__.py", line 8, in 
> 
> from .type_check import *
>   File "/usr/lib/python2.7/site-packages/numpy/lib/type_check.py", line 11, 
> in 
> import numpy.core.numeric as _nx
>   File "/usr/lib/python2.7/site-packages/numpy/core/__init__.py", line 35, in 
> 
> from . import _internal  # for freeze programs
>   File "/usr/lib/python2.7/site-packages/numpy/core/_internal.py", line 18, 
> in 
> from .numerictypes import object_
>   File "/usr/lib/python2.7/site-packages/numpy/core/numerictypes.py", line 
> 87, in 
> import numbers
> ImportError: No module named numbers


Run python and then try "import numbers". See that fail :)

Now try to figure what package provides numbers. I'm busy on a
non-gnuradio thing at them moment, but will try and make sure this isn't
a problem with the numpy recipe.

Philip

> 
> 
> 
> From: Philip Balister 
> Sent: Thursday, May 23, 2019 12:04 PM
> To: Jason Matusiak; Ettus Mail List
> Subject: Re: [USRP-users] GR in the E320
> 
> On 05/23/2019 11:54 AM, Jason Matusiak via USRP-users wrote:
>> OK, thanks Philip,
>>
>> This is all a little new/different for me.
>>
>> So once I've added in meta-sdr, all I should need to do is run 
>> gnuradio-demo-image?
>>
>> also, would I need to modify the following environment variables since I am 
>> building something out of meta-sdr?
>>
>> $ TEMPLATECONF=$(pwd)/meta-ettus//conf
>> $ source ./oe-core/oe-init-build-env ./build ./bitbake
> 
> My email fu is terrible today 
> 
> Probably use the templates for the E320 build then add meta-sdr by hand,
> I'd build dev image first, it doesn't have an x server.
> 
> And once again, I do contract work to make this stuff work, beyond the
> cases I can play with personally.
> 
> Philip
> 
> 
>>
>>
>> 
>> From: Philip Balister 
>> Sent: Thursday, May 23, 2019 11:43 AM
>> To: Jason Matusiak; Ettus Mail List
>> Subject: Re: [USRP-users] GR in the E320
>>
>> Oops, replied to copy in my inbox ...
>>
>> Adding meta-sdr to pick up gnuradio shouldn't have changed any machine
>> specific config.
>>
>> Regarding mender, it is great if you have a rack of usrp's to update,
>> but if you are working with one, I'd skip it and write cards by hand.
>> >From what I understand this would be much quicker.
>>
>> I don't have an E320, so pretty much flying blind regarding hardware issues.
>>
>> Philip
>>
>> On 05/23/2019 11:16 AM, Jason Matusiak via USRP-users wrote:
>>> Philip, before building one of your images, does anything need to be done 
>>> to get ethernet to work?  It seems like after using mender to setup a new 
>>> image and rebooting, I cannot bring up sfp0 to save my life.  It won't work 
>>> until I reboot again, but I think that that drops the mender image reverts 
>>> to the old one since I didn't commit it.   Any steps I am missing?
>>>
>>>
>>> 
>>> From: Jason Matusiak
>>> Sent: Tuesday, May 21, 2019 11:18 AM
>>> To: Philip Balister; Ettus Mail List
>>> Subject: Re: [USRP-users] GR in the E320
>>>
>>> OK, that seems to be building (who knows if it will succeed), thanks.
>>>
>>> I can't seem to find directions online about how to add in my own recipes, 
>>> or those written up somewhere?  Basically, I am trying to figure out how I 
>>> can add something like gr-my_blocks to the project (either part of bitbake, 
>>> or as a stand-alone build I move over to the device afterwards.
>>>
>>> 
>>> From: Philip Balister 
>>> Sent: Tuesday, May 21, 2019 11:05 AM
>>> To: Jason Matusiak; Ettus Mail List
>>> Subject: Re: [USRP-users] GR in the E320
>>>
>>> Edit bblayers.conf in your conf directory. There is also an add layer
>>> command, but I'm old fashioned :)
>>>
>>>

Re: [USRP-users] Multiple TX streams

[Vladica Sark via USRP-users]

I would tomorrow, when I am back at work.

On 23.05.19 19:09, Marcus D. Leech wrote:

On 05/23/2019 01:02 PM, Vladica Sark wrote:
I am using 1 Gb ETH interface. The sample rate is the default for 
tx_timed_samples, i.e. 6.25 MSps. I am getting no underrun indication.
The tx_timed_samples sends the samples to the radio and schedules the 
transmission 1.5 seconds in future. If I put only 1 radio, i.e. one IP 
address, everything works perfect.
With 2 IP addresses (two radios), sometimes reports success sometimes 
fail. It seems completely undetermined.

Could you share the error output with us when you use tx_timed_samples?




BR,
Vladica


On 23.05.19 17:47, Marcus D. Leech via USRP-users wrote:

On 05/23/2019 05:39 AM, Vladica Sark via USRP-users wrote:

Hi again,

I found an easy way to reproduce the problem. I use two x310's and 
run the tx_timed_samples as:


tx_timed_samples --args "addr0=192.168.50.2,addr1=192.168.130.2" 
--secs 0.5 --nsamps 100


sometimes it fails, sometimes it works. I use larger number of 
samples to be able to notice the LED blinking.


BR,
Vladica
Are you getting any under-run indication?  What type of ethernet 
interface are you using, and at what sample rates?






On 23.05.19 08:36, Vladica Sark wrote:

Hi folks,

I have 2x X310 connected to Octoclock (10 MHz + PPS), each with 2x 
UBX frontends. I control them from a C/C++ program. Since there are 
4 channels, I create 4 tx streamers in order to transmit timed 
samples on each of them. The transmissions are not at the same time 
and this is the reason for using 4 tx streamers. The problem is 
that when I schedule timed transmissions on all of the channels (at 
the same time for test), sometimes I do not get anything with 
recv_async_msg, i.e. the timeout expires. This also happens even 
when I schedule only a single transmission from single tx streamer 
(all 4 streamers are created).
Sometimes it happens that everything is working without problems, 
i.e. I make 200 transmissions on each of the channels and I get the 
proper response from the recv_async_msg, but many times, restarting 
the same program leads to just recv_async_msg with expired timeout. 
I am using UHD 3.13.0.


I can probably use one streamer and transmitting 0's on the rest of 
the channels, but I would like to avoid LO leakage in the air.


Best regards,
Vladica


___
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] Multiple TX streams

[Marcus D. Leech via USRP-users]

On 05/23/2019 01:02 PM, Vladica Sark wrote:
I am using 1 Gb ETH interface. The sample rate is the default for 
tx_timed_samples, i.e. 6.25 MSps. I am getting no underrun indication.
The tx_timed_samples sends the samples to the radio and schedules the 
transmission 1.5 seconds in future. If I put only 1 radio, i.e. one IP 
address, everything works perfect.
With 2 IP addresses (two radios), sometimes reports success sometimes 
fail. It seems completely undetermined.

Could you share the error output with us when you use tx_timed_samples?




BR,
Vladica


On 23.05.19 17:47, Marcus D. Leech via USRP-users wrote:

On 05/23/2019 05:39 AM, Vladica Sark via USRP-users wrote:

Hi again,

I found an easy way to reproduce the problem. I use two x310's and 
run the tx_timed_samples as:


tx_timed_samples --args "addr0=192.168.50.2,addr1=192.168.130.2" 
--secs 0.5 --nsamps 100


sometimes it fails, sometimes it works. I use larger number of 
samples to be able to notice the LED blinking.


BR,
Vladica
Are you getting any under-run indication?  What type of ethernet 
interface are you using, and at what sample rates?






On 23.05.19 08:36, Vladica Sark wrote:

Hi folks,

I have 2x X310 connected to Octoclock (10 MHz + PPS), each with 2x 
UBX frontends. I control them from a C/C++ program. Since there are 
4 channels, I create 4 tx streamers in order to transmit timed 
samples on each of them. The transmissions are not at the same time 
and this is the reason for using 4 tx streamers. The problem is 
that when I schedule timed transmissions on all of the channels (at 
the same time for test), sometimes I do not get anything with 
recv_async_msg, i.e. the timeout expires. This also happens even 
when I schedule only a single transmission from single tx streamer 
(all 4 streamers are created).
Sometimes it happens that everything is working without problems, 
i.e. I make 200 transmissions on each of the channels and I get the 
proper response from the recv_async_msg, but many times, restarting 
the same program leads to just recv_async_msg with expired timeout. 
I am using UHD 3.13.0.


I can probably use one streamer and transmitting 0's on the rest of 
the channels, but I would like to avoid LO leakage in the air.


Best regards,
Vladica


___
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] Multiple TX streams

[Vladica Sark via USRP-users]

I am using 1 Gb ETH interface. The sample rate is the default for 
tx_timed_samples, i.e. 6.25 MSps. I am getting no underrun indication.
The tx_timed_samples sends the samples to the radio and schedules the 
transmission 1.5 seconds in future. If I put only 1 radio, i.e. one IP 
address, everything works perfect.
With 2 IP addresses (two radios), sometimes reports success sometimes 
fail. It seems completely undetermined.


BR,
Vladica


On 23.05.19 17:47, Marcus D. Leech via USRP-users wrote:

On 05/23/2019 05:39 AM, Vladica Sark via USRP-users wrote:

Hi again,

I found an easy way to reproduce the problem. I use two x310's and run 
the tx_timed_samples as:


tx_timed_samples --args "addr0=192.168.50.2,addr1=192.168.130.2" 
--secs 0.5 --nsamps 100


sometimes it fails, sometimes it works. I use larger number of samples 
to be able to notice the LED blinking.


BR,
Vladica
Are you getting any under-run indication?  What type of ethernet 
interface are you using, and at what sample rates?






On 23.05.19 08:36, Vladica Sark wrote:

Hi folks,

I have 2x X310 connected to Octoclock (10 MHz + PPS), each with 2x 
UBX frontends. I control them from a C/C++ program. Since there are 4 
channels, I create 4 tx streamers in order to transmit timed samples 
on each of them. The transmissions are not at the same time and this 
is the reason for using 4 tx streamers. The problem is that when I 
schedule timed transmissions on all of the channels (at the same time 
for test), sometimes I do not get anything with recv_async_msg, i.e. 
the timeout expires. This also happens even when I schedule only a 
single transmission from single tx streamer (all 4 streamers are 
created).
Sometimes it happens that everything is working without problems, 
i.e. I make 200 transmissions on each of the channels and I get the 
proper response from the recv_async_msg, but many times, restarting 
the same program leads to just recv_async_msg with expired timeout. I 
am using UHD 3.13.0.


I can probably use one streamer and transmitting 0's on the rest of 
the channels, but I would like to avoid LO leakage in the air.


Best regards,
Vladica


___
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] GR in the E320

[Jason Matusiak via USRP-users]

OK, I've actually done that before, but when I boot up and run this command, it 
isn't happy:
root@ni-neon-rev2-mender:/usr/share/gnuradio/examples/analog# python ./fmtest.py
Traceback (most recent call last):
  File "./fmtest.py", line 23, in 
from gnuradio import gr
  File "/usr/lib/python2.7/site-packages/gnuradio/gr/__init__.py", line 44, in 

from top_block import *
  File "/usr/lib/python2.7/site-packages/gnuradio/gr/top_block.py", line 30, in 

from hier_block2 import hier_block2
  File "/usr/lib/python2.7/site-packages/gnuradio/gr/hier_block2.py", line 25, 
in 
import pmt
  File "/usr/lib/python2.7/site-packages/pmt/__init__.py", line 58, in 
from pmt_to_python import pmt_to_python as to_python
  File "/usr/lib/python2.7/site-packages/pmt/pmt_to_python.py", line 22, in 

import numpy
  File "/usr/lib/python2.7/site-packages/numpy/__init__.py", line 142, in 

from . import add_newdocs
  File "/usr/lib/python2.7/site-packages/numpy/add_newdocs.py", line 13, in 

from numpy.lib import add_newdoc
  File "/usr/lib/python2.7/site-packages/numpy/lib/__init__.py", line 8, in 

from .type_check import *
  File "/usr/lib/python2.7/site-packages/numpy/lib/type_check.py", line 11, in 

import numpy.core.numeric as _nx
  File "/usr/lib/python2.7/site-packages/numpy/core/__init__.py", line 35, in 

from . import _internal  # for freeze programs
  File "/usr/lib/python2.7/site-packages/numpy/core/_internal.py", line 18, in 

from .numerictypes import object_
  File "/usr/lib/python2.7/site-packages/numpy/core/numerictypes.py", line 87, 
in 
import numbers
ImportError: No module named numbers



From: Philip Balister 
Sent: Thursday, May 23, 2019 12:04 PM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] GR in the E320

On 05/23/2019 11:54 AM, Jason Matusiak via USRP-users wrote:
> OK, thanks Philip,
>
> This is all a little new/different for me.
>
> So once I've added in meta-sdr, all I should need to do is run 
> gnuradio-demo-image?
>
> also, would I need to modify the following environment variables since I am 
> building something out of meta-sdr?
>
> $ TEMPLATECONF=$(pwd)/meta-ettus//conf
> $ source ./oe-core/oe-init-build-env ./build ./bitbake

My email fu is terrible today 

Probably use the templates for the E320 build then add meta-sdr by hand,
I'd build dev image first, it doesn't have an x server.

And once again, I do contract work to make this stuff work, beyond the
cases I can play with personally.

Philip


>
>
> 
> From: Philip Balister 
> Sent: Thursday, May 23, 2019 11:43 AM
> To: Jason Matusiak; Ettus Mail List
> Subject: Re: [USRP-users] GR in the E320
>
> Oops, replied to copy in my inbox ...
>
> Adding meta-sdr to pick up gnuradio shouldn't have changed any machine
> specific config.
>
> Regarding mender, it is great if you have a rack of usrp's to update,
> but if you are working with one, I'd skip it and write cards by hand.
>>From what I understand this would be much quicker.
>
> I don't have an E320, so pretty much flying blind regarding hardware issues.
>
> Philip
>
> On 05/23/2019 11:16 AM, Jason Matusiak via USRP-users wrote:
>> Philip, before building one of your images, does anything need to be done to 
>> get ethernet to work?  It seems like after using mender to setup a new image 
>> and rebooting, I cannot bring up sfp0 to save my life.  It won't work until 
>> I reboot again, but I think that that drops the mender image reverts to the 
>> old one since I didn't commit it.   Any steps I am missing?
>>
>>
>> 
>> From: Jason Matusiak
>> Sent: Tuesday, May 21, 2019 11:18 AM
>> To: Philip Balister; Ettus Mail List
>> Subject: Re: [USRP-users] GR in the E320
>>
>> OK, that seems to be building (who knows if it will succeed), thanks.
>>
>> I can't seem to find directions online about how to add in my own recipes, 
>> or those written up somewhere?  Basically, I am trying to figure out how I 
>> can add something like gr-my_blocks to the project (either part of bitbake, 
>> or as a stand-alone build I move over to the device afterwards.
>>
>> 
>> From: Philip Balister 
>> Sent: Tuesday, May 21, 2019 11:05 AM
>> To: Jason Matusiak; Ettus Mail List
>> Subject: Re: [USRP-users] GR in the E320
>>
>> Edit bblayers.conf in your conf directory. There is also an add layer
>> command, but I'm old fashioned :)
>>
>> Philip
>>
>> On 05/21/2019 10:50 AM, Jason Matusiak via USRP-users wrote:
>>> Interesting, thanks.  They are using sumo, so I will try to check that 
>>> branch out and see how it works.
>>>
>>> I will need to research how to add it in and build it as I see pulling it 
>>> down and checking out sumo alone isn't enough.
>>>
>>> Thanks for the insights.
>>>
>>> 
>>> From: Philip Balister 
>>> Sent: Tuesday, May 21, 2019 10:39 AM
>>> To: Jason Matusiak; Ettus Mail

Re: [USRP-users] GR in the E320

[Philip Balister via USRP-users]

On 05/23/2019 11:54 AM, Jason Matusiak via USRP-users wrote:
> OK, thanks Philip,
> 
> This is all a little new/different for me.
> 
> So once I've added in meta-sdr, all I should need to do is run 
> gnuradio-demo-image?
> 
> also, would I need to modify the following environment variables since I am 
> building something out of meta-sdr?
> 
> $ TEMPLATECONF=$(pwd)/meta-ettus//conf
> $ source ./oe-core/oe-init-build-env ./build ./bitbake

My email fu is terrible today 

Probably use the templates for the E320 build then add meta-sdr by hand,
I'd build dev image first, it doesn't have an x server.

And once again, I do contract work to make this stuff work, beyond the
cases I can play with personally.

Philip


> 
> 
> 
> From: Philip Balister 
> Sent: Thursday, May 23, 2019 11:43 AM
> To: Jason Matusiak; Ettus Mail List
> Subject: Re: [USRP-users] GR in the E320
> 
> Oops, replied to copy in my inbox ...
> 
> Adding meta-sdr to pick up gnuradio shouldn't have changed any machine
> specific config.
> 
> Regarding mender, it is great if you have a rack of usrp's to update,
> but if you are working with one, I'd skip it and write cards by hand.
>>From what I understand this would be much quicker.
> 
> I don't have an E320, so pretty much flying blind regarding hardware issues.
> 
> Philip
> 
> On 05/23/2019 11:16 AM, Jason Matusiak via USRP-users wrote:
>> Philip, before building one of your images, does anything need to be done to 
>> get ethernet to work?  It seems like after using mender to setup a new image 
>> and rebooting, I cannot bring up sfp0 to save my life.  It won't work until 
>> I reboot again, but I think that that drops the mender image reverts to the 
>> old one since I didn't commit it.   Any steps I am missing?
>>
>>
>> 
>> From: Jason Matusiak
>> Sent: Tuesday, May 21, 2019 11:18 AM
>> To: Philip Balister; Ettus Mail List
>> Subject: Re: [USRP-users] GR in the E320
>>
>> OK, that seems to be building (who knows if it will succeed), thanks.
>>
>> I can't seem to find directions online about how to add in my own recipes, 
>> or those written up somewhere?  Basically, I am trying to figure out how I 
>> can add something like gr-my_blocks to the project (either part of bitbake, 
>> or as a stand-alone build I move over to the device afterwards.
>>
>> 
>> From: Philip Balister 
>> Sent: Tuesday, May 21, 2019 11:05 AM
>> To: Jason Matusiak; Ettus Mail List
>> Subject: Re: [USRP-users] GR in the E320
>>
>> Edit bblayers.conf in your conf directory. There is also an add layer
>> command, but I'm old fashioned :)
>>
>> Philip
>>
>> On 05/21/2019 10:50 AM, Jason Matusiak via USRP-users wrote:
>>> Interesting, thanks.  They are using sumo, so I will try to check that 
>>> branch out and see how it works.
>>>
>>> I will need to research how to add it in and build it as I see pulling it 
>>> down and checking out sumo alone isn't enough.
>>>
>>> Thanks for the insights.
>>>
>>> 
>>> From: Philip Balister 
>>> Sent: Tuesday, May 21, 2019 10:39 AM
>>> To: Jason Matusiak; Ettus Mail List
>>> Subject: Re: [USRP-users] GR in the E320
>>>
>>> You need the meta-sdr layer. Choosing a branch may be tricky, only the
>>> older ones have 3.7 support. My recent work in master is all in support
>>> of transitioning to the unreleased 3.8 gnuradio, which is much better
>>> for embedded builds.
>>>
>>> Might also be some pain due to Ettus forking the uhd recipe.
>>>
>>> Philip
>>>
>>> On 05/21/2019 10:30 AM, Jason Matusiak via USRP-users wrote:
 OK, so I am a total newbie when it comes to open-embedded.  I know that 
 the docker to build doesn't include a gnuradio-image bitbake option (only 
 developer-image), so I tried to make one.  I created a new 
 gnuradio-image.bb file and added gnuradio to the list of things to build.  
 Sadly, I appear to need to do more than that as it won't build:

 oe-builder@b3d40f15af25:~$ bitbake gnuradio-image --verbose
 Loading cache: 100% 
 |##|
  Time: 0:00:00
 Loaded 2964 entries from dependency cache.
 NOTE: Resolving any missing task queue dependencies
 NOTE: selecting opkg-utils-native to satisfy 
 virtual/update-alternatives-native due to PREFERRED_PROVIDERS
 NOTE: selecting linux-yocto to satisfy virtual/kernel due to 
 PREFERRED_PROVIDERS
 NOTE: selecting pseudo-native to satisfy virtual/fakeroot-native due to 
 PREFERRED_PROVIDERS
 NOTE: selecting opkg-native to satisfy opkg-native due to 
 PREFERRED_PROVIDERS
 NOTE: selecting nativesdk-glibc to satisfy runtime nativesdk-glibc due to 
 PREFERRED_PROVIDER_virtual/nativesdk-libc = nativesdk-glibc
>

Re: [USRP-users] GR in the E320

[Jason Matusiak via USRP-users]

OK, thanks Philip,

This is all a little new/different for me.

So once I've added in meta-sdr, all I should need to do is run 
gnuradio-demo-image?

also, would I need to modify the following environment variables since I am 
building something out of meta-sdr?

$ TEMPLATECONF=$(pwd)/meta-ettus//conf
$ source ./oe-core/oe-init-build-env ./build ./bitbake



From: Philip Balister 
Sent: Thursday, May 23, 2019 11:43 AM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] GR in the E320

Oops, replied to copy in my inbox ...

Adding meta-sdr to pick up gnuradio shouldn't have changed any machine
specific config.

Regarding mender, it is great if you have a rack of usrp's to update,
but if you are working with one, I'd skip it and write cards by hand.
>From what I understand this would be much quicker.

I don't have an E320, so pretty much flying blind regarding hardware issues.

Philip

On 05/23/2019 11:16 AM, Jason Matusiak via USRP-users wrote:
> Philip, before building one of your images, does anything need to be done to 
> get ethernet to work?  It seems like after using mender to setup a new image 
> and rebooting, I cannot bring up sfp0 to save my life.  It won't work until I 
> reboot again, but I think that that drops the mender image reverts to the old 
> one since I didn't commit it.   Any steps I am missing?
>
>
> 
> From: Jason Matusiak
> Sent: Tuesday, May 21, 2019 11:18 AM
> To: Philip Balister; Ettus Mail List
> Subject: Re: [USRP-users] GR in the E320
>
> OK, that seems to be building (who knows if it will succeed), thanks.
>
> I can't seem to find directions online about how to add in my own recipes, or 
> those written up somewhere?  Basically, I am trying to figure out how I can 
> add something like gr-my_blocks to the project (either part of bitbake, or as 
> a stand-alone build I move over to the device afterwards.
>
> 
> From: Philip Balister 
> Sent: Tuesday, May 21, 2019 11:05 AM
> To: Jason Matusiak; Ettus Mail List
> Subject: Re: [USRP-users] GR in the E320
>
> Edit bblayers.conf in your conf directory. There is also an add layer
> command, but I'm old fashioned :)
>
> Philip
>
> On 05/21/2019 10:50 AM, Jason Matusiak via USRP-users wrote:
>> Interesting, thanks.  They are using sumo, so I will try to check that 
>> branch out and see how it works.
>>
>> I will need to research how to add it in and build it as I see pulling it 
>> down and checking out sumo alone isn't enough.
>>
>> Thanks for the insights.
>>
>> 
>> From: Philip Balister 
>> Sent: Tuesday, May 21, 2019 10:39 AM
>> To: Jason Matusiak; Ettus Mail List
>> Subject: Re: [USRP-users] GR in the E320
>>
>> You need the meta-sdr layer. Choosing a branch may be tricky, only the
>> older ones have 3.7 support. My recent work in master is all in support
>> of transitioning to the unreleased 3.8 gnuradio, which is much better
>> for embedded builds.
>>
>> Might also be some pain due to Ettus forking the uhd recipe.
>>
>> Philip
>>
>> On 05/21/2019 10:30 AM, Jason Matusiak via USRP-users wrote:
>>> OK, so I am a total newbie when it comes to open-embedded.  I know that the 
>>> docker to build doesn't include a gnuradio-image bitbake option (only 
>>> developer-image), so I tried to make one.  I created a new 
>>> gnuradio-image.bb file and added gnuradio to the list of things to build.  
>>> Sadly, I appear to need to do more than that as it won't build:
>>>
>>> oe-builder@b3d40f15af25:~$ bitbake gnuradio-image --verbose
>>> Loading cache: 100% 
>>> |##|
>>>  Time: 0:00:00
>>> Loaded 2964 entries from dependency cache.
>>> NOTE: Resolving any missing task queue dependencies
>>> NOTE: selecting opkg-utils-native to satisfy 
>>> virtual/update-alternatives-native due to PREFERRED_PROVIDERS
>>> NOTE: selecting linux-yocto to satisfy virtual/kernel due to 
>>> PREFERRED_PROVIDERS
>>> NOTE: selecting pseudo-native to satisfy virtual/fakeroot-native due to 
>>> PREFERRED_PROVIDERS
>>> NOTE: selecting opkg-native to satisfy opkg-native due to 
>>> PREFERRED_PROVIDERS
>>> NOTE: selecting nativesdk-glibc to satisfy runtime nativesdk-glibc due to 
>>> PREFERRED_PROVIDER_virtual/nativesdk-libc = nativesdk-glibc
>>> ERROR: Nothing RPROVIDES 'gnuradio' (but 
>>> /home/oe-builder/meta-ettus/meta-ettus-core/recipes-core/images/gnuradio-image.bb
>>>  RDEPENDS on or otherwise requires it)
>>> NOTE: Runtime target 'gnuradio' is unbuildable, removing...
>>> Missing or unbuildable dependency chain was: ['gnuradio']
>>> NOTE: Target 'gnuradio-image' is unbuildable, removing...
>>> Missing or unbuildable dependency chain was: ['gnuradio-image', 'gnuradio']
>>> ERROR: Required build target 'gnuradio-ima

Re: [USRP-users] Multiple TX streams

[Marcus D. Leech via USRP-users]

On 05/23/2019 05:39 AM, Vladica Sark via USRP-users wrote:

Hi again,

I found an easy way to reproduce the problem. I use two x310's and run 
the tx_timed_samples as:


tx_timed_samples --args "addr0=192.168.50.2,addr1=192.168.130.2" 
--secs 0.5 --nsamps 100


sometimes it fails, sometimes it works. I use larger number of samples 
to be able to notice the LED blinking.


BR,
Vladica
Are you getting any under-run indication?  What type of ethernet 
interface are you using, and at what sample rates?






On 23.05.19 08:36, Vladica Sark wrote:

Hi folks,

I have 2x X310 connected to Octoclock (10 MHz + PPS), each with 2x 
UBX frontends. I control them from a C/C++ program. Since there are 4 
channels, I create 4 tx streamers in order to transmit timed samples 
on each of them. The transmissions are not at the same time and this 
is the reason for using 4 tx streamers. The problem is that when I 
schedule timed transmissions on all of the channels (at the same time 
for test), sometimes I do not get anything with recv_async_msg, i.e. 
the timeout expires. This also happens even when I schedule only a 
single transmission from single tx streamer (all 4 streamers are 
created).
Sometimes it happens that everything is working without problems, 
i.e. I make 200 transmissions on each of the channels and I get the 
proper response from the recv_async_msg, but many times, restarting 
the same program leads to just recv_async_msg with expired timeout. I 
am using UHD 3.13.0.


I can probably use one streamer and transmitting 0's on the rest of 
the channels, but I would like to avoid LO leakage in the air.


Best regards,
Vladica


___
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] GR in the E320

[Philip Balister via USRP-users]

Oops, replied to copy in my inbox ...

Adding meta-sdr to pick up gnuradio shouldn't have changed any machine
specific config.

Regarding mender, it is great if you have a rack of usrp's to update,
but if you are working with one, I'd skip it and write cards by hand.
>From what I understand this would be much quicker.

I don't have an E320, so pretty much flying blind regarding hardware issues.

Philip

On 05/23/2019 11:16 AM, Jason Matusiak via USRP-users wrote:
> Philip, before building one of your images, does anything need to be done to 
> get ethernet to work?  It seems like after using mender to setup a new image 
> and rebooting, I cannot bring up sfp0 to save my life.  It won't work until I 
> reboot again, but I think that that drops the mender image reverts to the old 
> one since I didn't commit it.   Any steps I am missing?
> 
> 
> 
> From: Jason Matusiak
> Sent: Tuesday, May 21, 2019 11:18 AM
> To: Philip Balister; Ettus Mail List
> Subject: Re: [USRP-users] GR in the E320
> 
> OK, that seems to be building (who knows if it will succeed), thanks.
> 
> I can't seem to find directions online about how to add in my own recipes, or 
> those written up somewhere?  Basically, I am trying to figure out how I can 
> add something like gr-my_blocks to the project (either part of bitbake, or as 
> a stand-alone build I move over to the device afterwards.
> 
> 
> From: Philip Balister 
> Sent: Tuesday, May 21, 2019 11:05 AM
> To: Jason Matusiak; Ettus Mail List
> Subject: Re: [USRP-users] GR in the E320
> 
> Edit bblayers.conf in your conf directory. There is also an add layer
> command, but I'm old fashioned :)
> 
> Philip
> 
> On 05/21/2019 10:50 AM, Jason Matusiak via USRP-users wrote:
>> Interesting, thanks.  They are using sumo, so I will try to check that 
>> branch out and see how it works.
>>
>> I will need to research how to add it in and build it as I see pulling it 
>> down and checking out sumo alone isn't enough.
>>
>> Thanks for the insights.
>>
>> 
>> From: Philip Balister 
>> Sent: Tuesday, May 21, 2019 10:39 AM
>> To: Jason Matusiak; Ettus Mail List
>> Subject: Re: [USRP-users] GR in the E320
>>
>> You need the meta-sdr layer. Choosing a branch may be tricky, only the
>> older ones have 3.7 support. My recent work in master is all in support
>> of transitioning to the unreleased 3.8 gnuradio, which is much better
>> for embedded builds.
>>
>> Might also be some pain due to Ettus forking the uhd recipe.
>>
>> Philip
>>
>> On 05/21/2019 10:30 AM, Jason Matusiak via USRP-users wrote:
>>> OK, so I am a total newbie when it comes to open-embedded.  I know that the 
>>> docker to build doesn't include a gnuradio-image bitbake option (only 
>>> developer-image), so I tried to make one.  I created a new 
>>> gnuradio-image.bb file and added gnuradio to the list of things to build.  
>>> Sadly, I appear to need to do more than that as it won't build:
>>>
>>> oe-builder@b3d40f15af25:~$ bitbake gnuradio-image --verbose
>>> Loading cache: 100% 
>>> |##|
>>>  Time: 0:00:00
>>> Loaded 2964 entries from dependency cache.
>>> NOTE: Resolving any missing task queue dependencies
>>> NOTE: selecting opkg-utils-native to satisfy 
>>> virtual/update-alternatives-native due to PREFERRED_PROVIDERS
>>> NOTE: selecting linux-yocto to satisfy virtual/kernel due to 
>>> PREFERRED_PROVIDERS
>>> NOTE: selecting pseudo-native to satisfy virtual/fakeroot-native due to 
>>> PREFERRED_PROVIDERS
>>> NOTE: selecting opkg-native to satisfy opkg-native due to 
>>> PREFERRED_PROVIDERS
>>> NOTE: selecting nativesdk-glibc to satisfy runtime nativesdk-glibc due to 
>>> PREFERRED_PROVIDER_virtual/nativesdk-libc = nativesdk-glibc
>>> ERROR: Nothing RPROVIDES 'gnuradio' (but 
>>> /home/oe-builder/meta-ettus/meta-ettus-core/recipes-core/images/gnuradio-image.bb
>>>  RDEPENDS on or otherwise requires it)
>>> NOTE: Runtime target 'gnuradio' is unbuildable, removing...
>>> Missing or unbuildable dependency chain was: ['gnuradio']
>>> NOTE: Target 'gnuradio-image' is unbuildable, removing...
>>> Missing or unbuildable dependency chain was: ['gnuradio-image', 'gnuradio']
>>> ERROR: Required build target 'gnuradio-image' has no buildable providers.
>>> Missing or unbuildable dependency chain was: ['gnuradio-image', 'gnuradio']
>>>
>>> Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
>>>
>>> Anyone know how to do add it (once that works, I'll want to add some of my 
>>> own OOT packages as well)?
>>>
>>>
>>>
>>>
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>>
>>
>>

Re: [USRP-users] GR in the E320

[Jason Matusiak via USRP-users]

Philip, before building one of your images, does anything need to be done to 
get ethernet to work?  It seems like after using mender to setup a new image 
and rebooting, I cannot bring up sfp0 to save my life.  It won't work until I 
reboot again, but I think that that drops the mender image reverts to the old 
one since I didn't commit it.   Any steps I am missing?



From: Jason Matusiak
Sent: Tuesday, May 21, 2019 11:18 AM
To: Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] GR in the E320

OK, that seems to be building (who knows if it will succeed), thanks.

I can't seem to find directions online about how to add in my own recipes, or 
those written up somewhere?  Basically, I am trying to figure out how I can add 
something like gr-my_blocks to the project (either part of bitbake, or as a 
stand-alone build I move over to the device afterwards.


From: Philip Balister 
Sent: Tuesday, May 21, 2019 11:05 AM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] GR in the E320

Edit bblayers.conf in your conf directory. There is also an add layer
command, but I'm old fashioned :)

Philip

On 05/21/2019 10:50 AM, Jason Matusiak via USRP-users wrote:
> Interesting, thanks.  They are using sumo, so I will try to check that branch 
> out and see how it works.
>
> I will need to research how to add it in and build it as I see pulling it 
> down and checking out sumo alone isn't enough.
>
> Thanks for the insights.
>
> 
> From: Philip Balister 
> Sent: Tuesday, May 21, 2019 10:39 AM
> To: Jason Matusiak; Ettus Mail List
> Subject: Re: [USRP-users] GR in the E320
>
> You need the meta-sdr layer. Choosing a branch may be tricky, only the
> older ones have 3.7 support. My recent work in master is all in support
> of transitioning to the unreleased 3.8 gnuradio, which is much better
> for embedded builds.
>
> Might also be some pain due to Ettus forking the uhd recipe.
>
> Philip
>
> On 05/21/2019 10:30 AM, Jason Matusiak via USRP-users wrote:
>> OK, so I am a total newbie when it comes to open-embedded.  I know that the 
>> docker to build doesn't include a gnuradio-image bitbake option (only 
>> developer-image), so I tried to make one.  I created a new gnuradio-image.bb 
>> file and added gnuradio to the list of things to build.  Sadly, I appear to 
>> need to do more than that as it won't build:
>>
>> oe-builder@b3d40f15af25:~$ bitbake gnuradio-image --verbose
>> Loading cache: 100% 
>> |##|
>>  Time: 0:00:00
>> Loaded 2964 entries from dependency cache.
>> NOTE: Resolving any missing task queue dependencies
>> NOTE: selecting opkg-utils-native to satisfy 
>> virtual/update-alternatives-native due to PREFERRED_PROVIDERS
>> NOTE: selecting linux-yocto to satisfy virtual/kernel due to 
>> PREFERRED_PROVIDERS
>> NOTE: selecting pseudo-native to satisfy virtual/fakeroot-native due to 
>> PREFERRED_PROVIDERS
>> NOTE: selecting opkg-native to satisfy opkg-native due to PREFERRED_PROVIDERS
>> NOTE: selecting nativesdk-glibc to satisfy runtime nativesdk-glibc due to 
>> PREFERRED_PROVIDER_virtual/nativesdk-libc = nativesdk-glibc
>> ERROR: Nothing RPROVIDES 'gnuradio' (but 
>> /home/oe-builder/meta-ettus/meta-ettus-core/recipes-core/images/gnuradio-image.bb
>>  RDEPENDS on or otherwise requires it)
>> NOTE: Runtime target 'gnuradio' is unbuildable, removing...
>> Missing or unbuildable dependency chain was: ['gnuradio']
>> NOTE: Target 'gnuradio-image' is unbuildable, removing...
>> Missing or unbuildable dependency chain was: ['gnuradio-image', 'gnuradio']
>> ERROR: Required build target 'gnuradio-image' has no buildable providers.
>> Missing or unbuildable dependency chain was: ['gnuradio-image', 'gnuradio']
>>
>> Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
>>
>> Anyone know how to do add it (once that works, I'll want to add some of my 
>> own OOT packages as well)?
>>
>>
>>
>>
>> ___
>> 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] Multiple TX streams

[Vladica Sark via USRP-users]

Hi again,

I found an easy way to reproduce the problem. I use two x310's and run 
the tx_timed_samples as:


tx_timed_samples --args "addr0=192.168.50.2,addr1=192.168.130.2" --secs 
0.5 --nsamps 100


sometimes it fails, sometimes it works. I use larger number of samples 
to be able to notice the LED blinking.


BR,
Vladica


On 23.05.19 08:36, Vladica Sark wrote:

Hi folks,

I have 2x X310 connected to Octoclock (10 MHz + PPS), each with 2x UBX 
frontends. I control them from a C/C++ program. Since there are 4 
channels, I create 4 tx streamers in order to transmit timed samples on 
each of them. The transmissions are not at the same time and this is the 
reason for using 4 tx streamers. The problem is that when I schedule 
timed transmissions on all of the channels (at the same time for test), 
sometimes I do not get anything with recv_async_msg, i.e. the timeout 
expires. This also happens even when I schedule only a single 
transmission from single tx streamer (all 4 streamers are created).
Sometimes it happens that everything is working without problems, i.e. I 
make 200 transmissions on each of the channels and I get the proper 
response from the recv_async_msg, but many times, restarting the same 
program leads to just recv_async_msg with expired timeout. I am using 
UHD 3.13.0.


I can probably use one streamer and transmitting 0's on the rest of the 
channels, but I would like to avoid LO leakage in the air.


Best regards,
Vladica


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

Re: [USRP-users] x310 gpsdo get_time_now() - uhd 3.14.0 bug?

[Ilay Nissim via USRP-users]

Hi,
Also UHD 14.00 original example fails to sync_to_gps.
This is with checking the original examples shipped
with ettus official release of  uhd ver 3.14.00
running  uhd/host/build/examples$ ./sync_to_gps
Here is the output
This looks like a bug in UHD 3.14.0
--

~/uhd/host/build/examples$ ./sync_to_gps

Creating the USRP device with: ...
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
UHD_3.14.0.0-0-unknown
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 8000 bytes.
[INFO] [X300] Radio 1x clock: 200 MHz
[INFO] [GPS] Found an internal GPSDO: LC_XO, Firmware Rev 0.929a
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D000)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1319 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1315 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1001)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD1001)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0)
Using Device: Single USRP:
  Device: X-Series Device
  Mboard 0: X310
  RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: TwinRX RX0
  RX Channel: 1
RX DSP: 1
RX Dboard: A
RX Subdev: TwinRX RX1
  RX Channel: 2
RX DSP: 0
RX Dboard: B
RX Subdev: TwinRX RX0
  RX Channel: 3
RX DSP: 1
RX Dboard: B
RX Subdev: TwinRX RX1
  TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: Unknown (0x0094) - 0
  TX Channel: 1
TX DSP: 0
TX Dboard: B
TX Subdev: Unknown (0x0094) - 0

Synchronizing mboard 0: X310

**Helpful Notes on Clock/PPS 
Selection**
As you can see, the default 10 MHz Reference and 1 PPS signals are now from the 
GPSDO.
If you would like to use the internal reference(TCXO) in other applications, 
you must configure that explicitly.
You can no longer select the external SMAs for 10 MHz or 1 PPS signaling.


Waiting for reference lock...LOCKED
WARNING:  GPS not locked - time will not be accurate until locked
USRP time: 1558515302.99762
GPSDO time: 1558515304.0

ERROR: Failed to synchronize USRP time to GPS time


Regards,
Ilay Nissim
RT Embedded Team Leader

From: Ilay Nissim
Sent: Thursday, May 16, 2019 8:48 PM
To: supp...@ettus.com; usrp-users@lists.ettus.com
Cc: Ilay Nissim
Subject: x310 gpsdo get_time_now()

Hi
I have an x310 connected to gpsdo UHD ver14.0
I sync to gpsdo at start of bringup
Than use get_time_now() to follow usrp time
It look like usrp time is2x slow
Meaning if 100 seocnds should have passed - 50 seconds pass


For example
Using clock source - gpsdo time source gpsdo
 if on  init gps time is
1558028200
And usrp is
1558028200

After 100 seconds
Usrptime is
1558028250
And gps time is
1558028300

Would be happy to get feedback
Regards,
Ilay Nissim
RT Embedded Team Leader
Netline Communications Technologies Ltd
Tel: + (972) 36068171
Fax: + (972) 36068101
http://www.netlinetech.com/
Azrieli Circular Tower , Menachem Begin 132, Tel-Aviv 67021, ISRAEL


This email and the associated attachments may contain information that is 
proprietary, privileged, confidential or otherwise protected from disclosure. 
If you are not the intended recipient or otherwise have received this message 
in error, you are not authorized to read, print, retain, copy or disseminate 
this message or any part of it. If you are not the intended recipient or 
otherwise have received this message in error, please notify me immediately, 
destroy any paper copies and delete all electronic files of the message.

This email and the associated attachments may contain information that is 
proprietary, privileged, confidential or otherwise protected from disclosure. 
If you are not the intended recipient or otherwise have received this message 
in error, you are not authorized to read, print, retain, copy or disseminate 
this message or any part of it. If you are not the intended recipient or 
otherwise have received this message in error, please notify me immediately, 
destroy any paper copies and delete all electronic files of the message.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com