Re: [USRP-users] Problems when Running UHD_3.14.1 Examples on E310

[Jason Matusiak via USRP-users]

Zhongren,

I am not sure that this will help you, but one of the things that I did when 
working with the E31x was to install everything to ~/localhost and leave the 
default stuff alone.  I then created a setup_env.sh for those new files 
(similar to what pybombs does), and run that before I using my custom stuff.

This allows the default stuff to stay there in case I want to test with it 
again.  It also keeps all of my stuff in a single folder that I can then blow 
away if I want.

Good luck!


From: USRP-users  on behalf of zcao--- via 
USRP-users 
Sent: Monday, November 4, 2019 3:25 PM
To: Philip Balister 
Cc: USRP-users 
Subject: Re: [USRP-users] Problems when Running UHD_3.14.1 Examples on E310

Philip,

Thanks for the response. That’s what we did to get through the issue.

But is it what we supposed to do, i.e., edit these UHD provided python scripts 
manually?

Thanks,
Zhongren

On Nov 4, 2019, at 2:27 PM, Philip Balister 
mailto:phi...@balister.org>> wrote:

On 11/4/19 5:04 PM, zcao--- via USRP-users wrote:
Hi,

We are trying to run UHD examples on E310. The process we took are as the 
following.

1. Flash a fresh SDcard using the dev image located at 
http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-e3xx-sg3/
 
>

2. Cross-compile UHD source code on a development machine and install the build 
on to the E310 device using sshfs. Note that this is a different from what is 
proposed in AN-311. We installed UHD 3.14 onto the device directly.

3. Running /usr/bin/uhd_find_devices, we got the following output, looks normal.

[INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700; 
UHD_3.14.1.1-0-g0347a6d8
--
-- UHD Device 0
--
Device Address:
   serial: 31819A1
   name:
   node: /dev/axi_fpga
   product: E3XX SG3
   type: e3x0


However, we ran into the following problems, which seem to be related.

1. We cannot run /usr/bin/uhd_usrp_probe, because of the FPGA compatibility. 
Specifically, the error messages are

Error: RuntimeError: Expected FPGA compatibility number 255.x, but got 14.0:
The FPGA build is not compatible with the host code build.
Please run:

"/usr/lib/uhd/utils/uhd_images_downloader.py"


2. But running the above python script gives us the following error messages.

-sh: /usr/lib/uhd/utils/uhd_images_downloader.py: 
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/python2: bad 
interpreter: No such file or directory/

Look at the script /usr/lib/uhd/utils/uhd_images_downloader.py and edit
the #!/bin/fo/bar/python to something reasonable.

Philip



Note that the python script is looking for the SDK, which should be on the 
development machine, instead of the device itself.

Would really appreciate it if anyone knows how to handle above issues in E310 
device itself?

Thanks,
Arnold



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


Arnold Z. Cao, Ph.D.

C-3 Comm Systems, LLC
3100 Clarendon Blvd., Suite 200
Arlington, VA 22201
Phone: (703) 829-0588
Email : z...@c3commsystems.com

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

Re: [USRP-users] RFNoC Radio Issue

[Jason Matusiak via USRP-users]

Jonathon, If you look at the more recent commits for UHD, they added in a fix 
to the split_stream error.  Basically you need to change a 1'b1 to a 2'b11 in 
the noc_shell section (I think that is the section, I can't recall off the top 
of my head).  Try that and rebuild.


From: USRP-users  on behalf of Jonathan 
Lockhart via USRP-users 
Sent: Thursday, October 31, 2019 3:30 PM
To: USRP-users@lists.ettus.com ; supp...@ettus.com 

Subject: Re: [USRP-users] RFNoC Radio Issue

Apologies, the files are attached.

On Thu, Oct 31, 2019 at 3:30 PM Jonathan Lockhart 
mailto:jlockhar...@gmail.com>> wrote:
Greetings,

I was wondering if anyone else has had this issue with the RFNoC radio block.

So I was using the copy block with the rfnoc_fosphor_network_usrp.grc file as I 
wanted to split off the signal before it went off to the RFNoC Window. So I put 
in a copy block (since the RFNoC Split block appears to be broken) and passed 
the data off to a ZMQ Push and back to the window to continue to be processed 
by the FPGA. GNURadio says this is all well and good since all vectors are 512 
and builds the file. However, when I run the .py file on my E312 it throws an 
error stating that the radio is providing data of size 8 when the copy block 
expects to get data of size 512 (the vector size).

[INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700; 
UHD_3.14.1.HEAD-0-gbfb9c1c7
[INFO] [E300] Loading FPGA image: /home/root/localinstall/e300.bit...
[INFO] [E300] FPGA image loaded
[INFO] [E300] Detecting internal GPS
 [INFO] [E300] GPSDO found
[INFO] [E300] Initializing core control (global registers)...

[INFO] [E300] Performing register loopback test...
[INFO] [E300] Register loopback test passed
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1000)
[WARNING] [RFNOC] Can't find a block controller for key FFT, using default 
block controller!
[INFO] [0/FFT_0] Initializing block control (NOC ID: 0xFF70)
[INFO] [0/Window_0] Initializing block control (NOC ID: 0xD053)
[WARNING] [RFNOC] Can't find a block controller for key fosphor, using default 
block controller!
[INFO] [0/fosphor_0] Initializing block control (NOC ID: 0x666F)
[INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0)
[INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0)
Traceback (most recent call last):
  File "rfnoc_fosphor_network_usrp.py", line 282, in 
main()
  File "rfnoc_fosphor_network_usrp.py", line 271, in main
tb = top_block_cls(fft_size=options.fft_size, fpga_path=options.fpga_path, 
freq=options.freq, gain=options.gain, host_ip_addr=options.host_ip_addr, 
samp_rate=options.samp_rate, tdecay=options.tdecay, trise=options.trise)
  File "rfnoc_fosphor_network_usrp.py", line 166, in __init__
self.connect((self.uhd_rfnoc_streamer_radio_0, 0), (self.blocks_copy_0, 0))
  File 
"/home/root/localinstall/usr/lib/python2.7/site-packages/gnuradio/gr/hier_block2.py",
 line 47, in wrapped
func(self, src, src_port, dst, dst_port)
  File 
"/home/root/localinstall/usr/lib/python2.7/site-packages/gnuradio/gr/hier_block2.py",
 line 110, in connect
self.primitive_connect(*args)
  File 
"/home/root/localinstall/usr/lib/python2.7/site-packages/gnuradio/gr/runtime_swig.py",
 line 3482, in primitive_connect
return _runtime_swig.top_block_sptr_primitive_connect(self, *args)
ValueError: itemsize mismatch: rfnoc_radio0:0 using 8, copy0:0 using 4096

I have attached my modified examples for anyone who is interested. I have tried 
to modify the python and that just gets me into more trouble.

Through my tracing of the files it appears that the RFNoC Radio block in the 
.py file never actually uses the vector size, and that the force vector length 
block is an additive to allow compliance when working in GNURadio, as it will 
not generate python with mismatched types and sizes. Trying to force the radio 
to take the 512 as an argument in the python throws a new error that the Radio 
is only allowed to have 5 arguments and I have supplied 6, and validated in the 
Ettus .py file that there is no arg for vector size.

I was wondering if anyone found away around this or got the RFNoC Split block 
working?

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

Re: [USRP-users] python 2.7 on N310

[Jason Matusiak via USRP-users]

Really?  OK, thanks Robin.  Maybe I'll see if I can find some toolchain from 
before the switch over (but I am sure too many other things will be too old for 
all of other packages.

I was surprised since that I could do this stuff with the E320 (which to me has 
a very similar setup), but the N310 wouldn't work.  I guess we will have to 
forgot using it in embedded mode and only use it in network mode.  Thanks Robin!


From: Robin Coxe 
Sent: Monday, October 21, 2019 12:54 PM
To: Jason Matusiak 
Cc: Ettus Mail List 
Subject: Re: [USRP-users] python 2.7 on N310

Python 3 has been the default for MPM on the N310 since June of 2017.
https://github.com/EttusResearch/uhd/commit/5f99240bd283da3da71588fcb1c1886937693928<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_EttusResearch_uhd_commit_5f99240bd283da3da71588fcb1c1886937693928=DwMFaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=W_MQLyUWPXWHfsF4mr51mTMqpeO4RbBBLexficV9DG8=JbLHwD_efOdK-ZuvD-QH2Fw4AAiWtCXu0WvdSfn6_xE=lE6ZF4x-LhtjQkpWmr6HKpawJBtAP1yjwDDIfqzCFhA=>

On Mon, Oct 21, 2019 at 9:37 AM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
I am just starting to play with the N310 and I am having issues with some of 
our flowgraphs that work fine with the X310 and the E320.  The issue seems to 
be that there seems to be minimal support for python 2.7 for the N310.  Is 
there a toolchain or anything else I can do to get better support?  Things like 
threading.py are missing and only in python3.5 for it.

Thanks.
~Jason
___
USRP-users mailing list
USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com=DwMFaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=W_MQLyUWPXWHfsF4mr51mTMqpeO4RbBBLexficV9DG8=JbLHwD_efOdK-ZuvD-QH2Fw4AAiWtCXu0WvdSfn6_xE=f3Ey7bGiI6_481vBRvMfnbI06m4xRL3McIn8x83oG20=>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] python 2.7 on N310

[Jason Matusiak via USRP-users]

I am just starting to play with the N310 and I am having issues with some of 
our flowgraphs that work fine with the X310 and the E320.  The issue seems to 
be that there seems to be minimal support for python 2.7 for the N310.  Is 
there a toolchain or anything else I can do to get better support?  Things like 
threading.py are missing and only in python3.5 for it.

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

Re: [USRP-users] UHD / RFNoC Versions and Flowgraph Error with X310

[Jason Matusiak via USRP-users]

Jeff,

This is an issue that tripped me up for numerous days in the past until 
Jonathon pointed me to the same fix.  It appears to be something wrong in 
gr-ettus (or a combo of the change and the UHD you and I both used), but they 
haven't seemed to have addressed this for some reason.  It would be nice if 
outsiders could edit the wiki (I get why they wouldn't allow that), so we could 
list some of these gotchyas to keep others from wasting days of time until 
Jonathon can bail us out again .


From: USRP-users  on behalf of Jeff S via 
USRP-users 
Sent: Wednesday, October 9, 2019 7:43 AM
To: Jonathon Pendlum 
Cc: usrp-users@lists.ettus.com 
Subject: Re: [USRP-users] UHD / RFNoC Versions and Flowgraph Error with X310

Jonathan,

I did what you suggested.  Starting from scratch and for the record (because my 
forgetful brain needs it and it may help someone else, or someone will point 
out the errors of my ways):

$ git clone -b master 
https://github.com/EttusResearch/gr-ettus.git
$ cd gr-ettus
$ git checkout 4980cbef0daf
$ mkdir build
$ cd build
$ cmake ../
$ make -j8
$ sudo make install
$ sudo ldconfig# Still not quite sure when I need this command, but I did 
it.

That seemed to fix the problem!

Is it due to a mixup on my end of what versions I originally had, or was it 
just because I cloned in the midst of some updates?

Thanks for the help!
Jeff



From: Jonathon Pendlum 
Sent: Tuesday, October 8, 2019 8:35 PM
To: Jeff S 
Cc: usrp-users@lists.ettus.com 
Subject: Re: [USRP-users] UHD / RFNoC Versions and Flowgraph Error with X310

Hi Jeff,

Try commit 4980cbef0daf from gr-ettus and please let me know if that solves the 
problem.

Jonathon

On Wed, Oct 9, 2019 at 10:23 AM Jeff S via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
I have been trying to set up an environment for using RFNoC on an X310.  It was 
running well before I tried to update the to using RFNoC according the the 
application note.  I'm wondering if I have an error relating to a version of 
UHD correlating to the other parts (gr-ettus, gnuradio, fpga).  I feel like I 
cannot trust documentation I see (like the X310 product description calling out 
Vivado 2015, but a recent email calling out 2017, and an earlier question that 
caused an application note to be deprecated).

I have two laptops which show the uhd (git branch) at version rfnoc-devel, and 
gr-ettus at master.  One will run a flowgraph with RFNoC blocks, and the other 
will get the error below with the same flowgraph (error on last line).  I'm 
just trying to figure out what direction to go before I delete everything and 
start over.  Similar questions about similar errors seemed to related to UHD 
versions, which I why I'm starting there.

Thanks,
Jeff

[32;1m[INFO] [UHD] [39;0mlinux; GNU C++ version 7.4.0; Boost_106501; 
UHD_4.0.0.rfnoc-devel-702-geec24d7b
[32;1m[INFO] [X300] [39;0mX300 initialization sequence...
[32;1m[INFO] [X300] [39;0mMaximum frame size: 1472 bytes.
[32;1m[INFO] [X300] [39;0mRadio 1x clock: 200 MHz
[32;1m[INFO] [GPS] [39;0mFound an internal GPSDO: LC_XO, Firmware Rev 0.929a
[32;1m[INFO] [0/DmaFIFO_0] [39;0mInitializing block control (NOC ID: 
0xF1F0D000)
[32;1m[INFO] [0/DmaFIFO_0] [39;0mBIST passed (Throughput: 1305 MB/s)
[32;1m[INFO] [0/DmaFIFO_0] [39;0mBIST passed (Throughput: 1307 MB/s)
[32;1m[INFO] [0/Radio_0] [39;0mInitializing block control (NOC ID: 
0x12AD1001)
[32;1m[INFO] [0/Radio_1] [39;0mInitializing block control (NOC ID: 
0x12AD1001)
[32;1m[INFO] [0/DDC_0] [39;0mInitializing block control (NOC ID: 
0xDDC0)
[32;1m[INFO] [0/DDC_1] [39;0mInitializing block control (NOC ID: 
0xDDC0)
[32;1m[INFO] [0/DUC_0] [39;0mInitializing block control (NOC ID: 
0xD0C0)
[32;1m[INFO] [0/DUC_1] [39;0mInitializing block control (NOC ID: 
0xD0C0)
Finding block for: Radio_0
Mapped external port 0 to 0
Mapped port 0 to 0/Radio_0
Mapped external port 1 to 1
Mapped port 1 to 0/Radio_0
TX args:
RX args:
0/Radio_0 has 1 input ports
0/Radio_0 has 2 output ports
getting block control for port 0
Finding block for: Radio_0
Mapped external port 0 to 0
Mapped port 0 to 0/Radio_0
Mapped external port 1 to 1
Mapped port 1 to 0/Radio_0
TX args:
RX args:
0/Radio_0 has 1 input ports
0/Radio_0 has 2 output ports
getting block control for port 0
Finding block for: DUC
Mapped external port 0 to 0
Mapped port 0 to 0/DUC_0
TX args:
RX args:
0/DUC_0 has 1 input ports
0/DUC_0 has 1 output ports
Finding block for: DmaFIFO
Mapped external port 0 to 0
Mapped port 0 to 0/DmaFIFO_0
Mapped external port 1 to 1
Mapped port 1 to 0/DmaFIFO_0
TX args:
RX args:

Re: [USRP-users] usrp probe and find commands

[Jason Matusiak via USRP-users]

Not sure.  I checked my notes and the firewall was the issue I had when I was 
forced to use the IP address.  All your network configurations look good?


From: Mark Koenig 
Sent: Friday, October 4, 2019 1:28 PM
To: Jason Matusiak 
Subject: Re: usrp probe and find commands


Firewall is inactive.



Could it be something with the iptables?





From: Jason Matusiak 
Date: Friday, October 4, 2019 at 1:26 PM
To: "usrp-users@lists.ettus.com" , Mark Koenig 

Subject: Re: usrp probe and find commands



Is your firewall blocking the port that UHD needs?  I feel like I had a serial 
problem in the past and that was the issue.





From: USRP-users  on behalf of Mark Koenig 
via USRP-users 
Sent: Friday, October 4, 2019 1:17 PM
To: usrp-users@lists.ettus.com 
Subject: [USRP-users] usrp probe and find commands



Does anyone have any idea why I can only probe my radio if I include the 
address string?



Uhd_usrp_probe --> yields no results



Uhd_usrp_probe –args “addr=192.168.10.2” --> find the radio and yields results





Also, the uhd_find_devices command does not return anything.



Thanks for the quick feedback.



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

Re: [USRP-users] usrp probe and find commands

[Jason Matusiak via USRP-users]

Is your firewall blocking the port that UHD needs?  I feel like I had a serial 
problem in the past and that was the issue.


From: USRP-users  on behalf of Mark Koenig 
via USRP-users 
Sent: Friday, October 4, 2019 1:17 PM
To: usrp-users@lists.ettus.com 
Subject: [USRP-users] usrp probe and find commands


Does anyone have any idea why I can only probe my radio if I include the 
address string?



Uhd_usrp_probe --> yields no results



Uhd_usrp_probe –args “addr=192.168.10.2” --> find the radio and yields results





Also, the uhd_find_devices command does not return anything.



Thanks for the quick feedback.



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

Re: [USRP-users] RFNoC not re-tuning consistently

[Jason Matusiak via USRP-users]

OK, I think I found the issue.  I am not sure what was causing things to 
sometimes work vs other times, but it seems to be the difference.  I pulled up 
an example RFNoC flowgraph and it didn't have any issues.  So then I started 
stripping things out and trying to compare things.  The only real difference 
that was a problem was two lines:

good:

args="input_rate={},output_rate={},fullscale={},freq={},gr_vlen={},{}".format(master_clock_rate,
 samp_rate, 1.0, 0.0, 256, "" if 256 == 1 else "spp={}".format(256)),
bad:

args="input_rate={},output_rate={},fullscale={},freq={},gr_vlen={},{}".format(master_clock_rate,
 samp_rate, 1.0, 0, 256, "" if 256 == 1 else "spp={}".format(256)),

and
good:
self.uhd_rfnoc_streamer_ddc_0.set_arg("freq", 0.0, chan)
bad:
self.uhd_rfnoc_streamer_ddc_0_0_0.set_arg("freq", 0, chan)

The difference between those lines is that the bad lines have the value "0" and 
the good has "0.0".  If I manually make the change the flowgraph seems to work 
fine.  I can't for the life of me figure out why one flowgraph is doing it as 
an int and the other as a float (they are both opened in the same GRC window), 
but everything is happy if I just do a save-as on the working one and start 
from there.


From: Marcus D Leech 
Sent: Tuesday, October 1, 2019 1:52 PM
To: Jason Matusiak 
Cc: usrp-users@lists.ettus.com 
Subject: Re: [USRP-users] RFNoC not re-tuning consistently

I wonder if this is just because in RFNoC the DDC is explicitly visible, so you 
have to program it to account for synthesizer step size?



Sent from my iPhone

On Oct 1, 2019, at 12:52 PM, Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:

I have an issue that is very odd to me.  I have tried two different X310s with 
different daughter cards and they are all exhibiting this behavior.  It feels 
like I am doing something stupid, but I can't quite figure out what. (a picture 
is attached)

If I have a usrp source connected to a freq sync, everything is golden.  If I 
instead use an RFNoC source connected to a DDC to the freq sync, I get 
inconsistent results.  I think the settings are the exact same, but it feels 
like the radio is not being reset properly.  Sometimes it tunes to where I tell 
it to and I can see my signal of interest perfectly, other times it off-tunes 
anywhere from a few MHz to way off the screen.  Subsequent retuning seems to 
actually make changes to the tune frequency, but not consistently (maybe I need 
to tune to 943MHz one time to mimic a tune to 910MHz. the next time I would 
have to tune somewhere else).

I am using the stock image and have tried with both XG and HG (though I am 
mostly testing with XG).

UHD_3.14.1.HEAD-0-g5491b80e

GR v3.7.13.4

___
USRP-users mailing list
USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com=DwMCaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=W_MQLyUWPXWHfsF4mr51mTMqpeO4RbBBLexficV9DG8=FE-XgMWjRnCsg9jWESEUgaV-ylQVbjIHIaQFFbsXSE0=HD_9V5Du1Mwt_qI6Cq-fhvMlJTJm3rwDd0bY0TDiZ4Q=>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC not re-tuning consistently

[Jason Matusiak via USRP-users]

Marcus,

I am not 100% sure I understand what you mean, but I am not sure why anything 
would need to be done differently (and in the past I feel like I had no 
issues).  They certainly don't talk about anything needed to be modified here:
https://kb.ettus.com/RFNoC#What_is_the_difference_between_USRP_Sink.2FSource_blocks_and_the_RFNoC:Radio_block.3F

And back to the modifications of the step size, would that still be a potential 
avenue to investigate knowing that sometimes things work and other times it 
doesn't?


From: Marcus D Leech 
Sent: Tuesday, October 1, 2019 1:52 PM
To: Jason Matusiak 
Cc: usrp-users@lists.ettus.com 
Subject: Re: [USRP-users] RFNoC not re-tuning consistently

I wonder if this is just because in RFNoC the DDC is explicitly visible, so you 
have to program it to account for synthesizer step size?



Sent from my iPhone

On Oct 1, 2019, at 12:52 PM, Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:

I have an issue that is very odd to me.  I have tried two different X310s with 
different daughter cards and they are all exhibiting this behavior.  It feels 
like I am doing something stupid, but I can't quite figure out what. (a picture 
is attached)

If I have a usrp source connected to a freq sync, everything is golden.  If I 
instead use an RFNoC source connected to a DDC to the freq sync, I get 
inconsistent results.  I think the settings are the exact same, but it feels 
like the radio is not being reset properly.  Sometimes it tunes to where I tell 
it to and I can see my signal of interest perfectly, other times it off-tunes 
anywhere from a few MHz to way off the screen.  Subsequent retuning seems to 
actually make changes to the tune frequency, but not consistently (maybe I need 
to tune to 943MHz one time to mimic a tune to 910MHz. the next time I would 
have to tune somewhere else).

I am using the stock image and have tried with both XG and HG (though I am 
mostly testing with XG).

UHD_3.14.1.HEAD-0-g5491b80e

GR v3.7.13.4

___
USRP-users mailing list
USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com=DwMCaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=W_MQLyUWPXWHfsF4mr51mTMqpeO4RbBBLexficV9DG8=FE-XgMWjRnCsg9jWESEUgaV-ylQVbjIHIaQFFbsXSE0=HD_9V5Du1Mwt_qI6Cq-fhvMlJTJm3rwDd0bY0TDiZ4Q=>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] RFNoC not re-tuning consistently

[Jason Matusiak via USRP-users]

I have an issue that is very odd to me.  I have tried two different X310s with 
different daughter cards and they are all exhibiting this behavior.  It feels 
like I am doing something stupid, but I can't quite figure out what. (a picture 
is attached)

If I have a usrp source connected to a freq sync, everything is golden.  If I 
instead use an RFNoC source connected to a DDC to the freq sync, I get 
inconsistent results.  I think the settings are the exact same, but it feels 
like the radio is not being reset properly.  Sometimes it tunes to where I tell 
it to and I can see my signal of interest perfectly, other times it off-tunes 
anywhere from a few MHz to way off the screen.  Subsequent retuning seems to 
actually make changes to the tune frequency, but not consistently (maybe I need 
to tune to 943MHz one time to mimic a tune to 910MHz. the next time I would 
have to tune somewhere else).

I am using the stock image and have tried with both XG and HG (though I am 
mostly testing with XG).

UHD_3.14.1.HEAD-0-g5491b80e

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

Re: [USRP-users] next pps issues with TwinRX

[Jason Matusiak via USRP-users]

Neel,

I updated to: UHD_3.14.1.1-0-g0347a6d8  as well as v3.7.13.5 for GR, still the 
same issues.

It almost feels like some sort of double/float mismatch somewhere since the 
alignment is so close to being right.


From: Neel Pandeya 
Sent: Monday, September 30, 2019 11:19 AM
To: Jason Matusiak 
Cc: usrp-users 
Subject: Re: [USRP-users] next pps issues with TwinRX

Hello Jason:

We'll look into this and get back to you shortly.

If you get a chance, could you please try it with the tagged UHD 3.14.1.1 ?

Which version of GNU Radio are you using?

--Neel Pandeya



On Mon, 30 Sep 2019 at 10:10, Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
We are having another issues with our TwinRXs.  A co-worker has been trying to 
get this to work for a while, but has had no luck with the PPS timing.  Here is 
the notes:

We are running UHD_3.14.1.HEAD-12-g5f75f73f.

The setup is a single X310 (revision: 11,  revision_compat: 7) with two TwinRX 
boards. The device gets Ref/PPS from an Octoclock.

The attached script has a hard-coded IP address and clock rate. It works for 
other X310s with UBX/SBX daughter boards as well as the E320.

Good results are (note line 5 below):

Synchronizing Radios to Reference Signals
Checking PPS synchronization
next_pps from 1569851984.633563 is 1569851985.00
Setting time for radio `gr uhd usrp source`: 2019-09-30 09:59:45
PPS alignment PASSED!: [1569851986.0, 1569851986]
All radios are Synchronized

Bad results are:
Synchronizing Radios to Reference Signals
Checking PPS synchronization
next_pps from 1569851508.136703 is 1569851509.00
Setting time for radio `gr uhd usrp source`: 2019-09-30 09:51:49
PPS alignment mismatch: [1569851509.995, 1569851509]

Any thoughts of why this might be happening?

___
USRP-users mailing list
USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com=DwMFaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=W_MQLyUWPXWHfsF4mr51mTMqpeO4RbBBLexficV9DG8=VzsjpGSylp7F9peAKPOcnLbFzmAh8CNVnwzwket3hCo=_gOstnMMEDkfFbD1tcNsLqzHaSnMGcIjP7W9NVzbH6M=>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] next pps issues with TwinRX

[Jason Matusiak via USRP-users]

Howdy Neel,

We are running GR v3.7.13.4.

We will get UHD 3.14.1.1 installed on one of our machines today and give that a 
shot.

Thanks.


From: Neel Pandeya 
Sent: Monday, September 30, 2019 11:19 AM
To: Jason Matusiak 
Cc: usrp-users 
Subject: Re: [USRP-users] next pps issues with TwinRX

Hello Jason:

We'll look into this and get back to you shortly.

If you get a chance, could you please try it with the tagged UHD 3.14.1.1 ?

Which version of GNU Radio are you using?

--Neel Pandeya



On Mon, 30 Sep 2019 at 10:10, Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
We are having another issues with our TwinRXs.  A co-worker has been trying to 
get this to work for a while, but has had no luck with the PPS timing.  Here is 
the notes:

We are running UHD_3.14.1.HEAD-12-g5f75f73f.

The setup is a single X310 (revision: 11,  revision_compat: 7) with two TwinRX 
boards. The device gets Ref/PPS from an Octoclock.

The attached script has a hard-coded IP address and clock rate. It works for 
other X310s with UBX/SBX daughter boards as well as the E320.

Good results are (note line 5 below):

Synchronizing Radios to Reference Signals
Checking PPS synchronization
next_pps from 1569851984.633563 is 1569851985.00
Setting time for radio `gr uhd usrp source`: 2019-09-30 09:59:45
PPS alignment PASSED!: [1569851986.0, 1569851986]
All radios are Synchronized

Bad results are:
Synchronizing Radios to Reference Signals
Checking PPS synchronization
next_pps from 1569851508.136703 is 1569851509.00
Setting time for radio `gr uhd usrp source`: 2019-09-30 09:51:49
PPS alignment mismatch: [1569851509.995, 1569851509]

Any thoughts of why this might be happening?

___
USRP-users mailing list
USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com=DwMFaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=W_MQLyUWPXWHfsF4mr51mTMqpeO4RbBBLexficV9DG8=VzsjpGSylp7F9peAKPOcnLbFzmAh8CNVnwzwket3hCo=_gOstnMMEDkfFbD1tcNsLqzHaSnMGcIjP7W9NVzbH6M=>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] next pps issues with TwinRX

[Jason Matusiak via USRP-users]

We are having another issues with our TwinRXs.  A co-worker has been trying to 
get this to work for a while, but has had no luck with the PPS timing.  Here is 
the notes:

We are running UHD_3.14.1.HEAD-12-g5f75f73f.

The setup is a single X310 (revision: 11,  revision_compat: 7) with two TwinRX 
boards. The device gets Ref/PPS from an Octoclock.

The attached script has a hard-coded IP address and clock rate. It works for 
other X310s with UBX/SBX daughter boards as well as the E320.

Good results are (note line 5 below):

Synchronizing Radios to Reference Signals
Checking PPS synchronization
next_pps from 1569851984.633563 is 1569851985.00
Setting time for radio `gr uhd usrp source`: 2019-09-30 09:59:45
PPS alignment PASSED!: [1569851986.0, 1569851986]
All radios are Synchronized

Bad results are:
Synchronizing Radios to Reference Signals
Checking PPS synchronization
next_pps from 1569851508.136703 is 1569851509.00
Setting time for radio `gr uhd usrp source`: 2019-09-30 09:51:49
PPS alignment mismatch: [1569851509.995, 1569851509]

Any thoughts of why this might be happening?

#!/usr/bin/env python2
from gnuradio import uhd
import time
import sys
import math
from datetime import datetime

MAX_ATTEMPTS = 5
ADDR = '192.168.10.2'
CLKRATE = 200e6

# make sure we start the time reset iterations on the PPS Edge
def get_pps_edge(usrp):
last_pps_time = usrp.get_time_last_pps()
while last_pps_time == usrp.get_time_last_pps():
pass

 START #
try:
usrp = uhd.usrp_source('addr=' + ADDR,
 uhd.stream_args(cpu_format='sc16', 
 channels=range(1)))
except Exception as e:
print str(e)
sys.exit()

# get external clock
try:
usrp.set_clock_source('external', 0)
except RuntimeError:
print "Radio " + ADDR + " is not seeing 10 MHz clock"
sys.exit()

# configure the usrp
usrp.set_clock_rate(CLKRATE, uhd.ALL_MBOARDS)

# check lock to 10 MHz reference signal
print "Synchronizing Radios to Reference Signals"
attempts = 0
ref_locked = ["not_queried_yet"]
while ref_locked != [" locked"]:
ref_locked[0] = str(usrp.get_mboard_sensor("ref_locked", 0)).split(':')[-1]
attempts += 1
if attempts >= MAX_ATTEMPTS:
print 'Unable to achieve ref lock. Exiting...'
sys.exit()

# check PPS synchronization
print "Checking PPS synchronization"
passed_test = False
attempts = 0
while not passed_test:

# re-align all radios
get_pps_edge(usrp)

# get far away from the "top of a second" so all clock sources will be on the same full second
time.sleep(.4)

time_real = time.time()  # system time should be synced with GPS time

#Round up to the next whole second
next_pps = math.ceil(time_real)
print 'next_pps from %f is %f' % (time_real, next_pps)

# set_time_next_pps is non-blocking, so set all radios immediately after finding an edge
print 'Setting time for radio `{}`: {}'.format(
usrp.name(), datetime.fromtimestamp(next_pps))
usrp.set_time_next_pps(uhd.time_spec_t(next_pps))

# sleep through one pps edge so time is set correctly on all USRPs
time.sleep(1)

# check if the pps is correct for all radios
get_pps_edge(usrp)

# get pps for each radio
last_pps = []
last_pps.append(usrp.get_time_last_pps().get_real_secs())
last_pps.append(int(time.time()))

# compare pps for each radio
if last_pps and last_pps.count(last_pps[0]) != len(last_pps):
print "PPS alignment mismatch: {}".format(last_pps)
passed_test = False
else:
print "PPS alignment PASSED!: {}".format(last_pps)
passed_test = True

attempts += 1
if attempts >= MAX_ATTEMPTS:
print 'Failed to synchronize radios after %d attempts' % MAX_ATTEMPTS
print 'Exiting...'
sys.exit()

print "All radios are Synchronized"


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

Re: [USRP-users] E320 unable to lock to external reference

[Jason Matusiak via USRP-users]

Nate,

Thanks, this did the trick.  Edited 
/usr/lib/python3.5/site-packages/usrp_mpm/periph_manager/e320_periphs.py on the 
E320 with the changes and now it locks perfectly (tested only in network mode). 
 Thanks for finding this and pushing it out!


From: Nate Temple 
Sent: Friday, September 20, 2019 11:35 AM
To: Jason Matusiak 
Cc: Michael West ; USRP-users@lists.ettus.com 

Subject: Re: [USRP-users] E320 unable to lock to external reference

Hi Jason,

Here is the commit that fixes the e320 ext ref issue.

https://github.com/EttusResearch/uhd/commit/6a11a141b8d32d1919e8f9fe95d5c65e95ddd03b<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_EttusResearch_uhd_commit_6a11a141b8d32d1919e8f9fe95d5c65e95ddd03b=DwMFaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=W_MQLyUWPXWHfsF4mr51mTMqpeO4RbBBLexficV9DG8=oDWTo8cej6KVST5c3HkT_yu6SjSnRet18xpZplUwqrg=SO-yC3_q1F1ocW5fw-9aqYxfXxQJJca7O-LppAJRY_4=>

We are aiming to have 3.14.1.1 tagged and released next week which will include 
this commit.

Regards,
Nate Temple


On Tue, Aug 6, 2019, 11:51 AM Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:
Thanks for the update Michael, I'll pass it along.  Fingers crossed.


From: Michael West mailto:michael.w...@ettus.com>>
Sent: Monday, August 5, 2019 4:49 PM
To: Nate Temple mailto:nate.tem...@ettus.com>>
Cc: Jason Matusiak 
mailto:ja...@gardettoengineering.com>>; Ettus 
Mail List mailto:usrp-users@lists.ettus.com>>
Subject: Re: [USRP-users] E320 unable to lock to external reference

We have someone looking into this now.  In the meantime, try adding the device 
arguments "clock_source=external,time_source=external".

Regards,
Michael

On Tue, Jul 23, 2019 at 12:23 PM Nate Temple via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
Hi Jason,

I'm fairly confident that this is just a software issue.

Regards,
Nate Temple

On Tue, Jul 23, 2019 at 11:06 AM Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:
Thank you Nate.  Good to hear that it wasn't a screw up on our part.  Do you 
have a gut as to whether or not it is a hardware or software issue?



From: Nate Temple mailto:nate.tem...@ettus.com>>
Sent: Tuesday, July 23, 2019 2:01 PM
To: Jason Matusiak 
mailto:ja...@gardettoengineering.com>>
Cc: Ettus Mail List 
mailto:usrp-users@lists.ettus.com>>
Subject: Re: [USRP-users] E320 unable to lock to external reference

Hi Jason,

I've been able to recreate this and have filed an issue on our internal bug 
tracker and escalated as a high priority issue. I'm not able to provide any ETA 
on when we will have a fix for it, but hope it will be soon.

I will follow up as soon as I have more information.

Regards,
Nate Temple

On Tue, Jul 23, 2019 at 10:12 AM Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:
Do you need anything from my side of things?


From: Nate Temple mailto:nate.tem...@ettus.com>>
Sent: Thursday, July 18, 2019 3:49 PM
To: Jason Matusiak 
mailto:ja...@gardettoengineering.com>>
Cc: Ettus Mail List 
mailto:usrp-users@lists.ettus.com>>
Subject: Re: [USRP-users] E320 unable to lock to external reference

Hi Jason,

This might be a bug with the E320. I will need to try to recreate this issue. 
I'll follow up as soon as I have more info.

Regards,
Nate Temple

On Thu, Jul 18, 2019 at 12:32 PM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
OK, we've been fighting this for a while and we think we narrowed it down to 
being a problem with the E320 (NOTE: we are running the E320 in network mode, 
not embedded)

Some background:
1) external reference input is from an octo clock (so it the 1pps input) on 
many different ports
a) also tried to use a  Symmetricom box for external reference and had 
the same problems

3) the same code we are testing with works when using an x310 instead of an 
e320, with inputs from the same octoclock

4) the code basically does this:
a) sets the reference source to external
b) checks to see if the reference is locked (and it keeps doing this 
until we get a "locked" response, using the uhd commands to do this)

5) for the e320, the locked status never returns (when running the x310 with 
this code, it sometimes responds with unlocked, but after a few checks it comes 
back ok)

6) I tried some of the Ettus (UHD) test code
a) running the "sync_to_gps" program did work - the reference was able 
to lock to the internal (gps) reference
b) "test_clock_synch"  returns similiar errors to what we get with our 
program (see below):
Checking USRP devices for lock.
 * 318B08B: false
WARNING: One or more devices not locked.
Querying Clock for time and setting USRP times...
[WARNING] [MPM.PeriphManager] Reference Clock reporting

Re: [USRP-users] No block_id specified for channel 0

[Jason Matusiak via USRP-users]

Howdy Jon,

Bingo.  I had suspected the same thing yesterday just before I left, but I 
wanted to let a new FPGA build overnight before I made any changes.  The FPGA 
change did nothing, but rolling back a commit for gr-ettus did.
I will say that even though things are "running" now, it doesn't seem to be 
100%.  I am going to dig through the commits and see if I need to go back a few 
more.  I am running OK for a few seconds. and then getting "Doverrun on chan 0" 
and then "[ERROR] [X300] 192.168.27.2: x300 fw communication failure #1
EnvironmentError: IOError: x300 fw poke32 - reply timed out".  It seems like 
the network just goes out to lunch (this 10G connection of mine has always been 
reliable until this).

So to summarize, yep, the latest gr-ettus commit threw a curveball.  But, 
things are not 100% working, and this block of mine was working fine on the 
E312/E320s.  I'll report back if something else turns up.



From: Jonathon Pendlum 
Sent: Tuesday, September 10, 2019 11:35 PM
To: Jason Matusiak 
Cc: Ettus Mail List 
Subject: Re: [USRP-users] No block_id specified for channel 0

Hi Jason,

Could you try reverting gr-ettus back one commit to 4980cbef and let me know if 
that works?

Jonathon

On Tue, Sep 10, 2019 at 5:23 AM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
I have an RFNoC  flowgraph and bitfile combo that used to work but is erroring 
out now. I've been using the code successfully on the E320 and E310 and decided 
to re-build for the X310 (and XG flowgraph).  When I run my flowgraph, I am see 
a lot of addition debug that I am not used to seeing (which is fine) and then 
my block in particular seems to cause problems and I get the error in the 
subject.  I am guessing that since I just rebuilt everything, some change needs 
to be made in my impl for my block due to some UHD update, but I can't quite 
figure out anywhere where something changes.  The beginning of the output when 
I run my flowgraph is:

[INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-36); 
Boost_105300; UHD_3.14.1.1-0-g98c7c986
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 8000 bytes.
[INFO] [X300] Radio 1x clock: 200 MHz
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D000)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1317 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1323 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: 0xDDC1)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC1)
[INFO] [0/DDC_2] Initializing block control (NOC ID: 0xDDC1)
[INFO] [0/DDC_3] Initializing block control (NOC ID: 0xDDC1)
[INFO] [0/keepMinN_0] Initializing block control (NOC ID: 0x229C30C919275220)
[INFO] [0/keepMinN_1] Initializing block control (NOC ID: 0x229C30C919275220)
[WARNING] [RFNOC] Can't find a block controller for key SplitStream, using 
default block controller!
[INFO] [0/SplitStream_0] Initializing block control (NOC ID: 0x5757)
[WARNING] [RFNOC] Can't find a block controller for key SplitStream, using 
default block controller!
[INFO] [0/SplitStream_1] Initializing block control (NOC ID: 0x5757)
Finding block for: Radio_1
Mapped external port 0 to 0
Mapped port 0 to 0/Radio_1
Mapped external port 1 to 1
Mapped port 1 to 0/Radio_1
TX args:
RX args:
0/Radio_1 has 1 input ports
0/Radio_1 has 2 output ports
getting block control for port 0
Finding block for: DDC_0
Mapped external port 0 to 0
Mapped port 0 to 0/DDC_0
TX args:
getting block control for port 0
getting block control for port 0


And the ehnd of that blob shows:

getting block control for port 0
getting block control for port 0
thread[thread-per-block[2]: ]: RuntimeError: Cannot create 
streamers: No block_id specified for channel 0.


And finally, if I let it sit there, the X310 must get into a wonky state 
because I start to get:

[ERROR] [X300] 
192.168.80.2<https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.80.2=DwMFaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=W_MQLyUWPXWHfsF4mr51mTMqpeO4RbBBLexficV9DG8=HJQv_tP-l348DEC-L6fSq05a8NuS_qL8oXAhNL7hdTw=RcTxqxOJH24llSidhjkaLXsSP1JwnViPVqwR1OKlzvo=>:
 x300 fw communication failure #1
EnvironmentError: IOError: x300 fw poke32 - reply timed out
[ERROR] [X300] 
192.168.80.2<https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.80.2=DwMFaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=W_MQLyUWPXWHfsF4mr51mTMqpeO4RbBBLexficV9DG8=HJQv_tP-l348DEC-L6fSq05a8NuS_qL8oXAhNL7hdTw=RcTxqxOJH24llSidhjkaLXsSP1JwnViPVqwR1OKlzvo=>:
 x300 fw communication failure #2
EnvironmentError: IOError: x300 fw poke32 - reply timed out
[ERROR] [X300] 
192.168.80.2<https://urldefense.p

[USRP-users] No block_id specified for channel 0

[Jason Matusiak via USRP-users]

I have an RFNoC  flowgraph and bitfile combo that used to work but is erroring 
out now. I've been using the code successfully on the E320 and E310 and decided 
to re-build for the X310 (and XG flowgraph).  When I run my flowgraph, I am see 
a lot of addition debug that I am not used to seeing (which is fine) and then 
my block in particular seems to cause problems and I get the error in the 
subject.  I am guessing that since I just rebuilt everything, some change needs 
to be made in my impl for my block due to some UHD update, but I can't quite 
figure out anywhere where something changes.  The beginning of the output when 
I run my flowgraph is:

[INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-36); 
Boost_105300; UHD_3.14.1.1-0-g98c7c986
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 8000 bytes.
[INFO] [X300] Radio 1x clock: 200 MHz
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D000)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1317 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1323 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: 0xDDC1)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC1)
[INFO] [0/DDC_2] Initializing block control (NOC ID: 0xDDC1)
[INFO] [0/DDC_3] Initializing block control (NOC ID: 0xDDC1)
[INFO] [0/keepMinN_0] Initializing block control (NOC ID: 0x229C30C919275220)
[INFO] [0/keepMinN_1] Initializing block control (NOC ID: 0x229C30C919275220)
[WARNING] [RFNOC] Can't find a block controller for key SplitStream, using 
default block controller!
[INFO] [0/SplitStream_0] Initializing block control (NOC ID: 0x5757)
[WARNING] [RFNOC] Can't find a block controller for key SplitStream, using 
default block controller!
[INFO] [0/SplitStream_1] Initializing block control (NOC ID: 0x5757)
Finding block for: Radio_1
Mapped external port 0 to 0
Mapped port 0 to 0/Radio_1
Mapped external port 1 to 1
Mapped port 1 to 0/Radio_1
TX args:
RX args:
0/Radio_1 has 1 input ports
0/Radio_1 has 2 output ports
getting block control for port 0
Finding block for: DDC_0
Mapped external port 0 to 0
Mapped port 0 to 0/DDC_0
TX args:
getting block control for port 0
getting block control for port 0


And the ehnd of that blob shows:

getting block control for port 0
getting block control for port 0
thread[thread-per-block[2]: ]: RuntimeError: Cannot create 
streamers: No block_id specified for channel 0.


And finally, if I let it sit there, the X310 must get into a wonky state 
because I start to get:

[ERROR] [X300] 192.168.80.2: x300 fw communication failure #1
EnvironmentError: IOError: x300 fw poke32 - reply timed out
[ERROR] [X300] 192.168.80.2: x300 fw communication failure #2
EnvironmentError: IOError: x300 fw poke32 - reply timed out
[ERROR] [X300] 192.168.80.2: x300 fw communication failure #1
EnvironmentError: IOError: x300 fw poke32 - reply timed out
[ERROR] [X300] 192.168.80.2: x300 fw communication failure #1
EnvironmentError: IOError: x300 fw poke32 - reply timed out
[ERROR] [X300] 192.168.80.2: x300 fw communication failure #2
EnvironmentError: IOError: x300 fw poke32 - reply timed out
[ERROR] [X300] 192.168.80.2: x300 fw communication failure #3
EnvironmentError: IOError: x300 fw poke32 - reply timed out
[ERROR] [UHD] An unexpected exception was caught in a task loop.The task loop 
will now exit, things may not work.EnvironmentError: IOError: 192.168.80.2: 
x300 fw communication failure #3
EnvironmentError: IOError: x300 fw poke32 - reply timed out



What am I missing here?
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] flowgraphs not stopping

[Jason Matusiak via USRP-users]

I think I've found the problem.  I thought I disabled a GR OOT block when I was 
running my tests this morning, but I either was wrong, or some process was hung 
in memory somewhere after I started stripping the flowgraph down.  The issue 
was a block that was spawning a thread that was listening on a UDP socket.  
When the flowgraph ended, the the thread was told to close, but the socket was 
blocking waiting for data that was never going to come.  I added in the timeout 
option to our socket initialization and it seems to work fine now.


From: USRP-users  on behalf of Jason 
Matusiak via USRP-users 
Sent: Wednesday, September 4, 2019 9:51 AM
To: Ettus Mail List 
Subject: [USRP-users] flowgraphs not stopping

I have a weird problem that I've seen for a while and I've just ignored until 
now.  I've seen this with numerous pieces of hardware, but I am currently using 
an E320 in network mode.  This seems to only happen when I am using RFNoC, so I 
assumed it was me, but today I was testing with only stock blocks and have the 
same issue.

The problem is that when I run a GR flowgraph without a GUI in "prompt for 
exit" mode, it doesn't always seem to exit.  I'll hit enter like I am supposed 
to, but it just hangs until I press ctrl-c.  Currently I have an RFNoC:Radio -> 
DmaFIFO -> GR blocks.  I have tested this with different combos of blocks and 
they all seem to have the same issue.  I originally thought it was me or the 
split stream block, but they are both out of the equation now.  Has anyone else 
seen this issue before?

I am running:
[INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-36); 
Boost_105300; UHD_3.14.1.HEAD-0-g5491b80e

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

[USRP-users] flowgraphs not stopping

[Jason Matusiak via USRP-users]

I have a weird problem that I've seen for a while and I've just ignored until 
now.  I've seen this with numerous pieces of hardware, but I am currently using 
an E320 in network mode.  This seems to only happen when I am using RFNoC, so I 
assumed it was me, but today I was testing with only stock blocks and have the 
same issue.

The problem is that when I run a GR flowgraph without a GUI in "prompt for 
exit" mode, it doesn't always seem to exit.  I'll hit enter like I am supposed 
to, but it just hangs until I press ctrl-c.  Currently I have an RFNoC:Radio -> 
DmaFIFO -> GR blocks.  I have tested this with different combos of blocks and 
they all seem to have the same issue.  I originally thought it was me or the 
split stream block, but they are both out of the equation now.  Has anyone else 
seen this issue before?

I am running:
[INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-36); 
Boost_105300; UHD_3.14.1.HEAD-0-g5491b80e

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

Re: [USRP-users] E320 unable to lock to external reference

[Jason Matusiak via USRP-users]

Thanks for the update Michael, I'll pass it along.  Fingers crossed.


From: Michael West 
Sent: Monday, August 5, 2019 4:49 PM
To: Nate Temple 
Cc: Jason Matusiak ; Ettus Mail List 

Subject: Re: [USRP-users] E320 unable to lock to external reference

We have someone looking into this now.  In the meantime, try adding the device 
arguments "clock_source=external,time_source=external".

Regards,
Michael

On Tue, Jul 23, 2019 at 12:23 PM Nate Temple via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
Hi Jason,

I'm fairly confident that this is just a software issue.

Regards,
Nate Temple

On Tue, Jul 23, 2019 at 11:06 AM Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:
Thank you Nate.  Good to hear that it wasn't a screw up on our part.  Do you 
have a gut as to whether or not it is a hardware or software issue?



From: Nate Temple mailto:nate.tem...@ettus.com>>
Sent: Tuesday, July 23, 2019 2:01 PM
To: Jason Matusiak 
mailto:ja...@gardettoengineering.com>>
Cc: Ettus Mail List 
mailto:usrp-users@lists.ettus.com>>
Subject: Re: [USRP-users] E320 unable to lock to external reference

Hi Jason,

I've been able to recreate this and have filed an issue on our internal bug 
tracker and escalated as a high priority issue. I'm not able to provide any ETA 
on when we will have a fix for it, but hope it will be soon.

I will follow up as soon as I have more information.

Regards,
Nate Temple

On Tue, Jul 23, 2019 at 10:12 AM Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:
Do you need anything from my side of things?


From: Nate Temple mailto:nate.tem...@ettus.com>>
Sent: Thursday, July 18, 2019 3:49 PM
To: Jason Matusiak 
mailto:ja...@gardettoengineering.com>>
Cc: Ettus Mail List 
mailto:usrp-users@lists.ettus.com>>
Subject: Re: [USRP-users] E320 unable to lock to external reference

Hi Jason,

This might be a bug with the E320. I will need to try to recreate this issue. 
I'll follow up as soon as I have more info.

Regards,
Nate Temple

On Thu, Jul 18, 2019 at 12:32 PM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
OK, we've been fighting this for a while and we think we narrowed it down to 
being a problem with the E320 (NOTE: we are running the E320 in network mode, 
not embedded)

Some background:
1) external reference input is from an octo clock (so it the 1pps input) on 
many different ports
a) also tried to use a  Symmetricom box for external reference and had 
the same problems

3) the same code we are testing with works when using an x310 instead of an 
e320, with inputs from the same octoclock

4) the code basically does this:
a) sets the reference source to external
b) checks to see if the reference is locked (and it keeps doing this 
until we get a "locked" response, using the uhd commands to do this)

5) for the e320, the locked status never returns (when running the x310 with 
this code, it sometimes responds with unlocked, but after a few checks it comes 
back ok)

