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: I am dead in the water due to the following error: RFNoC
not found. (Collins, Richard)
2. External Reference (Eric C.)
3. Re: Environmental Questions About the X310 and N210 (Nate Temple)
4. Re: External Reference (Marcus M?ller)
5. Re: External Reference (Nick Foster)
6. Re: Environmental Questions About the X310 and N210
(Dave NotTelling)
7. Re: Tuning Resolution of B210 RF Front end (Jeremy Hershberger)
8. Re: Tuning Resolution of B210 RF Front end (Marcus D. Leech)
9. Re: External Reference (Eric C.)
10. Re: External Reference (Nick Foster)
11. Re: Tuning Resolution of B210 RF Front end (Ian Buckley)
12. Re: External Reference (Eric C.)
13. Re: External Reference (Marcus D. Leech)
14. Re: Tuning Resolution of B210 RF Front end (Jeremy Hershberger)
15. Re: Tuning Resolution of B210 RF Front end (Marcus D. Leech)
16. FW: I am dead in the water due to the following error: RFNoC
not found. (Swanson, Craig)
17. Re: FW: I am dead in the water due to the following error:
RFNoC not found. (Collins, Richard)
18. Trouble building gr-ettus (using custom install prefix, and
(rfnoc-)radio-redo) (Collins, Richard)
19. Re: Trouble building gr-ettus (using custom install prefix,
and (rfnoc-)radio-redo) (Marcus M?ller)
----------------------------------------------------------------------
Message: 1
Date: Fri, 27 May 2016 12:20:41 -0400
From: "Collins, Richard" <[email protected]>
To: "Swanson, Craig" <[email protected]>,
[email protected]
Subject: Re: [USRP-users] I am dead in the water due to the following
error: RFNoC not found.
Message-ID:
<CABgQ8cY7GQn2UBHwYQX=gyTnC-9GWJaQ-_g7VP6tVa+P3SS=0...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Further info:
Doing a *make clean*, removing everything from the build folder, and
re-running cmake with the added *-DENABLE_B200=OFF* allowed the subsequent
*make* to finish successfully.
However, when I run make test, all tests pass except sph_recv_test.
Running just /opt/src/uhd-rfnoc/host/build/tests/sph_recv_test throws a few
"unknown location(0)" errors, and the whole output has been included as
sph_recv_test.txt .
Unrelated to the error, but related to what I've reported previously...
since I've installed everything to /opt/uhd-rfnoc/ instead of
/opt/gnuradio-rfnoc/, I've updated my source script to expand PATH,
LD_LIBRARY_PATH, and PKG_CONFIG_PATH accordingly.
Richard
On Fri, May 27, 2016 at 10:59 AM, Collins, Richard <
[email protected]> wrote:
> I'm getting the exact same error, as follows:
>
> [ 44%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/b200/b200_impl.cpp.o
> /opt/src/uhd-rfnoc/host/lib/usrp/b200/b200_impl.cpp: In constructor
> ?b200_impl::b200_impl(const uhd::device_addr_t&,
> uhd::transport::usb_device_handle::sptr&)?:
> /opt/src/uhd-rfnoc/host/lib/usrp/b200/b200_impl.cpp:624:93: error: no
> matching function for call to
> ?uhd::usrp::ad936x_manager::loopback_self_test(radio_ctrl_core_3000::sptr&,
> int, const int&)?
> _codec_mgr->loopback_self_test(perif.ctrl, TOREG(SR_CODEC_IDLE),
> RB64_CODEC_READBACK);
>
> ^
> In file included from
> /opt/src/uhd-rfnoc/host/lib/usrp/b200/b200_impl.hpp:25:0,
> from
> /opt/src/uhd-rfnoc/host/lib/usrp/b200/b200_impl.cpp:18:
> /opt/src/uhd-rfnoc/host/lib/usrp/common/ad936x_manager.hpp:82:18: note:
> candidate: virtual void
> uhd::usrp::ad936x_manager::loopback_self_test(boost::function<void(unsigned
> int)>, boost::function<long unsigned int()>)
> virtual void loopback_self_test(
> ^
> /opt/src/uhd-rfnoc/host/lib/usrp/common/ad936x_manager.hpp:82:18: note:
> candidate expects 2 arguments, 3 provided
> lib/CMakeFiles/uhd.dir/build.make:4365: recipe for target
> 'lib/CMakeFiles/uhd.dir/usrp/b200/b200_impl.cpp.o' failed
> make[2]: *** [lib/CMakeFiles/uhd.dir/usrp/b200/b200_impl.cpp.o] Error 1
> CMakeFiles/Makefile2:117: recipe for target 'lib/CMakeFiles/uhd.dir/all'
> failed
> make[1]: *** [lib/CMakeFiles/uhd.dir/all] Error 2
> Makefile:160: recipe for target 'all' failed
> make: *** [all] Error 2
>
>
> How I got here is by using the following commands:
>
> (from a directory under my user's ownership and group called "src"):
> $ git clone --recursive git://github.com/EttusResearch/uhd.git uhd-rfnoc
> $ cd uhd-rfnoc
> $ git checkout -b rfnoc-radio-redo -t origin/rfnoc-radio-redo
> $ cmake -DCMAKE_INSTALL_PREFIX=/opt/uhd-rfnoc/ -DENABLE_X300=ON
> -DENABLE_E300=ON -DLIB_SUFFIX=64 -Wno-dev ../
>
> Note, I already created and chown'd and chgrp'd folder, /opt/uhd-rfnoc/,
> and made a file (which I plan to "source" before attempting to run gnuradio
> once installed) that consists of the following text:
> BASE=/opt/gnuradio-rfnoc
> export PATH=${PATH}:${BASE}/bin
> export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${BASE}/lib64
> export PKG_CONFIG_PATH=${PKG_CONFIG_PATH}:${BASE}/lib64/pkgconfig
> export PYTHONPATH=${PYTHONPATH}:${BASE}/lib64/python2.7/site-packages/
>
> Should I be running cmake with a flag of -DENABLE_B200=OFF ?
> Or should I not have git-clone'd recursively?
>
> (I don't have a B200 or B210, so I'll try it with DENABLE_B200=OFF)
>
>
> - Richard
>
>
> On Sun, May 8, 2016 at 8:09 PM, Swanson, Craig via USRP-users <
> [email protected]> wrote:
>
>> ?Marcus,
>>
>> I just upgraded my image to e3xx-release-4 on my E310.
>>
>> Craig
>>
>>
>> *Craig F. Swanson*
>>
>> *Research Engineer II *
>> *Information and Communications Laboratory*
>> *Communications, Systems, and Spectrum Division*
>> *Georgia Tech Research Institute*
>>
>>
>> *Room 560 250 14th St NW *
>> *Atlanta, GA 30318*
>> *Cell: 770.298.9156 <770.298.9156>*
>> http://www.gtri.gatech.edu
>> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>>
>>
>> ------------------------------
>> *From:* Marcus M?ller <[email protected]>
>> *Sent:* Saturday, May 7, 2016 2:33 PM
>> *To:* Swanson, Craig; Martin Braun; Jonathon Pendlum
>> *Cc:* [email protected]
>> *Subject:* Re: [USRP-users] I am dead in the water due to the following
>> error: RFNoC not found.
>>
>> You're welcome! Hope this works out.
>>
>> If you're aiming for using RFNoC on your E310 (which I just realized
>> might be the case, looking at your -DENABLE_E300), you not only need any
>> version of UHD that supports RFNoC ? you need the version (and, most
>> importantly, since I guess you might be building your own FPGA images
>> sooner or later, the right FPGA source code) that runs on the E310.
>>
>> What image are you running on the E310?
>>
>> Best regards,
>> Marcus
>>
>> On 07.05.2016 20:30, Swanson, Craig wrote:
>>
>> Marcus,
>>
>> Thanks for the quick reply.
>>
>> Craig
>>
>>
>>
>> *Craig F. Swanson*
>>
>> *Research Engineer II *
>> *Information and Communications Laboratory*
>> *Communications, Systems, and Spectrum Division*
>> *Georgia Tech Research Institute*
>>
>>
>> *Room 560 250 14th St NW *
>> *Atlanta, GA 30318*
>> *Cell: 770.298.9156 <770.298.9156>*
>>
>> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>> http://www.gtri.gatech.edu
>>
>> ------------------------------
>> *From:* Marcus M?ller <[email protected]>
>> <[email protected]>
>> *Sent:* Saturday, May 7, 2016 2:23 PM
>> *To:* Swanson, Craig; Martin Braun; Jonathon Pendlum
>> *Cc:* [email protected]; Myers, David
>> *Subject:* Re: [USRP-users] I am dead in the water due to the following
>> error: RFNoC not found.
>>
>> Hi Craig,
>>
>> this won't work because you're (implicitly) checking out the "master"
>> branch of UHD - which isn't RFNoC'ed.
>>
>> So, I recommend modifying your script:
>>
>> instead of
>>
>> git clone https://github.com/EttusResearch/uhd
>>
>> use
>>
>> git clone -b rfnoc-devel https://github.com/EttusResearch/uhd
>> git submodule update --init ##fill the fpga-src directory with the
>> matching FPGA code
>>
>> . Of course, if you've still got the downloaded files around, you can
>> check out the right branch right now
>>
>> cd ~/uhd/host/build
>> sudo make uninstall
>> rm -r * ##cleans the build directory
>> git checkout -t rfnoc-devel ## checks out the RFNoC version of UHD
>> git submodule update --init ##fill the fpga-src directory with the
>> matching FPGA code
>> cmake -DENABLE_E300=ON ../
>> make -j8 && sudo make install && sudo ldconfig
>>
>> cd ~/gnuradio/build
>> cmake ..
>> make -j8 && sudo make install && sudo ldconfig
>>
>> and then try building gr-ettus again.
>>
>> Best regards,
>> Marcus
>> On 07.05.2016 20:11, Swanson, Craig via USRP-users wrote:
>>
>> Martin,
>>
>> When I perform a cmake ../ in gr-ettus, I get the following error:
>> CMake Error at CMakeLists.txt:113 (message):
>> RFNoC not found.
>>
>> Here are more details of the error:
>> craig@craig-VirtualBox:~/gr-ettus/build (master)$ cmake ../
>> -- The CXX compiler identification is GNU 4.8.4
>> -- The C compiler identification is GNU 4.8.4
>> -- Check for working CXX compiler: /usr/bin/c++
>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>> -- Detecting CXX compiler ABI info
>> -- Detecting CXX compiler ABI info - done
>> -- Check for working C compiler: /usr/bin/cc
>> -- Check for working C compiler: /usr/bin/cc -- works
>> -- Detecting C compiler ABI info
>> -- Detecting C compiler ABI info - done
>> -- Build type not specified: defaulting to release.
>> -- Boost version: 1.54.0
>> -- Found the following Boost libraries:
>> -- filesystem
>> -- system
>> -- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
>> -- Found UHD: /usr/local/lib/libuhd.so
>> CMake Error at CMakeLists.txt:113 (message):
>> RFNoC not found.
>>
>> Here is the script I am using:
>>
>> git clone https://github.com/EttusResearch/uhd
>> mkdir ~/uhd/host/build
>> cd ~/uhd/host/build
>> cmake ../ -DENABLE_E300=ON ../
>> make -j8
>> sudo make install -j8
>> sudo ldconfig
>>
>> git clone --recursive <http://git.gnuradio.org/git/gnuradio.git>
>> http://git.gnuradio.org/git/gnuradio.git
>> mkdir ~/gnuradio/build
>> cd ~/gnuradio/build
>> cmake ../
>> make -j8
>> sudo make install -j8
>> sudo ldconfig
>>
>> git clone https://github.com/EttusResearch/gr-ettus.git?
>> <https://github.com/EttusResearch/gr-ettus.git%E2%80%8B>
>> mkdir ~/gr-ettus/build
>> cd ~/gr-ettus/build
>> cmake ../
>> make -j8
>> sudo make install -j8
>> sudo ldconfig
>>
>>
>>
>> Craig
>>
>>
>> *Craig F. Swanson*
>>
>> *Research Engineer II *
>> *Information and Communications Laboratory*
>> *Communications, Systems, and Spectrum Division*
>> *Georgia Tech Research Institute*
>>
>>
>> *Room 560 250 14th St NW *
>> *Atlanta, GA 30318*
>> *Cell: 770.298.9156 <770.298.9156>*
>> <http://www.gtri.gatech.edu>http://www.gtri.gatech.edu
>>
>>
>>
>> _______________________________________________
>> 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/20160527/938f14ee/attachment-0001.html>
-------------- next part --------------
linux; GNU C++ version 5.3.1 20160413; Boost_105800;
UHD_003.010.rfnoc-471-g37ffaef2
Running 8 test cases...
data check 0
data check 1
data check 2
data check 3
data check 4
data check 5
data check 6
data check 7
data check 8
data check 9
data check 10
data check 11
data check 12
data check 13
data check 14
data check 15
data check 16
data check 17
data check 18
data check 19
data check 20
data check 21
data check 22
data check 23
data check 24
data check 25
data check 26
data check 27
data check 28
data check 29
timeout check 0
unknown location(0): fatal error in "test_sph_recv_one_channel_normal":
std::runtime_error: call to empty boost::function
/opt/src/uhd-rfnoc/host/tests/sph_recv_test.cpp(164): last checkpoint
data check 0
data check 1
data check 2
data check 3
data check 4
data check 5
data check 6
data check 7
data check 8
data check 9
data check 10
data check 11
data check 12
data check 13
data check 14
data check 15
-- expected: 15 got: 0
data check 16
data check 17
data check 18
data check 19
data check 20
data check 21
data check 22
data check 23
data check 24
data check 25
data check 26
data check 27
data check 28
data check 29
timeout check 0
unknown location(0): fatal error in "test_sph_recv_one_channel_sequence_error":
std::runtime_error: call to empty boost::function
/opt/src/uhd-rfnoc/host/tests/sph_recv_test.cpp(249): last checkpoint
data check 0
data check 1
data check 2
data check 3
data check 4
data check 5
data check 6
data check 7
data check 8
data check 9
data check 10
data check 11
data check 12
data check 13
data check 14
data check 15
metadata.error_code 8
data check 16
data check 17
data check 18
data check 19
data check 20
data check 21
data check 22
data check 23
data check 24
data check 25
data check 26
data check 27
data check 28
data check 29
timeout check 0
unknown location(0): fatal error in "test_sph_recv_one_channel_inline_message":
std::runtime_error: call to empty boost::function
/opt/src/uhd-rfnoc/host/tests/sph_recv_test.cpp(337): last checkpoint
data check 0
data check 1
data check 2
data check 3
data check 4
data check 5
data check 6
data check 7
data check 8
data check 9
data check 10
data check 11
data check 12
data check 13
data check 14
data check 15
data check 16
data check 17
data check 18
data check 19
data check 20
data check 21
data check 22
data check 23
data check 24
data check 25
data check 26
data check 27
data check 28
data check 29
timeout check 0
unknown location(0): fatal error in "test_sph_recv_multi_channel_normal":
std::runtime_error: call to empty boost::function
/opt/src/uhd-rfnoc/host/tests/sph_recv_test.cpp(432): last checkpoint
data check 0
data check 1
data check 2
data check 3
data check 4
data check 5
data check 6
data check 7
data check 8
data check 9
data check 10
data check 11
data check 12
data check 13
data check 14
data check 15
-- expected: 15 got: 0
data check 16
data check 17
data check 18
data check 19
data check 20
data check 21
data check 22
data check 23
data check 24
data check 25
data check 26
data check 27
data check 28
data check 29
timeout check 0
unknown location(0): fatal error in
"test_sph_recv_multi_channel_sequence_error": std::runtime_error: call to empty
boost::function
/opt/src/uhd-rfnoc/host/tests/sph_recv_test.cpp(532): last checkpoint
data check 0
data check 1
data check 2
data check 3
data check 4
data check 5
data check 6
data check 7
data check 8
data check 9
data check 10
data check 11
data check 12
data check 13
data check 14
data check 15
data check 16
data check 17
data check 18
data check 19
data check 20
data check 21
data check 22
data check 23
data check 24
data check 25
data check 26
data check 27
data check 28
data check 29
timeout check 0
unknown location(0): fatal error in "test_sph_recv_multi_channel_time_error":
std::runtime_error: call to empty boost::function
/opt/src/uhd-rfnoc/host/tests/sph_recv_test.cpp(625): last checkpoint
exception check
data check 0
data check 1
data check 2
data check 3
data check 4
data check 5
data check 6
data check 7
data check 8
data check 9
data check 10
data check 11
data check 12
data check 13
data check 14
data check 15
data check 16
data check 17
data check 18
data check 19
data check 20
data check 21
data check 22
data check 23
data check 24
data check 25
data check 26
data check 27
data check 28
data check 29
timeout check 0
unknown location(0): fatal error in "test_sph_recv_multi_channel_fragment":
std::runtime_error: call to empty boost::function
/opt/src/uhd-rfnoc/host/tests/sph_recv_test.cpp(798): last checkpoint
------------------------------
Message: 2
Date: Fri, 27 May 2016 09:36:18 -0600
From: "Eric C." <[email protected]>
To: [email protected]
Subject: [USRP-users] External Reference
Message-ID:
<CABf-Ja5yLPWUYDbafGb9WUyx=fdn17rayfveyzn+3ruoawk...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I have an N210 that I'm using with a WBX daughter card. In my lab at work
we have a high quality 10 MHz reference that I'm inputting to the USRP. I
think initially I had it hooked up at too high of a power. But I've since
added attenuators and it's at about 11 dBm, comfortably below the 15 dB
limit (that I should have looked up first).
I'm using gnuradio companion and the USRP source block has the time
reference set up as external. When I run in this mode, I'm getting quite
wrong frequency results (18 kHz off on a signal in the 400 MHz range). But
the E light is a steady green while I'm collecting (sometimes it turns off
when I'm not receiving though, sometimes it stays on). When I run the
uhd_fft application, or change my application to not set the source to
external, the results are visibly better. I can't tell how accurate they
are, but at least on the sale of observing the spectra they look centered
more appropriately.
Does that mean I'm using the internal oscillator? Is there something I'm
doing wrong? Did I fry the external LO input when I had too high of a
signal connected (I think it was just over 30 dBm)?
-- Eric C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160527/7272ebed/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 27 May 2016 10:59:47 -0700
From: Nate Temple <[email protected]>
To: Dave NotTelling <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Environmental Questions About the X310 and
N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Dave,
For the UBX-40/UBX-160
Operating Temperature Range: 0-40 ?C
Operating Humidity: 10% to 90%, noncondensing
We don't have any MTBF statistics.
Regards,
Nate
> On May 20, 2016, at 10:21 AM, Dave NotTelling via USRP-users
> <[email protected]> wrote:
>
> Is there any information about the max and min temps, and max humidity for
> both radios using the UBX-160 and UBX-40 daugherboards? What about MTBF
> numbers?
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 4
Date: Fri, 27 May 2016 20:07:06 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] External Reference
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Eric,
1W (30dBm) are indeed a bit much for the input circuitry. Let's look at
this:
1W means an U_eff of about 7V (considering the input impedance for 10MHz
should pretty much be 50 Ohm, and $P = \frac{U^2}R \implies U =
\sqrt{PR}$).
The two leads "exiting" to the right reach a clock multiplexer [1] which
is spec'ed for a maximum input voltage of 3.3V with the supply we drive it.
Now, to not exceed that, we have D503 [2] in place, which is basically
meant to suppress things > 12V as TVS diode. Check that diode, simply by
using a multimeter on the 10MHz ref input (remove all power from the
USRP before!). It should show the typical "resistance increase" of any
capacitor measured with DC: starting low, than getting progressively
higher, reaching some Megaohm value at the end. You might not see that
"starting low" moment.
Now, 12V > 3.3V, and that's why D501, a bog-normal BAV99T, with a
forward voltage of about 1.0V under "normal" circumstances (ie. current
limited to 50mA). I think you might have fried that. That one is a bit
harder to test, especially since I don't want to damage the clock
multiplexer in the process. Hm. A test method for this would be locate
R535 and R536 on the motherboard, and measure the DC resistance of
R535?transformer coil of T501?R536; you can't do that with a single
multimeter. You'll need to make a I/U curve for input voltages from -0.7
? 0V ... 0.7V and see whether you can see a offset "diode" typical
behaviour in the current. Make very sure not to touch your voltage
source to places that shouldn't get 0.7V. If you don't see that, D501 or
the semiconductors in the input stage of the clock plexer are probably
damaged.
So, in case the diode is damaged, you can try replacing it. Please only
do that if you have enough experience with SMD rework ? more often than
necessary, people use to much heat with too much air flow in a hot air
gun and blow away half of a board's components.
If you chose not to try to replace D501, or the input stage is indeed
damaged, you could also still use another N2xx and a MIMO cable. I'll
not advertise this too much, since no-one tested it, but it's possible
you can set the clock source to "mimo", get a Serial-attached-SCSI cable
(which has a MIMO-cable-compatible connector), hack it off, find the
right pins that connect to what's A8 / A9 in J707 of our N2xx schematic
[3, p. 5],
At any rate, if you have further problems, or questions,
[email protected] is there for you!
Best regards,
Marcus
[1] U18, SY89545L
[2] Semtech uClamp1211P
[3] http://files.ettus.com/schematics/n200/n2xx.pdf
On 27.05.2016 17:36, Eric C. via USRP-users wrote:
> I have an N210 that I'm using with a WBX daughter card. In my lab at
> work we have a high quality 10 MHz reference that I'm inputting to the
> USRP. I think initially I had it hooked up at too high of a power. But
> I've since added attenuators and it's at about 11 dBm, comfortably
> below the 15 dB limit (that I should have looked up first).
>
> I'm using gnuradio companion and the USRP source block has the time
> reference set up as external. When I run in this mode, I'm getting
> quite wrong frequency results (18 kHz off on a signal in the 400 MHz
> range). But the E light is a steady green while I'm collecting
> (sometimes it turns off when I'm not receiving though, sometimes it
> stays on). When I run the uhd_fft application, or change my
> application to not set the source to external, the results are visibly
> better. I can't tell how accurate they are, but at least on the sale
> of observing the spectra they look centered more appropriately.
>
> Does that mean I'm using the internal oscillator? Is there something
> I'm doing wrong? Did I fry the external LO input when I had too high
> of a signal connected (I think it was just over 30 dBm)?
>
> -- Eric C.
>
>
> _______________________________________________
> 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/20160527/e90714ee/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-7.png
Type: image/png
Size: 1495 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160527/e90714ee/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: n2xx_clock_inp.png
Type: image/png
Size: 10356 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160527/e90714ee/attachment-0003.png>
------------------------------
Message: 5
Date: Fri, 27 May 2016 18:17:44 +0000
From: Nick Foster <[email protected]>
To: Marcus M?ller <[email protected]>,
[email protected]
Subject: Re: [USRP-users] External Reference
Message-ID:
<CA+JMMq83GxB6viBvWC5=6x2fug7b3ncw44g-ydien-vujoc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Just get 10MHz at +15dBm into the clock input and see if you see a
reasonable clock waveform at the output of R535 on a 'scope.
On Fri, May 27, 2016 at 11:08 AM Marcus M?ller <[email protected]>
wrote:
> Hi Eric,
>
> 1W (30dBm) are indeed a bit much for the input circuitry. Let's look at
> this:
> 1W means an U_eff of about 7V (considering the input impedance for 10MHz
> should pretty much be 50 Ohm, and [image: $P = \frac{U^2}R \implies U =
> \sqrt{PR}$]).
> The two leads "exiting" to the right reach a clock multiplexer [1] which
> is spec'ed for a maximum input voltage of 3.3V with the supply we drive it.
>
>
>
> Now, to not exceed that, we have D503 [2] in place, which is basically
> meant to suppress things > 12V as TVS diode. Check that diode, simply by
> using a multimeter on the 10MHz ref input (remove all power from the USRP
> before!). It should show the typical "resistance increase" of any capacitor
> measured with DC: starting low, than getting progressively higher, reaching
> some Megaohm value at the end. You might not see that "starting low" moment.
>
> Now, 12V > 3.3V, and that's why D501, a bog-normal BAV99T, with a forward
> voltage of about 1.0V under "normal" circumstances (ie. current limited to
> 50mA). I think you might have fried that. That one is a bit harder to test,
> especially since I don't want to damage the clock multiplexer in the
> process. Hm. A test method for this would be locate R535 and R536 on the
> motherboard, and measure the DC resistance of R535?transformer coil of
> T501?R536; you can't do that with a single multimeter. You'll need to make
> a I/U curve for input voltages from -0.7 ? 0V ... 0.7V and see whether you
> can see a offset "diode" typical behaviour in the current. Make very sure
> not to touch your voltage source to places that shouldn't get 0.7V. If you
> don't see that, D501 or the semiconductors in the input stage of the clock
> plexer are probably damaged.
>
> So, in case the diode is damaged, you can try replacing it. Please only do
> that if you have enough experience with SMD rework ? more often than
> necessary, people use to much heat with too much air flow in a hot air gun
> and blow away half of a board's components.
>
> If you chose not to try to replace D501, or the input stage is indeed
> damaged, you could also still use another N2xx and a MIMO cable. I'll not
> advertise this too much, since no-one tested it, but it's possible you can
> set the clock source to "mimo", get a Serial-attached-SCSI cable (which has
> a MIMO-cable-compatible connector), hack it off, find the right pins that
> connect to what's A8 / A9 in J707 of our N2xx schematic [3, p. 5],
>
> At any rate, if you have further problems, or questions, [email protected]
> is there for you!
>
> Best regards,
> Marcus
>
>
> [1] U18, SY89545L
> [2] Semtech uClamp1211P
> [3] http://files.ettus.com/schematics/n200/n2xx.pdf
>
> On 27.05.2016 17:36, Eric C. via USRP-users wrote:
>
> I have an N210 that I'm using with a WBX daughter card. In my lab at work
> we have a high quality 10 MHz reference that I'm inputting to the USRP. I
> think initially I had it hooked up at too high of a power. But I've since
> added attenuators and it's at about 11 dBm, comfortably below the 15 dB
> limit (that I should have looked up first).
>
> I'm using gnuradio companion and the USRP source block has the time
> reference set up as external. When I run in this mode, I'm getting quite
> wrong frequency results (18 kHz off on a signal in the 400 MHz range). But
> the E light is a steady green while I'm collecting (sometimes it turns off
> when I'm not receiving though, sometimes it stays on). When I run the
> uhd_fft application, or change my application to not set the source to
> external, the results are visibly better. I can't tell how accurate they
> are, but at least on the sale of observing the spectra they look centered
> more appropriately.
>
> Does that mean I'm using the internal oscillator? Is there something I'm
> doing wrong? Did I fry the external LO input when I had too high of a
> signal connected (I think it was just over 30 dBm)?
>
> -- Eric C.
>
>
> _______________________________________________
> 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/20160527/786822cb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-7.png
Type: image/png
Size: 1495 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160527/786822cb/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: n2xx_clock_inp.png
Type: image/png
Size: 10356 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160527/786822cb/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: n2xx_clock_inp.png
Type: image/png
Size: 10356 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160527/786822cb/attachment-0005.png>
------------------------------
Message: 6
Date: Fri, 27 May 2016 14:31:51 -0400
From: Dave NotTelling <[email protected]>
To: Nate Temple <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Environmental Questions About the X310 and
N210
Message-ID:
<CAK6GVuNcpsAPK+y3fDY0eT=vKu=-dyku6z2ikcvjchbaqgr...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks!
On Fri, May 27, 2016 at 1:59 PM, Nate Temple <[email protected]> wrote:
> Hi Dave,
>
> For the UBX-40/UBX-160
>
> Operating Temperature Range: 0-40 ?C
> Operating Humidity: 10% to 90%, noncondensing
>
> We don't have any MTBF statistics.
>
> Regards,
> Nate
>
>
>
> > On May 20, 2016, at 10:21 AM, Dave NotTelling via USRP-users <
> [email protected]> wrote:
> >
> > Is there any information about the max and min temps, and max humidity
> for both radios using the UBX-160 and UBX-40 daugherboards? What about
> MTBF numbers?
> > _______________________________________________
> > 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/20160527/834bbdd7/attachment-0001.html>
------------------------------
Message: 7
Date: Fri, 27 May 2016 16:02:39 -0400
From: Jeremy Hershberger <[email protected]>
To: Ian Buckley <[email protected]>
Cc: "Marcus D. Leech" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Tuning Resolution of B210 RF Front end
Message-ID:
<camziklqhxmmfhj3v6kek58qsdoy1eebv+cb+q+uoe-tysuf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Ian,
I was able to tune to 50MHz and computed the difference between target and
actual frequency and got 0 Hz. (by examining the tune_result_t from the
set_rx_freq() and set_tx_freq() methods)
If I repeat the same test with a target freq of 50MHz+2.4Hz, I get a
difference of 0.0158099 Hz.
If the tuning resolution is in 2.4Hz steps, shouldn't I get a 0Hz
difference?
-Jeremy
On Thu, May 26, 2016 at 8:34 PM, Ian Buckley via USRP-users <
[email protected]> wrote:
> 2.4Hz for AD9361
> -Ian
>
> On Thu, May 26, 2016 at 3:26 PM, Marcus D. Leech via USRP-users <
> [email protected]> wrote:
>
>> On 05/26/2016 06:17 PM, Jeremy Hershberger via USRP-users wrote:
>>
>>> Using the functions multi_usrp::get_fe_rx_freq_range() and
>>> multi_usrp::get_fe_tx_freq_range() I am supposed to get the low, high, and
>>> step size of just the RF front end (without the DSP chain). However, when
>>> I looked at the attributes of both freq_range_t objects that were returned,
>>> the start is 50MHz, the stop is 6GHz, but the step size was set to 0.
>>>
>>> What is the step size of the RF Front End on the B210 (without the DSP)?
>>>
>>> Thanks,
>>>
>>> -Jeremy
>>>
>>> It depends on the master-clock setting, almost certainly, and the B2xx
>> have variable master-clock rates. Ettus engineers can comment
>> further on why this value is set to zero, but my guess it's due to the
>> above....
>>
>>
>>
>> _______________________________________________
>> 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/20160527/487d8009/attachment-0001.html>
------------------------------
Message: 8
Date: Fri, 27 May 2016 16:10:37 -0400
From: "Marcus D. Leech" <[email protected]>
To: Jeremy Hershberger <[email protected]>, Ian Buckley
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Tuning Resolution of B210 RF Front end
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 05/27/2016 04:02 PM, Jeremy Hershberger wrote:
> Ian,
>
> I was able to tune to 50MHz and computed the difference between target
> and actual frequency and got 0 Hz. (by examining the tune_result_t
> from the set_rx_freq() and set_tx_freq() methods)
>
> If I repeat the same test with a target freq of 50MHz+2.4Hz, I get a
> difference of 0.0158099 Hz.
>
> If the tuning resolution is in 2.4Hz steps, shouldn't I get a 0Hz
> difference?
>
>
> -Jeremy
Probably just some floating-point rounding going on somewhere in the stack.
But to put this in perspective, a difference of 0.0158099 Hz is 0.3PPB
at your desired center frequency. Since you likely aren't using a
reference that is that good, a disagreement in what the Fc is of
0.3PPB makes utterly no difference.
Further, since we're talking about floating-point here, it is unsound
programming practice to do something like:
if (value_that_was_computed == value_that_is_a_constant)
When using finite-precision floating-point math. So if this
0.01558Hz difference is important because you're doing comparisons like the
above, consider using a "isnearlythesameas()" type operation.
>
> On Thu, May 26, 2016 at 8:34 PM, Ian Buckley via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> 2.4Hz for AD9361
> -Ian
>
> On Thu, May 26, 2016 at 3:26 PM, Marcus D. Leech via USRP-users
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> On 05/26/2016 06:17 PM, Jeremy Hershberger via USRP-users wrote:
>
> Using the functions multi_usrp::get_fe_rx_freq_range() and
> multi_usrp::get_fe_tx_freq_range() I am supposed to get
> the low, high, and step size of just the RF front end
> (without the DSP chain). However, when I looked at the
> attributes of both freq_range_t objects that were
> returned, the start is 50MHz, the stop is 6GHz, but the
> step size was set to 0.
>
> What is the step size of the RF Front End on the B210
> (without the DSP)?
>
> Thanks,
>
> -Jeremy
>
> It depends on the master-clock setting, almost certainly, and
> the B2xx have variable master-clock rates. Ettus engineers
> can comment
> further on why this value is set to zero, but my guess it's
> due to the above....
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> 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/20160527/c9b0d7a5/attachment-0001.html>
------------------------------
Message: 9
Date: Fri, 27 May 2016 14:16:19 -0600
From: "Eric C." <[email protected]>
To: Nick Foster <[email protected]>
Cc: Marcus M?ller <[email protected]>,
[email protected]
Subject: Re: [USRP-users] External Reference
Message-ID:
<cabf-ja4egcysqvbltc7p6h2kojcjnmzjiqbtmbo8xwupdn1...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks for the input. It was a little hard getting to it but I measured the
resistance on D503 and it was just 50 ohms. So I think I fried that. I also
put a scope at R505 and I didn't see the 10 MHz signal. I verified the
signal was coming in using the proper pin on J510. Looks like my 4V peak to
peak reference clock did some damage. Ugh, this is a bad day. I thought
carefully about the powers input to the receiver but for some reason
totally forgot to check on the strength of the reference clock. (I didn't
follow your procedure yet on checking the other components, I'm not sure we
have all the equipment to do that).
So I take it that means it's just using the internal oscillator? I also
have a GPS DO that isn't hooked up, but looking at the schematic and board
it looks like that signal comes in in front of the damaged components
anyway, so I'm hosed with that too, right? Plus, we were wanting to use the
same reference for the signal generator and the USRP.
Does ettus do repairs? I guess I'd have to determine if the cost of that is
worth it to the company.
-- Eric C.
On Fri, May 27, 2016 at 12:17 PM, Nick Foster via USRP-users <
[email protected]> wrote:
> Just get 10MHz at +15dBm into the clock input and see if you see a
> reasonable clock waveform at the output of R535 on a 'scope.
>
> On Fri, May 27, 2016 at 11:08 AM Marcus M?ller <[email protected]>
> wrote:
>
>> Hi Eric,
>>
>> 1W (30dBm) are indeed a bit much for the input circuitry. Let's look at
>> this:
>> 1W means an U_eff of about 7V (considering the input impedance for 10MHz
>> should pretty much be 50 Ohm, and [image: $P = \frac{U^2}R \implies U =
>> \sqrt{PR}$]).
>> The two leads "exiting" to the right reach a clock multiplexer [1] which
>> is spec'ed for a maximum input voltage of 3.3V with the supply we drive it.
>>
>>
>>
>> Now, to not exceed that, we have D503 [2] in place, which is basically
>> meant to suppress things > 12V as TVS diode. Check that diode, simply by
>> using a multimeter on the 10MHz ref input (remove all power from the USRP
>> before!). It should show the typical "resistance increase" of any capacitor
>> measured with DC: starting low, than getting progressively higher, reaching
>> some Megaohm value at the end. You might not see that "starting low" moment.
>>
>> Now, 12V > 3.3V, and that's why D501, a bog-normal BAV99T, with a forward
>> voltage of about 1.0V under "normal" circumstances (ie. current limited to
>> 50mA). I think you might have fried that. That one is a bit harder to test,
>> especially since I don't want to damage the clock multiplexer in the
>> process. Hm. A test method for this would be locate R535 and R536 on the
>> motherboard, and measure the DC resistance of R535?transformer coil of
>> T501?R536; you can't do that with a single multimeter. You'll need to make
>> a I/U curve for input voltages from -0.7 ? 0V ... 0.7V and see whether you
>> can see a offset "diode" typical behaviour in the current. Make very sure
>> not to touch your voltage source to places that shouldn't get 0.7V. If you
>> don't see that, D501 or the semiconductors in the input stage of the clock
>> plexer are probably damaged.
>>
>> So, in case the diode is damaged, you can try replacing it. Please only
>> do that if you have enough experience with SMD rework ? more often than
>> necessary, people use to much heat with too much air flow in a hot air gun
>> and blow away half of a board's components.
>>
>> If you chose not to try to replace D501, or the input stage is indeed
>> damaged, you could also still use another N2xx and a MIMO cable. I'll not
>> advertise this too much, since no-one tested it, but it's possible you can
>> set the clock source to "mimo", get a Serial-attached-SCSI cable (which has
>> a MIMO-cable-compatible connector), hack it off, find the right pins that
>> connect to what's A8 / A9 in J707 of our N2xx schematic [3, p. 5],
>>
>> At any rate, if you have further problems, or questions,
>> [email protected] is there for you!
>>
>> Best regards,
>> Marcus
>>
>>
>> [1] U18, SY89545L
>> [2] Semtech uClamp1211P
>> [3] http://files.ettus.com/schematics/n200/n2xx.pdf
>>
>> On 27.05.2016 17:36, Eric C. via USRP-users wrote:
>>
>> I have an N210 that I'm using with a WBX daughter card. In my lab at work
>> we have a high quality 10 MHz reference that I'm inputting to the USRP. I
>> think initially I had it hooked up at too high of a power. But I've since
>> added attenuators and it's at about 11 dBm, comfortably below the 15 dB
>> limit (that I should have looked up first).
>>
>> I'm using gnuradio companion and the USRP source block has the time
>> reference set up as external. When I run in this mode, I'm getting quite
>> wrong frequency results (18 kHz off on a signal in the 400 MHz range). But
>> the E light is a steady green while I'm collecting (sometimes it turns off
>> when I'm not receiving though, sometimes it stays on). When I run the
>> uhd_fft application, or change my application to not set the source to
>> external, the results are visibly better. I can't tell how accurate they
>> are, but at least on the sale of observing the spectra they look centered
>> more appropriately.
>>
>> Does that mean I'm using the internal oscillator? Is there something I'm
>> doing wrong? Did I fry the external LO input when I had too high of a
>> signal connected (I think it was just over 30 dBm)?
>>
>> -- Eric C.
>>
>>
>> _______________________________________________
>> 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/20160527/58c496f2/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 27 May 2016 20:23:37 +0000
From: Nick Foster <[email protected]>
To: "Eric C." <[email protected]>
Cc: Marcus M?ller <[email protected]>,
[email protected]
Subject: Re: [USRP-users] External Reference
Message-ID:
<ca+jmmq9kqhxkz0rtyaxw4_6qdmgkvxq3cw5kxoag2dhkikr...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
If you select "external reference" but no clock is available due to damage,
the 100MHz master oscillator is free-running, which seems to fit your
observations.
On Fri, May 27, 2016, 1:16 PM Eric C. <[email protected]> wrote:
> Thanks for the input. It was a little hard getting to it but I measured
> the resistance on D503 and it was just 50 ohms. So I think I fried that. I
> also put a scope at R505 and I didn't see the 10 MHz signal. I verified the
> signal was coming in using the proper pin on J510. Looks like my 4V peak to
> peak reference clock did some damage. Ugh, this is a bad day. I thought
> carefully about the powers input to the receiver but for some reason
> totally forgot to check on the strength of the reference clock. (I didn't
> follow your procedure yet on checking the other components, I'm not sure we
> have all the equipment to do that).
>
> So I take it that means it's just using the internal oscillator? I also
> have a GPS DO that isn't hooked up, but looking at the schematic and board
> it looks like that signal comes in in front of the damaged components
> anyway, so I'm hosed with that too, right? Plus, we were wanting to use the
> same reference for the signal generator and the USRP.
>
> Does ettus do repairs? I guess I'd have to determine if the cost of that
> is worth it to the company.
>
>
> -- Eric C.
>
> On Fri, May 27, 2016 at 12:17 PM, Nick Foster via USRP-users <
> [email protected]> wrote:
>
>> Just get 10MHz at +15dBm into the clock input and see if you see a
>> reasonable clock waveform at the output of R535 on a 'scope.
>>
>> On Fri, May 27, 2016 at 11:08 AM Marcus M?ller <
>> [email protected]> wrote:
>>
>>> Hi Eric,
>>>
>>> 1W (30dBm) are indeed a bit much for the input circuitry. Let's look at
>>> this:
>>> 1W means an U_eff of about 7V (considering the input impedance for 10MHz
>>> should pretty much be 50 Ohm, and [image: $P = \frac{U^2}R \implies U =
>>> \sqrt{PR}$]).
>>> The two leads "exiting" to the right reach a clock multiplexer [1] which
>>> is spec'ed for a maximum input voltage of 3.3V with the supply we drive it.
>>>
>>>
>>>
>>> Now, to not exceed that, we have D503 [2] in place, which is basically
>>> meant to suppress things > 12V as TVS diode. Check that diode, simply by
>>> using a multimeter on the 10MHz ref input (remove all power from the USRP
>>> before!). It should show the typical "resistance increase" of any capacitor
>>> measured with DC: starting low, than getting progressively higher, reaching
>>> some Megaohm value at the end. You might not see that "starting low" moment.
>>>
>>> Now, 12V > 3.3V, and that's why D501, a bog-normal BAV99T, with a
>>> forward voltage of about 1.0V under "normal" circumstances (ie. current
>>> limited to 50mA). I think you might have fried that. That one is a bit
>>> harder to test, especially since I don't want to damage the clock
>>> multiplexer in the process. Hm. A test method for this would be locate R535
>>> and R536 on the motherboard, and measure the DC resistance of
>>> R535?transformer coil of T501?R536; you can't do that with a single
>>> multimeter. You'll need to make a I/U curve for input voltages from -0.7 ?
>>> 0V ... 0.7V and see whether you can see a offset "diode" typical behaviour
>>> in the current. Make very sure not to touch your voltage source to places
>>> that shouldn't get 0.7V. If you don't see that, D501 or the semiconductors
>>> in the input stage of the clock plexer are probably damaged.
>>>
>>> So, in case the diode is damaged, you can try replacing it. Please only
>>> do that if you have enough experience with SMD rework ? more often than
>>> necessary, people use to much heat with too much air flow in a hot air gun
>>> and blow away half of a board's components.
>>>
>>> If you chose not to try to replace D501, or the input stage is indeed
>>> damaged, you could also still use another N2xx and a MIMO cable. I'll not
>>> advertise this too much, since no-one tested it, but it's possible you can
>>> set the clock source to "mimo", get a Serial-attached-SCSI cable (which has
>>> a MIMO-cable-compatible connector), hack it off, find the right pins that
>>> connect to what's A8 / A9 in J707 of our N2xx schematic [3, p. 5],
>>>
>>> At any rate, if you have further problems, or questions,
>>> [email protected] is there for you!
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>>> [1] U18, SY89545L
>>> [2] Semtech uClamp1211P
>>> [3] http://files.ettus.com/schematics/n200/n2xx.pdf
>>>
>>> On 27.05.2016 17:36, Eric C. via USRP-users wrote:
>>>
>>> I have an N210 that I'm using with a WBX daughter card. In my lab at
>>> work we have a high quality 10 MHz reference that I'm inputting to the
>>> USRP. I think initially I had it hooked up at too high of a power. But I've
>>> since added attenuators and it's at about 11 dBm, comfortably below the 15
>>> dB limit (that I should have looked up first).
>>>
>>> I'm using gnuradio companion and the USRP source block has the time
>>> reference set up as external. When I run in this mode, I'm getting quite
>>> wrong frequency results (18 kHz off on a signal in the 400 MHz range). But
>>> the E light is a steady green while I'm collecting (sometimes it turns off
>>> when I'm not receiving though, sometimes it stays on). When I run the
>>> uhd_fft application, or change my application to not set the source to
>>> external, the results are visibly better. I can't tell how accurate they
>>> are, but at least on the sale of observing the spectra they look centered
>>> more appropriately.
>>>
>>> Does that mean I'm using the internal oscillator? Is there something I'm
>>> doing wrong? Did I fry the external LO input when I had too high of a
>>> signal connected (I think it was just over 30 dBm)?
>>>
>>> -- Eric C.
>>>
>>>
>>> _______________________________________________
>>> 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/20160527/e2c2f02d/attachment-0001.html>
------------------------------
Message: 11
Date: Fri, 27 May 2016 13:26:24 -0700
From: Ian Buckley <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: Jeremy Hershberger <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Tuning Resolution of B210 RF Front end
Message-ID:
<CAM_0ocHiVgZsFhwcuCOD0xsvvM7qfnJUms9A=wnej2wiedw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Jeremy FWIW That number is straight from ADI's data book, I haven't tried
to derive it by reverse engineering the synthesizer design. It may for
example be a worst case example at the upper frequency limit rather than a
fixed granularity over the whole frequency range. What happens if you go
repeat your experiment up near 6GHz?
-Ian
On Fri, May 27, 2016 at 1:10 PM, Marcus D. Leech <[email protected]> wrote:
> On 05/27/2016 04:02 PM, Jeremy Hershberger wrote:
>
> Ian,
>
> I was able to tune to 50MHz and computed the difference between target and
> actual frequency and got 0 Hz. (by examining the tune_result_t from the
> set_rx_freq() and set_tx_freq() methods)
>
> If I repeat the same test with a target freq of 50MHz+2.4Hz, I get a
> difference of 0.0158099 Hz.
>
> If the tuning resolution is in 2.4Hz steps, shouldn't I get a 0Hz
> difference?
>
>
> -Jeremy
>
> Probably just some floating-point rounding going on somewhere in the stack.
>
> But to put this in perspective, a difference of 0.0158099 Hz is 0.3PPB at
> your desired center frequency. Since you likely aren't using a
> reference that is that good, a disagreement in what the Fc is of 0.3PPB
> makes utterly no difference.
>
> Further, since we're talking about floating-point here, it is unsound
> programming practice to do something like:
>
> if (value_that_was_computed == value_that_is_a_constant)
>
> When using finite-precision floating-point math. So if this 0.01558Hz
> difference is important because you're doing comparisons like the
> above, consider using a "isnearlythesameas()" type operation.
>
>
>
> On Thu, May 26, 2016 at 8:34 PM, Ian Buckley via USRP-users <
> [email protected]> wrote:
>
>> 2.4Hz for AD9361
>> -Ian
>>
>> On Thu, May 26, 2016 at 3:26 PM, Marcus D. Leech via USRP-users <
>> [email protected]> wrote:
>>
>>> On 05/26/2016 06:17 PM, Jeremy Hershberger via USRP-users wrote:
>>>
>>>> Using the functions multi_usrp::get_fe_rx_freq_range() and
>>>> multi_usrp::get_fe_tx_freq_range() I am supposed to get the low, high, and
>>>> step size of just the RF front end (without the DSP chain). However, when
>>>> I looked at the attributes of both freq_range_t objects that were returned,
>>>> the start is 50MHz, the stop is 6GHz, but the step size was set to 0.
>>>>
>>>> What is the step size of the RF Front End on the B210 (without the DSP)?
>>>>
>>>> Thanks,
>>>>
>>>> -Jeremy
>>>>
>>>> It depends on the master-clock setting, almost certainly, and the B2xx
>>> have variable master-clock rates. Ettus engineers can comment
>>> further on why this value is set to zero, but my guess it's due to the
>>> above....
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20160527/98470709/attachment-0001.html>
------------------------------
Message: 12
Date: Fri, 27 May 2016 14:28:25 -0600
From: "Eric C." <[email protected]>
To: Nick Foster <[email protected]>
Cc: "Eric C." <[email protected]>, Marcus M?ller
<[email protected]>, [email protected]
Subject: Re: [USRP-users] External Reference
Message-ID:
<cabf-ja7zd5s8z5n7r0utdxxa1gyzw8dzxkfvzhhirgc4svx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Yes, that seems to match what I'm seeing. But if I select "default" then
what happens? I'm getting much better frequency results by selecting
"default."
Also, I nearly always get the E light to come on, whether I choose External
or Default. Sometimes it only stays on when I'm receiving data, but it
almost always is on. Should the E LED be on if I've selected "external" but
a signal isn't coming in, due to damage?
-- Eric C.
On Fri, May 27, 2016 at 2:23 PM, Nick Foster <[email protected]> wrote:
> If you select "external reference" but no clock is available due to
> damage, the 100MHz master oscillator is free-running, which seems to fit
> your observations.
>
> On Fri, May 27, 2016, 1:16 PM Eric C. <[email protected]> wrote:
>
>> Thanks for the input. It was a little hard getting to it but I measured
>> the resistance on D503 and it was just 50 ohms. So I think I fried that. I
>> also put a scope at R505 and I didn't see the 10 MHz signal. I verified the
>> signal was coming in using the proper pin on J510. Looks like my 4V peak to
>> peak reference clock did some damage. Ugh, this is a bad day. I thought
>> carefully about the powers input to the receiver but for some reason
>> totally forgot to check on the strength of the reference clock. (I didn't
>> follow your procedure yet on checking the other components, I'm not sure we
>> have all the equipment to do that).
>>
>> So I take it that means it's just using the internal oscillator? I also
>> have a GPS DO that isn't hooked up, but looking at the schematic and board
>> it looks like that signal comes in in front of the damaged components
>> anyway, so I'm hosed with that too, right? Plus, we were wanting to use the
>> same reference for the signal generator and the USRP.
>>
>> Does ettus do repairs? I guess I'd have to determine if the cost of that
>> is worth it to the company.
>>
>>
>> -- Eric C.
>>
>> On Fri, May 27, 2016 at 12:17 PM, Nick Foster via USRP-users <
>> [email protected]> wrote:
>>
>>> Just get 10MHz at +15dBm into the clock input and see if you see a
>>> reasonable clock waveform at the output of R535 on a 'scope.
>>>
>>> On Fri, May 27, 2016 at 11:08 AM Marcus M?ller <
>>> [email protected]> wrote:
>>>
>>>> Hi Eric,
>>>>
>>>> 1W (30dBm) are indeed a bit much for the input circuitry. Let's look at
>>>> this:
>>>> 1W means an U_eff of about 7V (considering the input impedance for
>>>> 10MHz should pretty much be 50 Ohm, and [image: $P = \frac{U^2}R
>>>> \implies U = \sqrt{PR}$]).
>>>> The two leads "exiting" to the right reach a clock multiplexer [1]
>>>> which is spec'ed for a maximum input voltage of 3.3V with the supply we
>>>> drive it.
>>>>
>>>>
>>>>
>>>> Now, to not exceed that, we have D503 [2] in place, which is basically
>>>> meant to suppress things > 12V as TVS diode. Check that diode, simply by
>>>> using a multimeter on the 10MHz ref input (remove all power from the USRP
>>>> before!). It should show the typical "resistance increase" of any capacitor
>>>> measured with DC: starting low, than getting progressively higher, reaching
>>>> some Megaohm value at the end. You might not see that "starting low"
>>>> moment.
>>>>
>>>> Now, 12V > 3.3V, and that's why D501, a bog-normal BAV99T, with a
>>>> forward voltage of about 1.0V under "normal" circumstances (ie. current
>>>> limited to 50mA). I think you might have fried that. That one is a bit
>>>> harder to test, especially since I don't want to damage the clock
>>>> multiplexer in the process. Hm. A test method for this would be locate R535
>>>> and R536 on the motherboard, and measure the DC resistance of
>>>> R535?transformer coil of T501?R536; you can't do that with a single
>>>> multimeter. You'll need to make a I/U curve for input voltages from -0.7 ?
>>>> 0V ... 0.7V and see whether you can see a offset "diode" typical behaviour
>>>> in the current. Make very sure not to touch your voltage source to places
>>>> that shouldn't get 0.7V. If you don't see that, D501 or the semiconductors
>>>> in the input stage of the clock plexer are probably damaged.
>>>>
>>>> So, in case the diode is damaged, you can try replacing it. Please only
>>>> do that if you have enough experience with SMD rework ? more often than
>>>> necessary, people use to much heat with too much air flow in a hot air gun
>>>> and blow away half of a board's components.
>>>>
>>>> If you chose not to try to replace D501, or the input stage is indeed
>>>> damaged, you could also still use another N2xx and a MIMO cable. I'll not
>>>> advertise this too much, since no-one tested it, but it's possible you can
>>>> set the clock source to "mimo", get a Serial-attached-SCSI cable (which has
>>>> a MIMO-cable-compatible connector), hack it off, find the right pins that
>>>> connect to what's A8 / A9 in J707 of our N2xx schematic [3, p. 5],
>>>>
>>>> At any rate, if you have further problems, or questions,
>>>> [email protected] is there for you!
>>>>
>>>> Best regards,
>>>> Marcus
>>>>
>>>>
>>>> [1] U18, SY89545L
>>>> [2] Semtech uClamp1211P
>>>> [3] http://files.ettus.com/schematics/n200/n2xx.pdf
>>>>
>>>> On 27.05.2016 17:36, Eric C. via USRP-users wrote:
>>>>
>>>> I have an N210 that I'm using with a WBX daughter card. In my lab at
>>>> work we have a high quality 10 MHz reference that I'm inputting to the
>>>> USRP. I think initially I had it hooked up at too high of a power. But I've
>>>> since added attenuators and it's at about 11 dBm, comfortably below the 15
>>>> dB limit (that I should have looked up first).
>>>>
>>>> I'm using gnuradio companion and the USRP source block has the time
>>>> reference set up as external. When I run in this mode, I'm getting quite
>>>> wrong frequency results (18 kHz off on a signal in the 400 MHz range). But
>>>> the E light is a steady green while I'm collecting (sometimes it turns off
>>>> when I'm not receiving though, sometimes it stays on). When I run the
>>>> uhd_fft application, or change my application to not set the source to
>>>> external, the results are visibly better. I can't tell how accurate they
>>>> are, but at least on the sale of observing the spectra they look centered
>>>> more appropriately.
>>>>
>>>> Does that mean I'm using the internal oscillator? Is there something
>>>> I'm doing wrong? Did I fry the external LO input when I had too high of a
>>>> signal connected (I think it was just over 30 dBm)?
>>>>
>>>> -- Eric C.
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20160527/ba905610/attachment-0001.html>
------------------------------
Message: 13
Date: Fri, 27 May 2016 16:33:28 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] External Reference
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 05/27/2016 04:28 PM, Eric C. via USRP-users wrote:
> Yes, that seems to match what I'm seeing. But if I select "default"
> then what happens? I'm getting much better frequency results by
> selecting "default."
>
> Also, I nearly always get the E light to come on, whether I choose
> External or Default. Sometimes it only stays on when I'm receiving
> data, but it almost always is on. Should the E LED be on if I've
> selected "external" but a signal isn't coming in, due to damage?
>
>
> -- Eric C.
Default on N210 means, AFAIR, "GSPDO if there is one, else internal".
>
> On Fri, May 27, 2016 at 2:23 PM, Nick Foster <[email protected]
> <mailto:[email protected]>> wrote:
>
> If you select "external reference" but no clock is available due
> to damage, the 100MHz master oscillator is free-running, which
> seems to fit your observations.
>
>
> On Fri, May 27, 2016, 1:16 PM Eric C. <[email protected]
> <mailto:[email protected]>> wrote:
>
> Thanks for the input. It was a little hard getting to it but I
> measured the resistance on D503 and it was just 50 ohms. So I
> think I fried that. I also put a scope at R505 and I didn't
> see the 10 MHz signal. I verified the signal was coming in
> using the proper pin on J510. Looks like my 4V peak to peak
> reference clock did some damage. Ugh, this is a bad day. I
> thought carefully about the powers input to the receiver but
> for some reason totally forgot to check on the strength of the
> reference clock. (I didn't follow your procedure yet on
> checking the other components, I'm not sure we have all the
> equipment to do that).
>
> So I take it that means it's just using the internal
> oscillator? I also have a GPS DO that isn't hooked up, but
> looking at the schematic and board it looks like that signal
> comes in in front of the damaged components anyway, so I'm
> hosed with that too, right? Plus, we were wanting to use the
> same reference for the signal generator and the USRP.
>
> Does ettus do repairs? I guess I'd have to determine if the
> cost of that is worth it to the company.
>
>
> -- Eric C.
>
> On Fri, May 27, 2016 at 12:17 PM, Nick Foster via USRP-users
> <[email protected]
> <mailto:[email protected]>> wrote:
>
> Just get 10MHz at +15dBm into the clock input and see if
> you see a reasonable clock waveform at the output of R535
> on a 'scope.
>
> On Fri, May 27, 2016 at 11:08 AM Marcus M?ller
> <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi Eric,
>
> 1W (30dBm) are indeed a bit much for the input
> circuitry. Let's look at this:
> 1W means an U_eff of about 7V (considering the input
> impedance for 10MHz should pretty much be 50 Ohm, and
> $P = \frac{U^2}R \implies U = \sqrt{PR}$).
> The two leads "exiting" to the right reach a clock
> multiplexer [1] which is spec'ed for a maximum input
> voltage of 3.3V with the supply we drive it.
>
>
>
> Now, to not exceed that, we have D503 [2] in place,
> which is basically meant to suppress things > 12V as
> TVS diode. Check that diode, simply by using a
> multimeter on the 10MHz ref input (remove all power
> from the USRP before!). It should show the typical
> "resistance increase" of any capacitor measured with
> DC: starting low, than getting progressively higher,
> reaching some Megaohm value at the end. You might not
> see that "starting low" moment.
>
> Now, 12V > 3.3V, and that's why D501, a bog-normal
> BAV99T, with a forward voltage of about 1.0V under
> "normal" circumstances (ie. current limited to 50mA).
> I think you might have fried that. That one is a bit
> harder to test, especially since I don't want to
> damage the clock multiplexer in the process. Hm. A
> test method for this would be locate R535 and R536 on
> the motherboard, and measure the DC resistance of
> R535?transformer coil of T501?R536; you can't do that
> with a single multimeter. You'll need to make a I/U
> curve for input voltages from -0.7 ? 0V ... 0.7V and
> see whether you can see a offset "diode" typical
> behaviour in the current. Make very sure not to touch
> your voltage source to places that shouldn't get 0.7V.
> If you don't see that, D501 or the semiconductors in
> the input stage of the clock plexer are probably damaged.
>
> So, in case the diode is damaged, you can try
> replacing it. Please only do that if you have enough
> experience with SMD rework ? more often than
> necessary, people use to much heat with too much air
> flow in a hot air gun and blow away half of a board's
> components.
>
> If you chose not to try to replace D501, or the input
> stage is indeed damaged, you could also still use
> another N2xx and a MIMO cable. I'll not advertise this
> too much, since no-one tested it, but it's possible
> you can set the clock source to "mimo", get a
> Serial-attached-SCSI cable (which has a
> MIMO-cable-compatible connector), hack it off, find
> the right pins that connect to what's A8 / A9 in J707
> of our N2xx schematic [3, p. 5],
>
> At any rate, if you have further problems, or
> questions, [email protected]
> <mailto:[email protected]> is there for you!
>
> Best regards,
> Marcus
>
>
> [1] U18, SY89545L
> [2] Semtech uClamp1211P
> [3] http://files.ettus.com/schematics/n200/n2xx.pdf
>
> On 27.05.2016 17:36, Eric C. via USRP-users wrote:
>> I have an N210 that I'm using with a WBX daughter
>> card. In my lab at work we have a high quality 10 MHz
>> reference that I'm inputting to the USRP. I think
>> initially I had it hooked up at too high of a power.
>> But I've since added attenuators and it's at about 11
>> dBm, comfortably below the 15 dB limit (that I should
>> have looked up first).
>>
>> I'm using gnuradio companion and the USRP source
>> block has the time reference set up as external. When
>> I run in this mode, I'm getting quite wrong frequency
>> results (18 kHz off on a signal in the 400 MHz
>> range). But the E light is a steady green while I'm
>> collecting (sometimes it turns off when I'm not
>> receiving though, sometimes it stays on). When I run
>> the uhd_fft application, or change my application to
>> not set the source to external, the results are
>> visibly better. I can't tell how accurate they are,
>> but at least on the sale of observing the spectra
>> they look centered more appropriately.
>>
>> Does that mean I'm using the internal oscillator? Is
>> there something I'm doing wrong? Did I fry the
>> external LO input when I had too high of a signal
>> connected (I think it was just over 30 dBm)?
>>
>> -- Eric C.
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> <mailto:[email protected]>
>>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> <mailto:[email protected]>
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[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/20160527/24d629bd/attachment-0001.html>
------------------------------
Message: 14
Date: Fri, 27 May 2016 16:51:27 -0400
From: Jeremy Hershberger <[email protected]>
To: Ian Buckley <[email protected]>
Cc: "Marcus D. Leech" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Tuning Resolution of B210 RF Front end
Message-ID:
<camziklqx_aralodtnetwlb9hkbmgs3kebsekickcn86uu_9...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Ian,
I repeated the experiment @ 5.9GHz, which is an even 2.4Hz divisor and got
2.38419Hz.
I was thinking that the actual tuning frequency was just a LUT value from
the LO frac PLL divisor setting. But apparently, the value is being
measured somehow from the hardware.
On Fri, May 27, 2016 at 4:26 PM, Ian Buckley <[email protected]> wrote:
> Jeremy FWIW That number is straight from ADI's data book, I haven't tried
> to derive it by reverse engineering the synthesizer design. It may for
> example be a worst case example at the upper frequency limit rather than a
> fixed granularity over the whole frequency range. What happens if you go
> repeat your experiment up near 6GHz?
> -Ian
>
> On Fri, May 27, 2016 at 1:10 PM, Marcus D. Leech <[email protected]>
> wrote:
>
>> On 05/27/2016 04:02 PM, Jeremy Hershberger wrote:
>>
>> Ian,
>>
>> I was able to tune to 50MHz and computed the difference between target
>> and actual frequency and got 0 Hz. (by examining the tune_result_t from the
>> set_rx_freq() and set_tx_freq() methods)
>>
>> If I repeat the same test with a target freq of 50MHz+2.4Hz, I get a
>> difference of 0.0158099 Hz.
>>
>> If the tuning resolution is in 2.4Hz steps, shouldn't I get a 0Hz
>> difference?
>>
>>
>> -Jeremy
>>
>> Probably just some floating-point rounding going on somewhere in the
>> stack.
>>
>> But to put this in perspective, a difference of 0.0158099 Hz is 0.3PPB at
>> your desired center frequency. Since you likely aren't using a
>> reference that is that good, a disagreement in what the Fc is of 0.3PPB
>> makes utterly no difference.
>>
>> Further, since we're talking about floating-point here, it is unsound
>> programming practice to do something like:
>>
>> if (value_that_was_computed == value_that_is_a_constant)
>>
>> When using finite-precision floating-point math. So if this 0.01558Hz
>> difference is important because you're doing comparisons like the
>> above, consider using a "isnearlythesameas()" type operation.
>>
>>
>>
>> On Thu, May 26, 2016 at 8:34 PM, Ian Buckley via USRP-users <
>> [email protected]> wrote:
>>
>>> 2.4Hz for AD9361
>>> -Ian
>>>
>>> On Thu, May 26, 2016 at 3:26 PM, Marcus D. Leech via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> On 05/26/2016 06:17 PM, Jeremy Hershberger via USRP-users wrote:
>>>>
>>>>> Using the functions multi_usrp::get_fe_rx_freq_range() and
>>>>> multi_usrp::get_fe_tx_freq_range() I am supposed to get the low, high, and
>>>>> step size of just the RF front end (without the DSP chain). However, when
>>>>> I looked at the attributes of both freq_range_t objects that were
>>>>> returned,
>>>>> the start is 50MHz, the stop is 6GHz, but the step size was set to 0.
>>>>>
>>>>> What is the step size of the RF Front End on the B210 (without the
>>>>> DSP)?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Jeremy
>>>>>
>>>>> It depends on the master-clock setting, almost certainly, and the B2xx
>>>> have variable master-clock rates. Ettus engineers can comment
>>>> further on why this value is set to zero, but my guess it's due to
>>>> the above....
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20160527/a012d305/attachment-0001.html>
------------------------------
Message: 15
Date: Fri, 27 May 2016 16:55:41 -0400
From: "Marcus D. Leech" <[email protected]>
To: Jeremy Hershberger <[email protected]>, Ian Buckley
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Tuning Resolution of B210 RF Front end
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 05/27/2016 04:51 PM, Jeremy Hershberger wrote:
> Ian,
>
> I repeated the experiment @ 5.9GHz, which is an even 2.4Hz divisor and
> got 2.38419Hz.
>
> I was thinking that the actual tuning frequency was just a LUT value
> from the LO frac PLL divisor setting. But apparently, the value is
> being measured somehow from the hardware.
It's not being measured, just calculated from the hardware parameters
(refclock frequency, PLL register widths, etc).
>
> On Fri, May 27, 2016 at 4:26 PM, Ian Buckley <[email protected]
> <mailto:[email protected]>> wrote:
>
> Jeremy FWIW That number is straight from ADI's data book, I
> haven't tried to derive it by reverse engineering the synthesizer
> design. It may for example be a worst case example at the upper
> frequency limit rather than a fixed granularity over the whole
> frequency range. What happens if you go repeat your experiment up
> near 6GHz?
> -Ian
>
> On Fri, May 27, 2016 at 1:10 PM, Marcus D. Leech
> <[email protected] <mailto:[email protected]>> wrote:
>
> On 05/27/2016 04:02 PM, Jeremy Hershberger wrote:
>> Ian,
>>
>> I was able to tune to 50MHz and computed the difference
>> between target and actual frequency and got 0 Hz. (by
>> examining the tune_result_t from the set_rx_freq() and
>> set_tx_freq() methods)
>>
>> If I repeat the same test with a target freq of 50MHz+2.4Hz,
>> I get a difference of 0.0158099 Hz.
>>
>> If the tuning resolution is in 2.4Hz steps, shouldn't I get a
>> 0Hz difference?
>>
>>
>> -Jeremy
> Probably just some floating-point rounding going on somewhere
> in the stack.
>
> But to put this in perspective, a difference of 0.0158099 Hz
> is 0.3PPB at your desired center frequency. Since you likely
> aren't using a
> reference that is that good, a disagreement in what the Fc
> is of 0.3PPB makes utterly no difference.
>
> Further, since we're talking about floating-point here, it is
> unsound programming practice to do something like:
>
> if (value_that_was_computed == value_that_is_a_constant)
>
> When using finite-precision floating-point math. So if
> this 0.01558Hz difference is important because you're doing
> comparisons like the
> above, consider using a "isnearlythesameas()" type operation.
>
>
>>
>> On Thu, May 26, 2016 at 8:34 PM, Ian Buckley via USRP-users
>> <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> 2.4Hz for AD9361
>> -Ian
>>
>> On Thu, May 26, 2016 at 3:26 PM, Marcus D. Leech via
>> USRP-users <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> On 05/26/2016 06:17 PM, Jeremy Hershberger via
>> USRP-users wrote:
>>
>> Using the functions
>> multi_usrp::get_fe_rx_freq_range() and
>> multi_usrp::get_fe_tx_freq_range() I am supposed
>> to get the low, high, and step size of just the
>> RF front end (without the DSP chain). However,
>> when I looked at the attributes of both
>> freq_range_t objects that were returned, the
>> start is 50MHz, the stop is 6GHz, but the step
>> size was set to 0.
>>
>> What is the step size of the RF Front End on the
>> B210 (without the DSP)?
>>
>> Thanks,
>>
>> -Jeremy
>>
>> It depends on the master-clock setting, almost
>> certainly, and the B2xx have variable master-clock
>> rates. Ettus engineers can comment
>> further on why this value is set to zero, but my
>> guess it's due to the above....
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> <mailto:[email protected]>
>>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>> _______________________________________________
>> 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/20160527/1966e7e3/attachment-0001.html>
------------------------------
Message: 16
Date: Fri, 27 May 2016 21:38:51 +0000
From: "Swanson, Craig" <[email protected]>
To: "[email protected]"
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: [USRP-users] FW: I am dead in the water due to the following
error: RFNoC not found.
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Richard,
Here is what Marcus suggested and it worked for me.
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th Street NW
Atlanta, GA 30318
Cell: 770-298-9156
http://www.gtri.gatech.edu
From: Marcus M?ller [mailto:[email protected]]
Sent: Saturday, May 07, 2016 2:23 PM
To: Swanson, Craig <[email protected]>; Martin Braun
<[email protected]>; Jonathon Pendlum <[email protected]>
Cc: [email protected]; Myers, David <[email protected]>
Subject: Re: [USRP-users] I am dead in the water due to the following error:
RFNoC not found.
Hi Craig,
this won't work because you're (implicitly) checking out the "master" branch of
UHD - which isn't RFNoC'ed.
So, I recommend modifying your script:
instead of
git clone https://github.com/EttusResearch/uhd
use
git clone -b rfnoc-devel https://github.com/EttusResearch/uhd
git submodule update --init ##fill the fpga-src directory with the matching
FPGA code
. Of course, if you've still got the downloaded files around, you can check out
the right branch right now
cd ~/uhd/host/build
sudo make uninstall
rm -r * ##cleans the build directory
git checkout -t rfnoc-devel ## checks out the RFNoC version of UHD
git submodule update --init ##fill the fpga-src directory with the matching
FPGA code
cmake -DENABLE_E300=ON ../
make -j8 && sudo make install && sudo ldconfig
cd ~/gnuradio/build
cmake ..
make -j8 && sudo make install && sudo ldconfig
and then try building gr-ettus again.
Best regards,
Marcus
On 07.05.2016 20:11, Swanson, Craig via USRP-users wrote:
Martin,
When I perform a cmake ../ in gr-ettus, I get the following error:
CMake Error at CMakeLists.txt:113 (message):
RFNoC not found.
Here are more details of the error:
craig@craig-VirtualBox:~/gr-ettus/build (master)$ cmake ../
-- The CXX compiler identification is GNU 4.8.4
-- The C compiler identification is GNU 4.8.4
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Build type not specified: defaulting to release.
-- Boost version: 1.54.0
-- Found the following Boost libraries:
-- filesystem
-- system
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
-- Found UHD: /usr/local/lib/libuhd.so
CMake Error at CMakeLists.txt:113 (message):
RFNoC not found.
Here is the script I am using:
git clone https://github.com/EttusResearch/uhd
mkdir ~/uhd/host/build
cd ~/uhd/host/build
cmake ../ -DENABLE_E300=ON ../
make -j8
sudo make install -j8
sudo ldconfig
git clone --recursive http://git.gnuradio.org/git/gnuradio.git
mkdir ~/gnuradio/build
cd ~/gnuradio/build
cmake ../
make -j8
sudo make install -j8
sudo ldconfig
git clone https://github.com/EttusResearch/gr-ettus.git?
mkdir ~/gr-ettus/build
cd ~/gr-ettus/build
cmake ../
make -j8
sudo make install -j8
sudo ldconfig
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu
_______________________________________________
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/20160527/aecb1e6a/attachment-0001.html>
------------------------------
Message: 17
Date: Fri, 27 May 2016 18:44:28 -0400
From: "Collins, Richard" <[email protected]>
To: "Swanson, Craig" <[email protected]>,
[email protected]
Subject: Re: [USRP-users] FW: I am dead in the water due to the
following error: RFNoC not found.
Message-ID:
<CABgQ8cYBOu1AZ-gt7tDLmpiFGQhMUF7Z_HZ3xZXAzV=yldm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks Craig,
I think it worked for me too ( "make" finished successfully, with only the
one error from "make test" ).
But I'm getting a different error now when trying to build gr-ettus, which
most likely has to do with my trying to use a different
CMAKE_INSTALL_PREFIX. But since that's a different problem, I'll start a
new thread.
Richard
On Fri, May 27, 2016 at 5:38 PM, Swanson, Craig <
[email protected]> wrote:
> Richard,
>
> Here is what Marcus suggested and it worked for me.
>
> Craig
>
>
>
> *Craig F. Swanson*
>
> *Research Engineer II*
>
> *Information and Communications Laboratory*
>
> *Communications, Systems, and Spectrum Division*
>
> Georgia Tech Research Institute
>
> Room 560
>
> 250 14th Street NW
>
> Atlanta, GA 30318
>
> Cell: 770-298-9156
>
> http://www.gtri.gatech.edu
>
>
>
> *From:* Marcus M?ller [mailto:[email protected]]
> *Sent:* Saturday, May 07, 2016 2:23 PM
> *To:* Swanson, Craig <[email protected]>; Martin Braun <
> [email protected]>; Jonathon Pendlum <[email protected]>
> *Cc:* [email protected]; Myers, David <
> [email protected]>
> *Subject:* Re: [USRP-users] I am dead in the water due to the following
> error: RFNoC not found.
>
>
>
> Hi Craig,
>
>
> this won't work because you're (implicitly) checking out the "master"
> branch of UHD - which isn't RFNoC'ed.
>
> So, I recommend modifying your script:
>
> instead of
>
> git clone https://github.com/EttusResearch/uhd
>
> use
>
> git clone -b rfnoc-devel https://github.com/EttusResearch/uhd
> git submodule update --init ##fill the fpga-src directory with the
> matching FPGA code
>
> . Of course, if you've still got the downloaded files around, you can
> check out the right branch right now
>
> cd ~/uhd/host/build
> sudo make uninstall
> rm -r * ##cleans the build directory
> git checkout -t rfnoc-devel ## checks out the RFNoC version of UHD
> git submodule update --init ##fill the fpga-src directory with the
> matching FPGA code
> cmake -DENABLE_E300=ON ../
> make -j8 && sudo make install && sudo ldconfig
>
> cd ~/gnuradio/build
> cmake ..
> make -j8 && sudo make install && sudo ldconfig
>
> and then try building gr-ettus again.
>
> Best regards,
> Marcus
> On 07.05.2016 20:11, Swanson, Craig via USRP-users wrote:
>
> Martin,
>
> When I perform a cmake ../ in gr-ettus, I get the following error:
>
> CMake Error at CMakeLists.txt:113 (message):
>
> RFNoC not found.
>
>
>
> Here are more details of the error:
>
> craig@craig-VirtualBox:~/gr-ettus/build (master)$ cmake ../
>
> -- The CXX compiler identification is GNU 4.8.4
>
> -- The C compiler identification is GNU 4.8.4
>
> -- Check for working CXX compiler: /usr/bin/c++
>
> -- Check for working CXX compiler: /usr/bin/c++ -- works
>
> -- Detecting CXX compiler ABI info
>
> -- Detecting CXX compiler ABI info - done
>
> -- Check for working C compiler: /usr/bin/cc
>
> -- Check for working C compiler: /usr/bin/cc -- works
>
> -- Detecting C compiler ABI info
>
> -- Detecting C compiler ABI info - done
>
> -- Build type not specified: defaulting to release.
>
> -- Boost version: 1.54.0
>
> -- Found the following Boost libraries:
>
> -- filesystem
>
> -- system
>
> -- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
>
> -- Found UHD: /usr/local/lib/libuhd.so
>
> CMake Error at CMakeLists.txt:113 (message):
>
> RFNoC not found.
>
>
> Here is the script I am using:
>
>
>
> git clone https://github.com/EttusResearch/uhd
>
> mkdir ~/uhd/host/build
>
> cd ~/uhd/host/build
>
> cmake ../ -DENABLE_E300=ON ../
>
> make -j8
>
> sudo make install -j8
>
> sudo ldconfig
>
>
> git clone --recursive http://git.gnuradio.org/git/gnuradio.git
> mkdir ~/gnuradio/build
>
> cd ~/gnuradio/build
>
> cmake ../
>
> make -j8
>
> sudo make install -j8
>
> sudo ldconfig
>
>
>
> git clone https://github.com/EttusResearch/gr-ettus.git?
>
> mkdir ~/gr-ettus/build
>
> cd ~/gr-ettus/build
>
> cmake ../
>
> make -j8
>
> sudo make install -j8
>
> sudo ldconfig
>
>
>
>
>
> Craig
>
>
>
> *Craig F. Swanson*
>
> *Research Engineer II*
>
> *Information and Communications Laboratory*
>
> *Communications, Systems, and Spectrum Division*
>
> *Georgia Tech Research Institute*
>
>
> *Room 560 250 14th St NW*
>
> *Atlanta, GA 30318*
>
> *Cell: 770.298.9156 <770.298.9156>*
>
> http://www.gtri.gatech.edu
>
>
>
>
>
>
> _______________________________________________
>
> 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/20160527/08c1d14f/attachment-0001.html>
------------------------------
Message: 18
Date: Fri, 27 May 2016 19:41:51 -0400
From: "Collins, Richard" <[email protected]>
To: [email protected]
Subject: [USRP-users] Trouble building gr-ettus (using custom install
prefix, and (rfnoc-)radio-redo)
Message-ID:
<CABgQ8cYE=W8m-0R0Eia5Rzim3qLOmo=loohq+jjpnh1on-h...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
The quick and dirty:
I'm trying to build gr-ettus but I get an error that UHDConfig.cmake can't
be found, as seen in [1]. It was suggested in the #gnuradio Freenode irc
chatroom to "modify the paths in it to [my] local installation", and that I
might need to put it in gr-ettus.
So I modified it as can be seen in [2], and moved it like this:
<user>@<machine>:/opt/src/gr-ettus/build$ cp
../../gnuradio-rfnoc/cmake/Modules/FindUHD.cmake ../cmake/Modules/
After running cmake again, I get the error that can be seen in [3] that
says "RFNoC not found."
--------
The longer explanation:
It may be good to know that I originally thought the problem [1] was due to
my installing UHD and GNURadio into separate directories.
First, i used build-gnuradio script to install dependencies (since that
script now seems to work for ubuntu16.04) and then
created/chown'ed/chgrp'ed destination folders in /opt/. I then git cloned
the projects and ran cmake for uhd (first) and gnuradio (second) before
running "make", "make test", "make install", and "sudo ldconfig", but
targeted to /opt/uhd-rfnoc and /opt/gnuradio-rfnoc, respectively.
Since ending up with this error [1], I uninstalled them in the reverse
order (gnuradio first, then uhd) with the following commands from each's
build directory:
make uninstall
git clean -d -x -f
sudo ldconfig
I then re-installed both using the following commands (now both targeted to
/opt/gnuradio-rfnoc/), and tried (again) to get gr-ettus working before
getting* the same exact error in [1].*
UHD:
git clone --recursive git://github.com/EttusResearch/uhd.git uhd-rfnoc
cd uhd-rfnoc
git checkout -b *rfnoc-radio-redo* -t origin/rfnoc-radio-redo
mkdir host/build && cd host/build
*cmake -DCMAKE_INSTALL_PREFIX=/opt/gnuradio-rfnoc/ -DENABLE_X300=ON
-DENABLE_E300=ON -DENABLE_B200=OFF -DLIB_SUFFIX=64 -Wno-dev ../*
make -j8 && make test && make install && sudo ldconfig
GNURadio:
git clone --recursive https://github.com/gnuradio/gnuradio.git
gnuradio-rfnoc
cd gnuradio-rfnoc
git checkout *maint*
*cmake -DCMAKE_INSTALL_PREFIX=/opt/**gnuradio-rfnoc/ -DLIB_SUFFIX=64
-DENABLE_GR_COMEDI=OFF -Wno-dev ../*
make -j8 && make test && make install && sudo ldconfig
gr-ettus:
git clone https://github.com/EttusResearch/gr-ettus.git
cd gr-ettus
git checkout
*radio-redo*mkdir build && cd build
*cmake -DCMAKE_INSTALL_PREFIX=/opt/**gnuradio-rfnoc/ Wno-dev ../*
# (tried with and without the -DLIB_SUFFIX=64)
# Again, in case it wasn't clear, error [1] happened again right here.
Installing into a separate directory is important to me for the sake of not
having to reinstall the operating system if I want to uninstall a version
of UHD or switch between versions of UHD/GNURadio. (Also, "make uninstall"
doesn't seem to work cleanly, or i did some command out of order almost a
year ago on my laptop, and am perpetually stuck with an rfnoc version of
uhd being detected no matter what I do.)
It's been suggested to use rfnoc-radio-redo instead of rfnoc-devel, and to
use Vivado 15.04 instead of 14.04, so I hope that's correct. I haven't seen
the "radio-redo" version of gr-ettus mentioned, but i figured it should
match.
Any advice on where to go from here would be appreciated. Although, I'm
pondering blowing it all away and reverting to an old image of the hard
drives before installing UHD and GNURadio, just this time not using custom
directories, and maybe not worrying about a "LIB_SUFFIX".
--------
[1]: http://pastebin.com/1cfVuu35
[2]: http://pastebin.com/8XaAcBiZ
[3]: http://pastebin.com/FDZyQY4y
[4]: http://pastebin.com/31yJjUNu
Thanks,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160527/7c2954cb/attachment-0001.html>
------------------------------
Message: 19
Date: Sat, 28 May 2016 10:09:10 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Trouble building gr-ettus (using custom
install prefix, and (rfnoc-)radio-redo)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Richard,
I'll address both issues one after the other. First the "not finding
UHD" issue:
to be honest, I'd rather not change the CMake scripts if avoidable;
instead, we should teach the build system too look for your things in
opt/gnuradio-rfnoc!
So, CMake asks pkg-config where UHD is installed. pkg-config has a
default directory (for my distro, it's /usr/lib64/pkgconfig, but this
might be different for yours) where it looks for .pc files that contain
info on how to include headers and link against libraries.
Now, my assumption is that you built your UHD in a manner that did not
put its .pc where pkg-config can find them (makes sense). Look into your
installation prefix: is there a lib/pkgconfig/ directory somewhere that
contains an uhd.pc file? If so:
you will need to inform pkg-config to look into that directory. That's
easy, just
export PKG_CONFIG_PATH=/path/to/the/uhd.pc:$PKG_CONFIG_PATH
It's also important to make sure the UHD that you find this way is the
first UHD your compiler and linker use. Otherwise, it might use another
installation of UHD, and as it seems, that doesn't have RFNoC. Also, the
build and installation order MUST be:
1. UHD (with RFNoC) build & install
2. GNU Radio (which by itself is RFNoC-agnostic, but needs to link
against the right UHD) build & install
3. gr-ettus (which depends on both GNU Radio and RFNoC'ed UHD) build &
install
So, you'd do about the same you did for PKG_CONFIG_PATH with
LD_LIBRARY_PATH for the directory containing the freshly built
libuhd.so. Then there's the issue of Python needing to find the GNU
Radio packages, so you'll need to fix PYTHONPATH, too (but I'll cover
that as soon as you've come as far as being able to find the right UHD
with RFNoC).
Frankly, doing this non-default prefix install by hand is a bit complex,
especially, if you haven't done this a couple of times before. That's
really really the purpose of PyBOMBS, to install libraries and software
into a non-system prefix, and giving you a readily written script that
you can source with your shell, giving you full access to what is
installed to that prefix. So, in an attempt to conserve as much of your
sanity as possible: What Linux distribution are you using? Many popular
ones are fully covered by pybombs, and it's easy to make pybombs install
UHD with RFNoC, GNU Radio and gr-ettus
Best regards,
Marcus
On 28.05.2016 01:41, Collins, Richard via USRP-users wrote:
> Hello,
>
> The quick and dirty:
>
> I'm trying to build gr-ettus but I get an error that UHDConfig.cmake
> can't be found, as seen in [1]. It was suggested in the #gnuradio
> Freenode irc chatroom to "modify the paths in it to [my] local
> installation", and that I might need to put it in gr-ettus.
>
> So I modified it as can be seen in [2], and moved it like this:
> <user>@<machine>:/opt/src/gr-ettus/build$ cp
> ../../gnuradio-rfnoc/cmake/Modules/FindUHD.cmake ../cmake/Modules/
>
> After running cmake again, I get the error that can be seen in [3]
> that says "RFNoC not found."
>
> --------
> The longer explanation:
>
> It may be good to know that I originally thought the problem [1] was
> due to my installing UHD and GNURadio into separate directories.
>
> First, i used build-gnuradio script to install dependencies (since
> that script now seems to work for ubuntu16.04) and then
> created/chown'ed/chgrp'ed destination folders in /opt/. I then git
> cloned the projects and ran cmake for uhd (first) and gnuradio
> (second) before running "make", "make test", "make install", and "sudo
> ldconfig", but targeted to /opt/uhd-rfnoc and /opt/gnuradio-rfnoc,
> respectively.
>
> Since ending up with this error [1], I uninstalled them in the reverse
> order (gnuradio first, then uhd) with the following commands from
> each's build directory:
> make uninstall
> git clean -d -x -f
> sudo ldconfig
>
> I then re-installed both using the following commands (now both
> targeted to /opt/gnuradio-rfnoc/), and tried (again) to get gr-ettus
> working before getting*the same exact error in [1].*
>
> UHD:
> git clone --recursive git://github.com/EttusResearch/uhd.git
> <http://github.com/EttusResearch/uhd.git> uhd-rfnoc
> cd uhd-rfnoc
> git checkout -b *rfnoc-radio-redo* -t origin/rfnoc-radio-redo
> mkdir host/build && cd host/build
> *cmake -DCMAKE_INSTALL_PREFIX=/opt/gnuradio-rfnoc/ -DENABLE_X300=ON
> -DENABLE_E300=ON -DENABLE_B200=OFF -DLIB_SUFFIX=64 -Wno-dev ../*
> make -j8 && make test && make install && sudo ldconfig
>
> GNURadio:
> git clone --recursive https://github.com/gnuradio/gnuradio.git
> gnuradio-rfnoc
> cd gnuradio-rfnoc
> git checkout *maint*
> *cmake -DCMAKE_INSTALL_PREFIX=/opt/**gnuradio-rfnoc/ -DLIB_SUFFIX=64
> -DENABLE_GR_COMEDI=OFF -Wno-dev ../*
> make -j8 && make test && make install && sudo ldconfig
>
> gr-ettus:
> git clone https://github.com/EttusResearch/gr-ettus.git
> cd gr-ettus
> git checkout *radio-redo
> *mkdir build && cd build*
> cmake -DCMAKE_INSTALL_PREFIX=/opt/**gnuradio-rfnoc/ Wno-dev ../*
> # (tried with and without the -DLIB_SUFFIX=64)
> # Again, in case it wasn't clear, error [1] happened again right here.
>
> Installing into a separate directory is important to me for the sake
> of not having to reinstall the operating system if I want to uninstall
> a version of UHD or switch between versions of UHD/GNURadio. (Also,
> "make uninstall" doesn't seem to work cleanly, or i did some command
> out of order almost a year ago on my laptop, and am perpetually stuck
> with an rfnoc version of uhd being detected no matter what I do.)
>
> It's been suggested to use rfnoc-radio-redo instead of rfnoc-devel,
> and to use Vivado 15.04 instead of 14.04, so I hope that's correct. I
> haven't seen the "radio-redo" version of gr-ettus mentioned, but i
> figured it should match.
>
> Any advice on where to go from here would be appreciated. Although,
> I'm pondering blowing it all away and reverting to an old image of the
> hard drives before installing UHD and GNURadio, just this time not
> using custom directories, and maybe not worrying about a "LIB_SUFFIX".
>
> --------
>
> [1]: http://pastebin.com/1cfVuu35
> [2]: http://pastebin.com/8XaAcBiZ
> [3]: http://pastebin.com/FDZyQY4y
> [4]: http://pastebin.com/31yJjUNu
>
>
> Thanks,
>
> Richard
>
>
> _______________________________________________
> 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/20160528/c8af10ab/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 69, Issue 28
******************************************
