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: GPSDO timing on E310 (Jason Matusiak)
2. Re: Trying to control E310 RFNoC FPGA noc_block_moving_avg
registers SR_SUM_LEN from laptop running a .grc WX GUI Slider
(Jonathon Pendlum)
3. Running UHD rx_sample_to_file on E310 (Zhongren Cao)
4. Re: GPSDO timing on E310 (Long, Jeffrey P.)
5. Fwd: X310 UBX Tx issues ([email protected])
6. Re: Running UHD rx_sample_to_file on E310 (Rob Kossler)
7. Re: GPSDO timing on E310 (Marcus M?ller)
8. Re: Fwd: X310 UBX Tx issues (Michael West)
9. Re: agc of uhd (Marcus D. Leech)
10. Re: Fwd: X310 UBX Tx issues ([email protected])
11. Re: Convert a USRP Rio to X310? (Neel Pandeya)
12. Separate thread for each streaming channel (Rob Kossler)
13. Re: Separate thread for each streaming channel (Michael West)
14. Re: Problem of running two channels of TVRX2 (Marcus D. Leech)
15. External reference input power X310, B200mini
([email protected])
16. Re: External reference input power X310, B200mini
([email protected])
----------------------------------------------------------------------
Message: 1
Date: Wed, 11 May 2016 13:03:04 -0400
From: Jason Matusiak <[email protected]>
To: "Long, Jeffrey P." <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] GPSDO timing on E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
> I would just hit it every second for 30 or so seconds after startup.
Have not really paid attention to how long it takes since in my
> app I burst every second and I have plenty of time to just do this
infinitely although I don't think that would be necessary.
That seems to do the trick! Do you have a guess why it works? We tried
running it once after 30 seconds of run-time, but that didn't do
anything. When we ran it once a second for the first thirty seconds
things get very tight (well within the tolerances). Thank you very much
for posting it, we would never have thought to do that ourselves.
------------------------------
Message: 2
Date: Wed, 11 May 2016 12:33:32 -0500
From: Jonathon Pendlum <[email protected]>
To: "Swanson, Craig" <[email protected]>
Cc: Martin Braun <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Trying to control E310 RFNoC FPGA
noc_block_moving_avg registers SR_SUM_LEN from laptop running a .grc
WX GUI Slider
Message-ID:
<CAGdo0uQhdH49A6upwAm8mJ=hg-4nudpqxddvvrriavzcyji...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Craig,
We already discussed this offline, but for everyone else's sake there is an
example GRC file in the gr-ettus examples directory for the moving average
block.
Jonathon
On Sun, May 8, 2016 at 5:05 AM, Swanson, Craig <
[email protected]> wrote:
> Jonathon and Martin,
>
> I am trying to learn how to control the registers SR_SUM_LEN? and
> SR_DIVISOR that reside inside the RFNoC noc_block_moving_avg.v file
> remotely from my laptop running a .grc file.
>
>
> Would you by any chance have a .grc file that provides an example of how I
> can control on my laptop running a flowgraph QT or WX GUI slider, the RFNoC
> FPGA registers in an E310?
>
>
> I think the best example would be the noc_block_moving_avg, since that is
> the once I am most aquainted with.
>
>
> Thanks,
>
> 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>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160511/e613feb8/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 11 May 2016 13:54:44 -0400
From: Zhongren Cao <[email protected]>
To: [email protected]
Subject: [USRP-users] Running UHD rx_sample_to_file on E310
Message-ID:
<CAFk80G81dP08b+k8hC2pQ_qA67F4fdWnPwoXfN=tzup9anw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
I am trying to run rx_sample_to_file on our newly acquired E310 platform.
The exact command I used is
/usr/lib/uhd/examples/rx_samples_to_file --nsamps 1024 --duration 10 --freq
903250000 --gain 0 --ant RX2 --subdev A:A --bw 500000 --stat
The terminal outputs are:
linux; GNU C++ version 4.9.1; Boost_105600; UHD_003.008.004-0-unknown
Creating the usrp device with: ...
-- Loading FPGA image: /usr/share/uhd/images/usrp_e310_fpga.bit... done
-- Detecting internal GPSDO.... found
-- Initializing core control...
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Performing CODEC loopback test... pass
-- Setting time source to internal
-- Asking for clock rate 32 MHz
-- Actually got clock rate 32 MHz
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
-- Initializing time to the internal GPSDO
Using Device: Single USRP:
Device: E-Series Device
Mboard 0: E310
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: FE-RX2
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: FE-TX2
TX Channel: 1
TX DSP: 1
TX Dboard: A
TX Subdev: FE-TX1
Setting RX Rate: 1.000000 Msps...
Actual RX Rate: 1.000000 Msps...
Setting RX Freq: 903.250000 MHz...
-- Tune Request: 903.250000 MHz
-- The RF LO does not support the requested frequency:
-- Requested LO Frequency: 903.250000 MHz
-- RF LO Result: 903.249999 MHz
-- Attempted to use the DSP to reach the requested frequency:
-- Desired DSP Frequency: -0.000001 MHz
-- DSP Result: -0.000001 MHz
-- Successfully tuned to 903.250000 MHz
--
Actual RX Freq: 903.250000 MHz...
Setting RX Gain: 0.000000 dB...
Actual RX Gain: 0.000000 dB...
Setting RX Bandwidth: 0.500000 MHz...
Actual RX Bandwidth: 56.000000 MHz...
Waiting for "lo_locked": ++++++++++ locked.
Received 1024 samples in 0.000006 seconds
170.666667 Msps
Done!
(Q1) According to a 04/12/14 post by Marcus Muller on this list, the
default data type is short, i.e., uint16. I tried to read the resulted
usrp_samples.dat file in Matlab using
fread(fid, inf, 'uint16');
However, the data I saw are overflows swinging between 0 and 65535, as
shown in the attached figure. I am wondering how should I setup the
parameters to same data and read data correctly?
(Q2) I tried to use 500KHz as the receiver bandwidth, but the terminal
output tells me the actual RX bandwidth is 56 MHz. Can you provide a list
of possible RX BW for E310?
(Q3) I invoked the --stat argument, which resulted in the output of
170.666667 Msps before "Done!". The help explanation is "show average
bandwidth on exit". What does this mean?
Thanks,
Zhongren
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160511/56d56e40/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2016-05-11 at 1.49.15 PM.png
Type: image/png
Size: 15904 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160511/56d56e40/attachment-0001.png>
------------------------------
Message: 4
Date: Wed, 11 May 2016 18:25:05 +0000
From: "Long, Jeffrey P." <[email protected]>
To: Jason Matusiak <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] GPSDO timing on E310
Message-ID:
<sn1pr09mb0831a4e421fb055654a7900ed9...@sn1pr09mb0831.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Jason-
Yeah no idea where the problem is. Obviously there is some instability and
until things get up and running you are wasting your time trying to set the pps.
Unfortunately I can't point to an exact software bug so the Ettus guys would
need to dive deep to try to figure this out.
Jeff
-----Original Message-----
From: Jason Matusiak [mailto:[email protected]]
Sent: Wednesday, May 11, 2016 1:03 PM
To: Long, Jeffrey P.; [email protected]
Subject: Re: [USRP-users] GPSDO timing on E310
> I would just hit it every second for 30 or so seconds after startup.
Have not really paid attention to how long it takes since in my
> app I burst every second and I have plenty of time to just do this
infinitely although I don't think that would be necessary.
That seems to do the trick! Do you have a guess why it works? We tried
running it once after 30 seconds of run-time, but that didn't do
anything. When we ran it once a second for the first thirty seconds
things get very tight (well within the tolerances). Thank you very much
for posting it, we would never have thought to do that ourselves.
------------------------------
Message: 5
Date: Wed, 11 May 2016 18:32:06 +0000 (UTC)
From: [email protected]
To: usrp-users <[email protected]>
Subject: [USRP-users] Fwd: X310 UBX Tx issues
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
----- Forwarded Message -----
From: [email protected]
To: "Michael West" <[email protected]>
Sent: Wednesday, May 11, 2016 2:31:39 PM
Subject: Re: [USRP-users] X310 UBX Tx issues
Hi Micheal,
I tried 5 other applications that I have and they all look much better and do
not have the small imperfection at the beginning of transmission...
tx_waveforms still produces a small (0.1 - 0.2 second) "anomaly" at the
beginning (area 3-4 below).
reproducing ASCII art:
___________________________
|
|
____|
|
____ |
| | |
------| |----------|
1 2 3 4
The area from 3-4 still remains (1-2 is much further down compared to before)
but does seem smaller while using tx_waveforms...
Maybe tx_waveforms does something a bit weird...
Here is the command line I used to reproduce the problem:
tx_waveforms --args addr=192.168.10.2 --rate 10000000 --freq 500000000 -bw
10000000 --ref external
The only other thing I can think of is I am still in 3.9.2, if you are working
from 3.9.4 baseline, maybe some other changes happened if you are not seeing
what I see...
Let me know if I can provide you with any other information...
Thanks,
----- Forwarded Message -----
From: "Michael West" <[email protected]>
To: "Tilla" <[email protected]>
Cc: "usrp-users" <[email protected]>
Sent: Tuesday, May 10, 2016 5:24:02 PM
Subject: Re: [USRP-users] X310 UBX Tx issues
Hi Tilla,
We have been looking into this issue here at Ettus. The different power levels
are explained as follows:
-70 dBm: the TX PA turning on (expected)
-48 dBm: the TX LOs being tuned (DC leakage)
-15 dBm: the start of streaming (tone output as expected)
-53 dBm (upon exiting the application): the TX mixer is left on
I have attached a patch that suppresses the DC leakage from the LO tuning and
the high noise floor after execution from the TX mixer being left on. It is a
very simple change to the UBX code. Give it a try and let me know how it works.
We are working on vetting the change now so we can include it in UHD. Any
feedback you might have will be greatly appreciated.
Thank you,
Michael
On Tue, Apr 19, 2016 at 2:10 PM, tilla--- via USRP-users <
[email protected] > wrote:
Probe output attached...
As a bonus, on page 3, there is a spectrum analyzer screen shot of the output
of uhd_usrp_probe...
Yes, there is rf output similar to described within tx_waveforms original issue
to start this thread.
The lowest signal level is the noise floor, the second level is output during
some of the startup of uhd_usrp_probe, the third level is output forever, even
after the uhd_usrp_probe application has exited...
From: "tilla--- via USRP-users" < [email protected] >
To: "Marcus M?ller" < [email protected] >, "Neel Pandeya" <
[email protected] >
Cc: "usrp-users" < [email protected] >
Sent: Tuesday, April 19, 2016 1:15:37 PM
Subject: Re: [USRP-users] X310 UBX Tx issues
Nothing yet.
Neel, listed below, UHD 3.9.2...
I can get you a probe output in a bit...
From: "Marcus M?ller via USRP-users" < [email protected] >
To: "usrp-users" < [email protected] >
Sent: Tuesday, April 19, 2016 11:39:59 AM
Subject: Re: [USRP-users] X310 UBX Tx issues
Hi Tilla,
I totally got lost in the discussions involving you, of which some were
off-list; has this been addressed?
Best regards,
Marcus
On 04/04/2016 05:59 PM, tilla--- via USRP-users wrote:
<blockquote>
Platform:
Win 7 64 bit
UHD 3.9.2
Visual Studio 2015 Update 1
X310 with UBX-160
10Gb interface
I am porting my hardware platform from WBX-120 cards over to UBX-160.
There are some strange things going on with UBX-160.
Looking at the output signal on a spectrum analyzer zero span 1 MHz BW at
center frequency, the noise floor is about -75 dbm.
executing the command tx_waveforms --args addr=192.168.40.2 --rate 10000000
--freq 300000000
When the app starts, signal level goes to about -70 dbm for 1 second, then -48
dbm for about 2 seconds, then to -15 dbm for the remainder of the application
execution. Upon control-c of the application to halt, a signal is still being
transmitted by the card at -53 dbm.
When run on a WBX-120, none of these startup or shutdown artifacts are present.
Seems to be present on all frequencies at varying amplitudes.
I have tried this on multiple X310s and multiple UBX cards, all exhibit the
same performance.
Is this something you guys are aware of?
Thanks,
_______________________________________________
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
_______________________________________________
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
</blockquote>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160511/39b909c0/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 11 May 2016 14:48:37 -0400
From: Rob Kossler <[email protected]>
To: Zhongren Cao <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Running UHD rx_sample_to_file on E310
Message-ID:
<cab__hts98xnd39qcbavink673n-dlnswgt_ncy3beb6iycu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Zhongren,
Use type 'int16' rather than 'uint16'. Also, be aware that the resulting
vector in matlab will be interleaved I/Q so you will want to de-interleave
this and put it in a complex vector. So, if you read the data into 'x',
you will want to do something like 'y=x(1:2:end) + i1*x(2:2:end);' such
that y is the complex baseband.
Rob
On Wed, May 11, 2016 at 1:54 PM, Zhongren Cao via USRP-users <
[email protected]> wrote:
> Hello,
>
> I am trying to run rx_sample_to_file on our newly acquired E310 platform.
> The exact command I used is
>
> /usr/lib/uhd/examples/rx_samples_to_file --nsamps 1024 --duration 10
> --freq 903250000 --gain 0 --ant RX2 --subdev A:A --bw 500000 --stat
>
> The terminal outputs are:
>
> linux; GNU C++ version 4.9.1; Boost_105600; UHD_003.008.004-0-unknown
>
> Creating the usrp device with: ...
> -- Loading FPGA image: /usr/share/uhd/images/usrp_e310_fpga.bit... done
> -- Detecting internal GPSDO.... found
> -- Initializing core control...
> -- Performing register loopback test... pass
> -- Performing register loopback test... pass
> -- Performing register loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Setting time source to internal
> -- Asking for clock rate 32 MHz
> -- Actually got clock rate 32 MHz
> -- Performing timer loopback test... pass
> -- Performing timer loopback test... pass
> -- Initializing time to the internal GPSDO
>
> Using Device: Single USRP:
> Device: E-Series Device
> Mboard 0: E310
> RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: FE-RX2
> TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: FE-TX2
> TX Channel: 1
> TX DSP: 1
> TX Dboard: A
> TX Subdev: FE-TX1
>
> Setting RX Rate: 1.000000 Msps...
> Actual RX Rate: 1.000000 Msps...
>
> Setting RX Freq: 903.250000 MHz...
> -- Tune Request: 903.250000 MHz
> -- The RF LO does not support the requested frequency:
> -- Requested LO Frequency: 903.250000 MHz
> -- RF LO Result: 903.249999 MHz
> -- Attempted to use the DSP to reach the requested frequency:
> -- Desired DSP Frequency: -0.000001 MHz
> -- DSP Result: -0.000001 MHz
> -- Successfully tuned to 903.250000 MHz
> --
> Actual RX Freq: 903.250000 MHz...
>
> Setting RX Gain: 0.000000 dB...
> Actual RX Gain: 0.000000 dB...
>
> Setting RX Bandwidth: 0.500000 MHz...
> Actual RX Bandwidth: 56.000000 MHz...
>
> Waiting for "lo_locked": ++++++++++ locked.
>
>
> Received 1024 samples in 0.000006 seconds
> 170.666667 Msps
>
> Done!
>
> (Q1) According to a 04/12/14 post by Marcus Muller on this list, the
> default data type is short, i.e., uint16. I tried to read the resulted
> usrp_samples.dat file in Matlab using
>
> fread(fid, inf, 'uint16');
>
> However, the data I saw are overflows swinging between 0 and 65535, as
> shown in the attached figure. I am wondering how should I setup the
> parameters to same data and read data correctly?
>
> (Q2) I tried to use 500KHz as the receiver bandwidth, but the terminal
> output tells me the actual RX bandwidth is 56 MHz. Can you provide a list
> of possible RX BW for E310?
>
> (Q3) I invoked the --stat argument, which resulted in the output of
> 170.666667 Msps before "Done!". The help explanation is "show average
> bandwidth on exit". What does this mean?
>
> Thanks,
>
> Zhongren
>
> _______________________________________________
> 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/20160511/8325c6d5/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 11 May 2016 21:33:22 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] GPSDO timing on E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Jeff, Hi Jason,
I think this thread slipped Ettus attention for a bit too long.
So, I don't readily have an explanation why you have timing jump around.
I'd have an explanation for slips of +- exactly 1s, though:
It takes a couple ms for the GPS data containing the time to propagate
through the serial line. Hence, when you ask "how late (in NMEA time
seconds) is it NOW, dear mboard sensor", you might get the current
second, or the last second.
The only solution to get certainty, which you cited in your first mail
in this thread, is to first wait for the PPS pulse, then wait a time
large enough for the time data to propagate, and then query the sensor.
We've covered the full "dance" in our manual[1], but I think we might
need to make that page more prominently linked from other pages than the
X310's.
Now, I'm not 100% sure what algorithms you're exactly using to ensure
GPS lock and correct GPS time extraction and setting, so I can only ask
you to verify what I propose in [1] is equivalent to your set up.
Best regards,
Marcus
[1] http://files.ettus.com/manual/page_gpsdo_x3x0.html#Setting
On 11.05.2016 20:25, Long, Jeffrey P. via USRP-users wrote:
> Jason-
>
> Yeah no idea where the problem is. Obviously there is some instability and
> until things get up and running you are wasting your time trying to set the
> pps.
> Unfortunately I can't point to an exact software bug so the Ettus guys would
> need to dive deep to try to figure this out.
>
> Jeff
>
> -----Original Message-----
> From: Jason Matusiak [mailto:[email protected]]
> Sent: Wednesday, May 11, 2016 1:03 PM
> To: Long, Jeffrey P.; [email protected]
> Subject: Re: [USRP-users] GPSDO timing on E310
>
> > I would just hit it every second for 30 or so seconds after startup.
> Have not really paid attention to how long it takes since in my
> > app I burst every second and I have plenty of time to just do this
> infinitely although I don't think that would be necessary.
>
> That seems to do the trick! Do you have a guess why it works? We tried
> running it once after 30 seconds of run-time, but that didn't do
> anything. When we ran it once a second for the first thirty seconds
> things get very tight (well within the tolerances). Thank you very much
> for posting it, we would never have thought to do that ourselves.
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 8
Date: Wed, 11 May 2016 13:01:05 -0700
From: Michael West <[email protected]>
To: Tilla <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Fwd: X310 UBX Tx issues
Message-ID:
<CAM4xKrqcVqWp=ld-nyfd5sz7d5tuvec_8jxm1kf+4dy2sd8...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Tilla,
I'm glad to hear there was a noticeable improvement. I am testing with our
development branch which is based on UHD 3.9.4 and yes, there have been
significant changes to the UBX code between 3.9.2 and 3.9.4.
The 1-2 area is during the device initialization and we are less concerned
about it. If it is a critical issue for you, please let us know.
The 3-4 area is of more concern to us right now. Are you using the UBX in
the default "performance" power mode or did you change the code to put it
in the "powersave" power mode? The reason I ask is that we do see the same
type of effect when the UBX is in "powersave" mode, but not it the default
"performance" mode. We know it has something to do with the TX PA and/or
RF switch, but we are still investigating.
Also, can you fill in the details in regards to area 3-4 (i.e. power level
and duration)?
I will let you know more as soon as I know.
Regards,
Michael
On Wed, May 11, 2016 at 11:32 AM, tilla--- via USRP-users <
[email protected]> wrote:
>
>
> ------------------------------
> *From: *[email protected]
> *To: *"Michael West" <[email protected]>
> *Sent: *Wednesday, May 11, 2016 2:31:39 PM
>
> *Subject: *Re: [USRP-users] X310 UBX Tx issues
>
> Hi Micheal,
>
> I tried 5 other applications that I have and they all look much better and
> do not have the small imperfection at the beginning of transmission...
>
> tx_waveforms still produces a small (0.1 - 0.2 second) "anomaly" at the
> beginning (area 3-4 below).
>
> reproducing ASCII art:
>
> ___________________________
> |
> |
> ____|
> |
> ____ |
> | | |
> ------| |----------|
>
> 1 2 3 4
>
> The area from 3-4 still remains (1-2 is much further down compared to
> before) but does seem smaller while using tx_waveforms...
>
> Maybe tx_waveforms does something a bit weird...
>
> Here is the command line I used to reproduce the problem:
>
> tx_waveforms --args addr=192.168.10.2 --rate 10000000 --freq 500000000 -bw
> 10000000 --ref external
>
> The only other thing I can think of is I am still in 3.9.2, if you are
> working from 3.9.4 baseline, maybe some other changes happened if you are
> not seeing what I see...
>
> Let me know if I can provide you with any other information...
>
> Thanks,
> ------------------------------
> *From: *"Michael West" <[email protected]>
> *To: *"Tilla" <[email protected]>
> *Cc: *"usrp-users" <[email protected]>
> *Sent: *Tuesday, May 10, 2016 5:24:02 PM
> *Subject: *Re: [USRP-users] X310 UBX Tx issues
>
> Hi Tilla,
>
> We have been looking into this issue here at Ettus. The different power
> levels are explained as follows:
>
> -70 dBm: the TX PA turning on (expected)
> -48 dBm: the TX LOs being tuned (DC leakage)
> -15 dBm: the start of streaming (tone output as expected)
> -53 dBm (upon exiting the application): the TX mixer is left on
>
> I have attached a patch that suppresses the DC leakage from the LO tuning
> and the high noise floor after execution from the TX mixer being left on.
> It is a very simple change to the UBX code. Give it a try and let me know
> how it works. We are working on vetting the change now so we can include
> it in UHD. Any feedback you might have will be greatly appreciated.
>
> Thank you,
> Michael
>
> On Tue, Apr 19, 2016 at 2:10 PM, tilla--- via USRP-users <
> [email protected]> wrote:
>
>> Probe output attached...
>>
>> As a bonus, on page 3, there is a spectrum analyzer screen shot of the
>> output of uhd_usrp_probe...
>>
>> Yes, there is rf output similar to described within tx_waveforms original
>> issue to start this thread.
>>
>> The lowest signal level is the noise floor, the second level is output
>> during some of the startup of uhd_usrp_probe, the third level is output
>> forever, even after the uhd_usrp_probe application has exited...
>>
>> ------------------------------
>> *From: *"tilla--- via USRP-users" <[email protected]>
>> *To: *"Marcus M?ller" <[email protected]>, "Neel Pandeya" <
>> [email protected]>
>> *Cc: *"usrp-users" <[email protected]>
>> *Sent: *Tuesday, April 19, 2016 1:15:37 PM
>>
>> *Subject: *Re: [USRP-users] X310 UBX Tx issues
>>
>> Nothing yet.
>>
>> Neel, listed below, UHD 3.9.2...
>>
>> I can get you a probe output in a bit...
>>
>> ------------------------------
>> *From: *"Marcus M?ller via USRP-users" <[email protected]>
>> *To: *"usrp-users" <[email protected]>
>> *Sent: *Tuesday, April 19, 2016 11:39:59 AM
>> *Subject: *Re: [USRP-users] X310 UBX Tx issues
>>
>> Hi Tilla,
>>
>> I totally got lost in the discussions involving you, of which some were
>> off-list; has this been addressed?
>>
>> Best regards,
>> Marcus
>>
>> On 04/04/2016 05:59 PM, tilla--- via USRP-users wrote:
>>
>> Platform:
>> Win 7 64 bit
>> UHD 3.9.2
>> Visual Studio 2015 Update 1
>> X310 with UBX-160
>> 10Gb interface
>>
>> I am porting my hardware platform from WBX-120 cards over to UBX-160.
>>
>> There are some strange things going on with UBX-160.
>>
>> Looking at the output signal on a spectrum analyzer zero span 1 MHz BW at
>> center frequency, the noise floor is about -75 dbm.
>>
>> executing the command tx_waveforms --args addr=192.168.40.2 --rate
>> 10000000 --freq 300000000
>>
>> When the app starts, signal level goes to about -70 dbm for 1 second,
>> then -48 dbm for about 2 seconds, then to -15 dbm for the remainder of the
>> application execution. Upon control-c of the application to halt, a signal
>> is still being transmitted by the card at -53 dbm.
>>
>> When run on a WBX-120, none of these startup or shutdown artifacts are
>> present.
>>
>> Seems to be present on all frequencies at varying amplitudes.
>>
>> I have tried this on multiple X310s and multiple UBX cards, all exhibit
>> the same performance.
>>
>> Is this something you guys are aware of?
>>
>> Thanks,
>>
>>
>>
>> _______________________________________________
>> 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
>>
>>
>> _______________________________________________
>> 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/20160511/8b72eb92/attachment-0001.html>
------------------------------
Message: 9
Date: Wed, 11 May 2016 16:19:05 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] agc of uhd
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 05/11/2016 04:16 AM, Ekko via USRP-users wrote:
> hello all
> i want to know how to enable the AGC of e310 in the uhd_sink or source
> whether it is just like change the master clock in the uhd_source or sink?
>
> thank you
>
> --Ekko
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
multi_usrp includes a set_rx_agc() method
http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#abdab1f6c3775a9071b15c9805f866486
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160511/140ee585/attachment-0001.html>
------------------------------
Message: 10
Date: Wed, 11 May 2016 20:58:59 +0000 (UTC)
From: [email protected]
To: Michael West <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Fwd: X310 UBX Tx issues
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Agreed, 1-2 area non issue.
Good call on the powersave mode. I had implemented that as suggested by Neel
during initial analysis and was still in my codebase for tx_waveforms. Once I
commented it out and re-ran everything was perfect.
Also explains why my other 5 apps were ok as they do not put the card into
powersave mode...
So if someone uses powersave mode, there is still some small gremlin, but
default mode works perfectly now for me in this environment.
So at some release in the future, this patch will get in there and things shall
be good from then on.
In the mean time, I may implement it in my local distro if necessary, but
chances are I will wait for the release this is in to deploy...
Thanks so much for all your help in figuring this out and let me know if you
need any further info.
----- Original Message -----
From: "Michael West" <[email protected]>
To: "Tilla" <[email protected]>
Cc: "usrp-users" <[email protected]>
Sent: Wednesday, May 11, 2016 4:01:05 PM
Subject: Re: [USRP-users] Fwd: X310 UBX Tx issues
Hi Tilla,
I'm glad to hear there was a noticeable improvement. I am testing with our
development branch which is based on UHD 3.9.4 and yes, there have been
significant changes to the UBX code between 3.9.2 and 3.9.4.
The 1-2 area is during the device initialization and we are less concerned
about it. If it is a critical issue for you, please let us know.
The 3-4 area is of more concern to us right now. Are you using the UBX in the
default "performance" power mode or did you change the code to put it in the
"powersave" power mode? The reason I ask is that we do see the same type of
effect when the UBX is in "powersave" mode, but not it the default
"performance" mode. We know it has something to do with the TX PA and/or RF
switch, but we are still investigating.
Also, can you fill in the details in regards to area 3-4 (i.e. power level and
duration)?
I will let you know more as soon as I know.
Regards,
Michael
On Wed, May 11, 2016 at 11:32 AM, tilla--- via USRP-users <
[email protected] > wrote:
From: [email protected]
To: "Michael West" < [email protected] >
Sent: Wednesday, May 11, 2016 2:31:39 PM
Subject: Re: [USRP-users] X310 UBX Tx issues
Hi Micheal,
I tried 5 other applications that I have and they all look much better and do
not have the small imperfection at the beginning of transmission...
tx_waveforms still produces a small (0.1 - 0.2 second) "anomaly" at the
beginning (area 3-4 below).
reproducing ASCII art:
___________________________
|
|
____|
|
____ |
| | |
------| |----------|
1 2 3 4
The area from 3-4 still remains (1-2 is much further down compared to before)
but does seem smaller while using tx_waveforms...
Maybe tx_waveforms does something a bit weird...
Here is the command line I used to reproduce the problem:
tx_waveforms --args addr=192.168.10.2 --rate 10000000 --freq 500000000 -bw
10000000 --ref external
The only other thing I can think of is I am still in 3.9.2, if you are working
from 3.9.4 baseline, maybe some other changes happened if you are not seeing
what I see...
Let me know if I can provide you with any other information...
Thanks,
From: "Michael West" < [email protected] >
To: "Tilla" < [email protected] >
Cc: "usrp-users" < [email protected] >
Sent: Tuesday, May 10, 2016 5:24:02 PM
Subject: Re: [USRP-users] X310 UBX Tx issues
Hi Tilla,
We have been looking into this issue here at Ettus. The different power levels
are explained as follows:
-70 dBm: the TX PA turning on (expected)
-48 dBm: the TX LOs being tuned (DC leakage)
-15 dBm: the start of streaming (tone output as expected)
-53 dBm (upon exiting the application): the TX mixer is left on
I have attached a patch that suppresses the DC leakage from the LO tuning and
the high noise floor after execution from the TX mixer being left on. It is a
very simple change to the UBX code. Give it a try and let me know how it works.
We are working on vetting the change now so we can include it in UHD. Any
feedback you might have will be greatly appreciated.
Thank you,
Michael
On Tue, Apr 19, 2016 at 2:10 PM, tilla--- via USRP-users <
[email protected] > wrote:
<blockquote>
Probe output attached...
As a bonus, on page 3, there is a spectrum analyzer screen shot of the output
of uhd_usrp_probe...
Yes, there is rf output similar to described within tx_waveforms original issue
to start this thread.
The lowest signal level is the noise floor, the second level is output during
some of the startup of uhd_usrp_probe, the third level is output forever, even
after the uhd_usrp_probe application has exited...
From: "tilla--- via USRP-users" < [email protected] >
To: "Marcus M?ller" < [email protected] >, "Neel Pandeya" <
[email protected] >
Cc: "usrp-users" < [email protected] >
Sent: Tuesday, April 19, 2016 1:15:37 PM
Subject: Re: [USRP-users] X310 UBX Tx issues
Nothing yet.
Neel, listed below, UHD 3.9.2...
I can get you a probe output in a bit...
From: "Marcus M?ller via USRP-users" < [email protected] >
To: "usrp-users" < [email protected] >
Sent: Tuesday, April 19, 2016 11:39:59 AM
Subject: Re: [USRP-users] X310 UBX Tx issues
Hi Tilla,
I totally got lost in the discussions involving you, of which some were
off-list; has this been addressed?
Best regards,
Marcus
On 04/04/2016 05:59 PM, tilla--- via USRP-users wrote:
<blockquote>
Platform:
Win 7 64 bit
UHD 3.9.2
Visual Studio 2015 Update 1
X310 with UBX-160
10Gb interface
I am porting my hardware platform from WBX-120 cards over to UBX-160.
There are some strange things going on with UBX-160.
Looking at the output signal on a spectrum analyzer zero span 1 MHz BW at
center frequency, the noise floor is about -75 dbm.
executing the command tx_waveforms --args addr=192.168.40.2 --rate 10000000
--freq 300000000
When the app starts, signal level goes to about -70 dbm for 1 second, then -48
dbm for about 2 seconds, then to -15 dbm for the remainder of the application
execution. Upon control-c of the application to halt, a signal is still being
transmitted by the card at -53 dbm.
When run on a WBX-120, none of these startup or shutdown artifacts are present.
Seems to be present on all frequencies at varying amplitudes.
I have tried this on multiple X310s and multiple UBX cards, all exhibit the
same performance.
Is this something you guys are aware of?
Thanks,
_______________________________________________
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
_______________________________________________
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
</blockquote>
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
</blockquote>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160511/749a61e1/attachment-0001.html>
------------------------------
Message: 11
Date: Wed, 11 May 2016 15:16:00 -0700
From: Neel Pandeya <[email protected]>
To: "Collins, Richard" <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Convert a USRP Rio to X310?
Message-ID:
<cacaxmv_uleevhpfjpv7a3ekztxkup+nmen2rnowmqppcfsg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Richard:
Yes, you can run UHD and GNU Radio on an NI-USRP RIO. However, there are
some important caveats. Let me first summarize the procedure. I assume that
the device already has a valid IP address, and that you can ping the
device. Power off the device and install whichever daughterboard(s) you
want. Then, build and install UHD 3.9.4 on your host system. Then, run
"sudo uhd_images_downloader" to download the UHD 3.9.4 FPGA image. Then,
flash the image onto the X300 using the "usrp_x3xx_fpga_burner" utility,
and then power-cycle the X300. At this point, test your UHD installation by
running "uhd_usrp_probe". Next, build and install GNU Radio 3.7.9.2. Then,
test your GNU Radio installation by running "uhd_fft".
The procedure is a little different if you want to use RFNoC, in which case
you'll need to install the rfnoc-devel branch of UHD, and install the
gr-ettus OOT module for GNU Radio. There are some instructions at the link
below. I would suggest that you get UHD 3.9.4 and GNU Radio 3.7.9.2 working
first, and then afterwards turn your attention to RFNoC.
https://github.com/EttusResearch/uhd/wiki/RFNoC:-Getting-Started
Now, there are some caveats in doing this. Opening the chassis and changing
the daughterboards will void your NI warranty. Also, NI is not able to
provide support for UHD, GNU Radio, or RFNoC, so you should direct your
support questions to the usrp-users and discuss-gnuradio mailing lists or
to [email protected].
--Neel Pandeya
On 10 May 2016 at 14:52, Collins, Richard via USRP-users <
[email protected]> wrote:
> Through some searching, I found someone wanted to turn an X310 into a Rio
> (
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-November/016563.html
> ), but I want to know if it is known (and not just theoretically possible)
> that someone can install a pair of CBX daughterboards (either CBX or UBX)
> into an NI USRP Rio, flash it with X310 UHD firmware and FPGA bitstream,
> and turn it into an X310.
>
> If it is possible, is there anything else that would have to be done?
>
> Most importantly, can this monster be used with RFNoC and GNURadio?
>
> 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/20160511/70e13f45/attachment-0001.html>
------------------------------
Message: 12
Date: Wed, 11 May 2016 18:31:52 -0400
From: Rob Kossler <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Separate thread for each streaming channel
Message-ID:
<CAB__hTSSuC9uzic=C2UxE_X2uvR3q2M14RagXxwUfQ4QgTxS=w...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I am trying to capture samples to RAM drive on 4 channels (2 X310 w/
UBX-160) at 100 MS/s per channel. A while ago, I determined that my CPU
couldn't keep up at this rate. So, I modified my C++ application (loosely
based on rx_samples_to_file.cpp) so that I could run a separate instance on
each of 2 PCs with each PC linked to an X310. This involved synchronizing
X310 clocks and streaming start times, but seems to work fine.
I recently discovered that if I ran both instances on the same PC (with
this PC connected to both X310s), I could successfully achieve 4 channels
at 100 MS/s on one PC. This surprised me because of my previous failure
using a single program instance. The primary difference I could think of
was that when two program instances are executing they are naturally on
different threads whereas my single instance pulls all samples from UHD on
one thread.
With this long intro, here is my question: Given that using 2 threads to
pull the data from UHD seems to work better than 1 thread, would I be best
off taking it a step further such that I use a separate thread for each
channel? This would mean I would have a single channel assigned to each RX
streamer. Let me know any pros/cons of implementing in this way.
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160511/4854fba1/attachment-0001.html>
------------------------------
Message: 13
Date: Wed, 11 May 2016 16:33:56 -0700
From: Michael West <[email protected]>
To: Rob Kossler <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Separate thread for each streaming channel
Message-ID:
<cam4xkrocwxspf4it2oa4zm4mnyteyquhmjys3pcox-q6ny7...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Rob,
Having multiple channels in a single streamer guarantees time alignment of
the received data across the channels, even when there are overruns.
Individual threads for each channel results in much better performance, but
can cause more work in aligning the data later (especially if there are
overruns).
We are working on some improvements for UHD 3.10.0 that will definitely
help. Namely, we added a thread to offload the receive side I/O for X310
over 10 GbE. This removes a significant load from the rx_streamer::recv()
call and should make it much easier for your application to achieve 4
channels at 100 MS/s on one PC. If you are using the head of the master
branch, that could explain the improvement.
Regards,
Michael
On Wed, May 11, 2016 at 3:31 PM, Rob Kossler via USRP-users <
[email protected]> wrote:
> I am trying to capture samples to RAM drive on 4 channels (2 X310 w/
> UBX-160) at 100 MS/s per channel. A while ago, I determined that my CPU
> couldn't keep up at this rate. So, I modified my C++ application (loosely
> based on rx_samples_to_file.cpp) so that I could run a separate instance on
> each of 2 PCs with each PC linked to an X310. This involved synchronizing
> X310 clocks and streaming start times, but seems to work fine.
>
> I recently discovered that if I ran both instances on the same PC (with
> this PC connected to both X310s), I could successfully achieve 4 channels
> at 100 MS/s on one PC. This surprised me because of my previous failure
> using a single program instance. The primary difference I could think of
> was that when two program instances are executing they are naturally on
> different threads whereas my single instance pulls all samples from UHD on
> one thread.
>
> With this long intro, here is my question: Given that using 2 threads to
> pull the data from UHD seems to work better than 1 thread, would I be best
> off taking it a step further such that I use a separate thread for each
> channel? This would mean I would have a single channel assigned to each RX
> streamer. Let me know any pros/cons of implementing in this way.
>
> Rob
>
> _______________________________________________
> 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/20160511/d054901e/attachment-0001.html>
------------------------------
Message: 14
Date: Wed, 11 May 2016 21:39:43 -0400
From: "Marcus D. Leech" <[email protected]>
To: Tai Wooi Ling <[email protected]>, "[email protected]"
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Problem of running two channels of TVRX2
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 05/11/2016 09:24 PM, Tai Wooi Ling wrote:
> Thank you for your information.
>
> I used only default image during two channels receptions. Hence, I
> change the image to ?usrp1_fpga_4rx.rbf? in device argument. For your
> information, i am using GRC. However, I still cannot receive signals
> when running both channel at the same time.
>
> Your help will be appreciated.
>
> ?? Windows ??
>
You'll have to give us more details about how you're setting up
streaming, etc.
Are you using Gnu Radio? Do you have a flow-graph that you can share?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160511/db670f70/attachment-0001.html>
------------------------------
Message: 15
Date: Thu, 12 May 2016 13:33:53 +0000
From: <[email protected]>
To: <[email protected]>
Subject: [USRP-users] External reference input power X310, B200mini
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi,
I tried finding some information related to the maximum and minimum input power
of the external 10MHz reference input for the X310 and the B200mini.
X310: in the manual there is only the maximum of +15dBm stated (as well as on
the enclosing). But I could not find the minimum value at which a reliable
operation is possible. Do you know any number?
B200mini: there I found the minimum value of +10dBm and the maximum value of
+27dBm in the schematic. However, +27dBm appears quite large to me. Is this
value really correct?
Maybe this information could be added to the manual as well :)
Regards,
Emanuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160512/5d2a1fa0/attachment-0001.html>
------------------------------
Message: 16
Date: Thu, 12 May 2016 10:56:24 -0400
From: [email protected]
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] External reference input power X310,
B200mini
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
I have found that 2.5V levels seem to work reliably across all the
products. I've been using external OCXOs, buffered with 74HC04 running
at 2.5V and that works just fine to drive multiple units.
On 2016-05-12 09:33, Emanuel via USRP-users wrote:
> Hi,
>
> I tried finding some information related to the maximum and minimum input
> power of the external 10MHz reference input for the X310 and the B200mini.
>
> X310: in the manual there is only the maximum of +15dBm stated (as well as on
> the enclosing). But I could not find the minimum value at which a reliable
> operation is possible. Do you know any number?
>
> B200mini: there I found the minimum value of +10dBm and the maximum value of
> +27dBm in the schematic. However, +27dBm appears quite large to me. Is this
> value really correct?
>
> Maybe this information could be added to the manual as well J
>
> Regards,
>
> Emanuel
> _______________________________________________
> 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/20160512/cd302826/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 12
******************************************