6) I tried some of the Ettus (UHD) test code
a) running the "sync_to_gps" program did work - the reference was able 
to lock to the internal (gps) reference
b) "test_clock_synch"  returns similiar errors to what we get with our 
program (see below):
Checking USRP devices for lock.
 * 318B08B: false
WARNING: One or more devices not locked.
Querying Clock for time and setting USRP times...
[WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked. MB_CLOCK_CTRL 
reg: 0x0002
Running 10 comparisons at random intervals.
Comparison #1
 * Clock time: 1563463644
 * 318B08B time: 1563463644
Comparison #2
 * Clock time: 1563463652
 * 318B08B time: 1563463652
Comparison #3
 * Clock time: 1563463657
 * 318B08B time: 1563463657
Comparison #4
 * Clock time: 1563463664
 * 318B08B time: 1563463664
Comparison #5
 * Clock time: 1563463666
 * 318B08B time: 1563463666
Comparison #6
 * Clock time: 1563463671
 * 318B08B time: 1563463671
Comparison #7
 * Clock time: 1563463676
 * 318B08B time: 1563463676
Comparison #8
 * Clock time: 1563463686
 * 318B08B time: 1563463686
Comparison #9
 * Clock time: 1563463689
 * 318B08B time: 1563463689
Comparison #10
 * Clock time: 1563463691
 * 318B08B time: 1563463691

Number of matches: 10/10


7) we ran the same tests at a sister site that has four E320s, and they all 
exhibited the same issues

8)Finally, a uhd_usrp_probe command returns this:

[INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-36); 
Boost_105300; UHD_3.14.1.0-9-g2aa5289d
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
mgmt_addr=192.168.10.3,type=e3xx,product=e320,serial=318B08B,claimed=False,addr=192.168.10.3
[WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked. MB_CLOCK_CTRL 
reg: 0x0002
... m

Re: [USRP-users] Error 'Timeout on Chan 0'

[Jason Matusiak via USRP-users]

Also, there is a timeout clock running somewhere (can't recall off the top of 
my head) that will throw that message when it gets tripped.  That is fine 
though if you are INTENDING to do something that might cause there to be a gap 
in samples and trigger a timeout.  I had an RFNoC block that was taking chunks 
of data and throwing away samples until a condition was met.  That message was 
printed because it didn't see samples moving though the stream, but that was by 
design.  I am almost positive that when having this discussion on the 
mailing-list in the past, someone pointed out where they commented out the line 
in UHD since they were doing something similar and didn't want to see it.


From: USRP-users  on behalf of Lars Kuger 
via USRP-users 
Sent: Friday, August 2, 2019 10:13 AM
To: usrp-users@lists.ettus.com 
Subject: Re: [USRP-users] Error 'Timeout on Chan 0'


Hello Kirsten,

I remember getting the same error message while developing a custom RFNoC 
block. I found the problem to be caused by the corresponding xml file which is 
located in the grc folder. I am not sure what part of the file exactly caused 
the error message (maybe the ordering of the parameters or tags within the 
parameters) but I eventually solved it by replacing the file with the xml file 
from a working block and modifying that one.

Best regards,
Lars


On 02.08.19 15:50, Leong, Kirsten - 0551 - MITLL via USRP-users wrote:

Hello,



I am using a USRP X310 and am using gnuradio companion to test a custom block. 
The current diagram flows as follows: File Source->RFNoC FIFO->custom 
block->complex to image->frequency sink. However, when I try to execute, I get 
the error ‘timeout on chan 0’. My testbench passes all 5 cases; I can read 
signals on the inputs and outputs of the noc block and the flow graph works 
once I remove my custom block. Where else should I be looking?



Thanks,

Kirsten



___
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] X310 slow with gnuradio

[Jason Matusiak via USRP-users]

Erik,

Whoops, I glazed over that point, sorry.  I am not really sure what else to 
try.  That is a pretty old version of GR, could you maybe try a newer version 
in a different directory/prefix (so it doesn't mess up your current build)?  At 
what sample rate do things seem to work right again?


From: Erik Heinz 
Sent: Monday, July 29, 2019 8:02 AM
To: Jason Matusiak ; usrp-users@lists.ettus.com 

Subject: AW: X310 slow with gnuradio


Hi jason,


I had the MTU set to 8028. I increased to 9000, just to make sure -> no change.

As I wrote, the UHD driver itself can transmit at full speed, so it should be 
no network issue.


Best regards,

Erik





Von: Jason Matusiak 
Gesendet: Montag, 29. Juli 2019 13:50
An: usrp-users@lists.ettus.com; Erik Heinz
Betreff: Re: X310 slow with gnuradio

Shot in the dark Erik:
What is your MTU set at for the ethernet port?  Try setting it to 9000 if 
it isn't and see if that does anything for you.

From: USRP-users  on behalf of Erik Heinz 
via USRP-users 
Sent: Monday, July 29, 2019 7:30 AM
To: usrp-users@lists.ettus.com 
Subject: [USRP-users] X310 slow with gnuradio


Hi,


I am getting lots of underflow errors when sending with gnuradio to an X310 at 
sampling rates of 50 MSps and higher. The flowchart is as simple as possible: a 
signal source and a

"UHD: USRP Sink" block. When sending and receiving at the same time, the 
performance is even worse.


The X310 is connected to the PC by 10G ethernet. Using the UHD example programs 
benchmark_rate, tx_waveforms, txrx_loopback_to_file etc., a sampling rate of 
200 MSps full duplex is no problem at all. So it is not a problem of the UHD 
driver and the network setup should be OK as well.


The processor is an Intel core i3-7100 @3.9GHz.  A gnuradio flowchart with a 
signal source, a throttle block and a file sink works at 50 MSps sampling rate 
and more, so the processor speed should not be a problem either. The gnuradio 
version is 3.7.11 which is the one currently distributed for Ubuntu buster.


Any ideas? Could an update to a more recent gnuradio version help?


Best regards,

Erik




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

Re: [USRP-users] X310 slow with gnuradio

[Jason Matusiak via USRP-users]

Shot in the dark Erik:
What is your MTU set at for the ethernet port?  Try setting it to 9000 if 
it isn't and see if that does anything for you.

From: USRP-users  on behalf of Erik Heinz 
via USRP-users 
Sent: Monday, July 29, 2019 7:30 AM
To: usrp-users@lists.ettus.com 
Subject: [USRP-users] X310 slow with gnuradio


Hi,


I am getting lots of underflow errors when sending with gnuradio to an X310 at 
sampling rates of 50 MSps and higher. The flowchart is as simple as possible: a 
signal source and a

"UHD: USRP Sink" block. When sending and receiving at the same time, the 
performance is even worse.


The X310 is connected to the PC by 10G ethernet. Using the UHD example programs 
benchmark_rate, tx_waveforms, txrx_loopback_to_file etc., a sampling rate of 
200 MSps full duplex is no problem at all. So it is not a problem of the UHD 
driver and the network setup should be OK as well.


The processor is an Intel core i3-7100 @3.9GHz.  A gnuradio flowchart with a 
signal source, a throttle block and a file sink works at 50 MSps sampling rate 
and more, so the processor speed should not be a problem either. The gnuradio 
version is 3.7.11 which is the one currently distributed for Ubuntu buster.


Any ideas? Could an update to a more recent gnuradio version help?


Best regards,

Erik




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

Re: [USRP-users] E320 unable to lock to external reference

[Jason Matusiak via USRP-users]

Thank you Nate.  Good to hear that it wasn't a screw up on our part.  Do you 
have a gut as to whether or not it is a hardware or software issue?



From: Nate Temple 
Sent: Tuesday, July 23, 2019 2:01 PM
To: Jason Matusiak 
Cc: Ettus Mail List 
Subject: Re: [USRP-users] E320 unable to lock to external reference

Hi Jason,

I've been able to recreate this and have filed an issue on our internal bug 
tracker and escalated as a high priority issue. I'm not able to provide any ETA 
on when we will have a fix for it, but hope it will be soon.

I will follow up as soon as I have more information.

Regards,
Nate Temple

On Tue, Jul 23, 2019 at 10:12 AM Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:
Do you need anything from my side of things?


From: Nate Temple mailto:nate.tem...@ettus.com>>
Sent: Thursday, July 18, 2019 3:49 PM
To: Jason Matusiak 
mailto:ja...@gardettoengineering.com>>
Cc: Ettus Mail List 
mailto:usrp-users@lists.ettus.com>>
Subject: Re: [USRP-users] E320 unable to lock to external reference

Hi Jason,

This might be a bug with the E320. I will need to try to recreate this issue. 
I'll follow up as soon as I have more info.

Regards,
Nate Temple

On Thu, Jul 18, 2019 at 12:32 PM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
OK, we've been fighting this for a while and we think we narrowed it down to 
being a problem with the E320 (NOTE: we are running the E320 in network mode, 
not embedded)

Some background:
1) external reference input is from an octo clock (so it the 1pps input) on 
many different ports
a) also tried to use a  Symmetricom box for external reference and had 
the same problems

