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: RFNoC: Vivado environment variables not persisting during
make (James Dunn)
2. E310 in network mode (Jason Matusiak)
3. Re: E310 in network mode (Philip Balister)
4. Re: E310 in network mode (Jason Matusiak)
5. Re: E310 in network mode (Philip Balister)
6. Re: E310 in network mode (Jason Matusiak)
7. Re: E310 in network mode (Philip Balister)
8. Re: NI2901 receive power (emre g?ng?r)
9. How can I confirm USRP Hardware functionality without
additional USRPs? (Ash Pesante)
10. Re: NI2901 receive power (Marcus D. Leech)
11. NI USRP-2920 might not be getting a PPS signal (Taylor Eisman)
12. USRP2 enclosure wanted (Evert Verduin)
13. Re: USRP Source receiving incorrect number of samples
(Jessica Iwamoto)
14. Incorrect tags in frequency sweep (Jessica Iwamoto)
15. Re: NI USRP-2920 might not be getting a PPS signal
(Marcus D. Leech)
16. Re: How can I confirm USRP Hardware functionality without
additional USRPs? (Marcus D. Leech)
17. NI USRP-2901 firmware, FPGA images to run with UHD (Fazle Elahi)
18. Re: NI USRP-2901 firmware, FPGA images to run with UHD
(Derek Kozel)
19. Re: NI2901 receive power (emre g?ng?r)
----------------------------------------------------------------------
Message: 1
Date: Mon, 17 Apr 2017 10:03:46 -0700
From: James Dunn <[email protected]>
To: Nicolas Cuervo <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNoC: Vivado environment variables not
persisting during make
Message-ID:
<ca+viziqiazkdrsqqzbqg-xmvxveaa18a8g4qqysvqcde26f...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Nicolas,
Thank you for the detailed reply. Since posting this issue, I have done a
reformat of our OS (Ubuntu 16.04.2) and a fresh installation RFNoC, Gnu
Radio, gr-ettus, and Vivado (2015.4). The issue has gone away with this
re-format. I am thinking that there may have been lingering pieces of an
old, non-RFNoC build of Gnu Radio on the system, that were interfering with
the environment setup.
I can now see Vivado in the environment after sourcing the setup:
root@sc2-tkn-rfnoc:~/tkn-scripts# source
/opt/Xilinx/Vivado/2015.4/settings64.sh
root@sc2-tkn-rfnoc:~/tkn-scripts# source
~/rfnoc/src/uhd-fpga/usrp3/top/x300/setupenv.sh
Setting up a 64-bit FPGA build environment for the USRP-X3x0...
- Vivado: Found (/opt/Xilinx/Vivado/2015.4/bin)
- Vivado HLS: Found (/opt/Xilinx/Vivado_HLS/2015.4/bin)
Environment successfully initialized.
root@sc2-tkn-rfnoc:~/tkn-scripts# vivado -version
Vivado v2015.4 (64-bit)
SW Build 1412921 on Wed Nov 18 09:44:32 MST 2015
IP Build 1412160 on Tue Nov 17 13:47:24 MST 2015
Copyright 1986-2015 Xilinx, Inc. All Rights Reserved.
As well as run the testbench for the threshold block as you describe:
========================================================
TESTBENCH FINISHED: noc_block_threshold
- Time elapsed: 7100 ns
- Tests Expected: 5
- Tests Run: 5
- Tests Passed: 5
Result: PASSED
========================================================
Thank you and best regards,
James
On Sun, Apr 16, 2017 at 5:26 AM, Nicolas Cuervo <[email protected]>
wrote:
> Hello James,
>
> Sorry for taking so much time getting back to you. Your email seems to
> have fallen through the cracks. This is very interesting, and for now I
> can't reproduce your issue. Could you please tell us what OS are you using?
>
> When you manually source the vivado environment, can you confirm that the
> vivado tools are available thereafter? To check this, please set up your
> vivado environment, which by your email I see it is located at
> [/rfnoc/src/uhd-fpga/usrp3/top/x300/setupenv.sh]. So please run:
>
> $ source ~/rfnoc/src/uhd-fpga/usrp3/top/x300/setupenv.sh
>
> and then run:
> $ vivado -version
>
> which should just give you the version installed. Just a small sanity
> check.
>
> In addition, have you tried running any of the other testbenches that are
> shipped within the uhd-fpga repository? After setting up your vivado
> environment, please go to any of the testbench locations and run the
> testbench for the given block. Let's say you run the testbench for the
> threshold block, so you go to ~/rfnoc/src/uhd-fpga/usrp3/
> lib/rfnoc/noc_block_threshold_tb/ (which I chose randomly, you can choose
> any of the testbench locations available to run this test) and within that
> directory you run:
>
> $ make xsim
>
> Which will start the testbench. Please let us know if this process
> finishes successfully or if it fails with the same error as the one
> described in your email.
>
> This is just will check a couple of things: first, if successful, it will
> say that the environment is being successfully sourced and that the
> environment is not going away unnoticed. Second, it will determine that
> the "sourcing" process and the run of the actual testbench are working as
> expected. Third, it will tell us if your Vivado Lab installation is being
> accepted by the tools as an acceptable version for running testbenches
> (which it should). Basically, it is just sanity checking.
>
> The fact that it initializes the vivado environment and thereafter it says
> that it is not found is definitely concerning. After we are certain that
> the required software is working as expected, we might dive into the
> rfnocmodtool generated block for more specific details.
>
> Regards,
> - Nicolas
>
>
>
> On Thu, Mar 30, 2017 at 9:19 PM, James Dunn via USRP-users <
> [email protected]> wrote:
>
>> Hello,
>>
>> I am working through the "Creating and running HDL testbenches" section
>> of the "Getting Started with RFNoC Development" wiki article, and run into
>> the same library problem as this thread describes:
>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/
>> 2016-February/018671.html
>>
>> I am able to follow all steps up until make noc_block_gain_tb without
>> issue, but when making the block, I see the following:
>>
>> dunn@bwrcdpt3600-11:~/rfnoc/src/rfnoc-tutorial/build$ make
>> noc_block_gain_tb
>> Setting up a 64-bit FPGA build environment for the USRP-E3x0...
>> - Vivado: Found (/opt/Xilinx/Vivado_Lab/2015.4/bin)
>> - Vivado HLS: Found (/opt/Xilinx/Vivado_HLS/2015.4/bin)
>>
>> Environment successfully initialized.
>> BUILDER: Checking tools...
>> * GNU bash, version 4.3.46(1)-release (x86_64-pc-linux-gnu)
>> * Python 2.7.12
>> * ERROR: Vivado not found in environment. Please run setupenv.sh
>> /home/dunn/rfnoc/src/uhd-fpga/usrp3/top/../tools/make/viv_preamble.mak:47:
>> recipe for target '.check_tool' failed
>> make[4]: *** [.check_tool] Error 1
>> CMakeFiles/noc_block_gain_tb.dir/build.make:57: recipe for target
>> 'CMakeFiles/noc_block_gain_tb' failed
>> make[3]: *** [CMakeFiles/noc_block_gain_tb] Error 2
>> CMakeFiles/Makefile2:131: recipe for target
>> 'CMakeFiles/noc_block_gain_tb.dir/all'
>> failed
>> make[2]: *** [CMakeFiles/noc_block_gain_tb.dir/all] Error 2
>> CMakeFiles/Makefile2:138: recipe for target
>> 'CMakeFiles/noc_block_gain_tb.dir/rule'
>> failed
>> make[1]: *** [CMakeFiles/noc_block_gain_tb.dir/rule] Error 2
>> Makefile:199: recipe for target 'noc_block_gain_tb' failed
>> make: *** [noc_block_gain_tb] Error 2
>>
>>
>> It looks like make is sourcing
>> ~/rfnoc/src/uhd-fpga/usrp3/top/x300/setupenv.sh
>> and finding the Vivado paths, but immediately afterward is unable to find
>> the environment variables. I have tried manually running "source
>> ./setupenv.sh" in the above directory, but still get the same error, when
>> this seemed to fix the problem in the thread mentioned above. I have also
>> sourced ~/rfnoc/setup_env.sh.
>>
>> We are using an X310 radio, with UHD, GNU Radio, and gr-ettus installed
>> per the wiki instructions using PyBOMBS. My login shell is bash, and I have
>> pointed sh to bash instead of dash. Our Vivado installation also seems to
>> be the correct version. Are there any recommendations on how to get this
>> environment variable to persist during make?
>>
>> Thank you and regards,
>> James Dunn
>>
>> _______________________________________________
>> 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/20170417/35bdf576/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 17 Apr 2017 13:32:25 -0400
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] E310 in network mode
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
I am going to try to work with an E310 in network mode this week for the
first time, and I have a question. The ettus instructions say to
rebuild UHD with some new CMake flags. Is that the PC's UHD, or the UHD
running on the E310? I would have said the E310, but it seems like when
I run usrp_e3x0_network_mode on the unmodified E310 it doesn't error
out, so now I am not sure.
------------------------------
Message: 3
Date: Mon, 17 Apr 2017 14:09:32 -0400
From: Philip Balister <[email protected]>
To: Jason Matusiak <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] E310 in network mode
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 04/17/2017 01:32 PM, Jason Matusiak via USRP-users wrote:
> I am going to try to work with an E310 in network mode this week for the
> first time, and I have a question. The ettus instructions say to
> rebuild UHD with some new CMake flags. Is that the PC's UHD, or the UHD
> running on the E310? I would have said the E310, but it seems like when
> I run usrp_e3x0_network_mode on the unmodified E310 it doesn't error
> out, so now I am not sure.
For network mode, do not rebuild UHD on the E310, just build the same
version that is pre-installed in the E310 on the desktop.
Philip
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 4
Date: Mon, 17 Apr 2017 14:11:43 -0400
From: Jason Matusiak <[email protected]>
To: Philip Balister <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] E310 in network mode
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
HI Philip. I wasn't going to rebuild the uhd ON the E310, I just wasn't
sure whose uhd needed to be rebuilt (the one running on the E310, or the
one running on my host PC). I am guessing based on your comment that
the E310's UHD is the one to rebuild.
On 04/17/2017 02:09 PM, Philip Balister wrote:
> On 04/17/2017 01:32 PM, Jason Matusiak via USRP-users wrote:
>> I am going to try to work with an E310 in network mode this week for the
>> first time, and I have a question. The ettus instructions say to
>> rebuild UHD with some new CMake flags. Is that the PC's UHD, or the UHD
>> running on the E310? I would have said the E310, but it seems like when
>> I run usrp_e3x0_network_mode on the unmodified E310 it doesn't error
>> out, so now I am not sure.
> For network mode, do not rebuild UHD on the E310, just build the same
> version that is pre-installed in the E310 on the desktop.
>
> Philip
>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
------------------------------
Message: 5
Date: Mon, 17 Apr 2017 14:20:52 -0400
From: Philip Balister <[email protected]>
To: Jason Matusiak <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] E310 in network mode
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 04/17/2017 02:11 PM, Jason Matusiak wrote:
> HI Philip. I wasn't going to rebuild the uhd ON the E310, I just wasn't
> sure whose uhd needed to be rebuilt (the one running on the E310, or the
> one running on my host PC). I am guessing based on your comment that
> the E310's UHD is the one to rebuild.
Arg, I wasn't clear :)
If at all possible, use the preinstalled version on the E310.
You build a matching version for the PC, this is usually easier than
replacing the one on the E310.
Philip
PS: Unless you are using rfnoc :)
>
>
> On 04/17/2017 02:09 PM, Philip Balister wrote:
>> On 04/17/2017 01:32 PM, Jason Matusiak via USRP-users wrote:
>>> I am going to try to work with an E310 in network mode this week for the
>>> first time, and I have a question. The ettus instructions say to
>>> rebuild UHD with some new CMake flags. Is that the PC's UHD, or the UHD
>>> running on the E310? I would have said the E310, but it seems like when
>>> I run usrp_e3x0_network_mode on the unmodified E310 it doesn't error
>>> out, so now I am not sure.
>> For network mode, do not rebuild UHD on the E310, just build the same
>> version that is pre-installed in the E310 on the desktop.
>>
>> Philip
>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>
>
------------------------------
Message: 6
Date: Mon, 17 Apr 2017 14:23:12 -0400
From: Jason Matusiak <[email protected]>
To: Philip Balister <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] E310 in network mode
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
I don't think that I need RFNoC for this test, so we should be OK
there. If we need to use RFNoC, I assume that is a problem because UHD
would need to be rebuilt from scratch in that case, right?
On 04/17/2017 02:20 PM, Philip Balister wrote:
> On 04/17/2017 02:11 PM, Jason Matusiak wrote:
>> HI Philip. I wasn't going to rebuild the uhd ON the E310, I just wasn't
>> sure whose uhd needed to be rebuilt (the one running on the E310, or the
>> one running on my host PC). I am guessing based on your comment that
>> the E310's UHD is the one to rebuild.
> Arg, I wasn't clear :)
>
> If at all possible, use the preinstalled version on the E310.
>
> You build a matching version for the PC, this is usually easier than
> replacing the one on the E310.
>
> Philip
>
> PS: Unless you are using rfnoc :)
>
>>
>> On 04/17/2017 02:09 PM, Philip Balister wrote:
>>> On 04/17/2017 01:32 PM, Jason Matusiak via USRP-users wrote:
>>>> I am going to try to work with an E310 in network mode this week for the
>>>> first time, and I have a question. The ettus instructions say to
>>>> rebuild UHD with some new CMake flags. Is that the PC's UHD, or the UHD
>>>> running on the E310? I would have said the E310, but it seems like when
>>>> I run usrp_e3x0_network_mode on the unmodified E310 it doesn't error
>>>> out, so now I am not sure.
>>> For network mode, do not rebuild UHD on the E310, just build the same
>>> version that is pre-installed in the E310 on the desktop.
>>>
>>> Philip
>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>
------------------------------
Message: 7
Date: Mon, 17 Apr 2017 14:26:53 -0400
From: Philip Balister <[email protected]>
To: Jason Matusiak <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] E310 in network mode
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 04/17/2017 02:23 PM, Jason Matusiak wrote:
> I don't think that I need RFNoC for this test, so we should be OK
> there. If we need to use RFNoC, I assume that is a problem because UHD
> would need to be rebuilt from scratch in that case, right?
Yep. I just added it in case someone finds this in the archive :)
I'm not even sure how network mode would interact with rfnoc.
Philip
>
>
> On 04/17/2017 02:20 PM, Philip Balister wrote:
>> On 04/17/2017 02:11 PM, Jason Matusiak wrote:
>>> HI Philip. I wasn't going to rebuild the uhd ON the E310, I just wasn't
>>> sure whose uhd needed to be rebuilt (the one running on the E310, or the
>>> one running on my host PC). I am guessing based on your comment that
>>> the E310's UHD is the one to rebuild.
>> Arg, I wasn't clear :)
>>
>> If at all possible, use the preinstalled version on the E310.
>>
>> You build a matching version for the PC, this is usually easier than
>> replacing the one on the E310.
>>
>> Philip
>>
>> PS: Unless you are using rfnoc :)
>>
>>>
>>> On 04/17/2017 02:09 PM, Philip Balister wrote:
>>>> On 04/17/2017 01:32 PM, Jason Matusiak via USRP-users wrote:
>>>>> I am going to try to work with an E310 in network mode this week
>>>>> for the
>>>>> first time, and I have a question. The ettus instructions say to
>>>>> rebuild UHD with some new CMake flags. Is that the PC's UHD, or
>>>>> the UHD
>>>>> running on the E310? I would have said the E310, but it seems like
>>>>> when
>>>>> I run usrp_e3x0_network_mode on the unmodified E310 it doesn't error
>>>>> out, so now I am not sure.
>>>> For network mode, do not rebuild UHD on the E310, just build the same
>>>> version that is pre-installed in the E310 on the desktop.
>>>>
>>>> Philip
>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> [email protected]
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>
>
>
------------------------------
Message: 8
Date: Tue, 18 Apr 2017 01:54:48 +0300
From: emre g?ng?r <[email protected]>
To: [email protected], Ettus Research Support
<[email protected]>
Subject: Re: [USRP-users] NI2901 receive power
Message-ID:
<cajd1uevj0bbfq2zumik9946gann-ro0fgt7g5a+zv8ve7no...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi again,
How the signal amplitudes which varies around -1 and 1 can be related with
voltage at the antenna terminal. What represents high voltage or low
voltage. I used corner reflector which has rcs close to 1000, that means
received power must be x1000 when there is an corner reflextor in front of
the antenna when compared with without corner reflector case.
That means the voltage at the antenna terminal is sqrt(1000).
But I measured this difference like x2 x3.
I used complex to mag square as you said and I also used low pass filter. I
could not understand logic of the low pass filter but it works as I said at
least I can see x2 x3 times difference at power.
But they can not answer my questions.
I can list them again for better reading.
1. How can I interpret signal which varied around -1 and 1, how can it be
related to voltage?
2. How should I choose cutoff frequency of the filter and transition width
of the filter, how it effects?
3. Measurement not even close to theory. Why I can not take x1000 power
with corner reflector when compared to without corner reflector case.
Best wishes.
Emre.
16 Nis 2017 ?S 10:39 tarihinde "Marcus D. Leech via USRP-users" <
[email protected]> yazd?:
> On 04/16/2017 03:26 PM, emre g?ng?r via USRP-users wrote:
>
>> Hello,
>>
>> I use usrp NI2901. I connect 2 horn antennas to usrp for transmit and
>> receive and I put a corner reflector 3m away from antenna and I measure the
>> results everything is okay. I also made measurements without corner
>> reflector, I see difference between them with network analyzer.
>>
>> But when I try to analyse the received signal on gnu radio and Matlab, I
>> can not see difference between measurements (with corner reflector and
>> without corner reflector)
>> I mean the recived signal does not have amplitude, received power
>> information.
>> Received signal amplitude is always between -1 and 1 regardless of my
>> gain, high scattering obstacle usage...
>>
>> What is the problem here, or how can I have received power information
>> with gnu radio?
>>
>> Best regards.
>> Emre.
>>
>>
>> The samples within Gnu Radio are complex-floats, and usually scaled into
> {-1,+1.0}, which is what you're seeing in terms of individual samples.
>
> Those samples are linearly-proportional to the instantaneous voltage as
> seen at the antenna terminals. If you want to turn that into something that
> is linearly-proportional to *power* as seen at the antenna terminals,
> you should compute complex-to-mag**2 on the samples, and then low-pass
> filter the result.
>
> Now, this won't be an absolute power level, just something that is
> linearly proportional to the power as seen at your antenna terminals. If
> you want
> *absolute* power, then you'll have to calibrate your receive setup with
> calibrated signals sources, and you'll have to do so for all the
> sample-rate,
> gain, and frequency settings you plan to use. USRPs are not
> calibrated laboratory instruments, like spectrum or network analysers.
> They are
> very general-purpose radios. If you want to use them for calibrated
> power measurement, then you'll have to undertake your own calibration
> process--that's just part of your own application of a very
> general-purpose component like USRPs.
>
>
>
>
> _______________________________________________
> 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/20170418/0c6a9fb3/attachment-0001.html>
------------------------------
Message: 9
Date: Mon, 17 Apr 2017 10:12:35 -0400
From: Ash Pesante <[email protected]>
To: [email protected]
Subject: [USRP-users] How can I confirm USRP Hardware functionality
without additional USRPs?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hello USRP Users! Have a transmission issue that I?m completely stumped on,
hoping I can get some insight, as this is my first experience with USRP devices
(Though I?ve used SDRs for receiving extensively)
Issue:
I?m having issues with transmitting signals on a used N210 I picked up? I see
energy on the frequency but no actual ?content?. How can I confirm that the
N210/SBX is operating properly without the use of a secondary UHD device?
Information on Verifying the Operation of the USRP Using UHD and GNU Radio -
Ettus Knowledge Base
<https://kb.ettus.com/Verifying_the_Operation_of_the_USRP_Using_UHD_and_GNU_Radio>
seems to require specialized signal analyzers or additional USRPs as shown in
other guides. I?m just trying to confirm this thing is operational. Best case
scenario, I?d like to hear some audio play over an FRS radio (NBFM) to confirm
its operational. I?m able to detect energy on the frequency, but it seems
unaffected by the use or non-use of an antenna, so I?m thinking there?s a
grounding problem or something I?m doing wrong, if the SBX isn?t a dud
(purchased from Ebay).
Is it possible that this SBX or N210 have custom
software/configuration/calibration? Am I wrong in thinking all you need hooked
up is power, ethernet, daughterboard and antenna? Could a lack of GPSDO be the
problem?
Longish Background:
Just got in last week an N210 w/SBX Daughterboard. Purchased used on Ebay, it
came with just the boards, screws, bulkhead cables and that?s it... I purchased
a 6V 3A charger off Amazon and it boots and responds fine. I?m able to receive
FRS frequencies using GNU Radio. But that?s the extent of the good news.
I?m having issues confirming that the radio is transmitting properly. The
use-case is OpenBTS 2G/3G, but when I use OpenBTS I get energy on the frequency
but phones can?t see it. At first I thought it was software issue, but I?m not
even able to get a simple NBFM audio signal to be received by a walky-talky.
When I?m not having underflows, I get just straight static (Using
http://files.ettus.com/tutorials/labs/Lab_1-5.pdf
<http://files.ettus.com/tutorials/labs/Lab_1-5.pdf> for GRC). After a bit of
troubleshooting, it seems that the energy is coming from the board, and not the
TX/RX output, as when I remove the antenna nothing changes, and signal can only
be seen when within 6? from the N210. Unfortunately in my frustration I
deleted the wrong virtual machine and lost all of the .grc files I had created?
But I can try to recreate them if they are needed.
I?ve gone through GRC based tests, as well as used the tx_waveform and
siggen_gui commands and all I get is energy but no audio on our systems (both
FRS radios, and a proprietary SDR system that won?t work with GNU Radio). I
also ran a benchmark_rate and confirmed an underflow problem, but otherwise
looks ok. ./benchmark_rate --rx_rate 10e6 --tx_rate 10e6 returns the following:
https://pastebin.com/qHPQYkkB <https://pastebin.com/qHPQYkkB>
I?ve used ?Firmware 10? and ?Firmware 11? for sure, as well as UHD 3.7 through
latest (UHD 3.9.1 I believe). I?ve used Ubuntu 12.04 through 16.10. Debian and
the like. I?ve used virtual machines and full-featured Intel integrated boards.
32 and 64 bit. Precompiled dpkg and built from source?.and they all have the
same issue. Energy and no content. I?ve reached the extent of my
knowledge-base, and so I?m reaching out to the community.
Thanks ahead for the help!
Ash Pesante
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170417/a7ea4bdc/attachment-0001.html>
------------------------------
Message: 10
Date: Mon, 17 Apr 2017 19:15:57 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] NI2901 receive power
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 04/17/2017 06:54 PM, emre g?ng?r via USRP-users wrote:
> Hi again,
>
> How the signal amplitudes which varies around -1 and 1 can be related
> with voltage at the antenna terminal. What represents high voltage or
> low voltage. I used corner reflector which has rcs close to 1000, that
> means received power must be x1000 when there is an corner reflextor
> in front of the antenna when compared with without corner reflector case.
>
> That means the voltage at the antenna terminal is sqrt(1000).
> But I measured this difference like x2 x3.
> I used complex to mag square as you said and I also used low pass
> filter. I could not understand logic of the low pass filter but it
> works as I said at least I can see x2 x3 times difference at power.
>
> But they can not answer my questions.
> I can list them again for better reading.
>
> 1. How can I interpret signal which varied around -1 and 1, how can it
> be related to voltage?
Because real-world, AC signals (like radio waves) are the superposition
of several sinusoids, all of which, when normalized, have instantaneous
values
in {-1,+1}. This is pretty basic. In Gnu Radio, signals are
normalized into {-1.0,+1.0} you cannot know what they actually
represent at the
antenna terminals without *calibration*. This has already been
mentioned.
>
> 2. How should I choose cutoff frequency of the filter and transition
> width of the filter, how it effects?
It's *YOUR* experiment--at what rate do you wish to measure power?
>
> 3. Measurement not even close to theory. Why I can not take x1000
> power with corner reflector when compared to without corner reflector
> case.
>
> Best wishes.
> Emre.
>
>
I can't answer this, because we have only a vague understanding of your
experimental setup. Have you taken into account path-loss? And again,
without
calibration, you can only assume relative power. That is, if the
received power increases by a factor of 2, your instantaneous voltage
reading will increase
by a factor of sqrt(2), etc. But for accuracy, you need to average
these readings over several cycles--hence the low-pass filtering--I
usually just use
a single-pole IIR filter. But getting into a protracted discussion
about why one filter is better than another for a specific purpose is
best done on the
discuss-gnuradio mailing list (and also, consulting on-line DSP
forums, and cracking-open a few DSP textbooks).
------------------------------
Message: 11
Date: Mon, 17 Apr 2017 18:24:02 -0500
From: Taylor Eisman <[email protected]>
To: [email protected]
Subject: [USRP-users] NI USRP-2920 might not be getting a PPS signal
Message-ID:
<CAPr5wS0AxzX5MHwtNR2HSbMPVjShbDPTco==tXj=ktz7mv+...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I recent re-flashed my USRP-2920 with some new firmware. Originally, this
USRP worked just fine. Can anybody identify what is causing this problem,
or how to turn on the internal PPS signal?
Thanks,
Taylor
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170417/71e12060/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FORUM_001.JPG
Type: image/jpeg
Size: 89800 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170417/71e12060/attachment-0001.JPG>
------------------------------
Message: 12
Date: Tue, 18 Apr 2017 01:00:37 +0200
From: Evert Verduin <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP2 enclosure wanted
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hello usrp enthousiasts,
My name is Evert, sdr, dsp and fpga fan.
I am Dutch. Currently working as an Electronics and software engineer.
I am looking for 1 or 2 ( depends if available) ettus usrp 2 enclosures.
Who has defect usrp2's and want to sell his case. Or perhaps someone Just Has a
case for sale.
Let me know!
Evert
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170418/f5563889/attachment-0001.html>
------------------------------
Message: 13
Date: Mon, 17 Apr 2017 23:43:42 +0000
From: Jessica Iwamoto <[email protected]>
To: Marcus M?ller <[email protected]>, usrp-users
<[email protected]>
Subject: Re: [USRP-users] USRP Source receiving incorrect number of
samples
Message-ID:
<sn1pr09mb10089c32300770d7b3f7883a9b...@sn1pr09mb1008.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi all,
I was able to fix my issue and have the source receive the correct number of
samples. I originally had independent threads controlling tuning the USRP and
requesting to receive samples, but when I synchronized these commands I fixed
the issue.
Jessica
From: USRP-users [mailto:[email protected]] On Behalf Of
Jessica Iwamoto via USRP-users
Sent: Friday, April 14, 2017 4:58 PM
To: Marcus M?ller <[email protected]>; usrp-users
<[email protected]>
Subject: Re: [USRP-users] USRP Source receiving incorrect number of samples
Hi Marcus,
I have a GNU radio flowgraph in python and in my code I simply start the
flowgraph and then issue stream commands periodically using the code in my
previous email to the USRP Source in my flowgraph. I don't call recv(). Does
that make sense?
Thanks,
Jessica
From: Marcus M?ller [mailto:[email protected]]
Sent: Friday, April 14, 2017 4:23 PM
To: Jessica Iwamoto
<[email protected]<mailto:[email protected]>>; usrp-users
<[email protected]<mailto:[email protected]>>
Subject: Re: [USRP-users] USRP Source receiving incorrect number of samples
Hi Jessica,
I was specifically hoping for the section where you call recv() and with what
arguments, and how often!
Best regards,
Marcus
On 15.04.2017 01:17, Jessica Iwamoto wrote:
Thanks,
Jessica
From: USRP-users [mailto:[email protected]] On Behalf Of
Marcus M?ller via USRP-users
Sent: Friday, April 14, 2017 2:27 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] USRP Source receiving incorrect number of samples
Dear Jessica,
expected behaviour is that you might need to call recv() multiple times to get
all samples until the rx_metadata contains the end of burst flag.
This would especially be necessary if the sampling rate dictates that you get
into a timeout if you received more samples.
Now, I'm not sure this is what's happening here. Could you share the code you
use to receive samples?
Best regards,
Marcus
On 14.04.2017 22:49, Jessica Iwamoto via USRP-users wrote:
Hi all,
I am using the NUM_SAMPS_AND_DONE mode on a USRP Source on the E310 to receive
a specified number of samples periodically, but when I look at the metadata for
the received samples, the number of samples I've received is not always equal
to the number of samples I've specified to the USRP Source block. By varying
the sampling rate, requested number of samples, and period at which I receive
the bursts, I've observed the following data:
period (s)
sampling rate
# samples requested
max error on # samples received
time spent sampling (s)
1
1000000
500000
1460
0.5
1
1000000
100000
0
0.1
1
500000
100000
584
0.2
1
500000
50000
0
0.1
1
500000
5000
0
0.01
1
500000
100000
584
0.2
0.5
1000000
100000
0
0.1
2
250000
100000
0
0.4
2
1000000
500000
0
0.5
2
1000000
1000000
3212
1
0.5
1000000
200000
1168
0.2
0.5
1000000
100000
0
0.1
It seems like there is some threshold for each period such that if you spend
more time sampling than the threshold, then an incorrect number of samples is
received, regardless of the sampling rate or number of samples requested. For
example, for a period of 1s, if you spend more than 0.1s sampling then an
incorrect number of samples is received.
Any thoughts on why this might be happening?
Thanks,
Jessica
_______________________________________________
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/20170417/bedb4c37/attachment-0001.html>
------------------------------
Message: 14
Date: Tue, 18 Apr 2017 00:08:41 +0000
From: Jessica Iwamoto <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] Incorrect tags in frequency sweep
Message-ID:
<sn1pr09mb100880c97cd6b170ed6e9c6e9b...@sn1pr09mb1008.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Hi all,
I am trying to sweep a range of frequencies and record a fixed number of
samples at each interval frequency, but I am running into issues with the
stream tags. I'm using the E310 in network mode. I first tell the USRP source
to tune to a frequency by sending a command to the USRP block's message port,
then issue a stream command (using uhd.stream_cmd_t and issue_stream_cmd) to
receive a fixed number of samples at some time shortly in the future (current
time + buffer time), sleep for a period of time, and then repeat this
tuning+sampling series for the entire range of frequencies. This seems to work,
except the tags on the data show the incorrect frequency. One frequency at the
beginning gets repeated and the rest of the frequency tags are shifted one
interval too late. Any thoughts on why this might be happening?
Thank you,
Jessica
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170418/e8bc854e/attachment-0001.html>
------------------------------
Message: 15
Date: Mon, 17 Apr 2017 21:28:10 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] NI USRP-2920 might not be getting a PPS
signal
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 04/17/2017 07:24 PM, Taylor Eisman via USRP-users wrote:
> I recent re-flashed my USRP-2920 with some new firmware. Originally,
> this USRP worked just fine. Can anybody identify what is causing this
> problem, or how to turn on the internal PPS signal?
>
>
> Thanks,
>
> Taylor
>
From what I recall, there IS NO internal PPS on the N2xx or USRP2
series. That's a B210 thing, and may also be in the X3xx. But I don't
think there's
an internal PPS (at least in the standard FPGAware) on the N2xx series.
------------------------------
Message: 16
Date: Mon, 17 Apr 2017 21:34:13 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] How can I confirm USRP Hardware
functionality without additional USRPs?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 04/17/2017 10:12 AM, Ash Pesante via USRP-users wrote:
> Hello USRP Users! Have a transmission issue that I?m completely
> stumped on, hoping I can get some insight, as this is my first
> experience with USRP devices (Though I?ve used SDRs for receiving
> extensively)
>
> /Issue:/
> I?m having issues with transmitting signals on a used N210 I picked
> up? I see energy on the frequency but no actual ?content?. How can I
> confirm that the N210/SBX is operating properly without the use of a
> secondary UHD device? Information on Verifying the Operation of the
> USRP Using UHD and GNU Radio - Ettus Knowledge Base
> <https://kb.ettus.com/Verifying_the_Operation_of_the_USRP_Using_UHD_and_GNU_Radio>
> seems
> to require specialized signal analyzers or additional USRPs as shown
> in other guides. I?m just trying to confirm this thing is operational.
> Best case scenario, I?d like to hear some audio play over an FRS radio
> (NBFM) to confirm its operational. I?m able to detect energy on the
> frequency, but it seems unaffected by the use or non-use of an
> antenna, so I?m thinking there?s a grounding problem or something I?m
> doing wrong, if the SBX isn?t a dud (purchased from Ebay).
>
> Is it possible that this SBX or N210 have custom
> software/configuration/calibration? Am I wrong in thinking all you
> need hooked up is power, ethernet, daughterboard and antenna? Could a
> lack of GPSDO be the problem?
>
> /Longish Background:/
> Just got in last week an N210 w/SBX Daughterboard. Purchased used on
> Ebay, it came with just the boards, screws, bulkhead cables and that?s
> it... I purchased a 6V 3A charger off Amazon and it boots and responds
> fine. I?m able to receive FRS frequencies using GNU Radio. But that?s
> the extent of the good news.
>
> I?m having issues confirming that the radio is transmitting properly.
> The use-case is OpenBTS 2G/3G, but when I use OpenBTS I get energy on
> the frequency but phones can?t see it. At first I thought it was
> software issue, but I?m not even able to get a simple NBFM audio
> signal to be received by a walky-talky. When I?m not having
> underflows, I get just straight static (Using
> http://files.ettus.com/tutorials/labs/Lab_1-5.pdf for GRC). After a
> bit of troubleshooting, it seems that the energy is coming from the
> board, and not the TX/RX output, as when I remove the antenna nothing
> changes, and signal can only be seen when within 6? from the N210.
> Unfortunately in my frustration I deleted the wrong virtual machine
> and lost all of the .grc files I had created? But I can try to
> recreate them if they are needed.
>
> I?ve gone through GRC based tests, as well as used the tx_waveform and
> siggen_gui commands and all I get is energy but no audio on our
> systems (both FRS radios, and a proprietary SDR system that won?t work
> with GNU Radio). I also ran a benchmark_rate and confirmed an
> underflow problem, but otherwise looks ok. ./benchmark_rate --rx_rate
> 10e6 --tx_rate 10e6 returns the following: https://pastebin.com/qHPQYkkB
>
> I?ve used ?Firmware 10? and ?Firmware 11? for sure, as well as UHD 3.7
> through latest (UHD 3.9.1 I believe). I?ve used Ubuntu 12.04 through
> 16.10. Debian and the like. I?ve used virtual machines and
> full-featured Intel integrated boards. 32 and 64 bit. Precompiled dpkg
> and built from source?.and they all have the same issue. Energy and no
> content. I?ve reached the extent of my knowledge-base, and so I?m
> reaching out to the community.
>
> Thanks ahead for the help!
> Ash Pesante
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
If your USRP appears to grossly function with a standard load of UHD,
then it is likely running standard firmware.
Check to make certain that you have the SBX wired up to the front-panel
correctly. What happens when you use something simple like
the tx_waveforms example?
It really is that case that when you're debugging radios or
troubleshooting broken radios, it is of *tremendous* help to have
appropriate lab equipment.
This is true of most pieces of complex electronics--SDRs aren't
special in this regard.
Now, it could be the case with your eBay-acquired USRP that there's a
problem with the baseband connection in your TX path--the DAC is broken, or
something is broken in the analog pathway from the DAC into the mixer
on the SBX card. Debugging this requires lab equipment. No real way around
that...
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170417/effa98ec/attachment-0001.html>
------------------------------
Message: 17
Date: Tue, 18 Apr 2017 09:45:35 +0600
From: Fazle Elahi <[email protected]>
To: [email protected]
Subject: [USRP-users] NI USRP-2901 firmware, FPGA images to run with
UHD
Message-ID:
<CAN3qBB0iWt4kcvRpP_6eTnTS3Cmjc=ful40wl9mehwhjfds...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi everyone,
I would like to use my USRP-2901(device) with GNU radio and openBTS. I have
found out that GNU radio and openBTS both rely on UHD drivers from Ettus
research and they usually need different FPGA image and firmware other than
supplied by NI USRP. I was able to run a FM demodulation vi using LabVIEW
and NI USRP drivers. So there is probably no issue with device
connectivity.
Now I want to use the device with GNU radio first so I tried to install UHD
drivers for windows 10,64 bit following these steps in the link
<https://files.ettus.com/manual/page_install.html> and went for the latest
binary release. Unfortunately, when I executed the uhd_find_devices.exe
program it can not find the device. The device pops up as 'West Bridge' in
device manager with yellow explanation mark.
I have seen few are using USRP 2901 with gnu radio so I think the device
has compatibility with UHD drivers. Please help me with how I can solve
this problem.
Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170418/d66eeefa/attachment-0001.html>
------------------------------
Message: 18
Date: Tue, 18 Apr 2017 09:10:30 +0100
From: Derek Kozel <[email protected]>
To: Fazle Elahi <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] NI USRP-2901 firmware, FPGA images to run
with UHD
Message-ID:
<CAA+K=ts3mkrv3ddwlvb3cqen52ewax2ijgg5hocb3mo_gcf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Fazle,
The USRP B210 (NI USRP-2901) requires that USB drivers be installed in
order for UHD to detect it. These drivers are available here and can be
manually installed from the device manager.
https://files.ettus.com/binaries/misc/erllc_uhd_winusb_driver.zip
Regards,
Derek
On Tue, Apr 18, 2017 at 4:45 AM, Fazle Elahi via USRP-users <
[email protected]> wrote:
> Hi everyone,
> I would like to use my USRP-2901(device) with GNU radio and openBTS. I
> have found out that GNU radio and openBTS both rely on UHD drivers from
> Ettus research and they usually need different FPGA image and firmware
> other than supplied by NI USRP. I was able to run a FM demodulation vi
> using LabVIEW and NI USRP drivers. So there is probably no issue with
> device connectivity.
>
> Now I want to use the device with GNU radio first so I tried to install
> UHD drivers for windows 10,64 bit following these steps in the link
> <https://files.ettus.com/manual/page_install.html> and went for the
> latest binary release. Unfortunately, when I executed the
> uhd_find_devices.exe program it can not find the device. The device pops up
> as 'West Bridge' in device manager with yellow explanation mark.
>
> I have seen few are using USRP 2901 with gnu radio so I think the device
> has compatibility with UHD drivers. Please help me with how I can solve
> this problem.
>
> Thank you.
>
> _______________________________________________
> 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/20170418/5a48a19f/attachment-0001.html>
------------------------------
Message: 19
Date: Tue, 18 Apr 2017 18:56:31 +0300
From: emre g?ng?r <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] NI2901 receive power
Message-ID:
<cajd1ueuacvw9gde3xsj9_yplgp7heb+oa_x+mjpstd0drus...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
I sent my experiment in gnu radio, I use NI2901. I connect horn antennas to
transmitter and reciver of Usrp. I have have high scattering obstacle
(trihedral corner reflector) I am trying to measure power when there is
corner reflector in front of antennas and without reflector.
I take data from gnu radio and transfer it Matlab, I plot received data.
As I said before I expect a bigger power change at graph. I dont mean I
want to find absolute power in this way but I expect that these power
values must be linearly related with power, but it is not.
I didnt understand why are we using low pass filter for taking result.
Because I sent signal with 5.1GHz center frequency. I also have no idea if
received signal always be normalized between -1 and 1 how can I have an
information related with voltage at the terminal of the antenna. In this
experiment how should I adjust low pass filter parameters.
Do you have any suggestion? How can I take correct power data by using gnu
radio NI2901 and Matlab.
I would be grateful if you can look at my experiment.
Yours faithfully.
Emre.
18 Nis 2017 02:16 tarihinde "Marcus D. Leech via USRP-users" <
[email protected]> yazd?:
On 04/17/2017 06:54 PM, emre g?ng?r via USRP-users wrote:
> Hi again,
>
> How the signal amplitudes which varies around -1 and 1 can be related with
> voltage at the antenna terminal. What represents high voltage or low
> voltage. I used corner reflector which has rcs close to 1000, that means
> received power must be x1000 when there is an corner reflextor in front of
> the antenna when compared with without corner reflector case.
>
> That means the voltage at the antenna terminal is sqrt(1000).
> But I measured this difference like x2 x3.
> I used complex to mag square as you said and I also used low pass filter.
> I could not understand logic of the low pass filter but it works as I said
> at least I can see x2 x3 times difference at power.
>
> But they can not answer my questions.
> I can list them again for better reading.
>
> 1. How can I interpret signal which varied around -1 and 1, how can it be
> related to voltage?
>
Because real-world, AC signals (like radio waves) are the superposition of
several sinusoids, all of which, when normalized, have instantaneous values
in {-1,+1}. This is pretty basic. In Gnu Radio, signals are normalized
into {-1.0,+1.0} you cannot know what they actually represent at the
antenna terminals without *calibration*. This has already been mentioned.
> 2. How should I choose cutoff frequency of the filter and transition width
> of the filter, how it effects?
>
It's *YOUR* experiment--at what rate do you wish to measure power?
> 3. Measurement not even close to theory. Why I can not take x1000 power
> with corner reflector when compared to without corner reflector case.
>
> Best wishes.
> Emre.
>
>
> I can't answer this, because we have only a vague understanding of your
experimental setup. Have you taken into account path-loss? And again,
without
calibration, you can only assume relative power. That is, if the
received power increases by a factor of 2, your instantaneous voltage
reading will increase
by a factor of sqrt(2), etc. But for accuracy, you need to average these
readings over several cycles--hence the low-pass filtering--I usually just
use
a single-pole IIR filter. But getting into a protracted discussion about
why one filter is better than another for a specific purpose is best done
on the
discuss-gnuradio mailing list (and also, consulting on-line DSP forums,
and cracking-open a few DSP textbooks).
_______________________________________________
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/20170418/2a43ccb6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot_2017-04-18-18-52-49.png
Type: image/png
Size: 471148 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170418/2a43ccb6/attachment-0001.png>
------------------------------
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 80, Issue 18
******************************************
