Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Loading USRP X3x0 by baseband processing functions
(Marcus M?ller)
2. Re: Fwd: First time UHD build (Marcus M?ller)
3. Re: Python Error Message: ImportError: DLL load failed: The
specified procedure could not be found. (Marcus M?ller)
4. Re: Help building UHD...? (Marcus M?ller)
5. TX and RX paths sharing a coherent LO (Rickard Radio)
6. Re: Python Error Message: ImportError: DLL load failed: The
specified procedure could not be found. (Marcus M?ller)
7. Re: TX and RX paths sharing a coherent LO (Marcus M?ller)
8. Re: TX and RX paths sharing a coherent LO (Rickard Radio)
9. N210 Stops Transmitting (Liwei)
10. Re: TX and RX paths sharing a coherent LO (Marcus M?ller)
11. USRP x310 does not reply to IP packets of odd length?
(Hrishikesh Shelar)
12. Re: [UHD 3.7.3] Release Announcement (Ralph A. Schmid, dk5ras)
13. Re: USRP x310 does not reply to IP packets of odd length?
(Hrishikesh Shelar)
14. Re: USRP x310 does not reply to IP packets of odd length?
(Marcus M?ller)
15. Re: TX and RX paths sharing a coherent LO (Rickard Radio)
16. Re: USRP x310 does not reply to IP packets of odd length?
(Hrishikesh Shelar)
17. Re: USRP x310 does not reply to IP packets of odd length?
(Matt Ettus)
18. Re: [UHD 3.7.3] Release Announcement (Balint Seeber)
19. Re: USRP x310 does not reply to IP packets of odd length?
(Hrishikesh Shelar)
20. Re: USRP x310 does not reply to IP packets of odd length?
(Matt Ettus)
21. Re: USRP x310 does not reply to IP packets of odd length?
(Hrishikesh Shelar)
22. Re: [UHD 3.7.3] Release Announcement (Ralph A. Schmid, dk5ras)
23. Re: [UHD 3.7.3] Release Announcement (Ralph A. Schmid, dk5ras)
24. ATR registers (Per Zetterberg)
25. X3X0 SBX corrupted samples? (LEMENAGER Claude)
26. Re: X3X0 SBX corrupted samples? (Marcus M?ller)
27. Re: X3X0 SBX corrupted samples? (Herv? BOEGLEN)
----------------------------------------------------------------------
Message: 1
Date: Wed, 08 Oct 2014 18:21:37 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Loading USRP X3x0 by baseband processing
functions
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hello Birhane,
sorry for the late reply, but:
The only limit is your ability to write FPGA code (absolutely
non-trivial, doesn't sound like a one-man project at all) and the free
ressources on the FPGA. Now, for larger FPGA projects I'd recommend
getting the X310.
Using the upcoming RF Network On Chip, our "next big thing" in USRP FPGA
architecture, this could get a little easier by encapsulating
functionality in computation nodes that can exchange information using a
flexible crossbar.
However, a complete GSM stack is a big thing, and I don't see much use
in implementing it in FPGA rather than host code, especially since
working GSM base stations already exist (openBTS).
Best regards,
Marcus M?ller
On 30.09.2014 21:35, Birhane Alemayoh via USRP-users wrote:
> Dear All,
> I have a very great interest to use the new USRP X3x0 series for my^GSM
> baseband signal processing because of its large user-programmable Kintex-7
> FPGA. However, i need to implement the baseband processing inside the
> USRP's FPGA, not insixe the host PC.
> My questionnow is can I implement the whole GSM baseband signal processing
> functions inside the FPGA using JTAG programmer? What are the constraints?
> Thank u in advance!
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141008/4386e28f/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 08 Oct 2014 18:25:09 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Fwd: First time UHD build
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Kalen,
just an idea:
your Boost_INCLUDE_DIR uses backslashes, whereas the rest of the output
uses forward slashes; maybe that's what confuses CMake.
Could you share your complete Cmake call?
Greetings,
Marcus
On 03.10.2014 19:20, Kalen Williams via USRP-users wrote:
> I'm trying to build UHD for the first time to use with the Ettus USRP X310,
> but I'm having issues with the Boost find function. Not sure what to do. I
> found a forum comment online somewhere that recommended manually overriding
> that function but I'd rather not do that.
>
> Configuring the python interpreter...
>
> Python interpreter: C:/Python26/python.exe
>
> Override with: -DPYTHON_EXECUTABLE=<path-to-python>
>
> Configuring Boost C++ Libraries...
>
> CMake Error at C:/Program Files
> (x86)/CMake/share/cmake-3.0/Modules/FindBoost.cmake:683 (file):
> file STRINGS file
> "C:/Users/Matt/Desktop/UHD-Clone/uhd/host/Boost_INCLUDE_DIR=c:\local\boost_1_56_0/boost/version.hpp"
> cannot be read.
> Call Stack (most recent call first):
> CMakeLists.txt:161 (FIND_PACKAGE)
>
> Could NOT find Boost
>
> Boost include directories: Boost_INCLUDE_DIR=c:\local\boost_1_56_0
>
> Boost library directories:
>
> Boost libraries:
>
> Python checking for Python version 2.6 or greater
>
> Python checking for Python version 2.6 or greater - found
>
> Python checking for Cheetah templates 2.0.0 or greater
>
> Python checking for Cheetah templates 2.0.0 or greater - found
>
> Configuring LibUHD support...
>
> Dependency Boost_FOUND = 0
>
> Dependency HAVE_PYTHON_PLAT_MIN_VERSION = TRUE
>
> Dependency HAVE_PYTHON_MODULE_CHEETAH = TRUE
>
> Disabling LibUHD support.
>
> Override with -DENABLE_LIBUHD=ON/OFF
>
> Configuring Examples support...
>
> Dependency ENABLE_LIBUHD = OFF
>
> Disabling Examples support.
>
> Override with -DENABLE_EXAMPLES=ON/OFF
>
> Configuring Utils support...
>
> Dependency ENABLE_LIBUHD = OFF
>
> Disabling Utils support.
>
> Override with -DENABLE_UTILS=ON/OFF
>
> Configuring Tests support...
>
> Dependency ENABLE_LIBUHD = OFF
>
> Disabling Tests support.
>
> Override with -DENABLE_TESTS=ON/OFF
>
> Configuring Manual support...
>
> Dependency DOXYGEN_FOUND = YES
>
> Enabling Manual support.
>
> Override with -DENABLE_MANUAL=ON/OFF
>
> Configuring API/Doxygen support...
>
> Dependency DOXYGEN_FOUND = YES
>
> Enabling API/Doxygen support.
>
> Override with -DENABLE_DOXYGEN=ON/OFF
>
> Could NOT find GZip (missing: GZIP_EXECUTABLE)
>
> Configuring Man Pages support...
>
> Dependency GZIP_FOUND = FALSE
>
> Dependency NOT_WIN32 =
>
> Disabling Man Pages support.
>
> Override with -DENABLE_MAN_PAGES=ON/OFF
>
> ######################################################
>
> # UHD enabled components
>
> ######################################################
>
> * Manual
>
> * API/Doxygen
>
> ######################################################
>
> # UHD disabled components
>
> ######################################################
>
> * LibUHD
>
> * Examples
>
> * Utils
>
> * Tests
>
> * Man Pages
>
> Building version: 003.007.002-87-gc3acbb87
>
> Using install prefix: C:/Program Files/UHD
>
> Compatible images can be downloaded from:
> http://files.ettus.com/binaries/master_images/archive/uhd-images_003.007.002-440-gb290682b.zip
>
> Configuring incomplete, errors occurred!
>
> See also "C:/Users/Matt/Desktop/UHD-build/CMakeFiles/CMakeOutput.log".
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141008/a2fff75b/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 08 Oct 2014 18:29:36 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Python Error Message: ImportError: DLL load
failed: The specified procedure could not be found.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
This looks like you're mixing GNU Radio and/or UHD versions.
I recommend uninstalling both GNU Radio and UHD, and searching for
remaining files with names containing uhd, as well for remaining GNU
Radio leftovers, especially _uhd_swig.* .
After that, install the latest UHD and GNU Radio version from
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki/GNURadio_Windows
again.
I hope that helps!
Greetings,
Marcus
On 07.10.2014 17:43, FIXED-TERM Ghobrial Antoun (CR/AEH4) via USRP-users
wrote:
> Hello ,
> I am using GNU Radio 3.7.3 (Unstable version) with UHD driver 3.7.0 (Unstable
> version). I build a simple Flow graph and I tried to execute the generated
> Python file and it gives me this error message :
>
> <<
> Traceback (most recent call last):
> File "D:\Antoun's Data\Matlab Projects\GNURadio_TestBed\GNU_USRP_Tx.py",
> line 11, in <module>
> from gnuradio import uhd
> File "C:\Program Files
> (x86)\gnuradio\lib\site-packages\gnuradio\uhd\__init__.py", line 135, in
> <module>
> _prepare_uhd_swig()
> File "C:\Program Files
> (x86)\gnuradio\lib\site-packages\gnuradio\uhd\__init__.py", line 38, in
> _prepare_uhd_swig
> import uhd_swig
> File "C:\Program Files
> (x86)\gnuradio\lib\site-packages\gnuradio\uhd\uhd_swig.py", line 26, in
> <module>
> _uhd_swig = swig_import_helper()
> File "C:\Program Files
> (x86)\gnuradio\lib\site-packages\gnuradio\uhd\uhd_swig.py", line 22, in
> swig_import_helper
> _mod = imp.load_module('_uhd_swig', fp, pathname, description)
> ImportError: DLL load failed: The specified procedure could not be found.
>
> I checked google with all Ettus mail list replies and all replies talked
> about checking the Path Environment and I should add these paths :
> - c:\program files (x86)\uhd\bin
> - c:\program files (x86)\gnuradio\bin
> - c:\python27\lib\site-packages
> -
> I already checked these paths several times using Rapid Environment Editor.
> I tried to invoke this command 'from gnuradio import uhd' in Python Shell and
> it showed me the same error message :
> <<
> Traceback (most recent call last):
> File "<pyshell#10>", line 1, in <module>
> from gnuradio import uhd
> File "C:\Program Files
> (x86)\gnuradio\lib\site-packages\gnuradio\uhd\__init__.py", line 135, in
> <module>
> _prepare_uhd_swig()
> File "C:\Program Files
> (x86)\gnuradio\lib\site-packages\gnuradio\uhd\__init__.py", line 38, in
> _prepare_uhd_swig
> import uhd_swig
> File "C:\Program Files
> (x86)\gnuradio\lib\site-packages\gnuradio\uhd\uhd_swig.py", line 26, in
> <module>
> _uhd_swig = swig_import_helper()
> File "C:\Program Files
> (x86)\gnuradio\lib\site-packages\gnuradio\uhd\uhd_swig.py", line 22, in
> swig_import_helper
> _mod = imp.load_module('_uhd_swig', fp, pathname, description)
> ImportError: DLL load failed: The specified procedure could not be found.
> Then the problem here is that it can't import uhd library .
>
> Any suggestion please to solve this problem.
>
>
>
>
> Best regards
>
> Antoun Ghobrial
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141008/0efc46ef/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 08 Oct 2014 18:37:15 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Help building UHD...?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Robert,
did you install make, and g++? CMake doesn't seem to find a program to
handle makefiles, at least.
Greetings,
Marcus
On 03.10.2014 02:50, Robert McIntyre via USRP-users wrote:
> Not sure what's going on here. Monday night, I was able to download and
> build UHD following these instructions on a stock/updated Debian Testing
> system:
>
> http://code.ettus.com/redmine/ettus/projects/uhd/wiki/UHD_build
>
> The next night I tried to build gnuradio, and had to stop in the middle, and
> it basically horked my system, so I just reinstalled the Debian Testing OS,
> and updated, and then started over last night.
>
> When I tried to build UHD again, I started getting CMAKE errors. Got
> frustrated, flattened my system (it's a test system), and installed Debian
> Stable (Wheezy), and tried again.
>
> Still getting CMAKE errors, but they're different now. Pasted below.
>
> Hoping someone can help decipher what I'm doing wrong. As far as I know,
> I've done the same thing every time. I tried fiddling with some of the CMake
> settings last night, but got nowhere. I took a look through the git repo
> history, and nothing sticks out, but I'm not familiar with the code.
>
> Thanks!
> Robert
>
> user@machine:/data/sources/uhd/host/build$ cmake ../
> CMake Error: CMake was unable to find a build program corresponding to "Unix
> Makefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a
> different build tool.
> CMake Error: Error required internal CMake variable not set, cmake may be not
> be built correctly.
> Missing variable is:
> CMAKE_CXX_COMPILER_ENV_VAR
> CMake Error: Error required internal CMake variable not set, cmake may be not
> be built correctly.
> Missing variable is:
> CMAKE_CXX_COMPILER
> CMake Error: Could not find cmake module
> file:/data/sources/uhd/host/build/CMakeFiles/CMakeCXXCompiler.cmake
> CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
> -- Configuring incomplete, errors occurred!
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141008/f14c9cdc/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 8 Oct 2014 18:48:49 +0200
From: Rickard Radio <[email protected]>
To: [email protected]
Subject: [USRP-users] TX and RX paths sharing a coherent LO
Message-ID:
<calycml4reduh73zkl6dhots4qppqu_hkz0ozusyxcnec-oe...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear usrp-users,
I am interested in coherently LO-mixing different TX and RX paths for some
experiments.
Q1: Which options exist to use the same(?) coherent(!) LO for different TX
and RX paths on the USRPs (N210 and/or B210)?
Q2: Related, with the N210s and the MIMO cable, can I obtain and use a
coherently shared LO for different TX and RX paths?
Q3: Follow up - do I need something else or in addition ?
Regards,
Rickard
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141008/ff086fb1/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 08 Oct 2014 18:52:39 +0200
From: Marcus M?ller <[email protected]>
To: [email protected],
[email protected]
Subject: Re: [USRP-users] Python Error Message: ImportError: DLL load
failed: The specified procedure could not be found.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Actually, trial shows that there is something wrong with the GNU Radio
installer. I'm afraid you'll have to turn to the discuss-gnuradio
mailing list to get help building GNU Radio on windows itself.
I generally recommend trying out our liveUSB system, which boots from an
>= 16GB USB drive, and comes with GNU Radio, UHD and a lot of
applications pre-installed.
Greetings,
Marcus
On 08.10.2014 18:29, Marcus M?ller wrote:
> This looks like you're mixing GNU Radio and/or UHD versions.
> I recommend uninstalling both GNU Radio and UHD, and searching for
> remaining files with names containing uhd, as well for remaining GNU
> Radio leftovers, especially _uhd_swig.* .
>
> After that, install the latest UHD and GNU Radio version from
> http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki/GNURadio_Windows
> again.
>
> I hope that helps!
>
> Greetings,
> Marcus
> On 07.10.2014 17:43, FIXED-TERM Ghobrial Antoun (CR/AEH4) via USRP-users
> wrote:
>> Hello ,
>> I am using GNU Radio 3.7.3 (Unstable version) with UHD driver 3.7.0
>> (Unstable version). I build a simple Flow graph and I tried to execute the
>> generated Python file and it gives me this error message :
>>
>> <<
>> Traceback (most recent call last):
>> File "D:\Antoun's Data\Matlab Projects\GNURadio_TestBed\GNU_USRP_Tx.py",
>> line 11, in <module>
>> from gnuradio import uhd
>> File "C:\Program Files
>> (x86)\gnuradio\lib\site-packages\gnuradio\uhd\__init__.py", line 135, in
>> <module>
>> _prepare_uhd_swig()
>> File "C:\Program Files
>> (x86)\gnuradio\lib\site-packages\gnuradio\uhd\__init__.py", line 38, in
>> _prepare_uhd_swig
>> import uhd_swig
>> File "C:\Program Files
>> (x86)\gnuradio\lib\site-packages\gnuradio\uhd\uhd_swig.py", line 26, in
>> <module>
>> _uhd_swig = swig_import_helper()
>> File "C:\Program Files
>> (x86)\gnuradio\lib\site-packages\gnuradio\uhd\uhd_swig.py", line 22, in
>> swig_import_helper
>> _mod = imp.load_module('_uhd_swig', fp, pathname, description)
>> ImportError: DLL load failed: The specified procedure could not be found.
>>
>> I checked google with all Ettus mail list replies and all replies talked
>> about checking the Path Environment and I should add these paths :
>> - c:\program files (x86)\uhd\bin
>> - c:\program files (x86)\gnuradio\bin
>> - c:\python27\lib\site-packages
>> -
>> I already checked these paths several times using Rapid Environment Editor.
>> I tried to invoke this command 'from gnuradio import uhd' in Python Shell
>> and it showed me the same error message :
>> <<
>> Traceback (most recent call last):
>> File "<pyshell#10>", line 1, in <module>
>> from gnuradio import uhd
>> File "C:\Program Files
>> (x86)\gnuradio\lib\site-packages\gnuradio\uhd\__init__.py", line 135, in
>> <module>
>> _prepare_uhd_swig()
>> File "C:\Program Files
>> (x86)\gnuradio\lib\site-packages\gnuradio\uhd\__init__.py", line 38, in
>> _prepare_uhd_swig
>> import uhd_swig
>> File "C:\Program Files
>> (x86)\gnuradio\lib\site-packages\gnuradio\uhd\uhd_swig.py", line 26, in
>> <module>
>> _uhd_swig = swig_import_helper()
>> File "C:\Program Files
>> (x86)\gnuradio\lib\site-packages\gnuradio\uhd\uhd_swig.py", line 22, in
>> swig_import_helper
>> _mod = imp.load_module('_uhd_swig', fp, pathname, description)
>> ImportError: DLL load failed: The specified procedure could not be found.
>> Then the problem here is that it can't import uhd library .
>>
>> Any suggestion please to solve this problem.
>>
>>
>>
>>
>> Best regards
>>
>> Antoun Ghobrial
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 7
Date: Wed, 08 Oct 2014 18:54:44 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] TX and RX paths sharing a coherent LO
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Rickard,
all the LOs are synthesized from the same motherboard reference, so Q1
is answered with "you get that for free".
Q2 is "yes".
Q3 gets the answer "if you want to use definite times when sampling, use
the timed commands feature of UHD".
:)
Greetings,
Marcus
On 08.10.2014 18:48, Rickard Radio via USRP-users wrote:
> Dear usrp-users,
>
> I am interested in coherently LO-mixing different TX and RX paths for some
> experiments.
>
> Q1: Which options exist to use the same(?) coherent(!) LO for different TX
> and RX paths on the USRPs (N210 and/or B210)?
> Q2: Related, with the N210s and the MIMO cable, can I obtain and use a
> coherently shared LO for different TX and RX paths?
> Q3: Follow up - do I need something else or in addition ?
>
> Regards,
> Rickard
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141008/f207cc10/attachment-0001.html>
------------------------------
Message: 8
Date: Wed, 8 Oct 2014 19:04:12 +0200
From: Rickard Radio <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] TX and RX paths sharing a coherent LO
Message-ID:
<CALycML7Wm=j6bjmvycqinw2i4f5ij5v5+odgmmye9pf-kvz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Sounds good!
Does this mean it really shares the same LO, i.e., also with the same and
uniquely occurring phase noise shared to all paths?! (I want that!)
Regards,
Rickard
On Wed, Oct 8, 2014 at 6:54 PM, Marcus M?ller <[email protected]>
wrote:
> Hi Rickard,
>
> all the LOs are synthesized from the same motherboard reference, so Q1 is
> answered with "you get that for free".
> Q2 is "yes".
> Q3 gets the answer "if you want to use definite times when sampling, use
> the timed commands feature of UHD".
> :)
>
> Greetings,
> Marcus
>
> On 08.10.2014 18:48, Rickard Radio via USRP-users wrote:
>
> Dear usrp-users,
>
> I am interested in coherently LO-mixing different TX and RX paths for some
> experiments.
>
> Q1: Which options exist to use the same(?) coherent(!) LO for different TX
> and RX paths on the USRPs (N210 and/or B210)?
> Q2: Related, with the N210s and the MIMO cable, can I obtain and use a
> coherently shared LO for different TX and RX paths?
> Q3: Follow up - do I need something else or in addition ?
>
> Regards,
> Rickard
>
>
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141008/45c60ed2/attachment-0001.html>
------------------------------
Message: 9
Date: Thu, 9 Oct 2014 01:10:13 +0800
From: Liwei <[email protected]>
To: [email protected]
Subject: [USRP-users] N210 Stops Transmitting
Message-ID:
<CAPE0SYwvj8nNEYOmHhxHo8Utmr_Lc=fq+55fcxm2c9t0cow...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello list,
This may have been asked before (I vaguely remember seeing an
email with a similar issue some time back), but what causes UHD to
stop sending transmission packets to an N210?
With a simple flowgraph [signal source] -> [uhd sink] at 200k
sample rate over gigabit ethernet, I get up to about 3 seconds of
transmission before everything suddenly goes silent.
Here's what I see logged:
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.002-107-g0ca4b4f8
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
SU
Nothing else after "SU".
Interestingly, if I add a receive + fft chain in the same
flowgraph, the receive stream works fine even after the transmission
has stopped. In fact, if I loop the TX and RX ports on the N210
together (with an attenuator in between) I can see, in the received
signal fft, the frequency peak for the few seconds the N210 is able to
transmit.
Gqrx also works well receiving FM radio stations all the way up to
about 10MHz sampling rate, after which samples start to get dropped.
I'm running on a fresh install of Ubuntu 14.04, with everything
installed using pyBOMBS. I've tried switching to yesterday's 3.7.3
maint branch but no difference. Firmware and FPGA image were updated
after each version switch.
Attached is a screenshot in Wireshark showing the sudden
transmission stop. Note that only packets originating from the
computer is shown.
Also attached is the output from uhd_usrp_probe.
$ uname -a
Linux Ubuntu 3.15.0-031500rc2-generic #201404201435 SMP Sun Apr 20
18:36:18 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
It may be due to a buggy ethernet adapter, but I've achieved over
900MBits/s for both TX and RX over iperf. I've also tried another Fast
(instead of gigabit) ethernet adapter and even Wi-Fi, but no
difference. There is currently a Dell managed switch in-between the
computer and N210, but I've tried directly connecting both together
with no difference in results either.
Also, the current setup works flawlessly with a B210 which I have on hand.
At this point, any hint would be great!
Thanks
Liwei
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2014-10-09 00:47:43.png
Type: image/png
Size: 244083 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141009/b8541426/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: probe_details
Type: application/octet-stream
Size: 2988 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141009/b8541426/attachment-0001.obj>
------------------------------
Message: 10
Date: Wed, 08 Oct 2014 19:19:54 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] TX and RX paths sharing a coherent LO
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
No, the LOs used for mixing are individually generated from the same
10MHz reference; they thus don't drift away from each other, but they
don't share the same jitter etc. However, the Ettus daughterboards
usually use rather decent synths, and thus the LO quality should be
dominated by the quality of the reference clock -- which again, is quite
ok, for most applications, and can be further optimized by
GPS-disciplining the reference.
Usually, that's how close you can get to shared LO if you want
independent TX and RX mixers.
Greetings,
Marcus
On 08.10.2014 19:04, Rickard Radio via USRP-users wrote:
> Sounds good!
>
> Does this mean it really shares the same LO, i.e., also with the same and
> uniquely occurring phase noise shared to all paths?! (I want that!)
>
> Regards,
> Rickard
>
>
>
> On Wed, Oct 8, 2014 at 6:54 PM, Marcus M?ller <[email protected]>
> wrote:
>
>> Hi Rickard,
>>
>> all the LOs are synthesized from the same motherboard reference, so Q1 is
>> answered with "you get that for free".
>> Q2 is "yes".
>> Q3 gets the answer "if you want to use definite times when sampling, use
>> the timed commands feature of UHD".
>> :)
>>
>> Greetings,
>> Marcus
>>
>> On 08.10.2014 18:48, Rickard Radio via USRP-users wrote:
>>
>> Dear usrp-users,
>>
>> I am interested in coherently LO-mixing different TX and RX paths for some
>> experiments.
>>
>> Q1: Which options exist to use the same(?) coherent(!) LO for different TX
>> and RX paths on the USRPs (N210 and/or B210)?
>> Q2: Related, with the N210s and the MIMO cable, can I obtain and use a
>> coherently shared LO for different TX and RX paths?
>> Q3: Follow up - do I need something else or in addition ?
>>
>> Regards,
>> Rickard
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing
>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141008/0dcf5f81/attachment-0001.html>
------------------------------
Message: 11
Date: Wed, 8 Oct 2014 11:45:37 -0700
From: Hrishikesh Shelar <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] USRP x310 does not reply to IP packets of odd
length?
Message-ID:
<cacm6m_dpjnv_jlsot_rzr8pevqjxyd1ezje6yy_iro1qjrb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey all,
I was observing some weird behavior while testing out transfer of IP
packets to and from the USRP. It seems as though the USRP can't correctly
parse packets that are odd in length. I was seeing odd length packets leave
my machine (using wireshark) but failed to see my custom USRP logic react
accordingly. Everything works if packets are even in length. At first I
thought it was a problem with my logic but I ran extensive testbenches and
couldn't pinpoint the error. So I decided to the USRP itself without my
logic in it and observed the same behavior. Using wireshark to sniff the
packets here is what I observed: (my USRP IP is 192.168.1.3)
>From a Windows terminal
ping 192.168.1.3 works
ping -l 512 192.168.1.3 works; reply packets are also 512 bytes long
ping -l 513 192.168.1.3 doesn't work: wireshark reports reply packets are
60 bytes long
ping -l 5 192.168.1.3 doesn't work: wireshark reports reply packets are 60
bytes long
Any odd length doesn't work.
>From a Linux terminal
ping 192.168.1.3 works
ping -s 512 192.168.1.3 works: reply packets are 520 bytes long
ping -s 513 192.168.1.3 doesn't work: wireshark reports reply packets are
60 bytes long
ping -s 5 192.168.1.3 works; reply packets are 60 bytes long
Any odd length above 17 doesn't work.
Any clue as to why this is happening? Also it seems as though the USRP
nominally uses packets that are even in length so this error wouldn't have
come up before?
Thanks,
Hrishikesh Shelar
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141008/bd300805/attachment-0001.html>
------------------------------
Message: 12
Date: Wed, 8 Oct 2014 20:48:55 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: "'Martin Braun'" <[email protected]>, "'Garver, Paul W'"
<[email protected]>, <[email protected]>
Subject: Re: [USRP-users] [UHD 3.7.3] Release Announcement
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi,
> On a side note, I have the suspicion that when people are talking about 'this
> issue', it's not always the same one. We really appreciate
This is also my guess. It seems I have two issues here, one general virtual
machine issue that has nothing to do with the uhd version, but just with
getting somehow out of sync in USB communication from other activity on the
system. From this the system can recover, with openbts even automatically by
restarting the service. The other issue with to me identical looking signs is
uhd version dependent and happens even when the machine is idle and the vmware
stuff does not slow down USB transfers.
> all bug reports, but please, if something fails, give us as much detail as
> possible, even if repeating information.
>
> Thanks,
> Martin
Ralph.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141008/c12c62c5/attachment-0001.sig>
------------------------------
Message: 13
Date: Wed, 8 Oct 2014 12:05:31 -0700
From: Hrishikesh Shelar <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP x310 does not reply to IP packets of
odd length?
Message-ID:
<CACM6M_cijs=n-igha5_ftee4xkddj0b1ryb9k9rk2aomnau...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Sorry I misspoke.
For the 513 length ping packets the 60 byte reply seen on wireshark wasn't
a reply to the ping, it was an ICMP information request which the USRP does
nominally. So essentially there was no reply.
Thanks again,
Hrishi
On Wed, Oct 8, 2014 at 11:45 AM, Hrishikesh Shelar <[email protected]>
wrote:
> Hey all,
>
> I was observing some weird behavior while testing out transfer of IP
> packets to and from the USRP. It seems as though the USRP can't correctly
> parse packets that are odd in length. I was seeing odd length packets leave
> my machine (using wireshark) but failed to see my custom USRP logic react
> accordingly. Everything works if packets are even in length. At first I
> thought it was a problem with my logic but I ran extensive testbenches and
> couldn't pinpoint the error. So I decided to the USRP itself without my
> logic in it and observed the same behavior. Using wireshark to sniff the
> packets here is what I observed: (my USRP IP is 192.168.1.3)
>
> From a Windows terminal
>
> ping 192.168.1.3 works
> ping -l 512 192.168.1.3 works; reply packets are also 512 bytes long
> ping -l 513 192.168.1.3 doesn't work: wireshark reports reply packets are
> 60 bytes long
> ping -l 5 192.168.1.3 doesn't work: wireshark reports reply packets are 60
> bytes long
>
> Any odd length doesn't work.
>
> From a Linux terminal
>
> ping 192.168.1.3 works
> ping -s 512 192.168.1.3 works: reply packets are 520 bytes long
> ping -s 513 192.168.1.3 doesn't work: wireshark reports reply packets are
> 60 bytes long
> ping -s 5 192.168.1.3 works; reply packets are 60 bytes long
>
> Any odd length above 17 doesn't work.
>
> Any clue as to why this is happening? Also it seems as though the USRP
> nominally uses packets that are even in length so this error wouldn't have
> come up before?
>
> Thanks,
> Hrishikesh Shelar
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141008/9087bef8/attachment-0001.html>
------------------------------
Message: 14
Date: Wed, 08 Oct 2014 22:32:24 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP x310 does not reply to IP packets of
odd length?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Hrishi,
you seem to be far more experienced in this matter than I could claim to
be, however I have one suspicion:
If I remember correctly, ICMP dictates that packets of odd length are
padded with a zero byte before checksum calculation.
And *if* I remember a discussion among students on a project correctly,
there are default implementations employing lwip (which happens to be
the IP stack on USRPs, at least on the N2x0 series) that simply "round
down" to the next multiple of 2, because no one ever uses odd packet
lengths...
Now, you would be seeing a broken package, unless your network card was
smart enough to offload ICMP checksum checking. Maybe that's a feature
you can disable?
Greetings,
Marcus
On 08.10.2014 21:05, Hrishikesh Shelar via USRP-users wrote:
> Sorry I misspoke.
>
> For the 513 length ping packets the 60 byte reply seen on wireshark wasn't
> a reply to the ping, it was an ICMP information request which the USRP does
> nominally. So essentially there was no reply.
>
> Thanks again,
> Hrishi
>
> On Wed, Oct 8, 2014 at 11:45 AM, Hrishikesh Shelar <[email protected]>
> wrote:
>
>> Hey all,
>>
>> I was observing some weird behavior while testing out transfer of IP
>> packets to and from the USRP. It seems as though the USRP can't correctly
>> parse packets that are odd in length. I was seeing odd length packets leave
>> my machine (using wireshark) but failed to see my custom USRP logic react
>> accordingly. Everything works if packets are even in length. At first I
>> thought it was a problem with my logic but I ran extensive testbenches and
>> couldn't pinpoint the error. So I decided to the USRP itself without my
>> logic in it and observed the same behavior. Using wireshark to sniff the
>> packets here is what I observed: (my USRP IP is 192.168.1.3)
>>
>> From a Windows terminal
>>
>> ping 192.168.1.3 works
>> ping -l 512 192.168.1.3 works; reply packets are also 512 bytes long
>> ping -l 513 192.168.1.3 doesn't work: wireshark reports reply packets are
>> 60 bytes long
>> ping -l 5 192.168.1.3 doesn't work: wireshark reports reply packets are 60
>> bytes long
>>
>> Any odd length doesn't work.
>>
>> From a Linux terminal
>>
>> ping 192.168.1.3 works
>> ping -s 512 192.168.1.3 works: reply packets are 520 bytes long
>> ping -s 513 192.168.1.3 doesn't work: wireshark reports reply packets are
>> 60 bytes long
>> ping -s 5 192.168.1.3 works; reply packets are 60 bytes long
>>
>> Any odd length above 17 doesn't work.
>>
>> Any clue as to why this is happening? Also it seems as though the USRP
>> nominally uses packets that are even in length so this error wouldn't have
>> come up before?
>>
>> Thanks,
>> Hrishikesh Shelar
>>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141008/eefb3b42/attachment-0001.html>
------------------------------
Message: 15
Date: Wed, 8 Oct 2014 23:44:41 +0200
From: Rickard Radio <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] TX and RX paths sharing a coherent LO
Message-ID:
<calycml6mp3vzusspn9b2dmp_mdythv_u8s2a8tfaw5yu5xs...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
OK, interesting.
Is it the exact same situation with two (or more) different transmitters
like TX1-TX2 as you explained here with TX-RX, namely that each path always
have physically different LO's but they are generated from the same 10MHz
reference?
Or can TX1-TX2 (or RX1-RX2) indeed use physically the same LO (i.e. with
same phase noise)? Or is that impossible too?
That is, is there any difference with synched TX-RX compared to synched
TX1-TX2 (or RX1-RX2)?
The thing is that in my experiment I preferably would like to use
physically the same LO for all RX's and TX's (i.e., with exactly the same
frequency and jitter etc.) but perhaps I need to resort to synched, but
still ever so slightly different, LO's for each path.
Regards,
Rickard
On Wed, Oct 8, 2014 at 7:19 PM, Marcus M?ller <[email protected]>
wrote:
> No, the LOs used for mixing are individually generated from the same
> 10MHz reference; they thus don't drift away from each other, but they don't
> share the same jitter etc. However, the Ettus daughterboards usually use
> rather decent synths, and thus the LO quality should be dominated by the
> quality of the reference clock -- which again, is quite ok, for most
> applications, and can be further optimized by GPS-disciplining the
> reference.
>
> Usually, that's how close you can get to shared LO if you want independent
> TX and RX mixers.
>
> Greetings,
> Marcus
>
>
> On 08.10.2014 19:04, Rickard Radio via USRP-users wrote:
>
> Sounds good!
>
> Does this mean it really shares the same LO, i.e., also with the same and
> uniquely occurring phase noise shared to all paths?! (I want that!)
>
> Regards,
> Rickard
>
>
>
> On Wed, Oct 8, 2014 at 6:54 PM, Marcus M?ller <[email protected]>
> <[email protected]>
> wrote:
>
>
> Hi Rickard,
>
> all the LOs are synthesized from the same motherboard reference, so Q1 is
> answered with "you get that for free".
> Q2 is "yes".
> Q3 gets the answer "if you want to use definite times when sampling, use
> the timed commands feature of UHD".
> :)
>
> Greetings,
> Marcus
>
> On 08.10.2014 18:48, Rickard Radio via USRP-users wrote:
>
> Dear usrp-users,
>
> I am interested in coherently LO-mixing different TX and RX paths for some
> experiments.
>
> Q1: Which options exist to use the same(?) coherent(!) LO for different TX
> and RX paths on the USRPs (N210 and/or B210)?
> Q2: Related, with the N210s and the MIMO cable, can I obtain and use a
> coherently shared LO for different TX and RX paths?
> Q3: Follow up - do I need something else or in addition ?
>
> Regards,
> Rickard
>
>
>
>
> ______________________________
> _________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141008/6f9ec010/attachment-0001.html>
------------------------------
Message: 16
Date: Wed, 8 Oct 2014 14:53:06 -0700
From: Hrishikesh Shelar <[email protected]>
To: "[email protected]" <[email protected]>,
[email protected]
Subject: Re: [USRP-users] USRP x310 does not reply to IP packets of
odd length?
Message-ID:
<CACM6M_en=7bzmp0n6ygz2dtwnnn0eaof8y3859u+p-s_cap...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Marcus,
Thanks! This definitely helps me in my debugging process. I found this
article
http://www.cisco.com/c/en/us/support/docs/field-notices/610/fn61087.html
that describes my problem exactly. Also the USRP uses a GMII interface
right? (looking at the source code) I think I have to sniff some more to
see if that pad byte is being sent or not from my end and change/configure
my NIC accordingly. Is it safe to assume then that the USRP cannot decode
odd length packets and expects even length packets?
Thanks again,
Hrishi
-----------------
Hi Hrishi,
you seem to be far more experienced in this matter than I could claim to
be, however I have one suspicion:
If I remember correctly, ICMP dictates that packets of odd length are
padded with a zero byte before checksum calculation.
And *if* I remember a discussion among students on a project correctly,
there are default implementations employing lwip (which happens to be
the IP stack on USRPs, at least on the N2x0 series) that simply "round
down" to the next multiple of 2, because no one ever uses odd packet
lengths...
Now, you would be seeing a broken package, unless your network card was
smart enough to offload ICMP checksum checking. Maybe that's a feature
you can disable?
Greetings,
Marcus
On Wed, Oct 8, 2014 at 12:05 PM, Hrishikesh Shelar <[email protected]>
wrote:
> Sorry I misspoke.
>
> For the 513 length ping packets the 60 byte reply seen on wireshark wasn't
> a reply to the ping, it was an ICMP information request which the USRP does
> nominally. So essentially there was no reply.
>
> Thanks again,
> Hrishi
>
> On Wed, Oct 8, 2014 at 11:45 AM, Hrishikesh Shelar <[email protected]>
> wrote:
>
>> Hey all,
>>
>> I was observing some weird behavior while testing out transfer of IP
>> packets to and from the USRP. It seems as though the USRP can't correctly
>> parse packets that are odd in length. I was seeing odd length packets leave
>> my machine (using wireshark) but failed to see my custom USRP logic react
>> accordingly. Everything works if packets are even in length. At first I
>> thought it was a problem with my logic but I ran extensive testbenches and
>> couldn't pinpoint the error. So I decided to the USRP itself without my
>> logic in it and observed the same behavior. Using wireshark to sniff the
>> packets here is what I observed: (my USRP IP is 192.168.1.3)
>>
>> From a Windows terminal
>>
>> ping 192.168.1.3 works
>> ping -l 512 192.168.1.3 works; reply packets are also 512 bytes long
>> ping -l 513 192.168.1.3 doesn't work: wireshark reports reply packets are
>> 60 bytes long
>> ping -l 5 192.168.1.3 doesn't work: wireshark reports reply packets are
>> 60 bytes long
>>
>> Any odd length doesn't work.
>>
>> From a Linux terminal
>>
>> ping 192.168.1.3 works
>> ping -s 512 192.168.1.3 works: reply packets are 520 bytes long
>> ping -s 513 192.168.1.3 doesn't work: wireshark reports reply packets are
>> 60 bytes long
>> ping -s 5 192.168.1.3 works; reply packets are 60 bytes long
>>
>> Any odd length above 17 doesn't work.
>>
>> Any clue as to why this is happening? Also it seems as though the USRP
>> nominally uses packets that are even in length so this error wouldn't have
>> come up before?
>>
>> Thanks,
>> Hrishikesh Shelar
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141008/054868f9/attachment-0001.html>
------------------------------
Message: 17
Date: Wed, 8 Oct 2014 14:57:01 -0700
From: Matt Ettus <[email protected]>
To: Hrishikesh Shelar <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP x310 does not reply to IP packets of
odd length?
Message-ID:
<CAN=1kn86pwt5usdu1wdq6of-x1ncewrokoaboxkwgdnmpaa...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
The USRP should be able to deal with odd length packets, but this is a
capability which is almost never used. Which USRP are you using?
Matt
On Wed, Oct 8, 2014 at 2:53 PM, Hrishikesh Shelar via USRP-users <
[email protected]> wrote:
> Hi Marcus,
>
> Thanks! This definitely helps me in my debugging process. I found this
> article
> http://www.cisco.com/c/en/us/support/docs/field-notices/610/fn61087.html
> that describes my problem exactly. Also the USRP uses a GMII interface
> right? (looking at the source code) I think I have to sniff some more to
> see if that pad byte is being sent or not from my end and change/configure
> my NIC accordingly. Is it safe to assume then that the USRP cannot decode
> odd length packets and expects even length packets?
>
> Thanks again,
> Hrishi
>
> -----------------
>
> Hi Hrishi,
>
> you seem to be far more experienced in this matter than I could claim to
> be, however I have one suspicion:
> If I remember correctly, ICMP dictates that packets of odd length are
> padded with a zero byte before checksum calculation.
> And *if* I remember a discussion among students on a project correctly,
> there are default implementations employing lwip (which happens to be
> the IP stack on USRPs, at least on the N2x0 series) that simply "round
> down" to the next multiple of 2, because no one ever uses odd packet
> lengths...
>
> Now, you would be seeing a broken package, unless your network card was
> smart enough to offload ICMP checksum checking. Maybe that's a feature
> you can disable?
>
> Greetings,
> Marcus
>
>
> On Wed, Oct 8, 2014 at 12:05 PM, Hrishikesh Shelar <[email protected]>
> wrote:
>
>> Sorry I misspoke.
>>
>> For the 513 length ping packets the 60 byte reply seen on wireshark
>> wasn't a reply to the ping, it was an ICMP information request which the
>> USRP does nominally. So essentially there was no reply.
>>
>> Thanks again,
>> Hrishi
>>
>> On Wed, Oct 8, 2014 at 11:45 AM, Hrishikesh Shelar <[email protected]>
>> wrote:
>>
>>> Hey all,
>>>
>>> I was observing some weird behavior while testing out transfer of IP
>>> packets to and from the USRP. It seems as though the USRP can't correctly
>>> parse packets that are odd in length. I was seeing odd length packets leave
>>> my machine (using wireshark) but failed to see my custom USRP logic react
>>> accordingly. Everything works if packets are even in length. At first I
>>> thought it was a problem with my logic but I ran extensive testbenches and
>>> couldn't pinpoint the error. So I decided to the USRP itself without my
>>> logic in it and observed the same behavior. Using wireshark to sniff the
>>> packets here is what I observed: (my USRP IP is 192.168.1.3)
>>>
>>> From a Windows terminal
>>>
>>> ping 192.168.1.3 works
>>> ping -l 512 192.168.1.3 works; reply packets are also 512 bytes long
>>> ping -l 513 192.168.1.3 doesn't work: wireshark reports reply packets
>>> are 60 bytes long
>>> ping -l 5 192.168.1.3 doesn't work: wireshark reports reply packets are
>>> 60 bytes long
>>>
>>> Any odd length doesn't work.
>>>
>>> From a Linux terminal
>>>
>>> ping 192.168.1.3 works
>>> ping -s 512 192.168.1.3 works: reply packets are 520 bytes long
>>> ping -s 513 192.168.1.3 doesn't work: wireshark reports reply packets
>>> are 60 bytes long
>>> ping -s 5 192.168.1.3 works; reply packets are 60 bytes long
>>>
>>> Any odd length above 17 doesn't work.
>>>
>>> Any clue as to why this is happening? Also it seems as though the USRP
>>> nominally uses packets that are even in length so this error wouldn't have
>>> come up before?
>>>
>>> Thanks,
>>> Hrishikesh Shelar
>>>
>>
>>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141008/24c578b2/attachment-0001.html>
------------------------------
Message: 18
Date: Wed, 8 Oct 2014 15:05:51 -0700
From: Balint Seeber <[email protected]>
To: "Ralph A. Schmid, dk5ras" <[email protected]>
Cc: "[email protected]" <[email protected]>,
"Garver, Paul W" <[email protected]>
Subject: Re: [USRP-users] [UHD 3.7.3] Release Announcement
Message-ID:
<capcb_2pmuyww_6-sb8s0ogb2fs5hcsbsa1b7xkkdrkkh6nl...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Ralph,
With 'master' UHD, please load the attached FW onto your device using
uhd_find_devices --args="fw=<path to .hex>"
And then run 'b2x0_side_channel.py' inside the attached tarball.
Make a note of the following counter values in your output:
phy_error_count: 00214 link_error_count: 00000 PHY_LOCK_EV:
00000 TRAINING_ERROR_EV: 00000 RX_ERROR_CRC32_EV: 00000
RX_ERROR_CRC16_EV: 00000 RX_ERROR_CRC5_EV: 00000
PHY_ERROR_DISPARITY_EV: 00000 PHY_ERROR_EB_UND_EV: 00001
PHY_ERROR_EB_OVR_EV: 00000 PHY_ERROR_DECODE_EV: 00001
Some will be non-zero, which is fine (e.g. phy_error_count).* You can
ignore the "usb_error_update_count" value.*
Then in another console, run whichever apps tend to cause the issue to
manifest itself, and keep an eye on those counters. If any of them go up
dramatically, that's a clue.
Thanks,
Balint
On Wed, Oct 8, 2014 at 11:48 AM, Ralph A. Schmid, dk5ras via USRP-users <
[email protected]> wrote:
> Hi,
>
> > On a side note, I have the suspicion that when people are talking about
> 'this issue', it's not always the same one. We really appreciate
>
> This is also my guess. It seems I have two issues here, one general
> virtual machine issue that has nothing to do with the uhd version, but just
> with getting somehow out of sync in USB communication from other activity
> on the system. From this the system can recover, with openbts even
> automatically by restarting the service. The other issue with to me
> identical looking signs is uhd version dependent and happens even when the
> machine is idle and the vmware stuff does not slow down USB transfers.
>
> > all bug reports, but please, if something fails, give us as much detail
> as possible, even if repeating information.
> >
> > Thanks,
> > Martin
>
> Ralph.
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141008/d47b3102/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: usrp_b200_fw.hex
Type: application/octet-stream
Size: 471937 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141008/d47b3102/attachment-0001.hex>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: b2x0-side_channel.tar.bz2
Type: application/x-bzip2
Size: 54064 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141008/d47b3102/attachment-0001.bz2>
------------------------------
Message: 19
Date: Wed, 8 Oct 2014 15:09:07 -0700
From: Hrishikesh Shelar <[email protected]>
To: Matt Ettus <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP x310 does not reply to IP packets of
odd length?
Message-ID:
<cacm6m_dz9eyvwepgelpjyaznp8whh-7nd9yvfohhmh7a_c1...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Matt,
I'm using the x310. My logic reacts to ip packets destined to address X. I
can see it react to even length packets but not to odd length packets.
They don't seem to come out from the simple_gemac.
Thanks,
Hrishi
On Wednesday, October 8, 2014, Matt Ettus <[email protected]> wrote:
>
> The USRP should be able to deal with odd length packets, but this is a
> capability which is almost never used. Which USRP are you using?
>
> Matt
>
> On Wed, Oct 8, 2014 at 2:53 PM, Hrishikesh Shelar via USRP-users <
> [email protected]
> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote:
>
>> Hi Marcus,
>>
>> Thanks! This definitely helps me in my debugging process. I found this
>> article
>> http://www.cisco.com/c/en/us/support/docs/field-notices/610/fn61087.html
>> that describes my problem exactly. Also the USRP uses a GMII interface
>> right? (looking at the source code) I think I have to sniff some more to
>> see if that pad byte is being sent or not from my end and change/configure
>> my NIC accordingly. Is it safe to assume then that the USRP cannot decode
>> odd length packets and expects even length packets?
>>
>> Thanks again,
>> Hrishi
>>
>> -----------------
>>
>> Hi Hrishi,
>>
>> you seem to be far more experienced in this matter than I could claim to
>> be, however I have one suspicion:
>> If I remember correctly, ICMP dictates that packets of odd length are
>> padded with a zero byte before checksum calculation.
>> And *if* I remember a discussion among students on a project correctly,
>> there are default implementations employing lwip (which happens to be
>> the IP stack on USRPs, at least on the N2x0 series) that simply "round
>> down" to the next multiple of 2, because no one ever uses odd packet
>> lengths...
>>
>> Now, you would be seeing a broken package, unless your network card was
>> smart enough to offload ICMP checksum checking. Maybe that's a feature
>> you can disable?
>>
>> Greetings,
>> Marcus
>>
>>
>> On Wed, Oct 8, 2014 at 12:05 PM, Hrishikesh Shelar <[email protected]
>> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote:
>>
>>> Sorry I misspoke.
>>>
>>> For the 513 length ping packets the 60 byte reply seen on wireshark
>>> wasn't a reply to the ping, it was an ICMP information request which the
>>> USRP does nominally. So essentially there was no reply.
>>>
>>> Thanks again,
>>> Hrishi
>>>
>>> On Wed, Oct 8, 2014 at 11:45 AM, Hrishikesh Shelar <[email protected]
>>> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote:
>>>
>>>> Hey all,
>>>>
>>>> I was observing some weird behavior while testing out transfer of IP
>>>> packets to and from the USRP. It seems as though the USRP can't correctly
>>>> parse packets that are odd in length. I was seeing odd length packets leave
>>>> my machine (using wireshark) but failed to see my custom USRP logic react
>>>> accordingly. Everything works if packets are even in length. At first I
>>>> thought it was a problem with my logic but I ran extensive testbenches and
>>>> couldn't pinpoint the error. So I decided to the USRP itself without my
>>>> logic in it and observed the same behavior. Using wireshark to sniff the
>>>> packets here is what I observed: (my USRP IP is 192.168.1.3)
>>>>
>>>> From a Windows terminal
>>>>
>>>> ping 192.168.1.3 works
>>>> ping -l 512 192.168.1.3 works; reply packets are also 512 bytes long
>>>> ping -l 513 192.168.1.3 doesn't work: wireshark reports reply packets
>>>> are 60 bytes long
>>>> ping -l 5 192.168.1.3 doesn't work: wireshark reports reply packets are
>>>> 60 bytes long
>>>>
>>>> Any odd length doesn't work.
>>>>
>>>> From a Linux terminal
>>>>
>>>> ping 192.168.1.3 works
>>>> ping -s 512 192.168.1.3 works: reply packets are 520 bytes long
>>>> ping -s 513 192.168.1.3 doesn't work: wireshark reports reply packets
>>>> are 60 bytes long
>>>> ping -s 5 192.168.1.3 works; reply packets are 60 bytes long
>>>>
>>>> Any odd length above 17 doesn't work.
>>>>
>>>> Any clue as to why this is happening? Also it seems as though the USRP
>>>> nominally uses packets that are even in length so this error wouldn't have
>>>> come up before?
>>>>
>>>> Thanks,
>>>> Hrishikesh Shelar
>>>>
>>>
>>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> <javascript:_e(%7B%7D,'cvml','[email protected]');>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
--
Sent from GMail Mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141008/cd88ca1c/attachment-0001.html>
------------------------------
Message: 20
Date: Wed, 8 Oct 2014 15:30:11 -0700
From: Matt Ettus <[email protected]>
To: Hrishikesh Shelar <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP x310 does not reply to IP packets of
odd length?
Message-ID:
<CAN=1kn_rGyXPFKXDQpf19R+2suR8aZLAfAfj5uPEpAg=idz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
And you are using it with 1G ethernet?
On Wed, Oct 8, 2014 at 3:09 PM, Hrishikesh Shelar <[email protected]> wrote:
> Hi Matt,
>
> I'm using the x310. My logic reacts to ip packets destined to address X. I
> can see it react to even length packets but not to odd length packets.
> They don't seem to come out from the simple_gemac.
>
> Thanks,
> Hrishi
>
>
> On Wednesday, October 8, 2014, Matt Ettus <[email protected]> wrote:
>
>>
>> The USRP should be able to deal with odd length packets, but this is a
>> capability which is almost never used. Which USRP are you using?
>>
>> Matt
>>
>> On Wed, Oct 8, 2014 at 2:53 PM, Hrishikesh Shelar via USRP-users <
>> [email protected]> wrote:
>>
>>> Hi Marcus,
>>>
>>> Thanks! This definitely helps me in my debugging process. I found this
>>> article
>>> http://www.cisco.com/c/en/us/support/docs/field-notices/610/fn61087.html
>>> that describes my problem exactly. Also the USRP uses a GMII interface
>>> right? (looking at the source code) I think I have to sniff some more to
>>> see if that pad byte is being sent or not from my end and change/configure
>>> my NIC accordingly. Is it safe to assume then that the USRP cannot decode
>>> odd length packets and expects even length packets?
>>>
>>> Thanks again,
>>> Hrishi
>>>
>>> -----------------
>>>
>>> Hi Hrishi,
>>>
>>> you seem to be far more experienced in this matter than I could claim to
>>> be, however I have one suspicion:
>>> If I remember correctly, ICMP dictates that packets of odd length are
>>> padded with a zero byte before checksum calculation.
>>> And *if* I remember a discussion among students on a project correctly,
>>> there are default implementations employing lwip (which happens to be
>>> the IP stack on USRPs, at least on the N2x0 series) that simply "round
>>> down" to the next multiple of 2, because no one ever uses odd packet
>>> lengths...
>>>
>>> Now, you would be seeing a broken package, unless your network card was
>>> smart enough to offload ICMP checksum checking. Maybe that's a feature
>>> you can disable?
>>>
>>> Greetings,
>>> Marcus
>>>
>>>
>>> On Wed, Oct 8, 2014 at 12:05 PM, Hrishikesh Shelar <[email protected]>
>>> wrote:
>>>
>>>> Sorry I misspoke.
>>>>
>>>> For the 513 length ping packets the 60 byte reply seen on wireshark
>>>> wasn't a reply to the ping, it was an ICMP information request which the
>>>> USRP does nominally. So essentially there was no reply.
>>>>
>>>> Thanks again,
>>>> Hrishi
>>>>
>>>> On Wed, Oct 8, 2014 at 11:45 AM, Hrishikesh Shelar <[email protected]>
>>>> wrote:
>>>>
>>>>> Hey all,
>>>>>
>>>>> I was observing some weird behavior while testing out transfer of IP
>>>>> packets to and from the USRP. It seems as though the USRP can't correctly
>>>>> parse packets that are odd in length. I was seeing odd length packets
>>>>> leave
>>>>> my machine (using wireshark) but failed to see my custom USRP logic react
>>>>> accordingly. Everything works if packets are even in length. At first I
>>>>> thought it was a problem with my logic but I ran extensive testbenches and
>>>>> couldn't pinpoint the error. So I decided to the USRP itself without my
>>>>> logic in it and observed the same behavior. Using wireshark to sniff the
>>>>> packets here is what I observed: (my USRP IP is 192.168.1.3)
>>>>>
>>>>> From a Windows terminal
>>>>>
>>>>> ping 192.168.1.3 works
>>>>> ping -l 512 192.168.1.3 works; reply packets are also 512 bytes long
>>>>> ping -l 513 192.168.1.3 doesn't work: wireshark reports reply packets
>>>>> are 60 bytes long
>>>>> ping -l 5 192.168.1.3 doesn't work: wireshark reports reply packets
>>>>> are 60 bytes long
>>>>>
>>>>> Any odd length doesn't work.
>>>>>
>>>>> From a Linux terminal
>>>>>
>>>>> ping 192.168.1.3 works
>>>>> ping -s 512 192.168.1.3 works: reply packets are 520 bytes long
>>>>> ping -s 513 192.168.1.3 doesn't work: wireshark reports reply packets
>>>>> are 60 bytes long
>>>>> ping -s 5 192.168.1.3 works; reply packets are 60 bytes long
>>>>>
>>>>> Any odd length above 17 doesn't work.
>>>>>
>>>>> Any clue as to why this is happening? Also it seems as though the USRP
>>>>> nominally uses packets that are even in length so this error wouldn't have
>>>>> come up before?
>>>>>
>>>>> Thanks,
>>>>> Hrishikesh Shelar
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>
> --
> Sent from GMail Mobile
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141008/426bc1d9/attachment-0001.html>
------------------------------
Message: 21
Date: Wed, 8 Oct 2014 15:33:55 -0700
From: Hrishikesh Shelar <[email protected]>
To: Matt Ettus <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP x310 does not reply to IP packets of
odd length?
Message-ID:
<CACM6M_e2-f31xStV+tbbHe=9anketrwwbzcq4frwcg-hkyx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Yes, 1G on the primary ethernet interface.
-Hrishi
On Wed, Oct 8, 2014 at 3:30 PM, Matt Ettus <[email protected]> wrote:
>
> And you are using it with 1G ethernet?
>
> On Wed, Oct 8, 2014 at 3:09 PM, Hrishikesh Shelar <[email protected]>
> wrote:
>
>> Hi Matt,
>>
>> I'm using the x310. My logic reacts to ip packets destined to address X.
>> I can see it react to even length packets but not to odd length packets.
>> They don't seem to come out from the simple_gemac.
>>
>> Thanks,
>> Hrishi
>>
>>
>> On Wednesday, October 8, 2014, Matt Ettus <[email protected]> wrote:
>>
>>>
>>> The USRP should be able to deal with odd length packets, but this is a
>>> capability which is almost never used. Which USRP are you using?
>>>
>>> Matt
>>>
>>> On Wed, Oct 8, 2014 at 2:53 PM, Hrishikesh Shelar via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> Hi Marcus,
>>>>
>>>> Thanks! This definitely helps me in my debugging process. I found this
>>>> article
>>>> http://www.cisco.com/c/en/us/support/docs/field-notices/610/fn61087.html
>>>> that describes my problem exactly. Also the USRP uses a GMII interface
>>>> right? (looking at the source code) I think I have to sniff some more to
>>>> see if that pad byte is being sent or not from my end and change/configure
>>>> my NIC accordingly. Is it safe to assume then that the USRP cannot decode
>>>> odd length packets and expects even length packets?
>>>>
>>>> Thanks again,
>>>> Hrishi
>>>>
>>>> -----------------
>>>>
>>>> Hi Hrishi,
>>>>
>>>> you seem to be far more experienced in this matter than I could claim to
>>>> be, however I have one suspicion:
>>>> If I remember correctly, ICMP dictates that packets of odd length are
>>>> padded with a zero byte before checksum calculation.
>>>> And *if* I remember a discussion among students on a project correctly,
>>>> there are default implementations employing lwip (which happens to be
>>>> the IP stack on USRPs, at least on the N2x0 series) that simply "round
>>>> down" to the next multiple of 2, because no one ever uses odd packet
>>>> lengths...
>>>>
>>>> Now, you would be seeing a broken package, unless your network card was
>>>> smart enough to offload ICMP checksum checking. Maybe that's a feature
>>>> you can disable?
>>>>
>>>> Greetings,
>>>> Marcus
>>>>
>>>>
>>>> On Wed, Oct 8, 2014 at 12:05 PM, Hrishikesh Shelar <[email protected]>
>>>> wrote:
>>>>
>>>>> Sorry I misspoke.
>>>>>
>>>>> For the 513 length ping packets the 60 byte reply seen on wireshark
>>>>> wasn't a reply to the ping, it was an ICMP information request which the
>>>>> USRP does nominally. So essentially there was no reply.
>>>>>
>>>>> Thanks again,
>>>>> Hrishi
>>>>>
>>>>> On Wed, Oct 8, 2014 at 11:45 AM, Hrishikesh Shelar <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Hey all,
>>>>>>
>>>>>> I was observing some weird behavior while testing out transfer of IP
>>>>>> packets to and from the USRP. It seems as though the USRP can't correctly
>>>>>> parse packets that are odd in length. I was seeing odd length packets
>>>>>> leave
>>>>>> my machine (using wireshark) but failed to see my custom USRP logic react
>>>>>> accordingly. Everything works if packets are even in length. At first I
>>>>>> thought it was a problem with my logic but I ran extensive testbenches
>>>>>> and
>>>>>> couldn't pinpoint the error. So I decided to the USRP itself without my
>>>>>> logic in it and observed the same behavior. Using wireshark to sniff the
>>>>>> packets here is what I observed: (my USRP IP is 192.168.1.3)
>>>>>>
>>>>>> From a Windows terminal
>>>>>>
>>>>>> ping 192.168.1.3 works
>>>>>> ping -l 512 192.168.1.3 works; reply packets are also 512 bytes long
>>>>>> ping -l 513 192.168.1.3 doesn't work: wireshark reports reply packets
>>>>>> are 60 bytes long
>>>>>> ping -l 5 192.168.1.3 doesn't work: wireshark reports reply packets
>>>>>> are 60 bytes long
>>>>>>
>>>>>> Any odd length doesn't work.
>>>>>>
>>>>>> From a Linux terminal
>>>>>>
>>>>>> ping 192.168.1.3 works
>>>>>> ping -s 512 192.168.1.3 works: reply packets are 520 bytes long
>>>>>> ping -s 513 192.168.1.3 doesn't work: wireshark reports reply packets
>>>>>> are 60 bytes long
>>>>>> ping -s 5 192.168.1.3 works; reply packets are 60 bytes long
>>>>>>
>>>>>> Any odd length above 17 doesn't work.
>>>>>>
>>>>>> Any clue as to why this is happening? Also it seems as though the
>>>>>> USRP nominally uses packets that are even in length so this error
>>>>>> wouldn't
>>>>>> have come up before?
>>>>>>
>>>>>> Thanks,
>>>>>> Hrishikesh Shelar
>>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>
>>
>> --
>> Sent from GMail Mobile
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141008/4684b91d/attachment-0001.html>
------------------------------
Message: 22
Date: Thu, 9 Oct 2014 08:35:43 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: "'Balint Seeber'" <[email protected]>
Cc: [email protected], "'Garver, Paul W'"
<[email protected]>
Subject: Re: [USRP-users] [UHD 3.7.3] Release Announcement
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Balint,
Thank you for the file and the instructions. This morning I already changed to
master, downloaded the images and recompiled the most important programs that
link to uhd, maybe during lunch break I will find some time and try out your
suggestions.
Ralph.
From: Balint Seeber [mailto:[email protected]]
Sent: Thursday, October 9, 2014 12:06 AM
To: Ralph A. Schmid, dk5ras
Cc: Martin Braun; Garver, Paul W; [email protected]
Subject: Re: [USRP-users] [UHD 3.7.3] Release Announcement
Hi Ralph,
With 'master' UHD, please load the attached FW onto your device using
uhd_find_devices --args="fw=<path to .hex>"
And then run 'b2x0_side_channel.py' inside the attached tarball.
Make a note of the following counter values in your output:
phy_error_count: 00214 link_error_count: 00000 PHY_LOCK_EV: 00000
TRAINING_ERROR_EV: 00000 RX_ERROR_CRC32_EV: 00000 RX_ERROR_CRC16_EV:
00000 RX_ERROR_CRC5_EV: 00000 PHY_ERROR_DISPARITY_EV: 00000
PHY_ERROR_EB_UND_EV: 00001 PHY_ERROR_EB_OVR_EV: 00000
PHY_ERROR_DECODE_EV: 00001
Some will be non-zero, which is fine (e.g. phy_error_count). You can ignore the
"usb_error_update_count" value.
Then in another console, run whichever apps tend to cause the issue to manifest
itself, and keep an eye on those counters. If any of them go up dramatically,
that's a clue.
Thanks,
Balint
On Wed, Oct 8, 2014 at 11:48 AM, Ralph A. Schmid, dk5ras via USRP-users
<[email protected] <mailto:[email protected]> > wrote:
Hi,
> On a side note, I have the suspicion that when people are talking about 'this
> issue', it's not always the same one. We really appreciate
This is also my guess. It seems I have two issues here, one general virtual
machine issue that has nothing to do with the uhd version, but just with
getting somehow out of sync in USB communication from other activity on the
system. From this the system can recover, with openbts even automatically by
restarting the service. The other issue with to me identical looking signs is
uhd version dependent and happens even when the machine is idle and the vmware
stuff does not slow down USB transfers.
> all bug reports, but please, if something fails, give us as much detail as
> possible, even if repeating information.
>
> Thanks,
> Martin
Ralph.
_______________________________________________
USRP-users mailing list
[email protected] <mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141009/1712d898/attachment-0001.html>
------------------------------
Message: 23
Date: Thu, 9 Oct 2014 12:43:16 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: "'Balint Seeber'" <[email protected]>
Cc: [email protected], "'Garver, Paul W'"
<[email protected]>
Subject: Re: [USRP-users] [UHD 3.7.3] Release Announcement
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
This is the last output before gqrx stalled, showing 32 MHz of bandwidth:
[00026 00006] 0001D4D3 0026 Keep-alive
[00019]
magic: 268582913
XFER_CPLT: 00000 SEND_CPLT: 00000 RECV_CPLT: 00000
PROD_EVENT: 00000 CONS_EVENT: 00000 ABORTED: 00000 ERROR: 00000
PROD_SUSP: 00000 CONS_SUSP: 00000 BUFFER_MARKER: 00000 BUFFER_EOP:
00000 BUFFER_ERROR: 00000 BUFFER_OCCUPIED: 00000 last_count: 00000
last_size: 00000 last_sid: 00000 bad_sid_count: 00000
XFER_CPLT: 00000 SEND_CPLT: 00000 RECV_CPLT: 00000
PROD_EVENT: 00000 CONS_EVENT: 00000 ABORTED: 00000 ERROR: 00000
PROD_SUSP: 00000 CONS_SUSP: 00000 BUFFER_MARKER: 00000 BUFFER_EOP:
00000 BUFFER_ERROR: 00000 BUFFER_OCCUPIED: 00000 last_count: 00000
last_size: 00000 last_sid: 00000 bad_sid_count: 00000
log_overrun_count: 00000 usb_error_update_count: 01243
phy_error_count: 01104 link_error_count: 00000 PHY_LOCK_EV: 00000
TRAINING_ERROR_EV: 00000 RX_ERROR_CRC32_EV: 00000 RX_ERROR_CRC16_EV:
00000RX_ERROR_CRC5_EV: 00000 PHY_ERROR_DISPARITY_EV: 00000
PHY_ERROR_EB_UND_EV: 00002 PHY_ERROR_EB_OVR_EV: 00001
PHY_ERROR_DECODE_EV: 00003
usb_ep_underrun_count: 00000 heap_size: 00000 resume_count: 00000
Master built from sources, images downloaded with the image downloader, copying
the firmware file over the original one in the /usr/local/share/blah path,
initializing the B210 with a uhd_usrp_probe, starting your script, watching it
for a short while, starting gqrx, going for a cup of tea, and when back seeing
the stalled software and the above output.
Does it tell you anything?
With best regards
Ralph.
From: Balint Seeber [mailto:[email protected]]
Sent: Thursday, 9 October, 2014 00:06
To: Ralph A. Schmid, dk5ras
Cc: Martin Braun; Garver, Paul W; [email protected]
Subject: Re: [USRP-users] [UHD 3.7.3] Release Announcement
Hi Ralph,
With 'master' UHD, please load the attached FW onto your device using
uhd_find_devices --args="fw=<path to .hex>"
And then run 'b2x0_side_channel.py' inside the attached tarball.
Make a note of the following counter values in your output:
phy_error_count: 00214 link_error_count: 00000 PHY_LOCK_EV: 00000
TRAINING_ERROR_EV: 00000 RX_ERROR_CRC32_EV: 00000 RX_ERROR_CRC16_EV:
00000 RX_ERROR_CRC5_EV: 00000 PHY_ERROR_DISPARITY_EV: 00000
PHY_ERROR_EB_UND_EV: 00001 PHY_ERROR_EB_OVR_EV: 00000
PHY_ERROR_DECODE_EV: 00001
Some will be non-zero, which is fine (e.g. phy_error_count). You can ignore the
"usb_error_update_count" value.
Then in another console, run whichever apps tend to cause the issue to manifest
itself, and keep an eye on those counters. If any of them go up dramatically,
that's a clue.
Thanks,
Balint
On Wed, Oct 8, 2014 at 11:48 AM, Ralph A. Schmid, dk5ras via USRP-users
<[email protected]> wrote:
Hi,
> On a side note, I have the suspicion that when people are talking about 'this
> issue', it's not always the same one. We really appreciate
This is also my guess. It seems I have two issues here, one general virtual
machine issue that has nothing to do with the uhd version, but just with
getting somehow out of sync in USB communication from other activity on the
system. From this the system can recover, with openbts even automatically by
restarting the service. The other issue with to me identical looking signs is
uhd version dependent and happens even when the machine is idle and the vmware
stuff does not slow down USB transfers.
> all bug reports, but please, if something fails, give us as much detail as
> possible, even if repeating information.
>
> Thanks,
> Martin
Ralph.
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141009/3215fc85/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141009/3215fc85/attachment-0001.sig>
------------------------------
Message: 24
Date: Thu, 9 Oct 2014 11:31:03 +0000
From: Per Zetterberg <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] ATR registers
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Dear List,
I am trying to use the ATR registers with a basic daughterboard. I do:
db_iface->set_pin_ctrl(m_unit,mask_write,mask_write);
db_iface->set_atr_reg(m_unit,
uhd::usrp::dboard_iface::ATR_REG_IDLE,atr_rx,mask_write);
db_iface->set_atr_reg(m_unit,
uhd::usrp::dboard_iface::ATR_REG_TX_ONLY,atr_tx,mask_write);
db_iface->set_atr_reg(m_unit,
uhd::usrp::dboard_iface::ATR_REG_RX_ONLY,atr_rx,mask_write);
Upon writing these values the settings of ATR_REG_IDLE should immediately take
effect until we ask the USRP to send or receive samples. But this does not seem
to be the case. Am I making a mistake?
BR/
Per
------------------------------
Message: 25
Date: Thu, 9 Oct 2014 15:30:31 +0200
From: LEMENAGER Claude <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] X3X0 SBX corrupted samples?
Message-ID:
<28824_1412861434_54368dfa_28824_14_9_59957d668d245c4eb38e8f85c054e9010775fbe...@thsonea01cms09p.one.grp>
Content-Type: text/plain; charset="iso-8859-1"
Hello,
I sample at least two channels (SBX 120) from one or multiple X310 boards each
equipped with two SBX radio boards.
I uses NIUSRPRIO_PCIE==>UHD003.007.002 ==>Gnuradio 3.7.5 (built for this UHD
under UBUNTU 14.04LTS).
The input is connected to a CW generator. The channels definition is A:0 B:0,
antenna is RX2 in all cases.
The problems :
1) I receive a warning concerning lo_locked no locked after timeout for each
channel (I read a discuss where this fact was given)
2) When I connect the A:0 channel on a gnuradio scope, this seems OK (I and
Q parts). When I connect a B:0 channel (from any X310 board) I receive the CW
wave plus spurious (sort of dirac through a filter) generally starting on Q
channel but not only. This look like an erroneous sample (digitally speaking
for example just an incorrect bit in the LSBs) before DDC. The spurious looks
like periodic but the period seems to change with radio frequency (to confirm)
Did somebody encounters this problem?
If yes, is there a solution.
I plan to try to reproduce this (or to see if it's the same) with UHD directly
accessed BY a C++ application.
Regards,
Claude Lem?nager
P.S. Conclusion about preceding discussion (june) about PCIe interface: The HP
PC on which I made my firsts experiences was equipped with one of the first
generation PCIe chip. So it failed to interface with X310. I now uses a last
generation pc and then there is no problem except for what I mention above.
Thanks for support.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141009/306df66d/attachment-0001.html>
------------------------------
Message: 26
Date: Thu, 09 Oct 2014 15:38:35 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] X3X0 SBX corrupted samples?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hello Mr. Lem?nager,
the warning that the LO is not locked is severe in principle; are you
using an external reference clock?
Could you paste the complete warning?
At which frequencies are you working?
Greetings,
Marcus
On 09.10.2014 15:30, LEMENAGER Claude via USRP-users wrote:
> Hello,
>
> I sample at least two channels (SBX 120) from one or multiple X310 boards
> each equipped with two SBX radio boards.
> I uses NIUSRPRIO_PCIE==>UHD003.007.002 ==>Gnuradio 3.7.5 (built for this UHD
> under UBUNTU 14.04LTS).
> The input is connected to a CW generator. The channels definition is A:0 B:0,
> antenna is RX2 in all cases.
> The problems :
>
> 1) I receive a warning concerning lo_locked no locked after timeout for
> each channel (I read a discuss where this fact was given)
>
> 2) When I connect the A:0 channel on a gnuradio scope, this seems OK (I
> and Q parts). When I connect a B:0 channel (from any X310 board) I receive
> the CW wave plus spurious (sort of dirac through a filter) generally starting
> on Q channel but not only. This look like an erroneous sample (digitally
> speaking for example just an incorrect bit in the LSBs) before DDC. The
> spurious looks like periodic but the period seems to change with radio
> frequency (to confirm)
>
>
> Did somebody encounters this problem?
>
> If yes, is there a solution.
>
> I plan to try to reproduce this (or to see if it's the same) with UHD
> directly accessed BY a C++ application.
>
> Regards,
>
> Claude Lem?nager
>
> P.S. Conclusion about preceding discussion (june) about PCIe interface: The
> HP PC on which I made my firsts experiences was equipped with one of the
> first generation PCIe chip. So it failed to interface with X310. I now uses a
> last generation pc and then there is no problem except for what I mention
> above. Thanks for support.
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141009/3a6e6855/attachment-0001.html>
------------------------------
Message: 27
Date: Thu, 09 Oct 2014 16:48:05 +0200
From: Herv? BOEGLEN <[email protected]>
To: LEMENAGER Claude <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] X3X0 SBX corrupted samples?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Hello Claude,
I had the same type of problem with an X310 + 2 CBX boards (see my past
posts on the list). The received signal on channel B was always worse
than channel A. Indeed, on channel B the noise floor was 40 dB higher
than on channel A.
My problem was solved by upgrading to UHD 003.007.003 (+ new firmware
images). As Martin Braun mentioned, there were some bugs in the FPGA
code solved by this release (at least for my problem).
Concerning the LO locking, I have a GPSDO kit and get sometimes the
lo_locked not locked message but It happens in average once every 10 runs.
Best regards
Herv?
Le 09/10/2014 15:30, LEMENAGER Claude via USRP-users a ?crit :
>
> Hello,
>
> I sample at least two channels (SBX 120) from one or multiple X310
> boards each equipped with two SBX radio boards.
>
> I uses NIUSRPRIO_PCIE?UHD003.007.002 ?Gnuradio 3.7.5 (built for this
> UHD under UBUNTU 14.04LTS).
>
> The input is connected to a CW generator. The channels definition is
> A:0 B:0, antenna is RX2 in all cases.
>
> The problems :
>
> 1)I receive a warning concerning lo_locked no locked after timeout for
> each channel (I read a discuss where this fact was given)
>
> 2)When I connect the A:0 channel on a gnuradio scope, this seems OK (I
> and Q parts). When I connect a B:0 channel (from any X310 board) I
> receive the CW wave plus spurious (sort of dirac through a filter)
> generally starting on Q channel but not only. This look like an
> erroneous sample (digitally speaking for example just an incorrect bit
> in the LSBs) before DDC. The spurious looks like periodic but the
> period seems to change with radio frequency (to confirm)
>
> Did somebody encounters this problem?
>
> If yes, is there a solution.
>
> I plan to try to reproduce this (or to see if it's the same) with UHD
> directly accessed BY a C++ application.
>
> Regards,
>
> Claude Lem?nager
>
> P.S. Conclusion about preceding discussion (june) about PCIe
> interface: The HP PC on which I made my firsts experiences was
> equipped with one of the first generation PCIe chip. So it failed to
> interface with X310. I now uses a last generation pc and then there is
> no problem except for what I mention above. Thanks for support.
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141009/a861b94b/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 50, Issue 9
*****************************************