3) the same code we are testing with works when using an x310 instead of an 
e320, with inputs from the same octoclock

4) the code basically does this:
a) sets the reference source to external
b) checks to see if the reference is locked (and it keeps doing this 
until we get a "locked" response, using the uhd commands to do this)

5) for the e320, the locked status never returns (when running the x310 with 
this code, it sometimes responds with unlocked, but after a few checks it comes 
back ok)

6) I tried some of the Ettus (UHD) test code
a) running the "sync_to_gps" program did work - the reference was able 
to lock to the internal (gps) reference
b) "test_clock_synch"  returns similiar errors to what we get with our 
program (see below):
Checking USRP devices for lock.
 * 318B08B: false
WARNING: One or more devices not locked.
Querying Clock for time and setting USRP times...
[WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked. MB_CLOCK_CTRL 
reg: 0x0002
Running 10 comparisons at random intervals.
Comparison #1
 * Clock time: 1563463644
 * 318B08B time: 1563463644
Comparison #2
 * Clock time: 1563463652
 * 318B08B time: 1563463652
Comparison #3
 * Clock time: 1563463657
 * 318B08B time: 1563463657
Comparison #4
 * Clock time: 1563463664
 * 318B08B time: 1563463664
Comparison #5
 * Clock time: 1563463666
 * 318B08B time: 1563463666
Comparison #6
 * Clock time: 1563463671
 * 318B08B time: 1563463671
Comparison #7
 * Clock time: 1563463676
 * 318B08B time: 1563463676
Comparison #8
 * Clock time: 1563463686
 * 318B08B time: 1563463686
Comparison #9
 * Clock time: 1563463689
 * 318B08B time: 1563463689
Comparison #10
 * Clock time: 1563463691
 * 318B08B time: 1563463691

Number of matches: 10/10


7) we ran the same tests at a sister site that has four E320s, and they all 
exhibited the same issues

8)Finally, a uhd_usrp_probe command returns this:

[INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-36); 
Boost_105300; UHD_3.14.1.0-9-g2aa5289d
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
mgmt_addr=192.168.10.3,type=e3xx,product=e320,serial=318B08B,claimed=False,addr=192.168.10.3
[WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked. MB_CLOCK_CTRL 
reg: 0x0002
... many of these warnings repeating ...
[WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked. MB_CLOCK_CTRL 
reg: 0x0002
[WARNING] [MPM.RPCServer] A timeout event occured!
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D000)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1324 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1322 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10003320)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
[INFO] [MPM.PeriphManager] init() called with device args 
`product=e320,mgmt_addr=192.168.10.3'.
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2)
[INFO] [0/Radio_0] Performing CODEC loopback test...
[INFO] [0/Radio_0] CODEC loopback test passed
[INFO] [0/Radio_0] Performing CODEC lo

Re: [USRP-users] E320 unable to lock to external reference

[Jason Matusiak via USRP-users]

Do you need anything from my side of things?


From: Nate Temple 
Sent: Thursday, July 18, 2019 3:49 PM
To: Jason Matusiak 
Cc: Ettus Mail List 
Subject: Re: [USRP-users] E320 unable to lock to external reference

Hi Jason,

This might be a bug with the E320. I will need to try to recreate this issue. 
I'll follow up as soon as I have more info.

Regards,
Nate Temple

On Thu, Jul 18, 2019 at 12:32 PM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
OK, we've been fighting this for a while and we think we narrowed it down to 
being a problem with the E320 (NOTE: we are running the E320 in network mode, 
not embedded)

Some background:
1) external reference input is from an octo clock (so it the 1pps input) on 
many different ports
a) also tried to use a  Symmetricom box for external reference and had 
the same problems

3) the same code we are testing with works when using an x310 instead of an 
e320, with inputs from the same octoclock

4) the code basically does this:
a) sets the reference source to external
b) checks to see if the reference is locked (and it keeps doing this 
until we get a "locked" response, using the uhd commands to do this)

5) for the e320, the locked status never returns (when running the x310 with 
this code, it sometimes responds with unlocked, but after a few checks it comes 
back ok)

6) I tried some of the Ettus (UHD) test code
a) running the "sync_to_gps" program did work - the reference was able 
to lock to the internal (gps) reference
b) "test_clock_synch"  returns similiar errors to what we get with our 
program (see below):
Checking USRP devices for lock.
 * 318B08B: false
WARNING: One or more devices not locked.
Querying Clock for time and setting USRP times...
[WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked. MB_CLOCK_CTRL 
reg: 0x0002
Running 10 comparisons at random intervals.
Comparison #1
 * Clock time: 1563463644
 * 318B08B time: 1563463644
Comparison #2
 * Clock time: 1563463652
 * 318B08B time: 1563463652
Comparison #3
 * Clock time: 1563463657
 * 318B08B time: 1563463657
Comparison #4
 * Clock time: 1563463664
 * 318B08B time: 1563463664
Comparison #5
 * Clock time: 1563463666
 * 318B08B time: 1563463666
Comparison #6
 * Clock time: 1563463671
 * 318B08B time: 1563463671
Comparison #7
 * Clock time: 1563463676
 * 318B08B time: 1563463676
Comparison #8
 * Clock time: 1563463686
 * 318B08B time: 1563463686
Comparison #9
 * Clock time: 1563463689
 * 318B08B time: 1563463689
Comparison #10
 * Clock time: 1563463691
 * 318B08B time: 1563463691

Number of matches: 10/10


7) we ran the same tests at a sister site that has four E320s, and they all 
exhibited the same issues

8)Finally, a uhd_usrp_probe command returns this:

[INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-36); 
Boost_105300; UHD_3.14.1.0-9-g2aa5289d
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
mgmt_addr=192.168.10.3,type=e3xx,product=e320,serial=318B08B,claimed=False,addr=192.168.10.3
[WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked. MB_CLOCK_CTRL 
reg: 0x0002
... many of these warnings repeating ...
[WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked. MB_CLOCK_CTRL 
reg: 0x0002
[WARNING] [MPM.RPCServer] A timeout event occured!
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D000)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1324 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1322 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10003320)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
[INFO] [MPM.PeriphManager] init() called with device args 
`product=e320,mgmt_addr=192.168.10.3'.
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2)
[INFO] [0/Radio_0] Performing CODEC loopback test...
[INFO] [0/Radio_0] CODEC loopback test passed
[INFO] [0/Radio_0] Performing CODEC loopback test...
[INFO] [0/Radio_0] CODEC loopback test passed
  _
 /
|   Device: E300-Series Device
| _
|/
|   |   Mboard: ni-e320-318B08B
|   |   eeprom_version: 2
|   |   mpm_version: 3.14.0.0-g6875d061
|   |   pid: 58144
|   |   product: e320
|   |   rev: 2
|   |   rpc_connection: remote
|   |   serial: 318B08B
|   |   type: e3xx
|   |   MPM Version: 1.2
|   |   FPGA Version: 3.1
|   |   FPGA git hash: e39334f.clean
|   |   RFNoC capable: Yes
|   |
|   |   Time sources:  internal, external, gpsdo
|   |   Clock sources: external, internal, gpsdo
|   |   Sensors: gps_sky, gps_locked, temp_rf_channelA, temp_rf_channelB, 
temp_internal, fan, temp_main_power, ref_locked, gps_gpgga, temp_fpga, gps_tpv, 
gps_time
|   | _

Re: [USRP-users] E320 unable to lock to external reference

[Jason Matusiak via USRP-users]

That would be great, thanks so much


From: Nate Temple 
Sent: Thursday, July 18, 2019 3:49 PM
To: Jason Matusiak 
Cc: Ettus Mail List 
Subject: Re: [USRP-users] E320 unable to lock to external reference

Hi Jason,

This might be a bug with the E320. I will need to try to recreate this issue. 
I'll follow up as soon as I have more info.

Regards,
Nate Temple

On Thu, Jul 18, 2019 at 12:32 PM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
OK, we've been fighting this for a while and we think we narrowed it down to 
being a problem with the E320 (NOTE: we are running the E320 in network mode, 
not embedded)

Some background:
1) external reference input is from an octo clock (so it the 1pps input) on 
many different ports
a) also tried to use a  Symmetricom box for external reference and had 
the same problems

3) the same code we are testing with works when using an x310 instead of an 
e320, with inputs from the same octoclock

4) the code basically does this:
a) sets the reference source to external
b) checks to see if the reference is locked (and it keeps doing this 
until we get a "locked" response, using the uhd commands to do this)

5) for the e320, the locked status never returns (when running the x310 with 
this code, it sometimes responds with unlocked, but after a few checks it comes 
back ok)

6) I tried some of the Ettus (UHD) test code
a) running the "sync_to_gps" program did work - the reference was able 
to lock to the internal (gps) reference
b) "test_clock_synch"  returns similiar errors to what we get with our 
program (see below):
Checking USRP devices for lock.
 * 318B08B: false
WARNING: One or more devices not locked.
Querying Clock for time and setting USRP times...
[WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked. MB_CLOCK_CTRL 
reg: 0x0002
Running 10 comparisons at random intervals.
Comparison #1
 * Clock time: 1563463644
 * 318B08B time: 1563463644
Comparison #2
 * Clock time: 1563463652
 * 318B08B time: 1563463652
Comparison #3
 * Clock time: 1563463657
 * 318B08B time: 1563463657
Comparison #4
 * Clock time: 1563463664
 * 318B08B time: 1563463664
Comparison #5
 * Clock time: 1563463666
 * 318B08B time: 1563463666
Comparison #6
 * Clock time: 1563463671
 * 318B08B time: 1563463671
Comparison #7
 * Clock time: 1563463676
 * 318B08B time: 1563463676
Comparison #8
 * Clock time: 1563463686
 * 318B08B time: 1563463686
Comparison #9
 * Clock time: 1563463689
 * 318B08B time: 1563463689
Comparison #10
 * Clock time: 1563463691
 * 318B08B time: 1563463691

Number of matches: 10/10


7) we ran the same tests at a sister site that has four E320s, and they all 
exhibited the same issues

8)Finally, a uhd_usrp_probe command returns this:

[INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-36); 
Boost_105300; UHD_3.14.1.0-9-g2aa5289d
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
mgmt_addr=192.168.10.3,type=e3xx,product=e320,serial=318B08B,claimed=False,addr=192.168.10.3
[WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked. MB_CLOCK_CTRL 
reg: 0x0002
... many of these warnings repeating ...
[WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked. MB_CLOCK_CTRL 
reg: 0x0002
[WARNING] [MPM.RPCServer] A timeout event occured!
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D000)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1324 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1322 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10003320)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
[INFO] [MPM.PeriphManager] init() called with device args 
`product=e320,mgmt_addr=192.168.10.3'.
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2)
[INFO] [0/Radio_0] Performing CODEC loopback test...
[INFO] [0/Radio_0] CODEC loopback test passed
[INFO] [0/Radio_0] Performing CODEC loopback test...
[INFO] [0/Radio_0] CODEC loopback test passed
  _
 /
|   Device: E300-Series Device
| _
|/
|   |   Mboard: ni-e320-318B08B
|   |   eeprom_version: 2
|   |   mpm_version: 3.14.0.0-g6875d061
|   |   pid: 58144
|   |   product: e320
|   |   rev: 2
|   |   rpc_connection: remote
|   |   serial: 318B08B
|   |   type: e3xx
|   |   MPM Version: 1.2
|   |   FPGA Version: 3.1
|   |   FPGA git hash: e39334f.clean
|   |   RFNoC capable: Yes
|   |
|   |   Time sources:  internal, external, gpsdo
|   |   Clock sources: external, internal, gpsdo
|   |   Sensors: gps_sky, gps_locked, temp_rf_channelA, temp_rf_channelB, 
temp_internal, fan, temp_main_power, ref_locked, gps_gpgga, temp_fpga, gps_tpv, 
gps_time
|   | _

[USRP-users] E320 unable to lock to external reference

[Jason Matusiak via USRP-users]

OK, we've been fighting this for a while and we think we narrowed it down to 
being a problem with the E320 (NOTE: we are running the E320 in network mode, 
not embedded)

Some background:
1) external reference input is from an octo clock (so it the 1pps input) on 
many different ports
a) also tried to use a  Symmetricom box for external reference and had 
the same problems

3) the same code we are testing with works when using an x310 instead of an 
e320, with inputs from the same octoclock

4) the code basically does this:
a) sets the reference source to external
b) checks to see if the reference is locked (and it keeps doing this 
until we get a "locked" response, using the uhd commands to do this)

5) for the e320, the locked status never returns (when running the x310 with 
this code, it sometimes responds with unlocked, but after a few checks it comes 
back ok)

6) I tried some of the Ettus (UHD) test code
a) running the "sync_to_gps" program did work - the reference was able 
to lock to the internal (gps) reference
b) "test_clock_synch"  returns similiar errors to what we get with our 
program (see below):
Checking USRP devices for lock.
 * 318B08B: false
WARNING: One or more devices not locked.
Querying Clock for time and setting USRP times...
[WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked. MB_CLOCK_CTRL 
reg: 0x0002
Running 10 comparisons at random intervals.
Comparison #1
 * Clock time: 1563463644
 * 318B08B time: 1563463644
Comparison #2
 * Clock time: 1563463652
 * 318B08B time: 1563463652
Comparison #3
 * Clock time: 1563463657
 * 318B08B time: 1563463657
Comparison #4
 * Clock time: 1563463664
 * 318B08B time: 1563463664
Comparison #5
 * Clock time: 1563463666
 * 318B08B time: 1563463666
Comparison #6
 * Clock time: 1563463671
 * 318B08B time: 1563463671
Comparison #7
 * Clock time: 1563463676
 * 318B08B time: 1563463676
Comparison #8
 * Clock time: 1563463686
 * 318B08B time: 1563463686
Comparison #9
 * Clock time: 1563463689
 * 318B08B time: 1563463689
Comparison #10
 * Clock time: 1563463691
 * 318B08B time: 1563463691

Number of matches: 10/10


7) we ran the same tests at a sister site that has four E320s, and they all 
exhibited the same issues

8)Finally, a uhd_usrp_probe command returns this:

[INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-36); 
Boost_105300; UHD_3.14.1.0-9-g2aa5289d
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
mgmt_addr=192.168.10.3,type=e3xx,product=e320,serial=318B08B,claimed=False,addr=192.168.10.3
[WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked. MB_CLOCK_CTRL 
reg: 0x0002
... many of these warnings repeating ...
[WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked. MB_CLOCK_CTRL 
reg: 0x0002
[WARNING] [MPM.RPCServer] A timeout event occured!
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D000)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1324 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1322 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10003320)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
[INFO] [MPM.PeriphManager] init() called with device args 
`product=e320,mgmt_addr=192.168.10.3'.
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2)
[INFO] [0/Radio_0] Performing CODEC loopback test...
[INFO] [0/Radio_0] CODEC loopback test passed
[INFO] [0/Radio_0] Performing CODEC loopback test...
[INFO] [0/Radio_0] CODEC loopback test passed
  _
 /
|   Device: E300-Series Device
| _
|/
|   |   Mboard: ni-e320-318B08B
|   |   eeprom_version: 2
|   |   mpm_version: 3.14.0.0-g6875d061
|   |   pid: 58144
|   |   product: e320
|   |   rev: 2
|   |   rpc_connection: remote
|   |   serial: 318B08B
|   |   type: e3xx
|   |   MPM Version: 1.2
|   |   FPGA Version: 3.1
|   |   FPGA git hash: e39334f.clean
|   |   RFNoC capable: Yes
|   |
|   |   Time sources:  internal, external, gpsdo
|   |   Clock sources: external, internal, gpsdo
|   |   Sensors: gps_sky, gps_locked, temp_rf_channelA, temp_rf_channelB, 
temp_internal, fan, temp_main_power, ref_locked, gps_gpgga, temp_fpga, gps_tpv, 
gps_time
|   | _
|   |/
|   |   |   RX Dboard: A
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: 0
|   |   |   |   Name: Neon
|   |   |   |   Antennas: RX2, TX/RX
|   |   |   |   Sensors: lo_locked, ad9361_temperature, rssi, lo_lock
|   |   |   |   Freq range: 70.000 to 6000.000 MHz
|   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
|   |   |   |   Bandwidth range: 2000.0 to 4000.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | 

Re: [USRP-users] Sequence Errors N200

[Jason Matusiak via USRP-users]

You are right, the table of revisions was for the X-series

try running the command from your prefix: 
src/uhd/host/build/utils/usrp_burn_mb_eeprom --args="type=n200" --read-all

don't quote me on the type portion, I don't have a board in front of me to see 
if it is n200 or something else.  I //think// that will report the major and 
minor revision values (I am grasping at straws here, just trying to figure out 
what the differences might be).

You are connecting the ethernet connections to the two devices through the 
exact same port on your PC?


From: Sumit Kumar 
Sent: Wednesday, July 17, 2019 8:24 AM
To: Jason Matusiak 
Cc: usrp-users@lists.ettus.com 
Subject: Re: [USRP-users] Sequence Errors N200

The sticker  for sbx shows F33612 and F33814.
How will this help ?


On Wed, Jul 17, 2019 at 1:50 PM Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:
Sumit,

OK, the last idea I have:

There is a sticker on the back of the N-series devices it usually says the 
version there, but not always.  This has a little info: 
https://kb.ettus.com/About_the_Motherboard_and_Daughtercard_EEPROM_on_USRP_Devices#N200.2F210_EEPROM

Do they match?


From: Sumit Kumar mailto:cog...@gmail.com>>
Sent: Wednesday, July 17, 2019 7:45 AM
To: Jason Matusiak 
mailto:ja...@gardettoengineering.com>>
Cc: usrp-users@lists.ettus.com 
mailto:usrp-users@lists.ettus.com>>
Subject: Re: [USRP-users] Sequence Errors N200

Hi Jason,

Yes they are consistent, I mean the output of uhd_usrp_probe for both N200 is 
exactly the same (except the ip, serial and mac addr).
I do not know where the problem is! Hardware or software

Regards
Sumit

On Wed, Jul 17, 2019 at 1:19 PM Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:
I am not really an N-series guy, so this probably won't be helpful.  Have you 
tried doing a uhd_usrp_probe on both devices and seen that the responses are 
consistent?


From: USRP-users 
mailto:usrp-users-boun...@lists.ettus.com>> 
on behalf of Sumit Kumar via USRP-users 
mailto:usrp-users@lists.ettus.com>>
Sent: Wednesday, July 17, 2019 7:15 AM
To: usrp-users@lists.ettus.com 
mailto:usrp-users@lists.ettus.com>>
Subject: [USRP-users] Sequence Errors N200

Hi,
I am trying transmit using Ettus N200 (call it A) but getting this error 
message on the console

SSU

I looked for it on google and found these links
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-May/037495.html
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2012-July/032838.html

Both the links  suggested problem related to the gigabit port. Then I connected 
another USRP N200 (call it B) to the same laptop and tried transmitting using 
that as there were no such sequence error messages.

This makes me believe there is some problem with the first USRP, i.e., A.

Further I tried with different versions of UHD 3.11, UHD 3.15.. but its the 
same.

Receive is good only transmit is throwing error.

Not only with UHD, even in labview, when I transmit, I see nothing coming out 
from the N200 (A).

I am using SBXv2 daughter board.

Any clue!

Regards
--
--
Sumit kumar
Postdoc
SnT, Luxembourg




--
--
Sumit kumar
Postdoc
SnT, Luxembourg




--
--
Sumit kumar
Postdoc
SnT, Luxembourg


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

Re: [USRP-users] Sequence Errors N200

[Jason Matusiak via USRP-users]

Sumit,

OK, the last idea I have:

There is a sticker on the back of the N-series devices it usually says the 
version there, but not always.  This has a little info: 
https://kb.ettus.com/About_the_Motherboard_and_Daughtercard_EEPROM_on_USRP_Devices#N200.2F210_EEPROM

Do they match?


From: Sumit Kumar 
Sent: Wednesday, July 17, 2019 7:45 AM
To: Jason Matusiak 
Cc: usrp-users@lists.ettus.com 
Subject: Re: [USRP-users] Sequence Errors N200

Hi Jason,

Yes they are consistent, I mean the output of uhd_usrp_probe for both N200 is 
exactly the same (except the ip, serial and mac addr).
I do not know where the problem is! Hardware or software

Regards
Sumit

On Wed, Jul 17, 2019 at 1:19 PM Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:
I am not really an N-series guy, so this probably won't be helpful.  Have you 
tried doing a uhd_usrp_probe on both devices and seen that the responses are 
consistent?


From: USRP-users 
mailto:usrp-users-boun...@lists.ettus.com>> 
on behalf of Sumit Kumar via USRP-users 
mailto:usrp-users@lists.ettus.com>>
Sent: Wednesday, July 17, 2019 7:15 AM
To: usrp-users@lists.ettus.com 
mailto:usrp-users@lists.ettus.com>>
Subject: [USRP-users] Sequence Errors N200

Hi,
I am trying transmit using Ettus N200 (call it A) but getting this error 
message on the console

SSU

I looked for it on google and found these links
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-May/037495.html
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2012-July/032838.html

Both the links  suggested problem related to the gigabit port. Then I connected 
another USRP N200 (call it B) to the same laptop and tried transmitting using 
that as there were no such sequence error messages.

This makes me believe there is some problem with the first USRP, i.e., A.

Further I tried with different versions of UHD 3.11, UHD 3.15.. but its the 
same.

Receive is good only transmit is throwing error.

Not only with UHD, even in labview, when I transmit, I see nothing coming out 
from the N200 (A).

I am using SBXv2 daughter board.

Any clue!

Regards
--
--
Sumit kumar
Postdoc
SnT, Luxembourg




--
--
Sumit kumar
Postdoc
SnT, Luxembourg


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

Re: [USRP-users] Sequence Errors N200

[Jason Matusiak via USRP-users]

I am not really an N-series guy, so this probably won't be helpful.  Have you 
tried doing a uhd_usrp_probe on both devices and seen that the responses are 
consistent?


From: USRP-users  on behalf of Sumit Kumar 
via USRP-users 
Sent: Wednesday, July 17, 2019 7:15 AM
To: usrp-users@lists.ettus.com 
Subject: [USRP-users] Sequence Errors N200

Hi,
I am trying transmit using Ettus N200 (call it A) but getting this error 
message on the console

SSU

I looked for it on google and found these links
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-May/037495.html
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2012-July/032838.html

Both the links  suggested problem related to the gigabit port. Then I connected 
another USRP N200 (call it B) to the same laptop and tried transmitting using 
that as there were no such sequence error messages.

This makes me believe there is some problem with the first USRP, i.e., A.

Further I tried with different versions of UHD 3.11, UHD 3.15.. but its the 
same.

Receive is good only transmit is throwing error.

Not only with UHD, even in labview, when I transmit, I see nothing coming out 
from the N200 (A).

I am using SBXv2 daughter board.

Any clue!

Regards
--
--
Sumit kumar
Postdoc
SnT, Luxembourg


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

Re: [USRP-users] USRP E313

[Jason Matusiak via USRP-users]

Koyel,

It "supports" it, but that is a bit of a misnomer.  Unless you are using the 
aforementioned network mode (which has its own speed limitations due to it not 
being designed for anything more than testing), the Ethernet goes through the 
ARM first, so the speeds are no where near the possibilities of 1Gb.  If you 
are able to buy something different and still need embedded, look at the E320.  
The firmware isn't quite ready for prime time, but it is usable enough and its 
network mode is designed to be used like the other non-embedded devices and can 
work up to 10G.



From: USRP-users  on behalf of Koyel Das 
(Vehere) via USRP-users 
Sent: Tuesday, July 16, 2019 4:31 AM
To: Robin Coxe; Marcus D Leech
Cc: Ettus Mail List
Subject: Re: [USRP-users] USRP E313

Does it support 1gig Ethernet? That is will the data rate be 1 gig?

Regards,

Koyel Das
Senior – Product Engineer
Vehere | Proactive Communications Intelligence & Cyber Defence
M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: www.vehere.com



Vehere is the proud recipient of the Fastest Growing Technology Company Awards 
in India & Asia since 2012!

The content of this e-mail is confidential and intended solely for the use of 
the addressee. The text of this email (including any attachments) may contain 
information, which is proprietary and/or confidential or privileged in nature 
belonging to Vehere Interactive Pvt Ltd and/or its associates/ group companies/ 
subsidiaries. If you are not the addressee, or the person responsible for 
delivering it to the addressee, any disclosure, copying, distribution or any 
action taken or omitted to be taken in reliance on it is prohibited and may be 
unlawful. If you have received this e-mail in error, please notify the sender 
and remove this communication entirely from your system. The recipient 
acknowledges that no guarantee or any warranty is given as to completeness and 
accuracy of the content of the email. The recipient further acknowledges that 
the views contained in the email message are those of the sender and may not 
necessarily reflect those of Vehere Interactive Pvt Ltd. Before opening and 
accessing the attachment please check and scan for virus. WARNING: Computer 
viruses can be transmitted via email. The recipient should check this email and 
any attachments for the presence of viruses. The company accepts no liability 
for any damage caused by any virus transmitted by this email.

From: Robin Coxe 
Sent: Monday, July 15, 2019 8:18:41 PM
To: Marcus D Leech
Cc: Koyel Das (Vehere); Ettus Mail List
Subject: Re: [USRP-users] USRP E313

The USRP E313 is an E310 in a weatherproof enclosure with PoE capability.   As 
Marcus points out, the network interface to the PC (over 1gigE RJ-45) has far 
less bandwidth than an Ettus-branded USRP X310 or NI USRP 294x or 295x using a 
PCIe or 2x10 gigE link to a host PC.



On Mon, Jul 15, 2019 at 7:44 AM Marcus D Leech via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
Not really possible except for a test mode called network mode that offers very 
low bandwidth

Sent from my iPhone

On Jul 15, 2019, at 4:27 AM, Koyel Das (Vehere) via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


Hi,


The following USRP


https://www.ettus.com/all-products/usrp-e313/

