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. GCC internal compiler fault when installing GNU-Radio
(Macre, William R)
2. Re: gain setting and clipping (Josh Blum)
3. Using multiple RX DDC chains on USRP2 (Roy Thompson)
4. Re: GCC internal compiler fault when installing GNU-Radio
(Philip Balister)
5. Re: Using multiple RX DDC chains on USRP2 (Josh Blum)
6. Re: Using multiple RX DDC chains on USRP2 (Roy Thompson)
7. Re: Using multiple RX DDC chains on USRP2 (Josh Blum)
8. Re: args field in uhd::tune_request_t (Josh Blum)
9. Re: Using 4 USRP with a Gigabit switch (Damien Serant)
10. SPI usage with lfrx db; (Furkan Elibol)
11. Re: SPI usage with lfrx db; (Per Zetterberg)
----------------------------------------------------------------------
Message: 1
Date: Thu, 7 Feb 2013 17:14:57 +0000
From: "Macre, William R" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] GCC internal compiler fault when installing
GNU-Radio
Message-ID:
<5e9bdf6832e57149b46d9becf6ab21510cef2...@rrc-ats-exmb2.ats.atsinnovate.com>
Content-Type: text/plain; charset="us-ascii"
The problem:
GCC internal compiler fault when installing GNU-Radio
What we need
-the exact version of GCC;
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/arm-angstrom-linux-gnueabi/4.5.3/lto-wrapper
Target: arm-angstrom-linux-gnueabi
Configured with:
/home/oe-classic/oe/build/tmp-angstrom_2010_x/work/armv7a-angstrom-linux-gnueabi/gcc-4.5-r38.1+svnr170880/gcc-4_5-branch/configure
--build=x86_64-linux --host=arm-angstrom-linux-gnueabi
--target=arm-angstrom-linux-gnueabi --prefix=/usr --exec_prefix=/usr
--bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/libexec
--datadir=/usr/share --sysconfdir=/etc --sharedstatedir=/com
--localstatedir=/var --libdir=/usr/lib --includedir=/usr/include
--oldincludedir=/usr/include --infodir=/usr/share/info --mandir=/usr/share/man
--with-libtool-sysroot=/home/oe-classic/oe/build/tmp-angstrom_2010_x/sysroots/armv7a-angstrom-linux-gnueabi
--enable-largefile --disable-nls --enable-ipv6 --with-gnu-ld --enable-shared
--enable-languages=c,c++,objc,fortran --enable-threads=posix --disable-multilib
--enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch
--program-prefix=arm-angstrom-linux-gnueabi- --enable-target-optspace
--enable-lto --enable-libssp --disable-bootstrap --disable-libgomp
--disable-libmudflap --with-float=softfp --with-local-prefix=/usr/local
--with-gxx-include-dir=/usr/include/c++/4.5.3
--with-build-sysroot=/home/oe-classic/oe/build/tmp-angstrom_2010_x/sysroots/armv7a-angstrom-linux-gnueabi
--enable-__cxa_atexit
Thread model: posix
gcc version 4.5.3 20110311 (prerelease) (GCC)
-the system type;
USRP-E110: P/N UE-110-KIT
ERROR recevied while installing gnuradio.git
BUILD Script: gnu_install.sh
./gnu_install.sh
#!/bin/sh
# How do I install GNU Radio from source?
# First, remove any existing installation by OpenEmbedded.
echo "First, remove any existing installation by OpenEmbedded."
opkg remove --force-depends gnuradio gnuradio-dev gnuradio-examples
task-gnuradio
# Note that building GNU Radio can take a significant amount of time!!
echo "Note that building GNU Radio can take a significant amount of time!!"
git clone http://gnuradio.org/git/gnuradio.git gnuradio.git
cd gnuradio.git
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr
-DCMAKE_TOOLCHAIN_FILE=../cmake/Toolchains/arm_cortex_a8_native.cmake
-DQT_QTCORE_INCLUDE_DIR=/usr/include/qt4/QtCore
-DQT_QTGUI_INCLUDE_DIR=/usr/include/qt4/QtGui
-DQT_QMAKE_EXECUTABLE=/usr/bin/qmake -DENABLE_GR_QTGUI=ON
-DQT_LIBRARY_DIR=/usr/lib -DQT_INCLUDE_DIR=/usr/include/qt4/
-DQT_MOC_EXECUTABLE=/usr/bin/moc -DQT_UIC_EXECUTABLE=/usr/bin/uic
-DQT_RCC_EXECUTABLE=/usr/bin/rcc -DCMAKE_BUILD_TYPE=release ../
make
make install
ldconfig
Console ERROR message:
[ 38%] Building CXX object
gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_general.dir/gnuradio_core_generalPYTHON_wrap.cxx.o
g++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[2]: ***
[gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_general.dir/gnuradio_core_generalPYTHON_wrap.cxx.o]
Error 1
make[1]: ***
[gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_general.dir/all] Error 2
make: *** [all] Error 2
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130207/7214cfd2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 906 bytes
Desc: image001.gif
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130207/7214cfd2/attachment-0001.gif>
------------------------------
Message: 2
Date: Thu, 07 Feb 2013 14:12:07 -0600
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] gain setting and clipping
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 02/06/2013 02:09 AM, Sivan Toledo wrote:
> Hi,
>
> I am trying to find good settings of the gain and LO frequency in order to
> detect weak signals in the presence of strong out-of-band (but nearby)
> signals with an N200+WBX.
>
> My obvious goal is to use the highest gain setting that does not result in
> saturation in the ADCs and in the arithmetic in the FPGA.
>
> Does saturation/clipping always results in maximum values (near 32767 in
> absolute value) in the samples I get? Is this a reliable signal to reduce
> gain (or move the LO away so that interfering signals are attenuated by the
> anti-aliasing filters in the WBX)?
>
32767 is the full scale of the ADC/DAC signals in the FPGA. The complex
magnitude of the signal should be less than 32767 to avoid clipping the
the FPGA DSP chain.
I should also point out that the clipping occurs in the CORDIC. So if
the DSP frequency (CORDIC frequency) is set to zero, then you can get
full scale though both I and Q.
With that in mind, you should be able to calibrate the saturation point
for your setup.
-josh
> Thanks, Sivan
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 3
Date: Thu, 7 Feb 2013 15:49:37 -0500
From: Roy Thompson <[email protected]>
To: [email protected]
Subject: [USRP-users] Using multiple RX DDC chains on USRP2
Message-ID:
<caozutcegdrf9t4j14hxzqwvmhishqtng6oqps8ogrytrg9v...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
I am starting to look through some of the FPGA code for the USRP2 and
I noticed that there are 2 RX DDC chains. I would like to be able to
use one of the chains to do standard DDC processing, and I would like
to modify the second chain to do custom processing on the same A/D
channel. The output sample rate for the second chain will be
different from the first. Is it possible to configure the UHD driver
to support this configuration and allow for receiving from both
chains?
Thanks,
Roy
------------------------------
Message: 4
Date: Thu, 07 Feb 2013 16:11:26 -0500
From: Philip Balister <[email protected]>
To: "Macre, William R" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] GCC internal compiler fault when installing
GNU-Radio
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Basically, gcc runs out of memory compiling recent gcc's. Add a 512M
swapfile for the compile. It is only one or two files that need the
extra memory to compile.
Philip
On 02/07/2013 12:14 PM, Macre, William R wrote:
>
>
> The problem:
>
> GCC internal compiler fault when installing GNU-Radio
>
>
>
> What we need
>
> -the exact version of GCC;
>
>
>
> gcc -v
>
> Using built-in specs.
>
> COLLECT_GCC=gcc
>
> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/arm-angstrom-linux-gnueabi/4.5.3/lto-wrapper
>
> Target: arm-angstrom-linux-gnueabi
>
> Configured with:
>
> /home/oe-classic/oe/build/tmp-angstrom_2010_x/work/armv7a-angstrom-linux-gnueabi/gcc-4.5-r38.1+svnr170880/gcc-4_5-branch/configure
>
> --build=x86_64-linux --host=arm-angstrom-linux-gnueabi
>
> --target=arm-angstrom-linux-gnueabi --prefix=/usr --exec_prefix=/usr
>
> --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/libexec
>
> --datadir=/usr/share --sysconfdir=/etc --sharedstatedir=/com
>
> --localstatedir=/var --libdir=/usr/lib --includedir=/usr/include
>
> --oldincludedir=/usr/include --infodir=/usr/share/info --mandir=/usr/share/man
>
> --with-libtool-sysroot=/home/oe-classic/oe/build/tmp-angstrom_2010_x/sysroots/armv7a-angstrom-linux-gnueabi
>
> --enable-largefile --disable-nls --enable-ipv6 --with-gnu-ld --enable-shared
>
> --enable-languages=c,c++,objc,fortran --enable-threads=posix
> --disable-multilib
>
> --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch
>
> --program-prefix=arm-angstrom-linux-gnueabi- --enable-target-optspace
>
> --enable-lto --enable-libssp --disable-bootstrap --disable-libgomp
>
> --disable-libmudflap --with-float=softfp --with-local-prefix=/usr/local
>
> --with-gxx-include-dir=/usr/include/c++/4.5.3
>
> --with-build-sysroot=/home/oe-classic/oe/build/tmp-angstrom_2010_x/sysroots/armv7a-angstrom-linux-gnueabi
>
> --enable-__cxa_atexit
>
> Thread model: posix
>
> gcc version 4.5.3 20110311 (prerelease) (GCC)
>
>
>
> -the system type;
>
> USRP-E110: P/N UE-110-KIT
>
>
>
>
>
>
>
> ERROR recevied while installing gnuradio.git
>
> BUILD Script: gnu_install.sh
>
>
>
> ./gnu_install.sh
>
> #!/bin/sh
>
> # How do I install GNU Radio from source?
>
>
>
> # First, remove any existing installation by OpenEmbedded.
>
> echo "First, remove any existing installation by OpenEmbedded."
>
> opkg remove --force-depends gnuradio gnuradio-dev gnuradio-examples
>
> task-gnuradio
>
>
>
> # Note that building GNU Radio can take a significant amount of time!!
>
> echo "Note that building GNU Radio can take a significant amount of time!!"
>
> git clone http://gnuradio.org/git/gnuradio.git gnuradio.git
>
> cd gnuradio.git
>
> mkdir build
>
> cd build
>
> cmake -DCMAKE_INSTALL_PREFIX=/usr
>
> -DCMAKE_TOOLCHAIN_FILE=../cmake/Toolchains/arm_cortex_a8_native.cmake
>
> -DQT_QTCORE_INCLUDE_DIR=/usr/include/qt4/QtCore
>
> -DQT_QTGUI_INCLUDE_DIR=/usr/include/qt4/QtGui
>
> -DQT_QMAKE_EXECUTABLE=/usr/bin/qmake -DENABLE_GR_QTGUI=ON
>
> -DQT_LIBRARY_DIR=/usr/lib -DQT_INCLUDE_DIR=/usr/include/qt4/
>
> -DQT_MOC_EXECUTABLE=/usr/bin/moc -DQT_UIC_EXECUTABLE=/usr/bin/uic
>
> -DQT_RCC_EXECUTABLE=/usr/bin/rcc -DCMAKE_BUILD_TYPE=release ../
>
> make
>
> make install
>
> ldconfig
>
>
>
>
>
> Console ERROR message:
>
> [ 38%] Building CXX object
>
> gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_general.dir/gnuradio_core_generalPYTHON_wrap.cxx.o
>
> g++: Internal error: Killed (program cc1plus)
>
> Please submit a full bug report.
>
> See <http://gcc.gnu.org/bugs.html> for instructions.
>
> make[2]: ***
>
> [gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_general.dir/gnuradio_core_generalPYTHON_wrap.cxx.o]
>
> Error 1
>
> make[1]: ***
>
> [gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_general.dir/all] Error 2
> make: *** [all] Error 2
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 5
Date: Thu, 07 Feb 2013 15:17:27 -0600
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Using multiple RX DDC chains on USRP2
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 02/07/2013 02:49 PM, Roy Thompson wrote:
> I am starting to look through some of the FPGA code for the USRP2 and
> I noticed that there are 2 RX DDC chains. I would like to be able to
> use one of the chains to do standard DDC processing, and I would like
> to modify the second chain to do custom processing on the same A/D
> channel. The output sample rate for the second chain will be
> different from the first. Is it possible to configure the UHD driver
> to support this configuration and allow for receiving from both
> chains?
>
The rx_multi_samples example can show you how to use two DDC chains. If
you had a WBX for example with frontend (named 0), this would map
frontend 0 located on the first and only daughterboard (named A) to DSP0
and DSP1 --subdev="A:0 A:0"
see the --help for more.
> std::cout <<
> " This is a demonstration of how to receive aligned data from
> multiple channels.\n"
> " This example can receive from multiple DSPs, multiple
> motherboards, or both.\n"
> " The MIMO cable or PPS can be used to synchronize the
> configuration. See --sync\n"
> "\n"
> " Specify --subdev to select multiple channels per motherboard.\n"
> " Ex: --subdev=\"0:A 0:B\" to get 2 channels on a Basic RX.\n"
> "\n"
> " Specify --args to select multiple motherboards in a
> configuration.\n"
> " Ex: --args=\"addr0=192.168.10.2, addr1=192.168.10.3\"\n"
> << std::endl;
See this readme, there is a place where it should be convenient to
replace the DDC with custom logic:
http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/fpga/README.txt
-josh
> Thanks,
> Roy
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 6
Date: Thu, 7 Feb 2013 16:30:02 -0500
From: Roy Thompson <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] Using multiple RX DDC chains on USRP2
Message-ID:
<caozutcfyhgfw_mtvfxhnkndirbdtdimznbmt3t5nhz8ekxo...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Thanks, will that work if the chains have different sample rates?
There is a comment in multi_usrp.hpp stating that all channels must
have the same rate, but it's not clear what causes the limitation
since it looks like it is possible to set the rate for individual
channels with set_rx_rate().
-Roy
On Thu, Feb 7, 2013 at 4:17 PM, Josh Blum <[email protected]> wrote:
>
>
> On 02/07/2013 02:49 PM, Roy Thompson wrote:
>> I am starting to look through some of the FPGA code for the USRP2 and
>> I noticed that there are 2 RX DDC chains. I would like to be able to
>> use one of the chains to do standard DDC processing, and I would like
>> to modify the second chain to do custom processing on the same A/D
>> channel. The output sample rate for the second chain will be
>> different from the first. Is it possible to configure the UHD driver
>> to support this configuration and allow for receiving from both
>> chains?
>>
>
> The rx_multi_samples example can show you how to use two DDC chains. If
> you had a WBX for example with frontend (named 0), this would map
> frontend 0 located on the first and only daughterboard (named A) to DSP0
> and DSP1 --subdev="A:0 A:0"
>
> see the --help for more.
>
>> std::cout <<
>> " This is a demonstration of how to receive aligned data from
>> multiple channels.\n"
>> " This example can receive from multiple DSPs, multiple
>> motherboards, or both.\n"
>> " The MIMO cable or PPS can be used to synchronize the
>> configuration. See --sync\n"
>> "\n"
>> " Specify --subdev to select multiple channels per motherboard.\n"
>> " Ex: --subdev=\"0:A 0:B\" to get 2 channels on a Basic RX.\n"
>> "\n"
>> " Specify --args to select multiple motherboards in a
>> configuration.\n"
>> " Ex: --args=\"addr0=192.168.10.2, addr1=192.168.10.3\"\n"
>> << std::endl;
>
>
> See this readme, there is a place where it should be convenient to
> replace the DDC with custom logic:
>
> http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/fpga/README.txt
>
> -josh
>
>> Thanks,
>> Roy
>>
>> _______________________________________________
>> 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
------------------------------
Message: 7
Date: Thu, 07 Feb 2013 15:41:19 -0600
From: Josh Blum <[email protected]>
To: Roy Thompson <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Using multiple RX DDC chains on USRP2
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 02/07/2013 03:30 PM, Roy Thompson wrote:
> Thanks, will that work if the chains have different sample rates?
> There is a comment in multi_usrp.hpp stating that all channels must
> have the same rate, but it's not clear what causes the limitation
> since it looks like it is possible to set the rate for individual
> channels with set_rx_rate().
Yes, all the api calls take a channel number. So in this case, you would
want a different rx_streamer for each channel, since they are at
different rates.
-josh
>
> -Roy
>
> On Thu, Feb 7, 2013 at 4:17 PM, Josh Blum <[email protected]> wrote:
>>
>>
>> On 02/07/2013 02:49 PM, Roy Thompson wrote:
>>> I am starting to look through some of the FPGA code for the USRP2 and
>>> I noticed that there are 2 RX DDC chains. I would like to be able to
>>> use one of the chains to do standard DDC processing, and I would like
>>> to modify the second chain to do custom processing on the same A/D
>>> channel. The output sample rate for the second chain will be
>>> different from the first. Is it possible to configure the UHD driver
>>> to support this configuration and allow for receiving from both
>>> chains?
>>>
>>
>> The rx_multi_samples example can show you how to use two DDC chains. If
>> you had a WBX for example with frontend (named 0), this would map
>> frontend 0 located on the first and only daughterboard (named A) to DSP0
>> and DSP1 --subdev="A:0 A:0"
>>
>> see the --help for more.
>>
>>> std::cout <<
>>> " This is a demonstration of how to receive aligned data from
>>> multiple channels.\n"
>>> " This example can receive from multiple DSPs, multiple
>>> motherboards, or both.\n"
>>> " The MIMO cable or PPS can be used to synchronize the
>>> configuration. See --sync\n"
>>> "\n"
>>> " Specify --subdev to select multiple channels per
>>> motherboard.\n"
>>> " Ex: --subdev=\"0:A 0:B\" to get 2 channels on a Basic RX.\n"
>>> "\n"
>>> " Specify --args to select multiple motherboards in a
>>> configuration.\n"
>>> " Ex: --args=\"addr0=192.168.10.2, addr1=192.168.10.3\"\n"
>>> << std::endl;
>>
>>
>> See this readme, there is a place where it should be convenient to
>> replace the DDC with custom logic:
>>
>> http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/fpga/README.txt
>>
>> -josh
>>
>>> Thanks,
>>> Roy
>>>
>>> _______________________________________________
>>> 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
------------------------------
Message: 8
Date: Thu, 07 Feb 2013 17:17:22 -0600
From: Josh Blum <[email protected]>
To: Sivan Toledo <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] args field in uhd::tune_request_t
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 02/06/2013 12:47 PM, Sivan Toledo wrote:
> Thanks a lot. I hope it makes it to the master branch and get tested. We'll
> definitely use it (I am not sure how bad are the spurs that we get in
> fractional mode, but we'll be happy to get rid of them and the specific
> choice of LO frequency is not really important to us).
If it helps in the meantime, there is a branch called
wip_integer_n_tuning on uhd.git with support for one of the sbx revs.
-josh
>
> Sivan
>
> On Wed, Feb 6, 2013 at 7:08 PM, Josh Blum <[email protected]> wrote:
>
>>
>>
>> On 02/06/2013 12:30 AM, Sivan Toledo wrote:
>>> Hi,
>>>
>>> The documentation (
>>>
>> http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1tune__request__t.html
>> )
>>> says that uhd::tune_request_t has an args field that allows you to
>> request
>>> integer rather than fractional synthesizer. It's not in my header fines
>>> (for 3.5.1 and 3.5.0) and the compiler complains that the field is
>> missing.
>>>
>>> Does this field exist in any version of UHD and does it actually work
>> (sets
>>> the synthesizer to integer-N tuning)?
>>>
>>
>> This was pushed out on the master branch so its not in any release.
>> There is SBX/WBX code to use this, but its in test and not yet pushed.
>>
>> -josh
>>
>>> Thanks, Sivan Toledo
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>
------------------------------
Message: 9
Date: Fri, 8 Feb 2013 01:13:04 +0100
From: Damien Serant <[email protected]>
To: [email protected]
Cc: USRP List <[email protected]>
Subject: Re: [USRP-users] Using 4 USRP with a Gigabit switch
Message-ID:
<CAM=tnlkgr6y02m+ahwcrkz4sjq53zmwpw+cf6+huavojn2q...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Thanks for your help. My problem is solved but i added some
answers/comments here below.
"Are you requesting continuous or finite streaming?"
I was using a continuous streaming. The number of received samples is
equal to the requested one.
I tried the progressive approach as you suggested:
- 1 USRP : OK
- 2 USRP : OK
- 3 USRP : OK
- 4 USRP : KO -> 30 sec to acquire 5 seconds.
I suspected a problem with my network card so i tried on another PC (a
laptop) and it works fine with 4 USRP even at 5MHz sampling freq ! So
problem solved
FYI the network card that was the source of the problem is a broadcom
NetXtreme Gigabit Ethernet. You can see the configurable parmaters of this
card on the screenshoot hare attached, may be one of them is causing the
problem ?
In addition during my test to write the receievd sample on HHD, i noticed
that use C-style files (FILE *) is much more efficient than usint C++-style
files (ofstream). The difference is spectacular : with the C-style file i
write 50 MB/s in real time, with C++-style, the first slow-down appears at
16 MB/s. Someone has already observed that ?
[image: Images int?gr?es 1]
2013/2/7 Josh Blum <[email protected]>
>
>
> On 02/06/2013 03:14 PM, Damien Serant wrote:
> > Hi list,
> >
> > I am experiencing some issue with my configuration using an Ethernet
> switch
> > even if i read on the list that it should work seamlessly . Here is the
> > situation:
> > - I use 2 pairs of USRPN200. In each pair, the 2 USRP are connected
> > together with a MIMO cable, and the master USRP of each pair has the
> > internal GPSDO from Ettus.
> > - The master USRP of each pair is connected to a Netgear 8 port Gigabit
> > switch.
> > - My PC is also connected to this switch.
> > - I wrote a simple UHD program (based on multi_sample_to_file) to record
> > the sample of each USRP. I use 1 multi_usrp object constructed with the 4
> > IP address of my USRP2 (all different of course). 1 have 1 rx_stream
> mapped
> > over my four channels so obtained.
> > - I record 4 files as expected, but the program spends more than 30
> seconds
> > to record 5 seconds of signal as if there was some bottle-neck somewhere
> > (the same without writing to the HDD). The problem is that the sampling
> > frequency is 200 kHz so the Gigabit network should handle that without
> any
> > issue, no ?
> >
>
> That sounds like a few MB worth of data. Shouldnt take much time at all.
>
> Are you requesting continuous or finite streaming? I would recommend to
> first count the number of samples coming out of the recv() call and make
> sure its what is expected.
>
> I guess another good approach would be to add in one device at a time
> and see where the application starts getting funny / breaking assumptions.
>
> > So my conclusion is that i am doing wrong somewhere. Actually i'm not
> sure
> > how to handle my 4 usrp with UHD:
> > - Treat each USRP pair in different USRP object ?
> > - Use one multi_usrp object, but one rx_stream per pair ?
> > - Execute multi_sample_to_file.exe for each pair ? -> i tried this
> > solution but it does not work : the files of one of two pair remains
> empty.
>
> All of those options should work. Usually ganging all 4 devices together
> into one object is a just convenience for dealing w/ alignment.
>
> -josh
>
> >
> > Thanks in advance
> > Damien
> >
> >
> >
> > _______________________________________________
> > 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/20130208/77905634/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 19934 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130208/77905634/attachment-0001.png>
------------------------------
Message: 10
Date: Fri, 8 Feb 2013 03:09:51 -0800 (PST)
From: Furkan Elibol <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] SPI usage with lfrx db;
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi all,
I want to use spi interface to control an external custom rf frontend from lfrx
daughterboard. I am using USRP N210 with uhd driver.
I wonder is there any documentation or a simple example which is related with
usage of the spi interface.
Thanks..
furkan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130208/4b65ae91/attachment-0001.html>
------------------------------
Message: 11
Date: Fri, 8 Feb 2013 12:06:08 +0000
From: Per Zetterberg <[email protected]>
To: Furkan Elibol <[email protected]>, usrp-users
<[email protected]>
Subject: Re: [USRP-users] SPI usage with lfrx db;
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
I suggest the use of general purpose pins instead. It's easier and more
flexible IMHO.
BR/
Per
________________________________________
From: USRP-users [[email protected]] on behalf of Furkan
Elibol [[email protected]]
Sent: Friday, February 08, 2013 12:09 PM
To: usrp-users
Subject: [USRP-users] SPI usage with lfrx db;
Hi all,
I want to use spi interface to control an external custom rf frontend from lfrx
daughterboard. I am using USRP N210 with uhd driver.
I wonder is there any documentation or a simple example which is related with
usage of the spi interface.
Thanks..
furkan
------------------------------
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 30, Issue 8
*****************************************