[https://www.ettus.com/wp-content/uploads/2019/01/E313_Front-Large_2-1200x630.jpg]
USRP E313 | Ettus Research, a National Instruments Brand | The leader in 
Software Defined Radio (SDR)
www.ettus.com
The USRP E313 is a rugged and weatherproof SDR designed for outdoor deployment. 
Containing an embedded USRP E310 inside an IP67-rated enclosure, the USRP E313 
provides ingress protection against dust and water with extensive testing to 
ensure operation under demanding environmental conditions.

has embedded processor I think. So is it possible that we don't use the 
embedded processor and use it like USRP 2955 that is capture data using 
gnuradio API and process it in our computer as we are doing with 2955?



Regards,

Koyel Das
Senior – Product Engineer

Vehere | Proactive Communications Intelligence & Cyber Defence
M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
www.vehere.com

[unnamed] [unnamed 
(1)]   [unnamed (2)] 


Vehere is the proud recipient of the Fastest Growing Technology Company Awards 
in India & Asia since 2012!

The content of this e-mail is confidential and intended solely for the use of 
the addressee. The text of this email (including any attachments) may contain 
information, which is proprietary and/or confidential or privileged in nature 
belonging to Vehere Interactive Pvt Ltd and/or its associates/ 

[USRP-users] Issues shutting down an E320

[Jason Matusiak via USRP-users]

I've noticed issues getting my E320 to shutdown sometimes.  It is almost like 
it is halting, but not going down far enough to turn off the unit (the LED 
doesn't turn off).


I'll issue the "shutdown -h now" command and it will kick me out of my ssh 
session (which is fine).  I cannot ping it anymore, so that makes me feel like 
it is shutting down, but the green LED never goes out.  I've tried the "-P" 
flag, but that doesn't seem to help.


Again, this isn't every time, but sometimes (maybe it is dependent on which 
E320 I am using, I haven't kept a good enough watch on when it happens to be 
sure).


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

Re: [USRP-users] E320 with larger SD card

[Jason Matusiak via USRP-users]

Alright, I am going to say that this is a non-starter for the time being.  
Digging around I found this "Known Issues" comment on the mender-convert page 
(https://github.com/mendersoftware/mender-convert):


  *   An issue for Raspberry Pi Zero W has been spotted with the mender-convert 
tool version 1.1.0. After an initial boot, having last partition resized to the 
end of the SD card, the correct device tree cannot be found. As a result the 
boot cannot succeed. For more information and current status, see issue 
tracker.

We aren't using a pi, but it certainly feels like the same issue.


From: Jason Matusiak
Sent: Thursday, June 20, 2019 10:24 AM
To: Chris Gobbett; Ettus List
Subject: Re: [USRP-users] E320 with larger SD card


OK, I thought I had it, but it is still not working.  Here are some new details 
though.


I load up a fresh SD card (I've tried both bmaptools as well as dd).  I toss it 
into my E320 and it boots up happy as pie.  I do a proper shutdown and put it 
back into my host PC.  I unmount and then using gparted I extend the data 
partition. I put the SD card back into the E320 and it boots up fine.  dh is 
showing that the partition is the new larger size and uhd_find_devices works, 
so I am happy there.  I reboot and all is gravy.  I shutdown -h now and 
power-up and all is gravy.


I then create a folder in /data called localinstall.  Shutdown and then boot 
up, all is fine.


I install my cross-compiled uhd into that folder.  I issue a shutdown -h now 
command and it seems to shutdown fine.  Then it never powers up again.  It 
really feels like even though the partition shows up as the new size on the 
device, that I am overwriting the small partition size and screwing things up...



From: Chris Gobbett 
Sent: Wednesday, June 19, 2019 8:21 PM
To: Jason Matusiak; Ettus List
Cc: Ettus Mail List
Subject: Re: [USRP-users] E320 with larger SD card


My understanding of the partiitons on the card are (in order);



Mender allows you to boot from one of the A/B partitions as your primary 
filesystem (mounted as /), plus the persistent data (mounted as /home/ or /data 
or similar).

My experience is if you perform resizing while keeping the partitions 
contiguous (no free space between them), and have the A and B partitions 
identical in size, it "just works". So my steps in the previous reply would 
look like:
   <--empty space--->  # original image on large SD Card
   <-empty 
space>  # shift persistent data to the end
   <--filesystem+kernel A-><--filesystem+kernel 
B->  # maximise A/B partitions, keeping A and B the 
same size

Rather than extending the data partition, I wanted to add new libraries and 
applications in /usr, which is located on the A/B partitions. Hence my 
instructions involve me resizing those partitions instead of the data partition.

If you're simply extending the size of the persistent data partition without 
shifting it's start point (while leaving the other partitions alone) I'm at a 
loss as to why it wouldn't work. But when you do this you may need some extra 
linux-fu to shift your new binary/library locations to that partition rather 
than the default /usr.

Cheers,
Chris

- Original Message -
From:
"Jason Matusiak" 

To:
"Chris Gobbett" 
Cc:
"Ettus Mail List" 
Sent:
Wed, 19 Jun 2019 23:12:40 +
Subject:
Re: [USRP-users] E320 with larger SD card


Chris, thanks for the tips.

So I put a fresh load on a card, then used gparted to extend the data partition 
to fill things out. That isn't enough, and your instructions certainly show 
more steps. But I don't understand what you mean with the partitions in the 
middle.

I'll read up on Mender and see if that answers it for me. Thanks again.
On Jun 19, 2019, at 6:56 PM, Chris Gobbett 
mailto:go...@tpg.com.au>> wrote:

Hi Jason,

I've had luck with the following:
- backup/clone the original SDCard image to disk and/or larger SDCard (using dd 
or otherwise)
- on the new card, resize/shift the data partion to the end of the card (using 
gparted)
- resize the two filesystem/kernel partitions to fill in the empty space in the 
middle, but they need to be the same size (using gparted)

Read up on Mender for more info on the partition layout 
(https://docs.mender.io/1.7/devices/general-system-requirements#partition-layout).
 It's a pain that they went with Mender for the default E320 card; it cuts the 
'usable' file system space in half, at the benefit of having 2 independent 
filesystem partitions... I haven't had time to fiddle around and ditch the 
mender for a 'normal' partition layout, but I'd assume it's possible.

Cheers,
Chris



- Original Message -
From:
"Jason Matusiak" 

To:
"Ettus Mail List" 
Cc:

Sent:
Wed, 19 Jun 2019 16:29:38 +
Subject:
[USRP-users] E320 with larger SD card



I wanted to use a 

Re: [USRP-users] E320 with larger SD card

[Jason Matusiak via USRP-users]

OK, I thought I had it, but it is still not working.  Here are some new details 
though.


I load up a fresh SD card (I've tried both bmaptools as well as dd).  I toss it 
into my E320 and it boots up happy as pie.  I do a proper shutdown and put it 
back into my host PC.  I unmount and then using gparted I extend the data 
partition. I put the SD card back into the E320 and it boots up fine.  dh is 
showing that the partition is the new larger size and uhd_find_devices works, 
so I am happy there.  I reboot and all is gravy.  I shutdown -h now and 
power-up and all is gravy.


I then create a folder in /data called localinstall.  Shutdown and then boot 
up, all is fine.


I install my cross-compiled uhd into that folder.  I issue a shutdown -h now 
command and it seems to shutdown fine.  Then it never powers up again.  It 
really feels like even though the partition shows up as the new size on the 
device, that I am overwriting the small partition size and screwing things up...



From: Chris Gobbett 
Sent: Wednesday, June 19, 2019 8:21 PM
To: Jason Matusiak; Ettus List
Cc: Ettus Mail List
Subject: Re: [USRP-users] E320 with larger SD card


My understanding of the partiitons on the card are (in order);



Mender allows you to boot from one of the A/B partitions as your primary 
filesystem (mounted as /), plus the persistent data (mounted as /home/ or /data 
or similar).

My experience is if you perform resizing while keeping the partitions 
contiguous (no free space between them), and have the A and B partitions 
identical in size, it "just works". So my steps in the previous reply would 
look like:
   <--empty space--->  # original image on large SD Card
   <-empty 
space>  # shift persistent data to the end
   <--filesystem+kernel A-><--filesystem+kernel 
B->  # maximise A/B partitions, keeping A and B the 
same size

Rather than extending the data partition, I wanted to add new libraries and 
applications in /usr, which is located on the A/B partitions. Hence my 
instructions involve me resizing those partitions instead of the data partition.

If you're simply extending the size of the persistent data partition without 
shifting it's start point (while leaving the other partitions alone) I'm at a 
loss as to why it wouldn't work. But when you do this you may need some extra 
linux-fu to shift your new binary/library locations to that partition rather 
than the default /usr.

Cheers,
Chris

- Original Message -
From:
"Jason Matusiak" 

To:
"Chris Gobbett" 
Cc:
"Ettus Mail List" 
Sent:
Wed, 19 Jun 2019 23:12:40 +
Subject:
Re: [USRP-users] E320 with larger SD card


Chris, thanks for the tips.

So I put a fresh load on a card, then used gparted to extend the data partition 
to fill things out. That isn't enough, and your instructions certainly show 
more steps. But I don't understand what you mean with the partitions in the 
middle.

I'll read up on Mender and see if that answers it for me. Thanks again.
On Jun 19, 2019, at 6:56 PM, Chris Gobbett 
mailto:go...@tpg.com.au>> wrote:

Hi Jason,

I've had luck with the following:
- backup/clone the original SDCard image to disk and/or larger SDCard (using dd 
or otherwise)
- on the new card, resize/shift the data partion to the end of the card (using 
gparted)
- resize the two filesystem/kernel partitions to fill in the empty space in the 
middle, but they need to be the same size (using gparted)

Read up on Mender for more info on the partition layout 
(https://docs.mender.io/1.7/devices/general-system-requirements#partition-layout).
 It's a pain that they went with Mender for the default E320 card; it cuts the 
'usable' file system space in half, at the benefit of having 2 independent 
filesystem partitions... I haven't had time to fiddle around and ditch the 
mender for a 'normal' partition layout, but I'd assume it's possible.

Cheers,
Chris



- Original Message -
From:
"Jason Matusiak" 

To:
"Ettus Mail List" 
Cc:

Sent:
Wed, 19 Jun 2019 16:29:38 +
Subject:
[USRP-users] E320 with larger SD card



I wanted to use a larger SD card than the one that as supplied, but I am having 
issues.  I loaded up the card, and then extended the data partition to use up 
the rest of the free space (about 100GB).  But then it doesn't boot.


I am wondering if the change to a partition size screwed up something in a 
config file somewhere.  Is there a way to fix this without rebuilding a docker 
image?  I am using the UHD 3.14.0.0. that has the smaller data partition (UHD 
3.14.1.0 has a larger data partition, but doesn't include any GR/python 
packages, so I need to use the older image).


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

Re: [USRP-users] E320 with larger SD card

[Jason Matusiak via USRP-users]

OK, I see now what you were doing different. I think I could deal with leaving 
the /data partition the same size and increasing the two filesystems. I was 
just trying to save myself the hassle of performing a mender update down the 
road and forgetting that the data in ~/ wasn't persistent.

I guess it is something to try for now (tomorrow), and then flesh out the /data 
problem after having a better understanding of what is going on (hopefully).
On Jun 19, 2019, at 8:21 PM, Chris Gobbett 
mailto:go...@tpg.com.au>> wrote:

My understanding of the partiitons on the card are (in order);



Mender allows you to boot from one of the A/B partitions as your primary 
filesystem (mounted as /), plus the persistent data (mounted as /home/ or /data 
or similar).

My experience is if you perform resizing while keeping the partitions 
contiguous (no free space between them), and have the A and B partitions 
identical in size, it "just works". So my steps in the previous reply would 
look like:
   <--empty space--->  # original image on large SD Card
   <-empty 
space>  # shift persistent data to the end
   <--filesystem+kernel A-><--filesystem+kernel 
B->  # maximise A/B partitions, keeping A and B the 
same size

Rather than extending the data partition, I wanted to add new libraries and 
applications in /usr, which is located on the A/B partitions. Hence my 
instructions involve me resizing those partitions instead of the data partition.

If you're simply extending the size of the persistent data partition without 
shifting it's start point (while leaving the other partitions alone) I'm at a 
loss as to why it wouldn't work. But when you do this you may need some extra 
linux-fu to shift your new binary/library locations to that partition rather 
than the default /usr.

Cheers,
Chris

- Original Message -
From:
"Jason Matusiak" 

To:
"Chris Gobbett" 
Cc:
"Ettus Mail List" 
Sent:
Wed, 19 Jun 2019 23:12:40 +
Subject:
Re: [USRP-users] E320 with larger SD card


Chris, thanks for the tips.

So I put a fresh load on a card, then used gparted to extend the data partition 
to fill things out. That isn't enough, and your instructions certainly show 
more steps. But I don't understand what you mean with the partitions in the 
middle.

I'll read up on Mender and see if that answers it for me. Thanks again.
On Jun 19, 2019, at 6:56 PM, Chris Gobbett < 
go...@tpg.com.au> wrote:

Hi Jason,

I've had luck with the following:
- backup/clone the original SDCard image to disk and/or larger SDCard (using dd 
or otherwise)
- on the new card, resize/shift the data partion to the end of the card (using 
gparted)
- resize the two filesystem/kernel partitions to fill in the empty space in the 
middle, but they need to be the same size (using gparted)

Read up on Mender for more info on the partition layout 
(https://docs.mender.io/1.7/devices/general-system-requirements#partition-layout).
 It's a pain that they went with Mender for the default E320 card; it cuts the 
'usable' file system space in half, at the benefit of having 2 independent 
filesystem partitions... I haven't had time to fiddle around and ditch the 
mender for a 'normal' partition layout, but I'd assume it's possible.

Cheers,
Chris



- Original Message -
From:
"Jason Matusiak" 

To:
"Ettus Mail List" 
Cc:

Sent:
Wed, 19 Jun 2019 16:29:38 +
Subject:
[USRP-users] E320 with larger SD card



I wanted to use a larger SD card than the one that as supplied, but I am having 
issues.  I loaded up the card, and then extended the data partition to use up 
the rest of the free space (about 100GB).  But then it doesn't boot.


I am wondering if the change to a partition size screwed up something in a 
config file somewhere.  Is there a way to fix this without rebuilding a docker 
image?  I am using the UHD 3.14.0.0. that has the smaller data partition (UHD 
3.14.1.0 has a larger data partition, but doesn't include any GR/python 
packages, so I need to use the older image).


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

Re: [USRP-users] E320 with larger SD card

[Jason Matusiak via USRP-users]

Chris, thanks for the tips.

So I put a fresh load on a card, then used gparted to extend the data partition 
to fill things out. That isn't enough, and your instructions certainly show 
more steps. But I don't understand what you mean with the partitions in the 
middle.

I'll read up on Mender and see if that answers it for me. Thanks again.
On Jun 19, 2019, at 6:56 PM, Chris Gobbett 
mailto:go...@tpg.com.au>> wrote:

Hi Jason,

I've had luck with the following:
- backup/clone the original SDCard image to disk and/or larger SDCard (using dd 
or otherwise)
- on the new card, resize/shift the data partion to the end of the card (using 
gparted)
- resize the two filesystem/kernel partitions to fill in the empty space in the 
middle, but they need to be the same size (using gparted)

Read up on Mender for more info on the partition layout 
(https://docs.mender.io/1.7/devices/general-system-requirements#partition-layout).
 It's a pain that they went with Mender for the default E320 card; it cuts the 
'usable' file system space in half, at the benefit of having 2 independent 
filesystem partitions... I haven't had time to fiddle around and ditch the 
mender for a 'normal' partition layout, but I'd assume it's possible.

Cheers,
Chris



- Original Message -
From:
"Jason Matusiak" 

To:
"Ettus Mail List" 
Cc:

Sent:
Wed, 19 Jun 2019 16:29:38 +
Subject:
[USRP-users] E320 with larger SD card



I wanted to use a larger SD card than the one that as supplied, but I am having 
issues.  I loaded up the card, and then extended the data partition to use up 
the rest of the free space (about 100GB).  But then it doesn't boot.


I am wondering if the change to a partition size screwed up something in a 
config file somewhere.  Is there a way to fix this without rebuilding a docker 
image?  I am using the UHD 3.14.0.0. that has the smaller data partition (UHD 
3.14.1.0 has a larger data partition, but doesn't include any GR/python 
packages, so I need to use the older image).


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

Re: [USRP-users] E320 with larger SD card

[Jason Matusiak via USRP-users]

I used bmaptool to write the image and I used gparted to extend it.  I just 
tried again and still no dice.


I just tried to boot with the serial terminal on and I see this on the screen 
(no LED ever comes on):


U-Boot SPL 2018.01 (May 10 2019 - 13:20:55)
mmc boot
Trying to boot from MMC1
reading u-boot.img
reading u-boot.img


U-Boot 2018.01 (May 10 2019 - 13:20:55 +)

Model: NI Ettus Research Project NEON SDR
DRAM:  ECC disabled 1 GiB
MMC:   sdhci@e010: 0






From: USRP-users  on behalf of Marcus D. 
Leech via USRP-users 
Sent: Wednesday, June 19, 2019 12:33 PM
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] E320 with larger SD card

On 06/19/2019 12:29 PM, Jason Matusiak via USRP-users wrote:

I wanted to use a larger SD card than the one that as supplied, but I am having 
issues.  I loaded up the card, and then extended the data partition to use up 
the rest of the free space (about 100GB).  But then it doesn't boot.

What steps did you take to extend the partition?




I am wondering if the change to a partition size screwed up something in a 
config file somewhere.  Is there a way to fix this without rebuilding a docker 
image?  I am using the UHD 3.14.0.0. that has the smaller data partition (UHD 
3.14.1.0 has a larger data partition, but doesn't include any GR/python 
packages, so I need to use the older image).


Thanks.



___
USRP-users mailing list
USRP-users@lists.ettus.com<mailto: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] E320 with larger SD card

[Jason Matusiak via USRP-users]

I wanted to use a larger SD card than the one that as supplied, but I am having 
issues.  I loaded up the card, and then extended the data partition to use up 
the rest of the free space (about 100GB).  But then it doesn't boot.


I am wondering if the change to a partition size screwed up something in a 
config file somewhere.  Is there a way to fix this without rebuilding a docker 
image?  I am using the UHD 3.14.0.0. that has the smaller data partition (UHD 
3.14.1.0 has a larger data partition, but doesn't include any GR/python 
packages, so I need to use the older image).


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

Re: [USRP-users] UHD not seeing E320

[Jason Matusiak via USRP-users]

Problem solved.  It was a firewall issue.  Is there a list of what ports I 
should make sure are opened to UDP?  The ones I caught were 49152 and 49154.


Are there any others I need to know?


From: Jason Matusiak
Sent: Wednesday, June 12, 2019 10:32 AM
To: Ettus Mail List
Subject: UHD not seeing E320


I have a new issue with my E320.  I loaded up an E320 with an SD card image 
that I have used on a different working E320.


On my personal machine, I am using a 1G image that seems to work fine and 
uhd_find_device (and probe) seems to be working fine.  I change the IP and load 
up an XG image onto it.  I move it physically to a server that uses 10G.  The 
particular ethernet port works fine with my X310 I had had hooked up to it.  I 
disconnected my X310 and plugged in my E320.  I can ping and SSH the device 
fine.  When I run a probe or a a find devices, I don't find a UHD device.  I 
tried with different versions of UHD and they all seem to have the same 
problem.  When I am ssh'ed onto the device, probes and finds work fine 
internally.


Is there something I am missing here?  The port worked with an X310 completely, 
and can talk to an E320, but that is all; I am very perplexed.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] UHD not seeing E320

[Jason Matusiak via USRP-users]

I have a new issue with my E320.  I loaded up an E320 with an SD card image 
that I have used on a different working E320.


On my personal machine, I am using a 1G image that seems to work fine and 
uhd_find_device (and probe) seems to be working fine.  I change the IP and load 
up an XG image onto it.  I move it physically to a server that uses 10G.  The 
particular ethernet port works fine with my X310 I had had hooked up to it.  I 
disconnected my X310 and plugged in my E320.  I can ping and SSH the device 
fine.  When I run a probe or a a find devices, I don't find a UHD device.  I 
tried with different versions of UHD and they all seem to have the same 
problem.  When I am ssh'ed onto the device, probes and finds work fine 
internally.


Is there something I am missing here?  The port worked with an X310 completely, 
and can talk to an E320, but that is all; I am very perplexed.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Unable to detect X310 over pcie

[Jason Matusiak via USRP-users]

I had similar issues (that I never overcame).  Here was some tips I received 
back in FEB when I tried: 
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-February/059114.html



From: USRP-users  on behalf of kailash 
kumar via USRP-users 
Sent: Tuesday, June 11, 2019 2:55 AM
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Unable to detect X310 over pcie

Hi,

I am unable to detect X310 over pcie. I have installed uhd(v3.14.0.0) and 
compiled and installed RIO drivers as well. Below is my configuration:

UHD RIO Installer version:
niusrprio-installer-18.0.0

[pretlist@clr-85a7812169e346e6b143a228fe1b9641 Downloads]$ sudo niusrprio_pcie 
start
Making sure drivers are up to date...
Module nikal is up-to-date
Module nibds is up-to-date
Module nistreamk is up-to-date
Module NiRioSrv is up-to-date
Module niusrpriok is up-to-date
Loading: NiRioSrv niusrpriok
Starting: niusrpriorpc

[pretlist@clr-85a7812169e346e6b143a228fe1b9641 Downloads]$ lsmod | grep -i ni
niusrpriok417792  0
NiRioSrv  942080  0
nistreamk 131072  2 niusrpriok,NiRioSrv
nibds  57344  2 niusrpriok,NiRioSrv
nikal  98304  4 niusrpriok,NiRioSrv,nistreamk,nibds

[pretlist@clr-85a7812169e346e6b143a228fe1b9641 Downloads]$ uname -r
4.19.48-48.lts2018

[pretlist@clr-85a7812169e346e6b143a228fe1b9641 Downloads]$ ls /dev/ni/
'nistreamk:0\nistreamk\0'

[pretlist@clr-85a7812169e346e6b143a228fe1b9641 Downloads]$ sudo netstat -anp| 
grep 5444
tcp0  0 0.0.0.0:54440.0.0.0:*  
 LISTEN  1845/niusrpriorpc

[pretlist@clr-85a7812169e346e6b143a228fe1b9641 Downloads]$ uhd_usrp_probe 
--args "type=x300,resource=RIO0"
[INFO] [UHD] linux; GNU C++ version 9.1.1 20190605 gcc-9-branch@271943; 
Boost_106800; UHD_3.14.0.HEAD-0-g6875d061
[ERROR] [UHD] Device discovery error: input stream error
Error: LookupError: KeyError: No devices found for ->
Device Address:
type: x300
resource: RIO0

[pretlist@clr-85a7812169e346e6b143a228fe1b9641 uhd]$ git status
HEAD detached at v3.14.0.0

Digging through uhd code
lib/usrp/x300/x300_impl.cpp (x300_find_pcie ) ->
lib/usrp/x300/x300_impl.cpp (niusrprio_session::enumerate(rpc_port_name, 
dev_info_vtr)) ->
lib/transport/nirio/niusrprio_session.cpp 
(nirio_status_chain(temp_rpc_client.niusrprio_enumerate(device_info_vtr), 
status)) ->
lib/transport/nirio/rpc/usrprio_rpc_client.cpp  
(usrprio_rpc_client::niusrprio_enumerate(NIUSRPRIO_ENUMERATE_ARGS))

out_args >> status; -> This returns status as -52012

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

Re: [USRP-users] E320 hogging the network

[Jason Matusiak via USRP-users]

Bingo, thanks.  One note though, the type is e3x0 (not e300).


Doesn't the e310 understand an IP address of 127.0.0.1 though?  I would think 
that something like that would be a perfect use-case for the localhost.




From: USRP-users  on behalf of Marcus D. 
Leech via USRP-users 
Sent: Friday, June 7, 2019 5:34 PM
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] E320 hogging the network

On 06/07/2019 03:05 PM, Jason Matusiak via USRP-users wrote:

OK, this is actually an E310 problem.  The E310 always looks off device first.  
A coworker reminded me that we spent a couple days years back trying to figure 
out why the device was asking like it was working, but we weren't seeing any 
results.  It was because it was actually talking to an N2xx on the network even 
with the IP address arg.


We never found a solution (using both the 127 and 192 address as an argument 
still causes issues).  So, it would be nice to clean this up on the E310 at 
some point, but for now I will try not to mix the E310 and E320 on the same 
subnet.

For the case of running E310 apps *on* the E310, just use "type=e300", radio 
hardware on the E310 itself doesn't *have* an IP address, so using
  addr= will simply cause UHD to go down the wrong device path when you're 
running it ON the E31x itself.


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

Re: [USRP-users] offset tuning on the TwinRX

[Jason Matusiak via USRP-users]

A good write-up, thanks Sulvain.


I forgot all about how they functioned.  I worked on an SDR project a million 
years ago (before SDR was a thing) that did this.  I just used it and didn't 
realize that it was a super-het, and then I forgot all about it once I started 
using USRPs.


Thanks.



From: Sylvain Munaut <246...@gmail.com>
Sent: Wednesday, June 5, 2019 11:31 AM
To: Jason Matusiak
Cc: Robin Coxe; Ettus Mail List
Subject: Re: [USRP-users] offset tuning on the TwinRX



On Wed, Jun 5, 2019 at 4:41 PM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
OK, thanks everyone.  I guess I have some superhet reading up to do .

In a nutshell, it's _always_ using LO offset :)

The RF path always brings the signal to some IF  (150 MHz IIRC), then the DDC 
blocks do the shift to baseband DC digitally.

So it's pretty much like if you had set the lo_offset = 150 MHz.

The finer points are :
 - It's not doing I/Q sampling, it uses one ADC for one channel and the other 
for the second one.
 - It's actually using band-pass sampling since the IF is higer than fs / 2.

But of course that means the hardware DDC blocks in the fpga are used already 
and that's why you can't (and there would be no point anyway) to apply some 
second level of lo_offset.


Cheers,

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

Re: [USRP-users] E320 hogging the network

[Jason Matusiak via USRP-users]

OK, I will keep an eye on that.  No GR will kill us for now though.  I've been 
playing with the build system for an E320 the last 2 weeks and have learned to 
build //some// extra things in (including GR, but I haven't moved that image 
onto a device yet), so I could probably take a swag at it, but it probably 
would be easier for me to just wait.  The main issue with GR on the E320 for me 
(which I assume will be an issue on the E310 as well) is that scipy isn't built 
for it.  Lots of GR examples use it, and I am worried that some of our internal 
OOT modules might, so I tried to build it in, but I went down a 2 day rabbit 
hole trying to get python-scipy working (it seems to be hard to do in oe based 
on other people in other projects struggling with it).


I'll keep an eye on the MPM and knowledge base updates, thanks.



From: Nate Temple 
Sent: Friday, June 7, 2019 3:10 PM
To: Jason Matusiak
Cc: Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Hi Jason,

You could try running the new 3.15 MPM based file system for the E310, but it 
has some caveats, more details here: 
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-May/059897.html



Regards,
Nate Temple

On Fri, Jun 7, 2019 at 12:05 PM Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:

OK, this is actually an E310 problem.  The E310 always looks off device first.  
A coworker reminded me that we spent a couple days years back trying to figure 
out why the device was asking like it was working, but we weren't seeing any 
results.  It was because it was actually talking to an N2xx on the network even 
with the IP address arg.


We never found a solution (using both the 127 and 192 address as an argument 
still causes issues).  So, it would be nice to clean this up on the E310 at 
some point, but for now I will try not to mix the E310 and E320 on the same 
subnet.



From: Jason Matusiak
Sent: Friday, June 7, 2019 12:41 PM
To: Nate Temple
Cc: Marcus D Leech; Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network


OK, maybe based on my last email (which crossed yours I think).  The addr flag 
doesn't seem to work at all with the uhd_usrp_probe on the E310 (at least my 
version).


From: Nate Temple mailto:nate.tem...@ettus.com>>
Sent: Friday, June 7, 2019 12:37 PM
To: Jason Matusiak
Cc: Marcus D Leech; Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Hi Jason,

For what its worth, I haven't personally ran this exact combo (E310 w/ UHD 3.11 
and E320 w/ 3.14) on the same subnet, but I have ran two N320's on the same 
subnet (192.168.10.2 and 192.168.10.3, both with 3.14). I did run into the 
issue where probing in embedded mode would pickup the other device first, but 
when providing a localhost addr, it worked as expected. I could use both 
devices from a common host in network mode.

Trying the E320/E310 on different subnets would be worth a try.

I'll open an internal issue on our bug tracker for this, there is likely 
improvements we can make to the device discovery.


Regards,
Nate Temple

On Fri, Jun 7, 2019 at 9:22 AM Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:

Howdy.


Nope, but it fails in a weird way.  I disconnected the E320 to make sure this 
issue wasn't due to it, but it still acts the same.


If I run: uhd_usrp_probe --args "addr=127.0.0.1"

root@ettus-e3xx-sg3:~# uhd_usrp_probe --args "addr=127.0.0.1"
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106400; UHD_3.11.0.1-0-unknown
Error: i2c_zc_impl recv timeout



Reading up on the USRP2, they specifically say that you need to be on different 
subnets if you are using more than on device.  I wonder if this is the case 
here too?
https://files.ettus.com/manual/page_usrp2.html#usrp2_network_multidev



From: Nate Temple mailto:nate.tem...@ettus.com>>
Sent: Friday, June 7, 2019 12:17 PM
To: Jason Matusiak
Cc: Marcus D Leech; Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Hi Jason,

On the E310, if you pass the device arg addr with 127.0.0.1 does it work as 
expected?

uhd_usrp_probe --args "addr=127.0.0.1"


Regards,
Nate Temple

On Fri, Jun 7, 2019 at 9:10 AM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:

Darn, I was hoping that was it, but I don't think so.


Here is the result from my E310:

eth0  Link encap:Ethernet  HWaddr 00:80:2F:25:44:46

and now the E320:

sfp0  Link encap:Ethernet  HWaddr 00:80:2F:24:C2:FB

If I ping each device on my host, then run arp, I see this (the mac addresses 
match up correctly):

Address  HWtype  HWaddress   Flags MaskIface
192.168.10.45ether   00:80:2f:24:c2:fb   C p4p1
192.168.10.95 

Re: [USRP-users] E320 hogging the network

[Jason Matusiak via USRP-users]

OK, this is actually an E310 problem.  The E310 always looks off device first.  
A coworker reminded me that we spent a couple days years back trying to figure 
out why the device was asking like it was working, but we weren't seeing any 
results.  It was because it was actually talking to an N2xx on the network even 
with the IP address arg.


We never found a solution (using both the 127 and 192 address as an argument 
still causes issues).  So, it would be nice to clean this up on the E310 at 
some point, but for now I will try not to mix the E310 and E320 on the same 
subnet.



From: Jason Matusiak
Sent: Friday, June 7, 2019 12:41 PM
To: Nate Temple
Cc: Marcus D Leech; Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network


OK, maybe based on my last email (which crossed yours I think).  The addr flag 
doesn't seem to work at all with the uhd_usrp_probe on the E310 (at least my 
version).


From: Nate Temple 
Sent: Friday, June 7, 2019 12:37 PM
To: Jason Matusiak
Cc: Marcus D Leech; Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Hi Jason,

For what its worth, I haven't personally ran this exact combo (E310 w/ UHD 3.11 
and E320 w/ 3.14) on the same subnet, but I have ran two N320's on the same 
subnet (192.168.10.2 and 192.168.10.3, both with 3.14). I did run into the 
issue where probing in embedded mode would pickup the other device first, but 
when providing a localhost addr, it worked as expected. I could use both 
devices from a common host in network mode.

Trying the E320/E310 on different subnets would be worth a try.

I'll open an internal issue on our bug tracker for this, there is likely 
improvements we can make to the device discovery.


Regards,
Nate Temple

On Fri, Jun 7, 2019 at 9:22 AM Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:

Howdy.


Nope, but it fails in a weird way.  I disconnected the E320 to make sure this 
issue wasn't due to it, but it still acts the same.


If I run: uhd_usrp_probe --args "addr=127.0.0.1"

root@ettus-e3xx-sg3:~# uhd_usrp_probe --args "addr=127.0.0.1"
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106400; UHD_3.11.0.1-0-unknown
Error: i2c_zc_impl recv timeout



Reading up on the USRP2, they specifically say that you need to be on different 
subnets if you are using more than on device.  I wonder if this is the case 
here too?
https://files.ettus.com/manual/page_usrp2.html#usrp2_network_multidev



From: Nate Temple mailto:nate.tem...@ettus.com>>
Sent: Friday, June 7, 2019 12:17 PM
To: Jason Matusiak
Cc: Marcus D Leech; Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Hi Jason,

On the E310, if you pass the device arg addr with 127.0.0.1 does it work as 
expected?

uhd_usrp_probe --args "addr=127.0.0.1"


Regards,
Nate Temple

On Fri, Jun 7, 2019 at 9:10 AM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:

Darn, I was hoping that was it, but I don't think so.


Here is the result from my E310:

eth0  Link encap:Ethernet  HWaddr 00:80:2F:25:44:46

and now the E320:

sfp0  Link encap:Ethernet  HWaddr 00:80:2F:24:C2:FB

If I ping each device on my host, then run arp, I see this (the mac addresses 
match up correctly):

Address  HWtype  HWaddress   Flags MaskIface
192.168.10.45ether   00:80:2f:24:c2:fb   C p4p1
192.168.10.95ether   00:80:2f:25:44:46   C p4p1

I figured that that would be fine though because I have the same issue when I 
am running commands ON my E310.  And if it was a routing issue, it would mean 
that both my machine and the E310 and the E320 were being screwed up.



From: Marcus D Leech mailto:patchvonbr...@gmail.com>>
Sent: Friday, June 7, 2019 12:01 PM
To: Jason Matusiak
Cc: Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Check the MAC addresses.

I know that on some ARM platforms that has to be programmed in at boot and 
perhaps these system images have it set to the same value.

Sent from my iPhone

On Jun 7, 2019, at 11:52 AM, Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


Philip,


They have unique addresses (10.95 and 10.45).  It is really weird that when I 
am on the E310, and set the ip-addr to himself, that he would even look off the 
device


They both have hostnames and they are not similar to each other at all.



From: Philip Balister mailto:phi...@balister.org>>
Sent: Friday, June 7, 2019 11:10 AM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Check each ones ip address, likely by running ifconfig. In the back of
my mind, I recall something l

Re: [USRP-users] E320 hogging the network

[Jason Matusiak via USRP-users]

OK, maybe based on my last email (which crossed yours I think).  The addr flag 
doesn't seem to work at all with the uhd_usrp_probe on the E310 (at least my 
version).


From: Nate Temple 
Sent: Friday, June 7, 2019 12:37 PM
To: Jason Matusiak
Cc: Marcus D Leech; Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Hi Jason,

For what its worth, I haven't personally ran this exact combo (E310 w/ UHD 3.11 
and E320 w/ 3.14) on the same subnet, but I have ran two N320's on the same 
subnet (192.168.10.2 and 192.168.10.3, both with 3.14). I did run into the 
issue where probing in embedded mode would pickup the other device first, but 
when providing a localhost addr, it worked as expected. I could use both 
devices from a common host in network mode.

Trying the E320/E310 on different subnets would be worth a try.

I'll open an internal issue on our bug tracker for this, there is likely 
improvements we can make to the device discovery.


Regards,
Nate Temple

On Fri, Jun 7, 2019 at 9:22 AM Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:

Howdy.


Nope, but it fails in a weird way.  I disconnected the E320 to make sure this 
issue wasn't due to it, but it still acts the same.


If I run: uhd_usrp_probe --args "addr=127.0.0.1"

root@ettus-e3xx-sg3:~# uhd_usrp_probe --args "addr=127.0.0.1"
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106400; UHD_3.11.0.1-0-unknown
Error: i2c_zc_impl recv timeout



Reading up on the USRP2, they specifically say that you need to be on different 
subnets if you are using more than on device.  I wonder if this is the case 
here too?
https://files.ettus.com/manual/page_usrp2.html#usrp2_network_multidev



From: Nate Temple mailto:nate.tem...@ettus.com>>
Sent: Friday, June 7, 2019 12:17 PM
To: Jason Matusiak
Cc: Marcus D Leech; Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Hi Jason,

On the E310, if you pass the device arg addr with 127.0.0.1 does it work as 
expected?

uhd_usrp_probe --args "addr=127.0.0.1"


Regards,
Nate Temple

On Fri, Jun 7, 2019 at 9:10 AM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:

Darn, I was hoping that was it, but I don't think so.


Here is the result from my E310:

eth0  Link encap:Ethernet  HWaddr 00:80:2F:25:44:46

and now the E320:

sfp0  Link encap:Ethernet  HWaddr 00:80:2F:24:C2:FB

If I ping each device on my host, then run arp, I see this (the mac addresses 
match up correctly):

Address  HWtype  HWaddress   Flags MaskIface
192.168.10.45ether   00:80:2f:24:c2:fb   C p4p1
192.168.10.95ether   00:80:2f:25:44:46   C p4p1

I figured that that would be fine though because I have the same issue when I 
am running commands ON my E310.  And if it was a routing issue, it would mean 
that both my machine and the E310 and the E320 were being screwed up.



From: Marcus D Leech mailto:patchvonbr...@gmail.com>>
Sent: Friday, June 7, 2019 12:01 PM
To: Jason Matusiak
Cc: Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Check the MAC addresses.

I know that on some ARM platforms that has to be programmed in at boot and 
perhaps these system images have it set to the same value.

Sent from my iPhone

On Jun 7, 2019, at 11:52 AM, Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


Philip,


They have unique addresses (10.95 and 10.45).  It is really weird that when I 
am on the E310, and set the ip-addr to himself, that he would even look off the 
device


They both have hostnames and they are not similar to each other at all.



From: Philip Balister mailto:phi...@balister.org>>
Sent: Friday, June 7, 2019 11:10 AM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Check each ones ip address, likely by running ifconfig. In the back of
my mind, I recall something like this in the E100 days. Do they have the
same hostname?

Philip

On 06/07/2019 07:37 AM, Jason Matusiak via USRP-users wrote:
> It looks like I am misunderstanding something with how the E320 handles the 
> network.
>
>
> I have my E320 on my subnet with the sfp0 assigned to 10.45 (instead of the 
> default 10.2).  I can ssh into it and things seem to run fine in embedded 
> mode.
>
>
> Now, if I ssh onto an E312 that is on the same network (IP 10.95), it doesn't 
> work right as long as the E320 is plugged in.  When I do a probe or run any 
> other UHD-type commands on the E310, it seems to always talk to the E320 
> first and it screws everything up.  It doesn't matter if I put the E310's 
> address into the command or not, the E320 responds.  

Re: [USRP-users] E320 hogging the network

[Jason Matusiak via USRP-users]

Howdy.


Nope, but it fails in a weird way.  I disconnected the E320 to make sure this 
issue wasn't due to it, but it still acts the same.


If I run: uhd_usrp_probe --args "addr=127.0.0.1"

root@ettus-e3xx-sg3:~# uhd_usrp_probe --args "addr=127.0.0.1"
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106400; UHD_3.11.0.1-0-unknown
Error: i2c_zc_impl recv timeout



Reading up on the USRP2, they specifically say that you need to be on different 
subnets if you are using more than on device.  I wonder if this is the case 
here too?
https://files.ettus.com/manual/page_usrp2.html#usrp2_network_multidev



From: Nate Temple 
Sent: Friday, June 7, 2019 12:17 PM
To: Jason Matusiak
Cc: Marcus D Leech; Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Hi Jason,

On the E310, if you pass the device arg addr with 127.0.0.1 does it work as 
expected?

uhd_usrp_probe --args "addr=127.0.0.1"


Regards,
Nate Temple

On Fri, Jun 7, 2019 at 9:10 AM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:

Darn, I was hoping that was it, but I don't think so.


Here is the result from my E310:

eth0  Link encap:Ethernet  HWaddr 00:80:2F:25:44:46

and now the E320:

sfp0  Link encap:Ethernet  HWaddr 00:80:2F:24:C2:FB

If I ping each device on my host, then run arp, I see this (the mac addresses 
match up correctly):

Address  HWtype  HWaddress   Flags MaskIface
192.168.10.45ether   00:80:2f:24:c2:fb   C p4p1
192.168.10.95ether   00:80:2f:25:44:46   C p4p1

I figured that that would be fine though because I have the same issue when I 
am running commands ON my E310.  And if it was a routing issue, it would mean 
that both my machine and the E310 and the E320 were being screwed up.



From: Marcus D Leech mailto:patchvonbr...@gmail.com>>
Sent: Friday, June 7, 2019 12:01 PM
To: Jason Matusiak
Cc: Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Check the MAC addresses.

I know that on some ARM platforms that has to be programmed in at boot and 
perhaps these system images have it set to the same value.

Sent from my iPhone

On Jun 7, 2019, at 11:52 AM, Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


Philip,


They have unique addresses (10.95 and 10.45).  It is really weird that when I 
am on the E310, and set the ip-addr to himself, that he would even look off the 
device


They both have hostnames and they are not similar to each other at all.



From: Philip Balister mailto:phi...@balister.org>>
Sent: Friday, June 7, 2019 11:10 AM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Check each ones ip address, likely by running ifconfig. In the back of
my mind, I recall something like this in the E100 days. Do they have the
same hostname?

Philip

On 06/07/2019 07:37 AM, Jason Matusiak via USRP-users wrote:
> It looks like I am misunderstanding something with how the E320 handles the 
> network.
>
>
> I have my E320 on my subnet with the sfp0 assigned to 10.45 (instead of the 
> default 10.2).  I can ssh into it and things seem to run fine in embedded 
> mode.
>
>
> Now, if I ssh onto an E312 that is on the same network (IP 10.95), it doesn't 
> work right as long as the E320 is plugged in.  When I do a probe or run any 
> other UHD-type commands on the E310, it seems to always talk to the E320 
> first and it screws everything up.  It doesn't matter if I put the E310's 
> address into the command or not, the E320 responds.  I also remember seeing 
> this occur when I was on my host machine running commands (the E320 bullied 
> its way into being the main attraction).
>
>
> My current work-around is to unplug Ethernet from the E320, run my command on 
> the E310, plug back into the E320, then run its command.  This seems to allow 
> things to work as I intended, but is obviously not ideal and is fairly 
> difficult to do when devices are remote.
>
>
> So what am I missing here?
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
USRP-users Info Page - 
Ettus<http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
lists.ettus.com<http://lists.ettus.com>
To see the collection of prior postings to the list, visit the USRP-users 
Archives.. Using USRP-users: To post a message to all the list members, send 
email to usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>. You can 
subscribe to the list, or change your existing 

Re: [USRP-users] E320 hogging the network

[Jason Matusiak via USRP-users]

Philip,


They have unique addresses (10.95 and 10.45).  It is really weird that when I 
am on the E310, and set the ip-addr to himself, that he would even look off the 
device


They both have hostnames and they are not similar to each other at all.



From: Philip Balister 
Sent: Friday, June 7, 2019 11:10 AM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Check each ones ip address, likely by running ifconfig. In the back of
my mind, I recall something like this in the E100 days. Do they have the
same hostname?

Philip

On 06/07/2019 07:37 AM, Jason Matusiak via USRP-users wrote:
> It looks like I am misunderstanding something with how the E320 handles the 
> network.
>
>
> I have my E320 on my subnet with the sfp0 assigned to 10.45 (instead of the 
> default 10.2).  I can ssh into it and things seem to run fine in embedded 
> mode.
>
>
> Now, if I ssh onto an E312 that is on the same network (IP 10.95), it doesn't 
> work right as long as the E320 is plugged in.  When I do a probe or run any 
> other UHD-type commands on the E310, it seems to always talk to the E320 
> first and it screws everything up.  It doesn't matter if I put the E310's 
> address into the command or not, the E320 responds.  I also remember seeing 
> this occur when I was on my host machine running commands (the E320 bullied 
> its way into being the main attraction).
>
>
> My current work-around is to unplug Ethernet from the E320, run my command on 
> the E310, plug back into the E320, then run its command.  This seems to allow 
> things to work as I intended, but is obviously not ideal and is fairly 
> difficult to do when devices are remote.
>
>
> So what am I missing here?
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
USRP-users Info Page - 
Ettus<http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
lists.ettus.com
To see the collection of prior postings to the list, visit the USRP-users 
Archives.. Using USRP-users: To post a message to all the list members, send 
email to usrp-users@lists.ettus.com. You can subscribe to the list, or change 
your existing subscription, in the sections below.


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

[USRP-users] two E320 radios

[Jason Matusiak via USRP-users]

OK, another E320 question.  With my custom RFNoC image, only a Radio_0 shows 
up.  Shouldn't there be a Radio_1 as well?
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] E320 hogging the network

[Jason Matusiak via USRP-users]

It looks like I am misunderstanding something with how the E320 handles the 
network.


I have my E320 on my subnet with the sfp0 assigned to 10.45 (instead of the 
default 10.2).  I can ssh into it and things seem to run fine in embedded mode.


Now, if I ssh onto an E312 that is on the same network (IP 10.95), it doesn't 
work right as long as the E320 is plugged in.  When I do a probe or run any 
other UHD-type commands on the E310, it seems to always talk to the E320 first 
and it screws everything up.  It doesn't matter if I put the E310's address 
into the command or not, the E320 responds.  I also remember seeing this occur 
when I was on my host machine running commands (the E320 bullied its way into 
being the main attraction).


My current work-around is to unplug Ethernet from the E320, run my command on 
the E310, plug back into the E320, then run its command.  This seems to allow 
things to work as I intended, but is obviously not ideal and is fairly 
difficult to do when devices are remote.


So what am I missing here?
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] problem with custom E320 FPGA image

[Jason Matusiak via USRP-users]

I figured it out.  The problem was that in noc_block_split_stream.v, rb_stb was 
set to 1'b1 in the noc_shell instantiation.


I changed it to  ".rb_stb({NUM_OUTPUTS{1'b1}})" and it seems to have build OK.



From: USRP-users  on behalf of Jason 
Matusiak via USRP-users 
Sent: Thursday, June 6, 2019 2:04 PM
To: Ettus Mail List
Subject: [USRP-users] problem with custom E320 FPGA image


I've seen chatter on this around here before (an I think I might have been 
involved with it during my failed N310 project a while back), but I haven't 
come up with a solution yet.


I have a custom RFNoC bitfile I want to use on the E320.  I set things up and 
built it with the mods in rfnoc_ce_auto_inst_e320.v to fix the clk like is done 
in rfnoc_ce_default_inst_e320.v.


It builds fine and I scp it over to the E320.  I then load it up with the 
command: uhd_image_loader --args="type=e3xx" --fpga-path="/home/root/e320.bit"


It acts like everything worked fine, but then when I probe it, it errors out:

root@ni-e320-318B090:~# uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106600; 
UHD_3.14.1.HEAD-0-g5491b80e
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
mgmt_addr=127.0.0.1,type=e3xx,product=e320,serial=318B090,claimed=False
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D000)
[INFO] [MPM.PeriphManager] init() called with device args 
`mgmt_addr=127.0.0.1,product=e320'.
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1313 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1337 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10003320)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC1)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC1)
[INFO] [0/DDC_2] Initializing block control (NOC ID: 0xDDC1)
[INFO] [0/DDC_3] Initializing block control (NOC ID: 0xDDC1)
[WARNING] [RFNOC] Can't find a block controller for key keepMinN, using default 
block controller!
[INFO] [0/keepMinN_0] Initializing block control (NOC ID: 0x229C30C919275220)
[WARNING] [RFNOC] Can't find a block controller for key keepMinN, using default 
block controller!
[INFO] [0/keepMinN_1] Initializing block control (NOC ID: 0x229C30C919275220)
[WARNING] [RFNOC] Can't find a block controller for key SplitStream, using 
default block controller!
[INFO] [0/SplitStream_0] Initializing block control (NOC ID: 0x5757)
[ERROR] [UHD] Exception caught in safe-call.
  in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with uhd::endianness_t 
_endianness = (uhd::endianness_t)1]
  at /opt/gnuradio/e320/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:52
this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block ctrl 
(CE_08_Port_A1) no response packet - AssertionError: bool(buff)
  in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) [with 
uhd::endianness_t _endianness = (uhd::endianness_t)1; uint64_t = long long 
unsigned int]
  at /opt/gnuradio/e320/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:142

[ERROR] [MPMD] Failure during block enumeration: EnvironmentError: IOError: 
[0/SplitStream_0] sr_read64() failed: EnvironmentError: IOError: Block ctrl 
(CE_08_Port_A1) no response packet - AssertionError: bool(buff)
  in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) [with 
uhd::endianness_t _endianness = (uhd::endianness_t)1; uint64_t = long long 
unsigned int]
  at /opt/gnuradio/e320/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:142

Error: RuntimeError: Failed to run enumerate_rfnoc_blocks()
root@ni-e320-318B090:~#



I thought that this error was due to the clocks in the inst file being wrong, 
but I've made that mod already.  Any other thoughts?  What is a little weird to 
me is that it is complaining about CE_08_Port_A1, but I only have 8 CEs, so I 
would have thought my largest one would be CE_07.


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

Re: [USRP-users] offset tuning on the TwinRX

[Jason Matusiak via USRP-users]

OK, thanks everyone.  I guess I have some superhet reading up to do .


From: Robin Coxe 
Sent: Tuesday, June 4, 2019 2:41 PM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] offset tuning on the TwinRX

Hi Jason.   Yes, it is a super-het receiver.   All other Ettus radios employ 
direct conversion transceivers.

-Robin



From: USRP-users  on behalf of Jason 
Matusiak via USRP-users 
Sent: Wednesday, June 5, 2019 2:31 AM
To: Ettus Mail List
Subject: [USRP-users] offset tuning on the TwinRX

An associate was asking me about the TwinRX (which I haven't really used).  He 
apparently uses offset tuning on the B series often for his gnuradio 
flowgraphs.  He was trying to do it with the TwinRX and can't find the hooks 
for it.  I looked around briefly and came up empty as well.  I assume that 
there is something about the TwinRX that prevents offset tuning, so I was 
curious what that might be.

Thanks
___
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]

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

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.
>>
>> Phil

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-user

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 'gnura

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

[Jason Matusiak via USRP-users]

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

[Jason Matusiak via USRP-users]

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

[Jason Matusiak via USRP-users]

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] vert 2450 quarter wave monopole?

[Jason Matusiak via USRP-users]

According to this, it is a dipole: 
https://kb.ettus.com/images/9/9e/ettus_research_vert2450_datasheet.pdf


From: USRP-users  on behalf of Koyel Das 
(Vehere) via USRP-users 
Sent: Tuesday, May 14, 2019 5:45 AM
To: 'USRP-users@lists.ettus.com'
Subject: [USRP-users] vert 2450 quarter wave monopole?


Hi,


Can someone tell me if vert 2450 is quarter wave monopole antenna? Or what is 
it?


Regards,

Koyel Das
Senior – Product Engineer

Vehere | Proactive Communications Intelligence & Cyber Defence
M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
www.vehere.com

[unnamed] [unnamed 
(1)]   [unnamed (2)] 


Vehere is the proud recipient of the Fastest Growing Technology Company Awards 
in India & Asia since 2012!

The content of this e-mail is confidential and intended solely for the use of 
the addressee. The text of this email (including any attachments) may contain 
information, which is proprietary and/or confidential or privileged in nature 
belonging to Vehere Interactive Pvt Ltd and/or its associates/ group companies/ 
subsidiaries. If you are not the addressee, or the person responsible for 
delivering it to the addressee, any disclosure, copying, distribution or any 
action taken or omitted to be taken in reliance on it is prohibited and may be 
unlawful. If you have received this e-mail in error, please notify the sender 
and remove this communication entirely from your system. The recipient 
acknowledges that no guarantee or any warranty is given as to completeness and 
accuracy of the content of the email. The recipient further acknowledges that 
the views contained in the email message are those of the sender and may not 
necessarily reflect those of Vehere Interactive Pvt Ltd. Before opening and 
accessing the attachment please check and scan for virus. WARNING: Computer 
viruses can be transmitted via email. The recipient should check this email and 
any attachments for the presence of viruses. The company accepts no liability 
for any damage caused by any virus transmitted by this email.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Need a little help with running legacy prebuilt UHD versions

[Jason Matusiak via USRP-users]

Maybe try running a VM of a version of Ubuntu that is roughly the vintage of 
that version of UHD?


From: USRP-users  on behalf of Joe Martin 
via USRP-users 
Sent: Thursday, May 9, 2019 9:53 AM
To: Joe Martin
Cc: usrp-users@lists.ettus.com
Subject: [USRP-users] Need a little help with running legacy prebuilt UHD 
versions

I need a bit of help to understand how to run legacy prebuilt UHD versions from 
the files.ettus.com/binaries/uhd 
repository.

I would like to try various UHD versions to try to find a version that will run 
with an elderly (Rev 2) N210 with unknown firmware/fpga images in it.  After 
downloading a legacy version, e.g., 
uhd_003.004.000-release_Ubuntu-11.10-x86_64.deb, and clicking “install” I am 
not understanding what I need to do next to actually run the version, as 
uhd_usrp_probe —version reports the version of UHD that I originally had 
installed, not the legacy version I intended to install.

I am running Ubuntu 18.04, should I expect to be able to run the legacy 
versions labeled, for example, *_Ubuntu-11.10-x86_64.deb, as in the example 
above ?

Clearly I’m missing something fundamental, and likely simple, in my 
understanding about how to use these prebuilt older versions.  I have had no 
problem building, installing, and running UHD versions from source but I have 
never tried to run a “prebuilt” version before.

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

Re: [USRP-users] Bringing an elderly N210 to life by loading current firmware/fpga images

[Jason Matusiak via USRP-users]

R3 didn't work for me either.  I am not sure I would even bother with the 
support email, I think they tried hard for me last year and they couldn't 
revive that rev's source code at all.  We abandoned our r2 Ns and just worked 
on the ones that were already working.


From: Joe Martin 
Sent: Wednesday, May 8, 2019 12:56 PM
To: Jason Matusiak
Cc: Joe Martin via USRP-users
Subject: Re: [USRP-users] Bringing an elderly N210 to life by loading current 
firmware/fpga images

Wow, okay; that’s disheartening.  Thanks much for the info, Jason.  Nope, the 
Rev3 bit file doesn’t work; tried it.  I’ll see if the support email adr can be 
of use.

Joe

On May 8, 2019, at 10:44 AM, Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:

Joe, I think you might be SOL.  If you take a look at this thread from me last 
year, I had no luck: 
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html


Also, when I pinged Ettus directly, here is some info I got back from them 
(from two different emails in the thread):
"we've been having some trouble tracking down Rev2 bitfiles, because no
one here was around when that was built. If you're trying to unbrick
them, Rev3 bitfiles might be OK, but I'm not completely sure.

supp...@ettus.com might know more by know.
really sorry, but those Rev2s are just so old. And all the people from
that era seem to be gone. Sorry, can't help you with those Rev2s."


From: USRP-users 
mailto:usrp-users-boun...@lists.ettus.com>> 
on behalf of Joe Martin via USRP-users 
mailto:usrp-users@lists.ettus.com>>
Sent: Wednesday, May 8, 2019 11:55 AM
To: Joe Martin via USRP-users
Subject: [USRP-users] Bringing an elderly N210 to life by loading current 
firmware/fpga images

I am trying to bring an elderly N210 r2.0 with unknown history to life by 
loading current UHD firmware and fpga images from a 1Gigabit ethernet 
connection on an AMD 2950X, 3.4GHz, 2TB SSD PC running Ubuntu 18.04 with UHD 
3.14.0.HEAD-0-gd20a7ae2 software but having difficulty.

Following instructions in “USRP Hardware Driver and USRP Manual: USRP2 and N2x0 
Series”:

My initial action was to load the “usrp_n210_r4_fpga.bit" file into the N210 
xc3sd3400a FPGA using a Xilinx Platform Cable USB II JTAG programming cable 
from a Win7 PC running Xilinx ISE iMPACT, which reported “Program Succeeded” 
for the action.  Ethernet LEDs on the N210 are variously lighted showing 
activity on the connection port.

With the N210 connected to the Linux PC 1Gbps ethernet port, issuing the 
following commands result in the responses shown in the screenshot image below:



My (naive!) interpretation of the above responses is that the FPGA may not 
actually have been programmed with the *.bit code even though iMPACT reported 
success in programming.  Can someone assist me in understanding whether my 
interpretation is correct or not and, most importantly, suggest what I might 
try next to bring this N210 to life?

The “Please run:” suggestion results in the “Received invalid reply 32 from 
device” error.  It seems no matter what I try the “Received invalid reply 32 
from device” RuntimeError is reported back when I try to load any new 
firmware/FPGA images.

Thanks!

Joe

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

Re: [USRP-users] Running E310 in Network Mode

[Jason Matusiak via USRP-users]

See here: https://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_network_mode



From: USRP-users  on behalf of Ramazan 
Çetin via USRP-users 
Sent: Wednesday, May 8, 2019 8:02 AM
To: Ettus Research Support; usrp-users@lists.ettus.com
Subject: [USRP-users] Running E310 in Network Mode

Hello,

We want to run USRP E310 in network mode. I think the samples coming
from FPGA passing through CPU before sending to network. This decreases
bandwidth because of CPU limitations.


So, is there any ettus image or suggestions that we can run E310
directly from FPGA to network without speed limitations? (like N210 or B210)

Best regards.

Ramazan


___
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] E320 numpy missing?

[Jason Matusiak via USRP-users]

Thanks Neel, I will keep an eye out for updates.


From: Neel Pandeya 
Sent: Saturday, May 4, 2019 1:23 AM
To: Jason Matusiak
Cc: Ettus Mail List; Chris Gobbett
Subject: Re: [USRP-users] E320 numpy missing?

Hello Jason and Chris:

I understand your frustration. We are working on instructions for adding GNU 
Radio support to the E320, and we will provide you with a filesystem. We should 
have something ready for you by the middle of next week. I can be your 
point-of-contact on this issue, and feel free to contact me directly. I will 
make a follow-on post as well to update the mailing list.

--Neel Pandeya



On Thu, 2 May 2019 at 08:07, Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
Chris,

It is a shame that the E320 doesn't seem to have complete support, but maybe 
someone from Ettus will chime in at some point (though it has already been over 
a month since you posted).  As of now, these are paperweights in our office and 
I have to switch gears to a different project with a different vendor until it 
gets updated.  I am not sure who we can even ping at Ettus on the embedded 
front in case they aren't monitoring the mailing list.  Do you have a contact 
there on the embedded side?

You don't happen to have a series of steps posted somewhere that you use to try 
to get the E320 to a usable state do you?




From: USRP-users 
mailto:usrp-users-boun...@lists.ettus.com>> 
on behalf of Chris Gobbett via USRP-users 
mailto:usrp-users@lists.ettus.com>>
Sent: Wednesday, May 1, 2019 9:21 PM
To: Ettus Mail List
Subject: Re: [USRP-users] E320 numpy missing?

I've had similar problems since this post in March, and still waiting on a 
'clean' way forward
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-March/059332.html

In the interim I've done lots of cross-compiling and also stealing 
libraries/binaries from working E310 images; many of the included binaries seem 
gimped or a step down from what was on the E310.

- Original Message -
From:
"Jason Matusiak" 
mailto:ja...@gardettoengineering.com>>

To:
"Philip Balister" mailto:phi...@balister.org>>, "Ettus 
Mail List" mailto:usrp-users@lists.ettus.com>>
Cc:

Sent:
Wed, 1 May 2019 14:40:16 +
Subject:
Re: [USRP-users] E320 numpy missing?


I just double-checked and ENABLE_PYTHON is on in my system (which was 
apparently the default since I didn't spell it out in my cmake command).


From: Jason Matusiak
Sent: Wednesday, May 1, 2019 10:36 AM
To: Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 numpy missing?

I actually was using a .sh file from earlier in April, but pulling down the 
most recent: e3xx_e320_sdk_default-v3.13.0.2-20190415.zip, I still don't see 
pretty much any site-packages in the sysroot.

Those things seem to be there automatically when using the .sh info with the 
e310 files.

I will try including python in the cmake path (which I've never needed to do 
before), but is that going to be enough?  I feel like the back-and-forth you 
and I had last year with the rocko build for the E310 were for pretty similar 
issues.  But honestly, I need to look back at the emails for the exact issues 
at the time.


From: Philip Balister mailto:phi...@balister.org>>
Sent: Wednesday, May 1, 2019 10:31 AM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] E320 numpy missing?

On 05/01/2019 09:55 AM, Jason Matusiak via USRP-users wrote:
> I also get a "ImportError: No module named sip" when I try to run: 
> uhd_siggen_gui
>
> So I think a few things might be missing from the cross-compile setup.

I took a few minutes and looked at the current state of the BSP. It
looks like you might have this image:

https://github.com/EttusResearch/meta-ettus/blob/master/meta-ettus-core/recipes-core/images/developer-image.bb

I forget where numpy is the gnuradio dependency tree, but I'm going to
guess if you enable python support in gnuradio (yes it might be possible
to use gnuradio without python) you will need numpy to build/run.

Philip

>
> 
> From: Jason Matusiak
> Sent: Wednesday, May 1, 2019 8:46 AM
> To: Ettus Mail List
> Subject: E320 numpy missing?
>
> Finally got my E320 in and I cross-compiled a new setup.  I tried to fire up 
> my flowgraph (which works fine on an E310) and it is complaining about numpy 
> missing.
>
> If I do a search from / on the E320, the only numpy that is showing up is:
> /usr/include/boost/python/numpy
>
> If I do a search from a good E310 in / I see:
> ./usr/lib/python2.7/site-packages/numpy
> ./usr/lib/python2.7/site-packages/numpy/core/include/numpy
> ./usr/lib/python2.7/site-packages/Cython/Includes/numpy
> ./usr/include/boost/python/numpy
>
>
&

Re: [USRP-users] E310 not locking on GPS

[Jason Matusiak via USRP-users]

You are probably right.  What I discovered was it is the ublox itself that is 
the problem.

My solution is that at the top of my GR constructor, I disable the gpsd, send a 
reset command to the ublox, and then reenable the gpsd. So far so good with 
that approach.

On May 2, 2019, at 7:36 PM, Dan CaJacob 
mailto:dan.caja...@gmail.com>> wrote:
GPS doesn't like to go back in time. You probably need to reset the almanac and 
a reboot is doing that.

On Tue, Apr 30, 2019, 9:53 AM Jason Matusiak via USRP-users < 
usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote:
I've seen this a few times, but I cannot seem to lock it down to any particular 
reason.  While sitting at my desk with a GPS simulator (so I have a known good 
signal), I will be doing testing and everything is fine (it seems to be walking 
around the place where the unit was built).  I will turn off the GPS unit for 
the night and then the next day when I turn it on, I never get a fix.  I've 
seen this numerous times and the only way I can fix it is to reboot the E310.  
It is like the GPS is getting into a mucked up stated.  Data comes streaming 
through, but it is just the last good signal.

I can't figure out a way to reset the GPS without rebooting it, does anyone 
know of a way?  I tried killing and restarting the daemon, but that doesn't 
seem to do anything.  I really think it is the GPS module, but rebooting it 
everytime I want to run things "just in case."

One other weird thing, when I run gpsmon in this screwed up state, it mostly 
looks OK, but it has weird characters displayed throughout the ASCII heading 
(for lack of a better term).

This is a good setup on a different unit (so I don't expect to see a fix):
tcp://localhost:2947  u-blox>
┌──┐┌─┐ 
or":11}
│Ch PRN  Az  El S/N Flag U ││ECEF Pos: +6378137.00m  +0.00m  +0.00m   │ 
er":"u-blox","subtype":"Unknown","activated":"2018-10-10T06:21:07.701Z","flags":1,"native":1,"bps":9600,"parity":"N","stopbits":1,"cycle":1.00,"mincycle":0.25}]}
│ 0   1   0 165   0 0110   ││ECEF Vel: +0.00m/s +0.00m/s +0.00m/s │ 
false,"timing":false,"split24":false,"pps":true}
│ 1   2   0 165   0 0110   ││ │
│ 2   4   0 165   0 0110   ││LTP Pos:   0.0°   0.0°   -18.00m │
│ 3   6   0 165  23 0310   ││LTP Vel:0.00m/s   0.0°   0.00m/s │
│ 4   7   0 165   0 0110   ││ │
│ 5   9   0 165  23 0310   ││Time: 0 00:00:00.00  │
│ 6  14   0 165  22 0310   ││Time GPS: Day:   │
│ 7  19   0 165  22 0310   ││ │
│ 8  20   0 165  21 0310   ││Est Pos Err998.72st Vel Err   0.00m/s│
│ 9  21   0 165   0 0110   ││PRNs:  0 PDOP:100.0 Fix 0x00 Flags 0x40  │
│10  22   0 165   0 0110   │└─── NAV_SOL ─┘
│11  23   0 165   0 0110   │┌─┐
│12  24   0 165   0 0110   ││DOP [H] 100.0[V] 100.0[P] 100.0[T] 100.0[G] 100.0│
│13  28   0 165  23 0310   │└─── NAV_DOP ─┘
│14  30   0 165   0 0110   │┌─┐
│15 136   0 165   0 0110   ││TOFF: > 1 dayPPS:│

There are lines around the different sections (they look like lines, not dashes 
and bars).


and then on the unit that is hosed:
tcp://localhost:2947  u-blox>
lqqklqk 
or":11}
xCh PRN  Az  El S/N Flag U xxECEF Pos: -2414806.17m +5389584.51m +2400650.28m x 
er":"u-blox","subtype":"Unknown","activated":"2019-01-08T14:52:40.454Z","flags":1,"native":1,"bps":9600,"parity":"N","stopbits":1,"cycle":1.00,"mincycle":0.25}]}
x 0   2   0 165  50 0700   xxECEF Vel: +0.00m/s +0.00m/s +0.00m/s x 
false,"timing":false,"split24":false,"pps":true}
x 1   4   0 165  50 0700   xx x
x 2   5   0 165  50 0700   xxLTP Pos:  22.2557151134f 114.134790532f20.19m x
x 3   8   0 165   0 0100   xxLTP Vel:0.00m/s   0.0f   0.00m/s x
x 4   9   0 165  50 0700   xx x
x 5  10   0 165  50 0700   xxTime: 61 06:13:40.00 x
x 6  12   0 165  50 0700   xxTime GPS: 1877+529282.000 Day: 6 x
x 7  13   0 165  50 0600   xx x
x 8  

Re: [USRP-users] E320 numpy missing?

[Jason Matusiak via USRP-users]

Chris,

It is a shame that the E320 doesn't seem to have complete support, but maybe 
someone from Ettus will chime in at some point (though it has already been over 
a month since you posted).  As of now, these are paperweights in our office and 
I have to switch gears to a different project with a different vendor until it 
gets updated.  I am not sure who we can even ping at Ettus on the embedded 
front in case they aren't monitoring the mailing list.  Do you have a contact 
there on the embedded side?

You don't happen to have a series of steps posted somewhere that you use to try 
to get the E320 to a usable state do you?




From: USRP-users  on behalf of Chris 
Gobbett via USRP-users 
Sent: Wednesday, May 1, 2019 9:21 PM
To: Ettus Mail List
Subject: Re: [USRP-users] E320 numpy missing?

I've had similar problems since this post in March, and still waiting on a 
'clean' way forward
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-March/059332.html

In the interim I've done lots of cross-compiling and also stealing 
libraries/binaries from working E310 images; many of the included binaries seem 
gimped or a step down from what was on the E310.

- Original Message -
From:
"Jason Matusiak" 

To:
"Philip Balister" , "Ettus Mail List" 

Cc:

Sent:
Wed, 1 May 2019 14:40:16 +
Subject:
Re: [USRP-users] E320 numpy missing?


I just double-checked and ENABLE_PYTHON is on in my system (which was 
apparently the default since I didn't spell it out in my cmake command).


From: Jason Matusiak
Sent: Wednesday, May 1, 2019 10:36 AM
To: Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 numpy missing?

I actually was using a .sh file from earlier in April, but pulling down the 
most recent: e3xx_e320_sdk_default-v3.13.0.2-20190415.zip, I still don't see 
pretty much any site-packages in the sysroot.

Those things seem to be there automatically when using the .sh info with the 
e310 files.

I will try including python in the cmake path (which I've never needed to do 
before), but is that going to be enough?  I feel like the back-and-forth you 
and I had last year with the rocko build for the E310 were for pretty similar 
issues.  But honestly, I need to look back at the emails for the exact issues 
at the time.


From: Philip Balister 
Sent: Wednesday, May 1, 2019 10:31 AM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] E320 numpy missing?

On 05/01/2019 09:55 AM, Jason Matusiak via USRP-users wrote:
> I also get a "ImportError: No module named sip" when I try to run: 
> uhd_siggen_gui
>
> So I think a few things might be missing from the cross-compile setup.

I took a few minutes and looked at the current state of the BSP. It
looks like you might have this image:

https://github.com/EttusResearch/meta-ettus/blob/master/meta-ettus-core/recipes-core/images/developer-image.bb

I forget where numpy is the gnuradio dependency tree, but I'm going to
guess if you enable python support in gnuradio (yes it might be possible
to use gnuradio without python) you will need numpy to build/run.

Philip

>
> 
> From: Jason Matusiak
> Sent: Wednesday, May 1, 2019 8:46 AM
> To: Ettus Mail List
> Subject: E320 numpy missing?
>
> Finally got my E320 in and I cross-compiled a new setup.  I tried to fire up 
> my flowgraph (which works fine on an E310) and it is complaining about numpy 
> missing.
>
> If I do a search from / on the E320, the only numpy that is showing up is:
> /usr/include/boost/python/numpy
>
> If I do a search from a good E310 in / I see:
> ./usr/lib/python2.7/site-packages/numpy
> ./usr/lib/python2.7/site-packages/numpy/core/include/numpy
> ./usr/lib/python2.7/site-packages/Cython/Includes/numpy
> ./usr/include/boost/python/numpy
>
>
> Back on the host machine, my E320 cross-compile prefix shows numpy:
> ./sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/include/boost/python/numpy
>
> My good E310 prefix shows:
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/build/src.linux-x86_64-2.7/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/build/src.linux-x86_64-2.7/numpy/core/include/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/numpy/core/include/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/Cython/Includes/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/numpy/core/include/numpy
> ./sysroots/armv7ahf-

Re: [USRP-users] E320 numpy missing?

[Jason Matusiak via USRP-users]

I just double-checked and ENABLE_PYTHON is on in my system (which was 
apparently the default since I didn't spell it out in my cmake command).


From: Jason Matusiak
Sent: Wednesday, May 1, 2019 10:36 AM
To: Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 numpy missing?

I actually was using a .sh file from earlier in April, but pulling down the 
most recent: e3xx_e320_sdk_default-v3.13.0.2-20190415.zip, I still don't see 
pretty much any site-packages in the sysroot.

Those things seem to be there automatically when using the .sh info with the 
e310 files.

I will try including python in the cmake path (which I've never needed to do 
before), but is that going to be enough?  I feel like the back-and-forth you 
and I had last year with the rocko build for the E310 were for pretty similar 
issues.  But honestly, I need to look back at the emails for the exact issues 
at the time.


From: Philip Balister 
Sent: Wednesday, May 1, 2019 10:31 AM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] E320 numpy missing?

On 05/01/2019 09:55 AM, Jason Matusiak via USRP-users wrote:
> I also get a "ImportError: No module named sip" when I try to run: 
> uhd_siggen_gui
>
> So I think a few things might be missing from the cross-compile setup.

I took a few minutes and looked at the current state of the BSP. It
looks like you might have this image:

https://github.com/EttusResearch/meta-ettus/blob/master/meta-ettus-core/recipes-core/images/developer-image.bb

I forget where numpy is the gnuradio dependency tree, but I'm going to
guess if you enable python support in gnuradio (yes it might be possible
to use gnuradio without python) you will need numpy to build/run.

Philip

>
> 
> From: Jason Matusiak
> Sent: Wednesday, May 1, 2019 8:46 AM
> To: Ettus Mail List
> Subject: E320 numpy missing?
>
> Finally got my E320 in and I cross-compiled a new setup.  I tried to fire up 
> my flowgraph (which works fine on an E310) and it is complaining about numpy 
> missing.
>
> If I do a search from / on the E320, the only numpy that is showing up is:
> /usr/include/boost/python/numpy
>
> If I do a search from a good E310 in / I see:
> ./usr/lib/python2.7/site-packages/numpy
> ./usr/lib/python2.7/site-packages/numpy/core/include/numpy
> ./usr/lib/python2.7/site-packages/Cython/Includes/numpy
> ./usr/include/boost/python/numpy
>
>
> Back on the host machine, my E320 cross-compile prefix shows numpy:
> ./sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/include/boost/python/numpy
>
> My good E310 prefix shows:
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/build/src.linux-x86_64-2.7/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/build/src.linux-x86_64-2.7/numpy/core/include/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/numpy/core/include/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/Cython/Includes/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/numpy/core/include/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/boost/python/numpy
>
> So, was numpy forgotten?  Left out for a reason?  I am going to attempt to 
> build it by hand, but I have a fear that I am going to go down dependency 
> hell with this and other missing packages that GR might want.
>
>
>
>
> ___
> 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] E320 numpy missing?

[Jason Matusiak via USRP-users]

I actually was using a .sh file from earlier in April, but pulling down the 
most recent: e3xx_e320_sdk_default-v3.13.0.2-20190415.zip, I still don't see 
pretty much any site-packages in the sysroot.

Those things seem to be there automatically when using the .sh info with the 
e310 files.

I will try including python in the cmake path (which I've never needed to do 
before), but is that going to be enough?  I feel like the back-and-forth you 
and I had last year with the rocko build for the E310 were for pretty similar 
issues.  But honestly, I need to look back at the emails for the exact issues 
at the time.


From: Philip Balister 
Sent: Wednesday, May 1, 2019 10:31 AM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] E320 numpy missing?

On 05/01/2019 09:55 AM, Jason Matusiak via USRP-users wrote:
> I also get a "ImportError: No module named sip" when I try to run: 
> uhd_siggen_gui
>
> So I think a few things might be missing from the cross-compile setup.

I took a few minutes and looked at the current state of the BSP. It
looks like you might have this image:

https://github.com/EttusResearch/meta-ettus/blob/master/meta-ettus-core/recipes-core/images/developer-image.bb

I forget where numpy is the gnuradio dependency tree, but I'm going to
guess if you enable python support in gnuradio (yes it might be possible
to use gnuradio without python) you will need numpy to build/run.

Philip

>
> 
> From: Jason Matusiak
> Sent: Wednesday, May 1, 2019 8:46 AM
> To: Ettus Mail List
> Subject: E320 numpy missing?
>
> Finally got my E320 in and I cross-compiled a new setup.  I tried to fire up 
> my flowgraph (which works fine on an E310) and it is complaining about numpy 
> missing.
>
> If I do a search from / on the E320, the only numpy that is showing up is:
> /usr/include/boost/python/numpy
>
> If I do a search from a good E310 in / I see:
> ./usr/lib/python2.7/site-packages/numpy
> ./usr/lib/python2.7/site-packages/numpy/core/include/numpy
> ./usr/lib/python2.7/site-packages/Cython/Includes/numpy
> ./usr/include/boost/python/numpy
>
>
> Back on the host machine, my E320 cross-compile prefix shows numpy:
> ./sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/include/boost/python/numpy
>
> My good E310 prefix shows:
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/build/src.linux-x86_64-2.7/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/build/src.linux-x86_64-2.7/numpy/core/include/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/numpy/core/include/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/Cython/Includes/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/numpy/core/include/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/boost/python/numpy
>
> So, was numpy forgotten?  Left out for a reason?  I am going to attempt to 
> build it by hand, but I have a fear that I am going to go down dependency 
> hell with this and other missing packages that GR might want.
>
>
>
>
> ___
> 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] E320 numpy missing?

[Jason Matusiak via USRP-users]

I also get a "ImportError: No module named sip" when I try to run: 
uhd_siggen_gui

So I think a few things might be missing from the cross-compile setup.


From: Jason Matusiak
Sent: Wednesday, May 1, 2019 8:46 AM
To: Ettus Mail List
Subject: E320 numpy missing?

Finally got my E320 in and I cross-compiled a new setup.  I tried to fire up my 
flowgraph (which works fine on an E310) and it is complaining about numpy 
missing.

If I do a search from / on the E320, the only numpy that is showing up is:
/usr/include/boost/python/numpy

If I do a search from a good E310 in / I see:
./usr/lib/python2.7/site-packages/numpy
./usr/lib/python2.7/site-packages/numpy/core/include/numpy
./usr/lib/python2.7/site-packages/Cython/Includes/numpy
./usr/include/boost/python/numpy


Back on the host machine, my E320 cross-compile prefix shows numpy:
./sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/include/boost/python/numpy

My good E310 prefix shows:
./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/build/src.linux-x86_64-2.7/numpy
./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/build/src.linux-x86_64-2.7/numpy/core/include/numpy
./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/numpy
./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/numpy/core/include/numpy
./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/Cython/Includes/numpy
./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/numpy
./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/numpy/core/include/numpy
./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/boost/python/numpy

So, was numpy forgotten?  Left out for a reason?  I am going to attempt to 
build it by hand, but I have a fear that I am going to go down dependency hell 
with this and other missing packages that GR might want.

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

[USRP-users] E320 numpy missing?

[Jason Matusiak via USRP-users]

Finally got my E320 in and I cross-compiled a new setup.  I tried to fire up my 
flowgraph (which works fine on an E310) and it is complaining about numpy 
missing.

If I do a search from / on the E320, the only numpy that is showing up is:
/usr/include/boost/python/numpy

If I do a search from a good E310 in / I see:
./usr/lib/python2.7/site-packages/numpy
./usr/lib/python2.7/site-packages/numpy/core/include/numpy
./usr/lib/python2.7/site-packages/Cython/Includes/numpy
./usr/include/boost/python/numpy


Back on the host machine, my E320 cross-compile prefix shows numpy:
./sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/include/boost/python/numpy

My good E310 prefix shows:
./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/build/src.linux-x86_64-2.7/numpy
./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/build/src.linux-x86_64-2.7/numpy/core/include/numpy
./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/numpy
./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/numpy/core/include/numpy
./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/Cython/Includes/numpy
./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/numpy
./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/numpy/core/include/numpy
./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/boost/python/numpy

So, was numpy forgotten?  Left out for a reason?  I am going to attempt to 
build it by hand, but I have a fear that I am going to go down dependency hell 
with this and other missing packages that GR might want.

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

[USRP-users] E310 not locking on GPS

[Jason Matusiak via USRP-users]

I've seen this a few times, but I cannot seem to lock it down to any particular 
reason.  While sitting at my desk with a GPS simulator (so I have a known good 
signal), I will be doing testing and everything is fine (it seems to be walking 
around the place where the unit was built).  I will turn off the GPS unit for 
the night and then the next day when I turn it on, I never get a fix.  I've 
seen this numerous times and the only way I can fix it is to reboot the E310.  
It is like the GPS is getting into a mucked up stated.  Data comes streaming 
through, but it is just the last good signal.

I can't figure out a way to reset the GPS without rebooting it, does anyone 
know of a way?  I tried killing and restarting the daemon, but that doesn't 
seem to do anything.  I really think it is the GPS module, but rebooting it 
everytime I want to run things "just in case."

One other weird thing, when I run gpsmon in this screwed up state, it mostly 
looks OK, but it has weird characters displayed throughout the ASCII heading 
(for lack of a better term).

This is a good setup on a different unit (so I don't expect to see a fix):
tcp://localhost:2947  u-blox>
┌──┐┌─┐ 
or":11}
│Ch PRN  Az  El S/N Flag U ││ECEF Pos: +6378137.00m  +0.00m  +0.00m   │ 
er":"u-blox","subtype":"Unknown","activated":"2018-10-10T06:21:07.701Z","flags":1,"native":1,"bps":9600,"parity":"N","stopbits":1,"cycle":1.00,"mincycle":0.25}]}
│ 0   1   0 165   0 0110   ││ECEF Vel: +0.00m/s +0.00m/s +0.00m/s │ 
false,"timing":false,"split24":false,"pps":true}
│ 1   2   0 165   0 0110   ││ │
│ 2   4   0 165   0 0110   ││LTP Pos:   0.0°   0.0°   -18.00m │
│ 3   6   0 165  23 0310   ││LTP Vel:0.00m/s   0.0°   0.00m/s │
│ 4   7   0 165   0 0110   ││ │
│ 5   9   0 165  23 0310   ││Time: 0 00:00:00.00  │
│ 6  14   0 165  22 0310   ││Time GPS: Day:   │
│ 7  19   0 165  22 0310   ││ │
│ 8  20   0 165  21 0310   ││Est Pos Err998.72st Vel Err   0.00m/s│
│ 9  21   0 165   0 0110   ││PRNs:  0 PDOP:100.0 Fix 0x00 Flags 0x40  │
│10  22   0 165   0 0110   │└─── NAV_SOL ─┘
│11  23   0 165   0 0110   │┌─┐
│12  24   0 165   0 0110   ││DOP [H] 100.0[V] 100.0[P] 100.0[T] 100.0[G] 100.0│
│13  28   0 165  23 0310   │└─── NAV_DOP ─┘
│14  30   0 165   0 0110   │┌─┐
│15 136   0 165   0 0110   ││TOFF: > 1 dayPPS:│

There are lines around the different sections (they look like lines, not dashes 
and bars).


and then on the unit that is hosed:
tcp://localhost:2947  u-blox>
lqqklqk 
or":11}
xCh PRN  Az  El S/N Flag U xxECEF Pos: -2414806.17m +5389584.51m +2400650.28m x 
er":"u-blox","subtype":"Unknown","activated":"2019-01-08T14:52:40.454Z","flags":1,"native":1,"bps":9600,"parity":"N","stopbits":1,"cycle":1.00,"mincycle":0.25}]}
x 0   2   0 165  50 0700   xxECEF Vel: +0.00m/s +0.00m/s +0.00m/s x 
false,"timing":false,"split24":false,"pps":true}
x 1   4   0 165  50 0700   xx x
x 2   5   0 165  50 0700   xxLTP Pos:  22.2557151134f 114.134790532f20.19m x
x 3   8   0 165   0 0100   xxLTP Vel:0.00m/s   0.0f   0.00m/s x
x 4   9   0 165  50 0700   xx x
x 5  10   0 165  50 0700   xxTime: 61 06:13:40.00 x
x 6  12   0 165  50 0700   xxTime GPS: 1877+529282.000 Day: 6 x
x 7  13   0 165  50 0600   xx x
x 8  17   0 165  50 0700   xxEst Pos Err2238690.24st Vel Err   0.00m/sx
x 9  20   0 165  50 0700   xxPRNs:  0 PDOP:100.0 Fix 0x00 Flags 0xdc  x
x10  23   0 165  50 0700   xmqqq NAV_SOL qj
x11  24   0 165   0 0110   xlqk
x12  27   0 165  50 0700   xxDOP [H] 100.0[V] 100.0[P] 100.0[T] 100.0[G] 100.0x
x13  28   0 165  50 0700   xmqqq NAV_DOP qj
x14 129 127  51   0 0110   xlqk
x15xxTOFF: > 1 dayPPS:x
mqq NAV_SVINFO jmqj

Not that instead of lines, I see characters.  What is up with that
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E312 wrong sample rate

[Jason Matusiak via USRP-users]

I guess I would need a block to count samples if I am going to a null sink?  
Otherwise I am not sure how to guage how many samples have passed.

Well, this is probably ignorant of me, but I assumed a higher master clock rate 
would allow me some sort of speed benefit somewhere.  I guess I can't say what 
since it has nothing to do with the Linux CPU speed  What is the benefit to 
running at a slower rate?


From: USRP-users  on behalf of Marcus D. 
Leech via USRP-users 
Sent: Monday, April 29, 2019 8:33 PM
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] E312 wrong sample rate

On 04/29/2019 03:28 PM, Jason Matusiak via USRP-users wrote:
I was debugging a problem with a flowgraph when I realized that I wasn't 
getting the amount of samples I expected passing out of the USRP source block.  
If I set a sample rate too low, it tells me it has to set the sample rate to 
0.125MSps.  Currently I have a single stream from my source block, 30MHz clock 
rate, 500kHz sample rate.

If I run for 20 seconds streaming the data to a file (unbuffered set to off) as 
a complex, I would expect to see 20s * 8B * 500KHz = 80MB of data in the file.

Instead, running it empirically (so the numbers will have to be ballpark and 
not exact), I see file size of 116153944.  If I make the assumption that the 
sample rate was really 500kHz, that means it ran for 29.03s.  This is obviously 
off by 50%.  If I assume that 10s of data was really collected, that means I 
had an actual sample rate of 1.451924MSps.

If I run these tests with the minimal 125kHz sample rate, I see things off by 
about double what I would expect.

Moving my sample rate around the 1MSps range seems to work closer to what I 
expect, but of course I can't write files that fast without getting 'O' on the 
screen.  Ultimately I need to use two receivers, so I don't believe that I can 
push the clock rate above 30.72MHz.

I am running UHD-3_14 with RFNoC enabled (though I am not using RFNoC in this 
particular flowgraph).  What am I missing here?

Have it write to /dev/null, and time how long it takes to gather some large 
number of samples, and go from there.
   If your delivered sample rate is 500ksps, I don't see why you need a master 
clock rate as high as 30Msps, but perhaps you have
   your reasons.

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

[USRP-users] E312 wrong sample rate

[Jason Matusiak via USRP-users]

I was debugging a problem with a flowgraph when I realized that I wasn't 
getting the amount of samples I expected passing out of the USRP source block.  
If I set a sample rate too low, it tells me it has to set the sample rate to 
0.125MSps.  Currently I have a single stream from my source block, 30MHz clock 
rate, 500kHz sample rate.

If I run for 20 seconds streaming the data to a file (unbuffered set to off) as 
a complex, I would expect to see 20s * 8B * 500KHz = 80MB of data in the file.

Instead, running it empirically (so the numbers will have to be ballpark and 
not exact), I see file size of 116153944.  If I make the assumption that the 
sample rate was really 500kHz, that means it ran for 29.03s.  This is obviously 
off by 50%.  If I assume that 10s of data was really collected, that means I 
had an actual sample rate of 1.451924MSps.

If I run these tests with the minimal 125kHz sample rate, I see things off by 
about double what I would expect.

Moving my sample rate around the 1MSps range seems to work closer to what I 
expect, but of course I can't write files that fast without getting 'O' on the 
screen.  Ultimately I need to use two receivers, so I don't believe that I can 
push the clock rate above 30.72MHz.

I am running UHD-3_14 with RFNoC enabled (though I am not using RFNoC in this 
particular flowgraph).  What am I missing here?
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] ValueError: recv_buff_size must be larger than the recv_frame_size.

[Jason Matusiak via USRP-users]

I know this is an older thread, but I am running up against the same issue.  Do 
you know if you were able to get past it?


Thanks



On Wed, Aug 22, 2018 at 11:12 AM, Andrew Danowitz <
and...@whitefoxdefense.com> wrote:

> Hi,
>
> I rebuilt everything using the latest recipes for rfnoc and e3xx-rfnoc.
> Now when I try to run any rfnoc flow-chart on the e310, I get the following
> error:
>
> ValueError: recv_buff_size must be larger than the recv_frame_size.
>
> Even if I just take an rfnoc: radio block and connect it directly to a qt
> time sink, I get:
>
> Initializing block control (NOC ID: 0x5B888C918ACDF7F3)
> thread[thread-per-block[0]: ]: ValueError:
> recv_buff_size must be larger than the recv_frame_size.
>
> Has anyone run into this before? Where are these buffer and frame sizes
> set?
>
> Thanks,
> Andrew
>

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

Re: [USRP-users] RFNoC has no attribute E312

[Jason Matusiak via USRP-users]

Whoops.  Realized it was a swig issue.  Once I fixed the problem it was fine 
again.  Hopefully this helps someone else in the future.


From: Jason Matusiak
Sent: Tuesday, April 23, 2019 10:29 AM
To: Ettus Mail List
Subject: RFNoC has no attribute E312

OK, I am missing something simple here that I am just overlooking.  I have a 
particular bitfile that when I do a probe on my E312 using it and its 
associated UHD/GR/etc, it runs OK and shows me my RFNoC blocks (it actuall 
shows an EnvironmentError: IOError on the radio, but usually those things seem 
to be ignored).

But if I use the bitfile in my flowgraph it starts to set stuff up and then 
crashes with this error:
AttributeError: 'module' object has no attribute 'vustomBlock'

Why did it see it with the probe, but not with the flowgraph?
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] RFNoC has no attribute E312

[Jason Matusiak via USRP-users]

OK, I am missing something simple here that I am just overlooking.  I have a 
particular bitfile that when I do a probe on my E312 using it and its 
associated UHD/GR/etc, it runs OK and shows me my RFNoC blocks (it actuall 
shows an EnvironmentError: IOError on the radio, but usually those things seem 
to be ignored).

But if I use the bitfile in my flowgraph it starts to set stuff up and then 
crashes with this error:
AttributeError: 'module' object has no attribute 'vustomBlock'

Why did it see it with the probe, but not with the flowgraph?
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC RX -> TX loopback

[Jason Matusiak via USRP-users]

I haven't tried it yet, but have you looked at this blog post (I //think// it 
is still relevant today)?
https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/



From: USRP-users  on behalf of Ryan Marlow 
via USRP-users 
Sent: Thursday, April 11, 2019 10:51 AM
To: USRP-users@lists.ettus.com
Subject: [USRP-users] RFNoC RX -> TX loopback

Hello all,
Quick question on a RX -> TX loopback application. Say I have a rfnoc graph 
that has been connected as Radio RX -> processing block -> Radio TX so there is 
no data samples streaming to/from the host. Can I just issue the "start 
streaming" command to the Radio block itself or do I need to use a
uhd::rx_streamer to issue the command? Is there any other gotcha that I am 
overlooking?
Thanks,
Ryan
--
Ryan L. Marlow
R L Marlow Consulting LLC
rlmarlow.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] OOT RFNoC not building on latest

[Jason Matusiak via USRP-users]

OK, I have a work-around to this for now.  I needed to comment out the two 
lines:
 ${CPPUNIT_INCLUDE_DIRS}
and
 ${CPPUNIT_LIBRARY_DIRS}

on lines 190 and 197 of gr-ettus/CMakeLists.txt.

I guess maybe a check needs to be done so that when it is determined that 
CPPUINIT is getting ignored (like it is in the this case), it doesn't try to 
include it anymore?


From: USRP-users  on behalf of Jason 
Matusiak via USRP-users 
Sent: Wednesday, April 10, 2019 1:23 PM
To: usrp-users@lists.ettus.com
Subject: [USRP-users] OOT RFNoC not building on latest

Trying to build a FPGA image with an OOT module is not going well.  I first 
built with standard blocks and that worked, so I know my setup is OK.

I then tried to build with my OOT module (and this used to work on an old 
prefix), but now is erroring out because it can't find my OOT block.  The 
command I am running is:
python uhd_image_builder.py -y 
/opt/gnuradio/e320/src/rfnoc-nocblocks/fpga_build/my_yaml.yml -I 
/opt/gnuradio/e320/src/rfnoc-nocblocks -d e320 -t E320_RFNOC_XG

The error I see is:
ERROR: [Synth 8-439] module 'noc_block_keepMinN' not found 
[/opt/gnuradio/e320/src/uhd/fpga-src/usrp3/top/e320/rfnoc_ce_auto_inst_e320.v:54]
ERROR: [Synth 8-285] failed synthesizing module 'e320_core' 
[/opt/gnuradio/e320/src/uhd/fpga-src/usrp3/top/e320/e320_core.v:17]
ERROR: [Synth 8-285] failed synthesizing module 'e320' 
[/opt/gnuradio/e320/src/uhd/fpga-src/usrp3/top/e320/e320.v:13]
[00:10:22] Current task: Synthesis +++ Current Phase: Starting
ERROR: [Common 17-69] Command failed: Synthesis failed - please see the console 
or run log file for details
[00:10:23] Current task: Synthesis +++ Current Phase: Finished
[00:10:23] Process terminated. Status: Failure

Did something change with the image builder (I am running a newer UHD than I 
used to since this is for an E320)?



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

[USRP-users] OOT RFNoC not building on latest

[Jason Matusiak via USRP-users]

Trying to build a FPGA image with an OOT module is not going well.  I first 
built with standard blocks and that worked, so I know my setup is OK.

I then tried to build with my OOT module (and this used to work on an old 
prefix), but now is erroring out because it can't find my OOT block.  The 
command I am running is:
python uhd_image_builder.py -y 
/opt/gnuradio/e320/src/rfnoc-nocblocks/fpga_build/my_yaml.yml -I 
/opt/gnuradio/e320/src/rfnoc-nocblocks -d e320 -t E320_RFNOC_XG

The error I see is:
ERROR: [Synth 8-439] module 'noc_block_keepMinN' not found 
[/opt/gnuradio/e320/src/uhd/fpga-src/usrp3/top/e320/rfnoc_ce_auto_inst_e320.v:54]
ERROR: [Synth 8-285] failed synthesizing module 'e320_core' 
[/opt/gnuradio/e320/src/uhd/fpga-src/usrp3/top/e320/e320_core.v:17]
ERROR: [Synth 8-285] failed synthesizing module 'e320' 
[/opt/gnuradio/e320/src/uhd/fpga-src/usrp3/top/e320/e320.v:13]
[00:10:22] Current task: Synthesis +++ Current Phase: Starting
ERROR: [Common 17-69] Command failed: Synthesis failed - please see the console 
or run log file for details
[00:10:23] Current task: Synthesis +++ Current Phase: Finished
[00:10:23] Process terminated. Status: Failure

Did something change with the image builder (I am running a newer UHD than I 
used to since this is for an E320)?



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

Re: [USRP-users] rfnoc build for an e320

[Jason Matusiak via USRP-users]

I am looping back to this.  I thought I had things working, but I realized late 
yesterday that my working prefix seemed to be based on a different 
cross-compile environment (by working, I mean building.  I still don't have my 
e320 yet).

After I had it "working,"  I followed my steps again to make sure I really did. 
 That was when I realized I had done something wrong and it still doesn't work. 
 Here is my steps (my error will follow them):
PREFIX=/opt/gnuradio/e320

chmod +x oecore-x86_64-cortexa9hf-neon-toolchain-nodistro.0.sh
sh ./oecore-x86_64-cortexa9hf-neon-toolchain-nodistro.0.sh -y -d $PREFIX
cd $PREFIX
source ./environment-setup-cortexa9hf-neon-oe-linux-gnueabi
mkdir src && cd src

git clone --recursive -b UHD-3.14 https://github.com/EttusResearch/uhd.git
cd uhd
git submodule foreach --recursive git checkout UHD-3.14
cd host && mkdir arm-build && cd arm-build
cmake -DCMAKE_TOOLCHAIN_FILE=../host/cmake/Toolchains/oe-sdk_cross.cmake 
-DCMAKE_INSTALL_PREFIX=/usr -DENABLE_E300=ON -DENABLE_E320=ON -DENABLE_B100=OFF 
-DENABLE_X300=OFF -DENABLE_B200=OFF -DENABLE_USRP1=OFF -DENABLE_USRP2=OFF 
-DENABLE_N300=OFF -DENABLE_OCTOCLOCK=OFF -DENABLE_N230=OFF -DENABLE_N320=OFF 
-DENABLE_DOXYGEN=OFF -DENABLE_MANUAL=OFF -DENABLE_MAN_PAGES=OFF 
-DENABLE_RFNOC=ON ../
make -j32
make install DESTDIR=$PREFIX
make install DESTDIR=$PREFIX/sysroots/cortexa9hf-neon-oe-linux-gnueabi

cd $PREFIX/src
git clone -b v3.7.13.4 --recursive https://github.com/gnuradio/gnuradio.git
cd gnuradio && mkdir arm-build && cd arm-build
cmake -Wno-dev -DCMAKE_TOOLCHAIN_FILE=../cmake/Toolchains/oe-sdk_cross.cmake 
-DENABLE_GR_WXGUI=OFF -DENABLE_GR_VOCODER=OFF -DENABLE_GR_DTV=OFF 
-DENABLE_GR_ATSC=OFF -DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ../
make -j32
make install DESTDIR=$PREFIX
make install DESTDIR=$PREFIX/sysroots/cortexa9hf-neon-oe-linux-gnueabi

cd $PREFIX/src
git clone -b master https://github.com/EttusResearch/gr-ettus.git
cd gr-ettus/ && mkdir arm-build && cd arm-build
cmake -Wno-dev 
-DCMAKE_TOOLCHAIN_FILE=$PREFIX/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake 
-DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr  -DENABLE_QT=OFF ..


And the error:

CMake Error: The following variables are used in this project, but they are set 
to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake 
files:
CPPUNIT_INCLUDE_DIRS (ADVANCED)



I see that there was a commit on 2/25 that made it so that cppunit was 
optional, but I am using the most recent commit (3/7) and that doesn't seem to 
work (I checked and the changes are indeed in the files from that 2/25 
commit).

From: Nate Temple 
Sent: Monday, April 8, 2019 4:03 PM
To: Jason Matusiak
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] rfnoc build for an e320

Hi Jason,

You can disable the QT widgets (not needed on the E320 itself) by adding the 
cmake flag -DENABLE_QT=OFF



Regards,
Nate Temple


On Mon, Apr 8, 2019 at 1:00 PM Nate Temple 
mailto:nate.tem...@ettus.com>> wrote:
Hi Jason,

It looks like you are missing the package: python-setuptools

Note, you should not use rfnoc-devel, but instead use a newer version of UHD 
like v3.14.0.0, and then you can enable RFNoC by adding the cmake flag 
-DENABLE_RFNOC=ON

Regards,
Nate Temple


On Mon, Apr 8, 2019 at 12:34 PM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
I should be getting an e320 in this week, so I started to get my environment 
setup.  I started off like I do for the e310 and ran the cross-compile shell 
script.  I then sourced the environment.  I cloned uhd and checked out 
rfnoc-devel like I usually do.  Within uhd, I created a folder called 
build_mpm.  Within that, I ran: cmake 
-DCMAKE_TOOLCHAIN_FILE=../host/cmake/Toolchains/oe-sdk_cross.cmake 
-DCMAKE_INSTALL_PREFIX=/usr ../mpm/

That seemed to work OK.  I then ran mak -j12 and it looks like it is done and 
worked, but it actually throws an error at the end:
[ 98%] Linking CXX shared library libpyusrp_periphs.so
[ 98%] Built target pyusrp_periphs
[100%] Generating build/timestamp
Traceback (most recent call last):
  File "/opt/gnuradio/e320/src/uhd/build_mpm/python/setup.py", line 11, in 

from setuptools import setup
ImportError: No module named 'setuptools'
make[2]: *** [python/build/timestamp] Error 1
make[1]: *** [python/CMakeFiles/usrp_mpm.dir/all] Error 2
make: *** [all] Error 2

Is something missing that needs to be built before building UHD?

___
USRP-users mailing list
USRP-users@lists.ettus.com<mailto: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] rfnoc build for an e320

[Jason Matusiak via USRP-users]

So I think I goofed.  Not sure why I was pointing it to the mpm directory for 
the CMakeLists.  When I do the normal ../ it builds fine.

Now I end up with the issue I used to have with the e310 many moons ago.  The 
sysroots doesn't have qt in it.  So when I run a cmake of gr-ettus, I get this 
error:
CMake Warning at 
/opt/gnuradio/e320/sysroots/x86_64-oesdk-linux/usr/share/cmake-3.10/Modules/FindQt4.cmake:620
 (message):
  /usr/bin/qmake-qt4 reported QT_INSTALL_LIBS as "/usr/lib64" but QtCore
  could not be found there.  Qt is NOT installed correctly for the target
  build environment.
Call Stack (most recent call first):
  CMakeLists.txt:149 (find_package)


CMake Error at CMakeLists.txt:151 (message):
  Qt not found.


-- Configuring incomplete, errors occurred!


In the past I had to use a special cross-compile setup that as far as  I know 
still isn't hosted on the Ettus site.  Does something like that exist for this?


From: Jason Matusiak
Sent: Monday, April 8, 2019 3:33 PM
To: usrp-users@lists.ettus.com
Subject: rfnoc build for an e320

I should be getting an e320 in this week, so I started to get my environment 
setup.  I started off like I do for the e310 and ran the cross-compile shell 
script.  I then sourced the environment.  I cloned uhd and checked out 
rfnoc-devel like I usually do.  Within uhd, I created a folder called 
build_mpm.  Within that, I ran: cmake 
-DCMAKE_TOOLCHAIN_FILE=../host/cmake/Toolchains/oe-sdk_cross.cmake 
-DCMAKE_INSTALL_PREFIX=/usr ../mpm/

That seemed to work OK.  I then ran mak -j12 and it looks like it is done and 
worked, but it actually throws an error at the end:
[ 98%] Linking CXX shared library libpyusrp_periphs.so
[ 98%] Built target pyusrp_periphs
[100%] Generating build/timestamp
Traceback (most recent call last):
  File "/opt/gnuradio/e320/src/uhd/build_mpm/python/setup.py", line 11, in 

from setuptools import setup
ImportError: No module named 'setuptools'
make[2]: *** [python/build/timestamp] Error 1
make[1]: *** [python/CMakeFiles/usrp_mpm.dir/all] Error 2
make: *** [all] Error 2

Is something missing that needs to be built before building UHD?

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

[USRP-users] rfnoc build for an e320

[Jason Matusiak via USRP-users]

I should be getting an e320 in this week, so I started to get my environment 
setup.  I started off like I do for the e310 and ran the cross-compile shell 
script.  I then sourced the environment.  I cloned uhd and checked out 
rfnoc-devel like I usually do.  Within uhd, I created a folder called 
build_mpm.  Within that, I ran: cmake 
-DCMAKE_TOOLCHAIN_FILE=../host/cmake/Toolchains/oe-sdk_cross.cmake 
-DCMAKE_INSTALL_PREFIX=/usr ../mpm/

That seemed to work OK.  I then ran mak -j12 and it looks like it is done and 
worked, but it actually throws an error at the end:
[ 98%] Linking CXX shared library libpyusrp_periphs.so
[ 98%] Built target pyusrp_periphs
[100%] Generating build/timestamp
Traceback (most recent call last):
  File "/opt/gnuradio/e320/src/uhd/build_mpm/python/setup.py", line 11, in 

from setuptools import setup
ImportError: No module named 'setuptools'
make[2]: *** [python/build/timestamp] Error 1
make[1]: *** [python/CMakeFiles/usrp_mpm.dir/all] Error 2
make: *** [all] Error 2

Is something missing that needs to be built before building UHD?

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

Re: [USRP-users] E310 environment

[Jason Matusiak via USRP-users]

FWIW, these are the steps I use (some of them aren't really needed, but it 
works, so I do it every time):

mkdir ~/E310   ###This is the directory that will be a mount point for your 
remote E310
sshfs -o allow_root root@192.168.1.10:/ ~/E310   ###Your E310's / directory now 
starts at ~/E310 on your host
mkdir ~/E310/home/root/localinstall
PREFIX=/opt/gnuradio/test
PREFIX_E310=~/E310/home/root/localinstall
cd ~/Downloads
get your oecore .sh file mine is renamed, so yours will be different
chmod +x oecore-x86_64-armv7ahf-neon-toolchain-nodistro.0_rocko_with_qt.sh
sh ./oecore-x86_64-armv7ahf-neon-toolchain-nodistro.0_rocko_with_qt.sh -y -d 
$PREFIX

cd $PREFIX
source ./environment-setup-armv7ahf-neon-oe-linux-gnueabi
echo $CC###This is just to verify that we have the cross-compile tools 
setup right. You see armv7 in some of the values
mkdir src && cd src

(in the next step I am building for RFNoC, most likely you can leave that out 
if you don't care for it)
git clone --recursive -b rfnoc-devel https://github.com/EttusResearch/uhd.git
cd uhd
git submodule foreach --recursive git checkout rfnoc-devel
cd host/ && mkdir arm-build && cd arm-build
cmake -DCMAKE_TOOLCHAIN_FILE=../host/cmake/Toolchains/oe-sdk_cross.cmake 
-DCMAKE_INSTALL_PREFIX=/usr -DENABLE_E300=ON -DENABLE_B100=OFF 
-DENABLE_X300=OFF -DENABLE_B200=OFF -DENABLE_USRP1=OFF -DENABLE_USRP2=OFF 
-DENABLE_N300=OFF -DENABLE_OCTOCLOCK=OFF -DENABLE_N230=OFF -DENABLE_DOXYGEN=OFF 
-DENABLE_MANUAL=OFF -DENABLE_MAN_PAGES=OFF ..
make -j32
make install DESTDIR=$PREFIX
make install DESTDIR=$PREFIX/sysroots/armv7ahf-neon-oe-linux-gnueabi
make install DESTDIR=$PREFIX_E310

(This next step is something I do so I can source the new environment on the 
E310 when I am ready to use it)
printf "LOCALPREFIX=~/localinstall/usr
export PATH=\$LOCALPREFIX/bin:\$PATH
export LD_LOAD_LIBRARY=\$LOCALPREFIX/lib:\$LD_LOAD_LIBRARY
export LD_LIBRARY_PATH=\$LOCALPREFIX/lib:\$LD_LIBRARY_PATH
export PYTHONPATH=\$LOCALPREFIX/lib/python2.7/site-packages:\$PYTHONPATH
export PKG_CONFIG_PATH=\$LOCALPREFIX/lib/pkgconfig:\$PKG_CONFIG_PATH
export GRC_BLOCKS_PATH=\$LOCALPREFIX/share/gnuradio/grc/blocks:\$GRC_BLOCKS_PATH
export UHD_RFNOC_DIR=\$LOCALPREFIX/share/uhd/rfnoc/
export UHD_IMAGES_DIR=\$LOCALPREFIX/share/uhd/images" > 
$PREFIX_E310/../setup_env.sh
chmod +x $PREFIX_E310/../setup_env.sh

(use the fefault version if you want, this is just what I am currently using)
cd $PREFIX/src
git clone -b v3.7.12.0 --recursive https://github.com/gnuradio/gnuradio.git
cd gnuradio && mkdir arm-build && cd arm-build
cmake -Wno-dev -DCMAKE_TOOLCHAIN_FILE=../cmake/Toolchains/oe-sdk_cross.cmake 
-DENABLE_GR_WXGUI=OFF -DENABLE_GR_VOCODER=OFF -DENABLE_GR_DTV=OFF 
-DENABLE_GR_ATSC=OFF -DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ../
make -j32
make install DESTDIR=$PREFIX
make install DESTDIR=$PREFIX/sysroots/armv7ahf-neon-oe-linux-gnueabi
make install DESTDIR=$PREFIX_E310

(the next one is for if you want RFNoC)
cd $PREFIX/src
git clone -b master https://github.com/EttusResearch/gr-ettus.git
cd gr-ettus/ && mkdir arm-build && cd arm-build
cmake -Wno-dev 
-DCMAKE_TOOLCHAIN_FILE=$PREFIX/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake 
-DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ..
make -j32
make install DESTDIR=$PREFIX
make install DESTDIR=$PREFIX/sysroots/armv7ahf-neon-oe-linux-gnueabi
make install DESTDIR=$PREFIX_E310


Now, whenever you have a project that you want to cross-compile for the E310:
d $PREFIX/src
git clone   
https://github.com/myawesomeproject/myawesomeproject.git
cd myawesomeproject/ && mkdir arm-build && cd arm-build
cmake -Wno-dev 
-DCMAKE_TOOLCHAIN_FILE=$PREFIX/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake 
-DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ..
make -j32
make install DESTDIR=$PREFIX
make install DESTDIR=$PREFIX/sysroots/armv7ahf-neon-oe-linux-gnueabi
make install DESTDIR=$PREFIX_E310


From: USRP-users  on behalf of Martin K via 
USRP-users 
Sent: Wednesday, April 3, 2019 11:23 AM
To: usrp-users
Subject: [USRP-users] E310 environment

I am trying to follow the instructions at
https://files.ettus.com/manual/page_usrp_e3x0.html

I have a fresh installation of Ubuntu (either 16.04 or 18.04)

When I get to the point of setting up the cross compilation
environment, I get a fatal error. This is some sort of Python issue,
for which I am not a Python developer, I have no idea what I should be
doing to fix this.

My goal is to compile my custom C++ code against UHD for the E310. If
there is a better solution please let me know. Thank you.

$ . e3xx/environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi
$ CC
Fatal Python error: Py_Initialize: Unable to get the locale encoding
ModuleNotFoundError: No module named 'encodings'

Current thread 0x7f05861ce740 (most recent call first):
Aborted (core dumped)

--
Martin K.

___
USRP-users mailing 

Re: [USRP-users] Maximal number of RFNoC-blocks

[Jason Matusiak via USRP-users]

I don't know why this would be, but it almost feels like a hex issue somewhere. 
 Where are you setting the block size to 10?  It feels like something is 
interpreting that as 0x10, and I think 16 is a magic number that is too large.


From: USRP-users  on behalf of Armin 
Schmidt via USRP-users 
Sent: Thursday, April 4, 2019 4:13 AM
To: USRP-users@lists.ettus.com
Subject: [USRP-users] Maximal number of RFNoC-blocks

Hallo everyone and Ettus development team,

We use uhd 3.14 rc1 and we have the strange behaviour, that after the magic 
number of 10 RFNoC-blocks on the FPGA, we get the following error:


[ERROR] [UHD] Exception caught in safe-call.
  in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with uhd::endianness_t 
_endianness = (uhd::endianness_t)0u]
  at /home/gab2/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:60
this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block ctrl 
(CE_13_Port_00) no response packet - AssertionError: bool(buff)
  in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) [with 
uhd::endianness_t _endianness = (uhd::endianness_t)0u; uint64_t = long unsigned 
int]
  at /home/gab2/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:155

terminate called after throwing an instance of 'uhd::io_error'
  what():  EnvironmentError: IOError: Block ctrl (CE_00_Port_30) packet parse 
error - EnvironmentError: IOError: Expected SID: 02:30>00:00  Received SID: 
00:12>02:00
Aborted (core dumped)

It is not a problem of the FPGA-Capacity and also not a timing issue. So it 
seems to be somehow a hardcoded limit from ettus. Does someone know how to 
stretch this limit? So 10 RFNoC-blocks works just fine, but with 12 we get this 
error! It is also not dependant of the type of blocks, we put on the FPGA.

Many thanks for your help!

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

Re: [USRP-users] X310 unable to connect after recovery procedure

[Jason Matusiak via USRP-users]

And you have a 1Gb SFP plugged into the first port in the X310 going to a 1GB 
connection on the other end?


From: USRP-users  on behalf of Nicolas 
GALLAND via USRP-users 
Sent: Thursday, March 28, 2019 7:26 AM
To: Marcus D. Leech; Joe Martin
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] X310 unable to connect after recovery procedure

Hi,

I used the file named usrp_x310_fpga_HG.bit

Nicolas


Le 27/03/2019 à 15:10, Marcus D. Leech a écrit :
> On 03/27/2019 05:39 AM, Nicolas GALLAND wrote:
>> Hi,
>>
>> after the recovery, i can't ping the device to the default address.
>> It gives me a "host unreachable" error when I try.
>>
>> Nicolas
> Which image did you select when you used Vivado to recover the device
> via JTAG?
>
>
>>
>> Le 26/03/2019 à 17:28, Marcus D Leech a écrit :
>>> So it’s not clear where we are at here.
>>>
>>> After recovery can you ping the device at the default address?
>>>
>>>
>>>
>>> Sent from my iPhone
>>>
 On Mar 25, 2019, at 12:12 PM, Joe Martin via USRP-users
  wrote:

 Thanks, Nicolas.  I am interested to hear how you eventually clear
 the problem as I also have an X310 and so far all works fine but
 someday I may face the same issue as you are experiencing so please
 when you find a solution please post it.  I am not experienced
 enough yet with mine to be able to suggest a solution for you
 unfortunately.  Maybe someone else can.

 I (like you) am eager to hear any suggestion(s) to resolve your issue.

 Regards,

 Joe

> On Mar 25, 2019, at 9:28 AM, Nicolas GALLAND
>  wrote:
>
> Hi,
>
> it is indeed a typo here. I did ping 192.168.10.2 first, and then
> I tried on 192.168.10.3 to see if the error message was the same.
> In any case (even using ping broadcast on all the sub network my
> computer is connected to) i have this message. It looks like there
> is a connection between the computer and the device, since my
> computer says there is no more network when I switch off the USRP.
>
> Kind regards
>
> Nicolas
>> Le 22/03/2019 à 18:52, Joe Martin a écrit :
>> Nicolas,
>>
>> It appears you were pinging 192.168.10.3, not 192.168.10.2.
>> Maybe this particular example was simply a typo and you used the
>> correct IP address to ping during your other tests?
>>
>> Regards,
>>
>> Joe
>>
>>> On Mar 22, 2019, at 11:05 AM, Nicolas GALLAND via USRP-users
>>>  wrote:
>>>
>>> Hello everyone,
>>>
>>> I had some trouble with my X310 and I needed to upload my UHD
>>> installation and consequently to update the FPGA image on the
>>> board. After doing it through eternet port, I lost connection so
>>> I decide to follow the recovery procedure to upload the FPGA
>>> image using the JTAG port (following
>>> https://kb.ettus.com/X300/X310_Device_Recovery).
>>>
>>> The upload is fine, and the computer recognises the network with
>>> IP address 192.168.10.1, but when I try to ping 192.168.10.2 (as
>>> explained in the procedure) I have
>>>
>>> PING 192.168.10.3 (192.168.10.3) 56(84) bytes of data.
>>>  From 192.168.10.1 icmp_seq=1 Destination Host Unreachable
>>>  From 192.168.10.1 icmp_seq=2 Destination Host Unreachable
>>>  From 192.168.10.1 icmp_seq=3 Destination Host Unreachable
>>>  From 192.168.10.1 icmp_seq=4 Destination Host Unreachable
>>>  From 192.168.10.1 icmp_seq=5 Destination Host Unreachable
>>>
>>> until I stop it. I have two x310 in the same situation, and I
>>> tried on two different computers with different ethernet cables.
>>>
>>> Could the hardware be broken ? (If so, isn't it strange that the
>>> computer still sees the network ?)
>>>
>>> Thanks a lot, and nice week end !
>>>
>>> Kind regards,
>>>
>>> Nicolas
>>>

 ___
 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] E310 IMU

[Jason Matusiak via USRP-users]

As usual, I should have emailed days ago since I found the answer just 
afterwards.

Using the code from here: 
https://github.com/kriswiner/MPU9150/blob/master/MPU9150BasicAHRS.ino

I was able to get good values.  q[0] is w in his equation.


From: Jason Matusiak
Sent: Monday, March 18, 2019 12:40 PM
To: Ettus Mail List
Subject: E310 IMU

I've started playing with the E310's IMU and I keep seeming to go around in 
circles.  All I really want is a heading.  I have my own app that is heavily 
borrowed from the RTIMULibDemo included on the device (and from github), but I 
can't seem to get the heading still right when dealing with the quaternions 
(and I've googled a 100 different things and never seem to get the right 
answers when I try their equations).

I am sure I am making some small thing overly complicated, but I have been 
stuck for a couple of days now.  The frustrating thing is that if I plot in 
wolframalpha (say "draw .646-.258i-.675j-.233k as a rotation operator"), the 
plot perfectly mimics what I was doing with the E310 when I captured that data. 
 So trying to figure out how to determine that I have a heading 45 degrees off 
of North in that dataset is beyond me.

Anyone played with the E310 IMU stuff further?
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] E310 IMU

[Jason Matusiak via USRP-users]

I've started playing with the E310's IMU and I keep seeming to go around in 
circles.  All I really want is a heading.  I have my own app that is heavily 
borrowed from the RTIMULibDemo included on the device (and from github), but I 
can't seem to get the heading still right when dealing with the quaternions 
(and I've googled a 100 different things and never seem to get the right 
answers when I try their equations).

I am sure I am making some small thing overly complicated, but I have been 
stuck for a couple of days now.  The frustrating thing is that if I plot in 
wolframalpha (say "draw .646-.258i-.675j-.233k as a rotation operator"), the 
plot perfectly mimics what I was doing with the E310 when I captured that data. 
 So trying to figure out how to determine that I have a heading 45 degrees off 
of North in that dataset is beyond me.

Anyone played with the E310 IMU stuff further?
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Hardware clocks, X310

[Jason Matusiak via USRP-users]

Cherif.  I will attempt to take a stab at a few of your questions.  Don't take 
my answers as 100% right

1 - All the blocks run at the same rate, but I am pretty sure you can implement 
an MMCM within your block to lower the rate for your needs and then back up to 
the crossbar rate.  Don't quote me, but I feel like I had this conversation 
with someone a few years back on the mailing list.
2 - The ADC/DAC are tied to the master clock rate (in the case of the X310, 
either 186.32MHz, or 200MHz)
3 - I don't believe so unless you do what I mentioned in the first comment.

All that said, I believe a lot of stuff can be tweaked under the hood, but it 
is hard to say what that will break, and it isn't exactly supported.


From: USRP-users  on behalf of Cherif Diouf 
via USRP-users 
Sent: Thursday, February 28, 2019 10:05 AM
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Hardware clocks, X310


Hello guys,



I am a researcher working with the X310 USRP. I have a couple of questions 
regarding the Hardware clocks.

The bus_clock and radio_clk are by default respectively set at 166 MHz and 200 
MHz.

And if I am right the crossbar clock ce_clk is also at 200 MHz. Is there a 
solution to bring it down to ce_clk = 50 MHz, in that case

1)  Does it mean that all the Kintex XC410T blocks will run at 50 MHz ? Is 
this safe?

2)   What about the ADC and DAC and their sampling clock?

3)  Finally can we have different RFnoc blocks running at different clock 
frequencies and still have the  crossbar  running at a given clock frequency?



Best Regards

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

Re: [USRP-users] E310 RFNoC FFT Overrun Issue

[Jason Matusiak via USRP-users]

Ramazan,

The timeout channel 0 error is using a timeout that RFNoC is throwing.  There 
is a timeout built in that can be ignored if you are purposely dropping a bunch 
of samples in the RFNoC domain (which I do in a few flowgraphs).  If you dig 
through the mailing list, someone pointed to where in the code this gets 
printed; they comment it out so they don't have to see it.  It is pretty 
annoying to me when I am trying to drop samples on purpose, but I haven't 
commented it out since I want to see it if I wasn't trying to drop samples.  My 
money is on your keep-1-in-n tripping this up.






From: USRP-users  on behalf of Ramazan 
Çetin via USRP-users 
Sent: Tuesday, February 19, 2019 7:11 AM
To: Jonathon Pendlum; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] E310 RFNoC FFT Overrun Issue


Hi Jonathon,

Thanks you for your suggestions. I have achieved getting 60 MHz spectrum 
samples to file on ARM processor using;

RFNoC: Radio -> RFNoC: FFT -> RFNoC: Vector IIR -> RFNoC: Keep 1 in N -> File 
Sink

It just getting overflows after 4-5 seconds such as "overrun on chan 0". Is 
this because of RFNoC side or processor side ?

Also, Keep 1 in B block works as using packets not samples this is also perfect 
for me. I will not lose FFT bins.

But i can not much understand Vector IIR part. Why is it used and good for FFT 
outputs? Is it for averaging results ?

Thank you for your time. Best regards.

Ramazan

On 11.02.2019 08:09, Jonathon Pendlum wrote:
Hi Ramazan,

I would suggest first testing with a signal generated with GNU Radio. For 
example, use a Fast Noise Source + Low Pass Filter to crudely simulate 
receiving a wide band signal. See what it looks like without running it through 
RFNoC. Then replace the RFNoC radio block with those blocks and look at the 
result.

You should also consider using the ZeroMQ blocks to forward data over Ethernet 
to a host PC to view your data in real time. Look at the gr-ettus example 
flowgraphs rfnoc_fft_network_usrp (runs on E310) and rfnoc_fft_network_host 
(runs on host PC).

One guess I can make is try increasing the FFT RFNoC block gain. By default, it 
is set to a very conservative value, so try changing it to 21. That gain value 
sets the Xilinx's FFT IP core scaling schedule, which you can read about here: 
https://www.xilinx.com/support/documentation/ip_documentation/xfft/v9_0/pg109-xfft.pdf
 (see SCALE_SCH on page 15, the core uses Radix-4). You can also try adjusting 
it with a slider in real time. Note that it may behave a bit odd as it is not a 
linear mapping due to the scaling schedule format.

The overflows are due to either the ARM processors cannot keep up with the 
processing load or the SD card write speed is too slow. Try increasing N in 
Keep One in N.

Jonathon

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

[USRP-users] adding new hooks to gr-ettus

[Jason Matusiak via USRP-users]

A while back, I had asked about the lack of get_mboard_sensor when using an 
RFNoC source block: 
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-October/058279.html

I just revisted that this week and seem to have the hooks working as I would 
hope.  I then went to move onto some other commands that we need, but am not 
having as good of luck.  A top python block we have configures the USRP like  
this:
# configure the usrp
radio.usrp.set_clock_rate(radio.clockrate, uhd.ALL_MBOARDS)
radio.usrp.set_samp_rate(self.samp_rate)
radio.usrp.set_time_source('external', 0)
radio.usrp.set_min_output_buffer(2**24)

I know the last command is a GR one, but the top three are not.  I cannot seem 
to figure out how to do it from rfnoc_* from gr-ettus.  Anyone have any ideas?
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] two X310s in one RFNoC flowgraph

[Jason Matusiak via USRP-users]

 addr0 and addr1 like this: "addr0=192.168.30.2, addr1=192.168.40.2" (I 
tried it both with and without the quotes and it works fine either way),


Now, Device 0 will get associated with addr0, and device 1 will get associates 
with addr1.


I hope that makes sense and helps someone.


From: Rob Kossler mailto:rkoss...@nd.edu>>
Sent: Friday, February 1, 2019 9:23 AM
To: Jason Matusiak
Cc: Ettus Mail List
Subject: Re: [USRP-users] two X310s in one RFNoC flowgraph

Hi Jason,
Given that under the hood, the stock multi_usrp (along with legacy_compat) 
implements an RFNoC graph, it must be possible.  I have run multiple X310s with 
the stock multi_usrp.  I have looked at legacy_compat pretty thoroughly and it 
keeps track of blocks as a function of device number (motherboard).  If I had a 
2nd X310 handy, I would try it with my own non-stock multi_usrp object, but I 
don't - sorry.
Rob

On Fri, Feb 1, 2019 at 8:30 AM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:

Is it possible to have a single flowgraph that has 2 X310s running RFNoC in it? 
 I can't seem to figure out a way to make it work, though I think there must be 
a way.  Both streams would be streaming to the same host machine for processing.


Thanks.

___
USRP-users mailing list
USRP-users@lists.ettus.com<mailto: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] two X310s in one RFNoC flowgraph

[Jason Matusiak via USRP-users]

ulti_usrp.  I have looked at legacy_compat pretty thoroughly and it 
keeps track of blocks as a function of device number (motherboard).  If I had a 
2nd X310 handy, I would try it with my own non-stock multi_usrp object, but I 
don't - sorry.
Rob

On Fri, Feb 1, 2019 at 8:30 AM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:

Is it possible to have a single flowgraph that has 2 X310s running RFNoC in it? 
 I can't seem to figure out a way to make it work, though I think there must be 
a way.  Both streams would be streaming to the same host machine for processing.


Thanks.

___
USRP-users mailing list
USRP-users@lists.ettus.com<mailto: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] using PCIe on X310

[Jason Matusiak via USRP-users]

I am attempting to use PCIe on an X310 for the first time.  I poked around and 
it looked like I needed to download and install 
niusrprio-installer-18.0.0.tar.gz.  It seems to install correctly.  I started 
up the service and then the X310, but I cannot seem to uhd_find_device.

I am running Centos 7.4 and:
3.10.0-957.5.1.el7.x86_64 #1 SMP Fri Feb 1 14:54:57 UTC 2019 x86_64 x86_64 
x86_64 GNU/Linux

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

Re: [USRP-users] two X310s in one RFNoC flowgraph

[Jason Matusiak via USRP-users]

 addr0, and device 1 will get associates 
with addr1.


I hope that makes sense and helps someone.


From: Rob Kossler mailto:rkoss...@nd.edu>>
Sent: Friday, February 1, 2019 9:23 AM
To: Jason Matusiak
Cc: Ettus Mail List
Subject: Re: [USRP-users] two X310s in one RFNoC flowgraph

Hi Jason,
Given that under the hood, the stock multi_usrp (along with legacy_compat) 
implements an RFNoC graph, it must be possible.  I have run multiple X310s with 
the stock multi_usrp.  I have looked at legacy_compat pretty thoroughly and it 
keeps track of blocks as a function of device number (motherboard).  If I had a 
2nd X310 handy, I would try it with my own non-stock multi_usrp object, but I 
don't - sorry.
Rob

On Fri, Feb 1, 2019 at 8:30 AM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:

Is it possible to have a single flowgraph that has 2 X310s running RFNoC in it? 
 I can't seem to figure out a way to make it work, though I think there must be 
a way.  Both streams would be streaming to the same host machine for processing.


Thanks.

___
USRP-users mailing list
USRP-users@lists.ettus.com<mailto: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] two X310s in one RFNoC flowgraph

[Jason Matusiak via USRP-users]

ph

If you use 2 X310 with non-TwinRx daughterboards, it can work with the same 
flowgraph (including the fosphor block)?  I ask because I am  wondering if 
there could be a bug in the fosphor block's handling of device number (either 
gr-ettus or uhd).
Rob

On Fri, Feb 1, 2019 at 1:19 PM Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:
When I run my flowgraph with the addresses setup that worked before twinrx, it 
starts to set everything up and seems to be talking to both ip addresses.  Then 
it craps out here:

[WARNING] [RFNOC] Assuming max packet size for 0/DDC_0
[WARNING] [RFNOC] Assuming max packet size for 0/DDC_1
[WARNING] [RFNOC] Assuming max packet size for 1/DDC_1
[WARNING] [RFNOC] Assuming max packet size for 1/DDC_0
Traceback (most recent call last):
  File "/opt/gnuradio/rfnoc/src/gr-ettus/examples/rfnoc/rfnoc_fosphor.py", line 
644, in 
main()
  File "/opt/gnuradio/rfnoc/src/gr-ettus/examples/rfnoc/rfnoc_fosphor.py", line 
632, in main
tb = top_block_cls()
  File "/opt/gnuradio/rfnoc/src/gr-ettus/examples/rfnoc/rfnoc_fosphor.py", line 
475, in __init__
self.device3.connect(self.uhd_rfnoc_streamer_fft_0_0_0.get_block_id(), 0, 
self.uhd_rfnoc_streamer_fosphor_1.get_block_id(), 0)
  File "/opt/gnuradio/rfnoc/lib64/python2.7/site-packages/ettus/ettus_swig.py", 
line 1264, in connect
return _ettus_swig.device3_sptr_connect(self, *args)
RuntimeError: RuntimeError: On node 1/fosphor_1, input port 0 is already 
connected.

>>> Done

That error at the end is usually what you see when you try to use a single 
block twice without setting up the block select value.  I have checked things 
about 50 times, and I have everything setup right as device 1 and 2, and the 
blocks (I started with a working flowgraph for non TwinRX X310s), but I keep 
getting that error.

If feels like there is a UHD issue that when it is trying to setup which block 
goes with which device, it thinks that there is only one device



From: Rob Kossler mailto:rkoss...@nd.edu>>
Sent: Friday, February 1, 2019 1:14 PM
To: Jason Matusiak
Cc: Ettus Mail List
Subject: Re: [USRP-users] two X310s in one RFNoC flowgraph

How is it failing?

On Fri, Feb 1, 2019 at 1:11 PM Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:
Yep, works fine.  When I am doing it in companion, it also reports info on both 
boxes while setting it up, but it feels like it only tries to talk to the first 
one it sees.


From: Rob Kossler mailto:rkoss...@nd.edu>>
Sent: Friday, February 1, 2019 1:08 PM
To: Jason Matusiak
Cc: Ettus Mail List
Subject: Re: [USRP-users] two X310s in one RFNoC flowgraph

Perhaps run uhd_usrp_probe with --args="addr0=192.168.30.2,addr1=192.168.40.2" 
and make sure that it is happy and shows you all of the blocks.
Rob

On Fri, Feb 1, 2019 at 12:17 PM Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:
Upon further review, even though this worked, it doesn't seem to work for dual 
X310s with TwinRXs in it.  Anyone have any multi-usrp advice with that (since I 
pretty much no experience with TwinRX)?  I figure there might be a clue that 
there could help me with the rfnoc side of things.



From: Jason Matusiak
Sent: Friday, February 1, 2019 9:43 AM
To: Rob Kossler
Cc: Ettus Mail List
Subject: Re: [USRP-users] two X310s in one RFNoC flowgraph


Rob,


I just figured it out (I found lots of people asking the question, but no 
answers, so hopefully this can help someone else).


1st - Set the "device select" option to 0 and 1 for the different X310s 
(usually you leave it at -1, but change the block select, but here we need to 
mod it).

2nd - you need a single Device3 like usual

3rd - under the Device Arguments block, add in your two IP addresses using the 
key of addr0 and addr1 like this: "addr0=192.168.30.2, addr1=192.168.40.2" (I 
tried it both with and without the quotes and it works fine either way),


Now, Device 0 will get associated with addr0, and device 1 will get associates 
with addr1.


I hope that makes sense and helps someone.


From: Rob Kossler mailto:rkoss...@nd.edu>>
Sent: Friday, February 1, 2019 9:23 AM
To: Jason Matusiak
Cc: Ettus Mail List
Subject: Re: [USRP-users] two X310s in one RFNoC flowgraph

Hi Jason,
Given that under the hood, the stock multi_usrp (along with legacy_compat) 
implements an RFNoC graph, it must be possible.  I have run multiple X310s with 
the stock multi_usrp.  I have looked at legacy_compat pretty thoroughly and it 
keeps track of blocks as a function of device number (motherboard).  If I had a 
2nd X310 handy, I would try it with my own non-stock multi_usrp object, but I 
don't - sorry.
Rob

On Fri, Feb 1, 2019 at 8:30 AM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:

I

Re: [USRP-users] two X310s in one RFNoC flowgraph

[Jason Matusiak via USRP-users]

ses.  Then 
it craps out here:

[WARNING] [RFNOC] Assuming max packet size for 0/DDC_0
[WARNING] [RFNOC] Assuming max packet size for 0/DDC_1
[WARNING] [RFNOC] Assuming max packet size for 1/DDC_1
[WARNING] [RFNOC] Assuming max packet size for 1/DDC_0
Traceback (most recent call last):
  File "/opt/gnuradio/rfnoc/src/gr-ettus/examples/rfnoc/rfnoc_fosphor.py", line 
644, in 
main()
  File "/opt/gnuradio/rfnoc/src/gr-ettus/examples/rfnoc/rfnoc_fosphor.py", line 
632, in main
tb = top_block_cls()
  File "/opt/gnuradio/rfnoc/src/gr-ettus/examples/rfnoc/rfnoc_fosphor.py", line 
475, in __init__
self.device3.connect(self.uhd_rfnoc_streamer_fft_0_0_0.get_block_id(), 0, 
self.uhd_rfnoc_streamer_fosphor_1.get_block_id(), 0)
  File "/opt/gnuradio/rfnoc/lib64/python2.7/site-packages/ettus/ettus_swig.py", 
line 1264, in connect
return _ettus_swig.device3_sptr_connect(self, *args)
RuntimeError: RuntimeError: On node 1/fosphor_1, input port 0 is already 
connected.

>>> Done

That error at the end is usually what you see when you try to use a single 
block twice without setting up the block select value.  I have checked things 
about 50 times, and I have everything setup right as device 1 and 2, and the 
blocks (I started with a working flowgraph for non TwinRX X310s), but I keep 
getting that error.

If feels like there is a UHD issue that when it is trying to setup which block 
goes with which device, it thinks that there is only one device



From: Rob Kossler mailto:rkoss...@nd.edu>>
Sent: Friday, February 1, 2019 1:14 PM
To: Jason Matusiak
Cc: Ettus Mail List
Subject: Re: [USRP-users] two X310s in one RFNoC flowgraph

How is it failing?

On Fri, Feb 1, 2019 at 1:11 PM Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:
Yep, works fine.  When I am doing it in companion, it also reports info on both 
boxes while setting it up, but it feels like it only tries to talk to the first 
one it sees.


From: Rob Kossler mailto:rkoss...@nd.edu>>
Sent: Friday, February 1, 2019 1:08 PM
To: Jason Matusiak
Cc: Ettus Mail List
Subject: Re: [USRP-users] two X310s in one RFNoC flowgraph

Perhaps run uhd_usrp_probe with --args="addr0=192.168.30.2,addr1=192.168.40.2" 
and make sure that it is happy and shows you all of the blocks.
Rob

On Fri, Feb 1, 2019 at 12:17 PM Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:
Upon further review, even though this worked, it doesn't seem to work for dual 
X310s with TwinRXs in it.  Anyone have any multi-usrp advice with that (since I 
pretty much no experience with TwinRX)?  I figure there might be a clue that 
there could help me with the rfnoc side of things.



From: Jason Matusiak
Sent: Friday, February 1, 2019 9:43 AM
To: Rob Kossler
Cc: Ettus Mail List
Subject: Re: [USRP-users] two X310s in one RFNoC flowgraph


Rob,


I just figured it out (I found lots of people asking the question, but no 
answers, so hopefully this can help someone else).


1st - Set the "device select" option to 0 and 1 for the different X310s 
(usually you leave it at -1, but change the block select, but here we need to 
mod it).

2nd - you need a single Device3 like usual

3rd - under the Device Arguments block, add in your two IP addresses using the 
key of addr0 and addr1 like this: "addr0=192.168.30.2, addr1=192.168.40.2" (I 
tried it both with and without the quotes and it works fine either way),


Now, Device 0 will get associated with addr0, and device 1 will get associates 
with addr1.


I hope that makes sense and helps someone.


From: Rob Kossler mailto:rkoss...@nd.edu>>
Sent: Friday, February 1, 2019 9:23 AM
To: Jason Matusiak
Cc: Ettus Mail List
Subject: Re: [USRP-users] two X310s in one RFNoC flowgraph

Hi Jason,
Given that under the hood, the stock multi_usrp (along with legacy_compat) 
implements an RFNoC graph, it must be possible.  I have run multiple X310s with 
the stock multi_usrp.  I have looked at legacy_compat pretty thoroughly and it 
keeps track of blocks as a function of device number (motherboard).  If I had a 
2nd X310 handy, I would try it with my own non-stock multi_usrp object, but I 
don't - sorry.
Rob

On Fri, Feb 1, 2019 at 8:30 AM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:

Is it possible to have a single flowgraph that has 2 X310s running RFNoC in it? 
 I can't seem to figure out a way to make it work, though I think there must be 
a way.  Both streams would be streaming to the same host machine for processing.


Thanks.

___
USRP-users mailing list
USRP-users@lists.ettus.com<mailto: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] two X310s in one RFNoC flowgraph

[Jason Matusiak via USRP-users]

ice 0 will get associated with addr0, and device 1 will get associates 
with addr1.


I hope that makes sense and helps someone.


From: Rob Kossler mailto:rkoss...@nd.edu>>
Sent: Friday, February 1, 2019 9:23 AM
To: Jason Matusiak
Cc: Ettus Mail List
Subject: Re: [USRP-users] two X310s in one RFNoC flowgraph

Hi Jason,
Given that under the hood, the stock multi_usrp (along with legacy_compat) 
implements an RFNoC graph, it must be possible.  I have run multiple X310s with 
the stock multi_usrp.  I have looked at legacy_compat pretty thoroughly and it 
keeps track of blocks as a function of device number (motherboard).  If I had a 
2nd X310 handy, I would try it with my own non-stock multi_usrp object, but I 
don't - sorry.
Rob

On Fri, Feb 1, 2019 at 8:30 AM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:

Is it possible to have a single flowgraph that has 2 X310s running RFNoC in it? 
 I can't seem to figure out a way to make it work, though I think there must be 
a way.  Both streams would be streaming to the same host machine for processing.


Thanks.

___
USRP-users mailing list
USRP-users@lists.ettus.com<mailto: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] two X310s in one RFNoC flowgraph

[Jason Matusiak via USRP-users]

When I run my flowgraph with the addresses setup that worked before twinrx, it 
starts to set everything up and seems to be talking to both ip addresses.  Then 
it craps out here:

[WARNING] [RFNOC] Assuming max packet size for 0/DDC_0
[WARNING] [RFNOC] Assuming max packet size for 0/DDC_1
[WARNING] [RFNOC] Assuming max packet size for 1/DDC_1
[WARNING] [RFNOC] Assuming max packet size for 1/DDC_0
Traceback (most recent call last):
  File "/opt/gnuradio/rfnoc/src/gr-ettus/examples/rfnoc/rfnoc_fosphor.py", line 
644, in 
main()
  File "/opt/gnuradio/rfnoc/src/gr-ettus/examples/rfnoc/rfnoc_fosphor.py", line 
632, in main
tb = top_block_cls()
  File "/opt/gnuradio/rfnoc/src/gr-ettus/examples/rfnoc/rfnoc_fosphor.py", line 
475, in __init__
self.device3.connect(self.uhd_rfnoc_streamer_fft_0_0_0.get_block_id(), 0, 
self.uhd_rfnoc_streamer_fosphor_1.get_block_id(), 0)
  File "/opt/gnuradio/rfnoc/lib64/python2.7/site-packages/ettus/ettus_swig.py", 
line 1264, in connect
return _ettus_swig.device3_sptr_connect(self, *args)
RuntimeError: RuntimeError: On node 1/fosphor_1, input port 0 is already 
connected.

>>> Done

That error at the end is usually what you see when you try to use a single 
block twice without setting up the block select value.  I have checked things 
about 50 times, and I have everything setup right as device 1 and 2, and the 
blocks (I started with a working flowgraph for non TwinRX X310s), but I keep 
getting that error.

If feels like there is a UHD issue that when it is trying to setup which block 
goes with which device, it thinks that there is only one device



From: Rob Kossler 
Sent: Friday, February 1, 2019 1:14 PM
To: Jason Matusiak
Cc: Ettus Mail List
Subject: Re: [USRP-users] two X310s in one RFNoC flowgraph

How is it failing?

On Fri, Feb 1, 2019 at 1:11 PM Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:
Yep, works fine.  When I am doing it in companion, it also reports info on both 
boxes while setting it up, but it feels like it only tries to talk to the first 
one it sees.


From: Rob Kossler mailto:rkoss...@nd.edu>>
Sent: Friday, February 1, 2019 1:08 PM
To: Jason Matusiak
Cc: Ettus Mail List
Subject: Re: [USRP-users] two X310s in one RFNoC flowgraph

Perhaps run uhd_usrp_probe with --args="addr0=192.168.30.2,addr1=192.168.40.2" 
and make sure that it is happy and shows you all of the blocks.
Rob

On Fri, Feb 1, 2019 at 12:17 PM Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:
Upon further review, even though this worked, it doesn't seem to work for dual 
X310s with TwinRXs in it.  Anyone have any multi-usrp advice with that (since I 
pretty much no experience with TwinRX)?  I figure there might be a clue that 
there could help me with the rfnoc side of things.



From: Jason Matusiak
Sent: Friday, February 1, 2019 9:43 AM
To: Rob Kossler
Cc: Ettus Mail List
Subject: Re: [USRP-users] two X310s in one RFNoC flowgraph


Rob,


I just figured it out (I found lots of people asking the question, but no 
answers, so hopefully this can help someone else).


1st - Set the "device select" option to 0 and 1 for the different X310s 
(usually you leave it at -1, but change the block select, but here we need to 
mod it).

2nd - you need a single Device3 like usual

3rd - under the Device Arguments block, add in your two IP addresses using the 
key of addr0 and addr1 like this: "addr0=192.168.30.2, addr1=192.168.40.2" (I 
tried it both with and without the quotes and it works fine either way),


Now, Device 0 will get associated with addr0, and device 1 will get associates 
with addr1.


I hope that makes sense and helps someone.


From: Rob Kossler mailto:rkoss...@nd.edu>>
Sent: Friday, February 1, 2019 9:23 AM
To: Jason Matusiak
Cc: Ettus Mail List
Subject: Re: [USRP-users] two X310s in one RFNoC flowgraph

Hi Jason,
Given that under the hood, the stock multi_usrp (along with legacy_compat) 
implements an RFNoC graph, it must be possible.  I have run multiple X310s with 
the stock multi_usrp.  I have looked at legacy_compat pretty thoroughly and it 
keeps track of blocks as a function of device number (motherboard).  If I had a 
2nd X310 handy, I would try it with my own non-stock multi_usrp object, but I 
don't - sorry.
Rob

On Fri, Feb 1, 2019 at 8:30 AM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:

Is it possible to have a single flowgraph that has 2 X310s running RFNoC in it? 
 I can't seem to figure out a way to make it work, though I think there must be 
a way.  Both streams would be streaming to the same host machine for processing.


Thanks.

___
USRP-users mailing list
USRP-users@lists.et

Re: [USRP-users] two X310s in one RFNoC flowgraph

[Jason Matusiak via USRP-users]

Yep, works fine.  When I am doing it in companion, it also reports info on both 
boxes while setting it up, but it feels like it only tries to talk to the first 
one it sees.


From: Rob Kossler 
Sent: Friday, February 1, 2019 1:08 PM
To: Jason Matusiak
Cc: Ettus Mail List
Subject: Re: [USRP-users] two X310s in one RFNoC flowgraph

Perhaps run uhd_usrp_probe with --args="addr0=192.168.30.2,addr1=192.168.40.2" 
and make sure that it is happy and shows you all of the blocks.
Rob

On Fri, Feb 1, 2019 at 12:17 PM Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:
Upon further review, even though this worked, it doesn't seem to work for dual 
X310s with TwinRXs in it.  Anyone have any multi-usrp advice with that (since I 
pretty much no experience with TwinRX)?  I figure there might be a clue that 
there could help me with the rfnoc side of things.



From: Jason Matusiak
Sent: Friday, February 1, 2019 9:43 AM
To: Rob Kossler
Cc: Ettus Mail List
Subject: Re: [USRP-users] two X310s in one RFNoC flowgraph


Rob,


I just figured it out (I found lots of people asking the question, but no 
answers, so hopefully this can help someone else).


1st - Set the "device select" option to 0 and 1 for the different X310s 
(usually you leave it at -1, but change the block select, but here we need to 
mod it).

2nd - you need a single Device3 like usual

3rd - under the Device Arguments block, add in your two IP addresses using the 
key of addr0 and addr1 like this: "addr0=192.168.30.2, addr1=192.168.40.2" (I 
tried it both with and without the quotes and it works fine either way),


Now, Device 0 will get associated with addr0, and device 1 will get associates 
with addr1.


I hope that makes sense and helps someone.


From: Rob Kossler mailto:rkoss...@nd.edu>>
Sent: Friday, February 1, 2019 9:23 AM
To: Jason Matusiak
Cc: Ettus Mail List
Subject: Re: [USRP-users] two X310s in one RFNoC flowgraph

Hi Jason,
Given that under the hood, the stock multi_usrp (along with legacy_compat) 
implements an RFNoC graph, it must be possible.  I have run multiple X310s with 
the stock multi_usrp.  I have looked at legacy_compat pretty thoroughly and it 
keeps track of blocks as a function of device number (motherboard).  If I had a 
2nd X310 handy, I would try it with my own non-stock multi_usrp object, but I 
don't - sorry.
Rob

On Fri, Feb 1, 2019 at 8:30 AM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:

Is it possible to have a single flowgraph that has 2 X310s running RFNoC in it? 
 I can't seem to figure out a way to make it work, though I think there must be 
a way.  Both streams would be streaming to the same host machine for processing.


Thanks.

___
USRP-users mailing list
USRP-users@lists.ettus.com<mailto: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] two X310s in one RFNoC flowgraph

[Jason Matusiak via USRP-users]

Upon further review, even though this worked, it doesn't seem to work for dual 
X310s with TwinRXs in it.  Anyone have any multi-usrp advice with that (since I 
pretty much no experience with TwinRX)?  I figure there might be a clue that 
there could help me with the rfnoc side of things.



From: Jason Matusiak
Sent: Friday, February 1, 2019 9:43 AM
To: Rob Kossler
Cc: Ettus Mail List
Subject: Re: [USRP-users] two X310s in one RFNoC flowgraph


Rob,


I just figured it out (I found lots of people asking the question, but no 
answers, so hopefully this can help someone else).


1st - Set the "device select" option to 0 and 1 for the different X310s 
(usually you leave it at -1, but change the block select, but here we need to 
mod it).

2nd - you need a single Device3 like usual

3rd - under the Device Arguments block, add in your two IP addresses using the 
key of addr0 and addr1 like this: "addr0=192.168.30.2, addr1=192.168.40.2" (I 
tried it both with and without the quotes and it works fine either way),


Now, Device 0 will get associated with addr0, and device 1 will get associates 
with addr1.


I hope that makes sense and helps someone.


From: Rob Kossler 
Sent: Friday, February 1, 2019 9:23 AM
To: Jason Matusiak
Cc: Ettus Mail List
Subject: Re: [USRP-users] two X310s in one RFNoC flowgraph

Hi Jason,
Given that under the hood, the stock multi_usrp (along with legacy_compat) 
implements an RFNoC graph, it must be possible.  I have run multiple X310s with 
the stock multi_usrp.  I have looked at legacy_compat pretty thoroughly and it 
keeps track of blocks as a function of device number (motherboard).  If I had a 
2nd X310 handy, I would try it with my own non-stock multi_usrp object, but I 
don't - sorry.
Rob

On Fri, Feb 1, 2019 at 8:30 AM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:

Is it possible to have a single flowgraph that has 2 X310s running RFNoC in it? 
 I can't seem to figure out a way to make it work, though I think there must be 
a way.  Both streams would be streaming to the same host machine for processing.


Thanks.

___
USRP-users mailing list
USRP-users@lists.ettus.com<mailto: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