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: Frequency Offsets for USRP -N210 (Matt Ettus)
2. Re: Frequency Offsets for USRP -N210 (mahaveer gupta)
3. Re: Frequency Offsets for USRP -N210 (Matt Ettus)
4. Re: Frequency Offsets for USRP -N210 (mahaveer gupta)
5. Re: Frequency Offsets for USRP -N210 (Matt Ettus)
6. Re: Frequency Offsets for USRP -N210 (mahaveer gupta)
7. USRP B100 and USB 3.0 (Mark McCarron)
8. Re: Sending data to USRP2 with Simulink, without Buffer
Overflow (Ken)
9. Re: Sending data to USRP2 with Simulink, without Buffer
Overflow (Mike McLernon)
10. Re: USRP B100 and USB 3.0 (Matt Ettus)
----------------------------------------------------------------------
Message: 1
Date: Wed, 15 May 2013 09:02:41 -0700
From: Matt Ettus <[email protected]>
To: mahaveer gupta <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Frequency Offsets for USRP -N210
Message-ID:
<CAN=1kn-1qmfzdcmekbo-xhye6vzxvmowjchpe_rd_ogzo4h...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
The estimator has its own error. What size are the changes you are seeing?
Matt
On Tue, May 14, 2013 at 11:03 PM, mahaveer gupta <[email protected]>wrote:
> Hello,
>
> The frequency offset computed for a a pair of USRP-N210's comes out to be
> different every time
>
> Frequency offsets usually vary in longer timescales but I get completely
> non-correlated values every time I make transmissions between a
> transmitter-receiver pair.
>
> When I sent back-to-back packets, the offset estimation from different
> preambles deviate as big as 30-40%. Is this the expected behavior? Will
> appreciate if somebody can help me figure out whats going on here?
>
> Wondering whether there is a way to calibrate the USRP such that the
> frequency offset does not vary in shorter time-scales
>
>
> Thanks,
> M
>
>
> _______________________________________________
> 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/20130515/80eb7ebe/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 15 May 2013 12:22:50 -0400
From: mahaveer gupta <[email protected]>
To: Matt Ettus <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Frequency Offsets for USRP -N210
Message-ID:
<camhwhyydzkcpsys8nva2qhgxkzk9uw4bvtyrecqxivjibyq...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Matt,
the estimation is done once in 240 samples at 1Mhz, 2.4Ghz band. The FFT
size is 64
Thanks
On Wed, May 15, 2013 at 12:02 PM, Matt Ettus <[email protected]> wrote:
>
> The estimator has its own error. What size are the changes you are seeing?
>
> Matt
>
>
> On Tue, May 14, 2013 at 11:03 PM, mahaveer gupta <[email protected]>wrote:
>
>> Hello,
>>
>> The frequency offset computed for a a pair of USRP-N210's comes out to be
>> different every time
>>
>> Frequency offsets usually vary in longer timescales but I get completely
>> non-correlated values every time I make transmissions between a
>> transmitter-receiver pair.
>>
>> When I sent back-to-back packets, the offset estimation from different
>> preambles deviate as big as 30-40%. Is this the expected behavior? Will
>> appreciate if somebody can help me figure out whats going on here?
>>
>> Wondering whether there is a way to calibrate the USRP such that the
>> frequency offset does not vary in shorter time-scales
>>
>>
>> Thanks,
>> M
>>
>>
>> _______________________________________________
>> 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/20130515/cb51c664/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 15 May 2013 09:24:49 -0700
From: Matt Ettus <[email protected]>
To: mahaveer gupta <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Frequency Offsets for USRP -N210
Message-ID:
<CAN=1kn-v7f73maotabxyu2jffkm56jamd0kcaymzjztdnf5...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Yes, but what are the frequency errors you are seeing?
On Wed, May 15, 2013 at 9:22 AM, mahaveer gupta <[email protected]>wrote:
> Hi Matt,
>
> the estimation is done once in 240 samples at 1Mhz, 2.4Ghz band. The FFT
> size is 64
>
> Thanks
>
>
> On Wed, May 15, 2013 at 12:02 PM, Matt Ettus <[email protected]> wrote:
>
>>
>> The estimator has its own error. What size are the changes you are
>> seeing?
>>
>> Matt
>>
>>
>> On Tue, May 14, 2013 at 11:03 PM, mahaveer gupta <[email protected]>wrote:
>>
>>> Hello,
>>>
>>> The frequency offset computed for a a pair of USRP-N210's comes out to be
>>> different every time
>>>
>>> Frequency offsets usually vary in longer timescales but I get completely
>>> non-correlated values every time I make transmissions between a
>>> transmitter-receiver pair.
>>>
>>> When I sent back-to-back packets, the offset estimation from different
>>> preambles deviate as big as 30-40%. Is this the expected behavior? Will
>>> appreciate if somebody can help me figure out whats going on here?
>>>
>>> Wondering whether there is a way to calibrate the USRP such that the
>>> frequency offset does not vary in shorter time-scales
>>>
>>>
>>>
>>> Thanks,
>>> M
>>>
>>>
>>> _______________________________________________
>>> 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/20130515/0b9caf2e/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 15 May 2013 12:35:39 -0400
From: mahaveer gupta <[email protected]>
To: Matt Ettus <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Frequency Offsets for USRP -N210
Message-ID:
<camhwhyy8lbwsl7dd8nrxdr1z+71na3utn5ddklx1ghcsapd...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
the mean angle difference between 32 samples (half preamble) which is
output by ofdm_sync_pn was around 5 degrees. The standard deviation was
around 2-.2.5 degrees
Thanks
On Wed, May 15, 2013 at 12:24 PM, Matt Ettus <[email protected]> wrote:
>
> Yes, but what are the frequency errors you are seeing?
>
>
> On Wed, May 15, 2013 at 9:22 AM, mahaveer gupta <[email protected]>wrote:
>
>> Hi Matt,
>>
>> the estimation is done once in 240 samples at 1Mhz, 2.4Ghz band. The FFT
>> size is 64
>>
>> Thanks
>>
>>
>> On Wed, May 15, 2013 at 12:02 PM, Matt Ettus <[email protected]> wrote:
>>
>>>
>>> The estimator has its own error. What size are the changes you are
>>> seeing?
>>>
>>> Matt
>>>
>>>
>>> On Tue, May 14, 2013 at 11:03 PM, mahaveer gupta
>>> <[email protected]>wrote:
>>>
>>>> Hello,
>>>>
>>>> The frequency offset computed for a a pair of USRP-N210's comes out to be
>>>> different every time
>>>>
>>>> Frequency offsets usually vary in longer timescales but I get completely
>>>> non-correlated values every time I make transmissions between a
>>>> transmitter-receiver pair.
>>>>
>>>> When I sent back-to-back packets, the offset estimation from different
>>>> preambles deviate as big as 30-40%. Is this the expected behavior? Will
>>>> appreciate if somebody can help me figure out whats going on here?
>>>>
>>>> Wondering whether there is a way to calibrate the USRP such that the
>>>> frequency offset does not vary in shorter time-scales
>>>>
>>>>
>>>>
>>>> Thanks,
>>>> M
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20130515/e865d97e/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 15 May 2013 10:30:04 -0700
From: Matt Ettus <[email protected]>
To: mahaveer gupta <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Frequency Offsets for USRP -N210
Message-ID:
<CAN=1kn9QDHPW_Hc604VuJ5b8rkuzhEuG=k0fyDeFVXVRYY=d...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
32 samples is a very short time to measure frequency. Have you measured in
the same way on simulated data with comparable noise levels?
Matt
On Wed, May 15, 2013 at 9:35 AM, mahaveer gupta <[email protected]>wrote:
> the mean angle difference between 32 samples (half preamble) which is
> output by ofdm_sync_pn was around 5 degrees. The standard deviation was
> around 2-.2.5 degrees
>
> Thanks
>
>
> On Wed, May 15, 2013 at 12:24 PM, Matt Ettus <[email protected]> wrote:
>
>>
>> Yes, but what are the frequency errors you are seeing?
>>
>>
>> On Wed, May 15, 2013 at 9:22 AM, mahaveer gupta <[email protected]>wrote:
>>
>>> Hi Matt,
>>>
>>> the estimation is done once in 240 samples at 1Mhz, 2.4Ghz band. The FFT
>>> size is 64
>>>
>>> Thanks
>>>
>>>
>>> On Wed, May 15, 2013 at 12:02 PM, Matt Ettus <[email protected]> wrote:
>>>
>>>>
>>>> The estimator has its own error. What size are the changes you are
>>>> seeing?
>>>>
>>>> Matt
>>>>
>>>>
>>>> On Tue, May 14, 2013 at 11:03 PM, mahaveer gupta
>>>> <[email protected]>wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> The frequency offset computed for a a pair of USRP-N210's comes out to be
>>>>> different every time
>>>>>
>>>>> Frequency offsets usually vary in longer timescales but I get completely
>>>>> non-correlated values every time I make transmissions between a
>>>>> transmitter-receiver pair.
>>>>>
>>>>> When I sent back-to-back packets, the offset estimation from different
>>>>> preambles deviate as big as 30-40%. Is this the expected behavior? Will
>>>>> appreciate if somebody can help me figure out whats going on here?
>>>>>
>>>>> Wondering whether there is a way to calibrate the USRP such that the
>>>>> frequency offset does not vary in shorter time-scales
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>> M
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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/20130515/256fa6e0/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 15 May 2013 13:39:53 -0400
From: mahaveer gupta <[email protected]>
To: Matt Ettus <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Frequency Offsets for USRP -N210
Message-ID:
<camhwhya6olynssuvxfh6d9ww+t3xmhs5uenkbpkikepsxkr...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Thats a good point. Simulations could be helpful, also will measure the
frequency offset over a larger sample size (like 1024). In general my
expectation is that the offset should not vary much except for temperature
of the daughterboard, if it gets heated up
On Wed, May 15, 2013 at 1:30 PM, Matt Ettus <[email protected]> wrote:
>
> 32 samples is a very short time to measure frequency. Have you measured
> in the same way on simulated data with comparable noise levels?
>
> Matt
>
>
> On Wed, May 15, 2013 at 9:35 AM, mahaveer gupta <[email protected]>wrote:
>
>> the mean angle difference between 32 samples (half preamble) which is
>> output by ofdm_sync_pn was around 5 degrees. The standard deviation was
>> around 2-.2.5 degrees
>>
>> Thanks
>>
>>
>> On Wed, May 15, 2013 at 12:24 PM, Matt Ettus <[email protected]> wrote:
>>
>>>
>>> Yes, but what are the frequency errors you are seeing?
>>>
>>>
>>> On Wed, May 15, 2013 at 9:22 AM, mahaveer gupta <[email protected]>wrote:
>>>
>>>> Hi Matt,
>>>>
>>>> the estimation is done once in 240 samples at 1Mhz, 2.4Ghz band. The
>>>> FFT size is 64
>>>>
>>>> Thanks
>>>>
>>>>
>>>> On Wed, May 15, 2013 at 12:02 PM, Matt Ettus <[email protected]> wrote:
>>>>
>>>>>
>>>>> The estimator has its own error. What size are the changes you are
>>>>> seeing?
>>>>>
>>>>> Matt
>>>>>
>>>>>
>>>>> On Tue, May 14, 2013 at 11:03 PM, mahaveer gupta <[email protected]
>>>>> > wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> The frequency offset computed for a a pair of USRP-N210's comes out to
>>>>>> be different every time
>>>>>>
>>>>>> Frequency offsets usually vary in longer timescales but I get completely
>>>>>> non-correlated values every time I make transmissions between a
>>>>>> transmitter-receiver pair.
>>>>>>
>>>>>> When I sent back-to-back packets, the offset estimation from different
>>>>>> preambles deviate as big as 30-40%. Is this the expected behavior? Will
>>>>>> appreciate if somebody can help me figure out whats going on here?
>>>>>>
>>>>>> Wondering whether there is a way to calibrate the USRP such that the
>>>>>> frequency offset does not vary in shorter time-scales
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> M
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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/20130515/4964383d/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 15 May 2013 19:59:26 +0100
From: Mark McCarron <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] USRP B100 and USB 3.0
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Does anyone know if there are any plans to update the B100 to USB 3.0?
If so, does anyone know what options will exist for current B100 owners?
Regards,
Mark McCarron
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130515/00e08559/attachment-0001.html>
------------------------------
Message: 8
Date: Wed, 15 May 2013 22:02:10 +0000 (UTC)
From: Ken <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Sending data to USRP2 with Simulink, without
Buffer Overflow
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Mike McLernon <Mike.McLernon@...> writes:
>
> Hi Vlad,
>
> Some questions to make sure I understand your working environment:
> 1. What version of MATLAB/Simulink are you using? R2010b?
> 2. What frame size(s) are you using?
> 3. What is your USRP decimation factor on the Rx side?
> 4. Have you confirmed buffer overflow with the 'overrun' port on the
USRP Rx block?
> 5. Have you tried running in Rapid Accelerator mode?
>
> Once we get that info, we can diagnose a bit better.
>
> Hth,
> Mike
>
> -----Original Message-----
> From: usrp-users-bounces@...
> [mailto:usrp-users-bounces@...] On Behalf Of Vlad Stoica
> Sent: Wednesday, April 13, 2011 5:19 AM
> To: USRP-users@...
> Subject: [USRP-users] Sending data to USRP2 with Simulink, without Buffer
Overflow
>
> Hello guys
>
> I have implemented an OFDM transmitter and receiver modell in Simulink.
> It should work at 10.7MHz with the LF daughterboards.
>
> I use frame based computing, and one frame lasts 46.6msec. My signal has a
width of 40kHz.
>
> My first tests have been to write the OFDM modulated signal into a wave
file, output it via soundcard, with a
> SMIQ Modulator do a vector modulation to 10.7MHz and then give that signal
to the RX.
>
> On the computer i ran the receive modell (with frequency and time synchro)
and it worked fine !
>
> Now instead of writing a wave file i directly send the data to the USRP2.
> But it seems that some packets get lost, and i guess there is a buffer
overflow at the USRP2 input.
>
> Do you know how i can synchronize my transmitter modell with the buffer in
USRP2 ?
>
> I'm thinking about using UHD drivers, and Embedded Matlab "load libraries"
> and transmit the files with the UHD.
>
> Thanks for ideas and hints !
>
> Greetz
> Vlad
> --
> NEU: FreePhone - kostenlos mobil telefonieren und surfen!
> Jetzt informieren: http://www.gmx.net/de/go/freephone
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@...
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
Hello to anyone who can help me out. I am a total stranger, when it comes to
using GNU and SDR. I am interested in playing with a complete transmit and
receive OFDM model that can be ported into USRP. I don't mind giving my e-
mail. I would also like to put convolutional or permutation codding in the
model.
Ken
------------------------------
Message: 9
Date: Thu, 16 May 2013 02:33:34 +0000
From: Mike McLernon <[email protected]>
To: Ken <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Sending data to USRP2 with Simulink, without
Buffer Overflow
Message-ID:
<e3879be9a282cb45aab7ce258a9ae48f21a2f...@exmb-01-ah.ad.mathworks.com>
Content-Type: text/plain; charset="us-ascii"
Hi Ken,
Do you plan to use GNU Radio or MATLAB/Simulink?
Mike
________________________________________
From: USRP-users [[email protected]] on behalf of Ken
[[email protected]]
Sent: Wednesday, May 15, 2013 6:02 PM
To: [email protected]
Subject: Re: [USRP-users] Sending data to USRP2 with Simulink, without Buffer
Overflow
Mike McLernon <Mike.McLernon@...> writes:
>
> Hi Vlad,
>
> Some questions to make sure I understand your working environment:
> 1. What version of MATLAB/Simulink are you using? R2010b?
> 2. What frame size(s) are you using?
> 3. What is your USRP decimation factor on the Rx side?
> 4. Have you confirmed buffer overflow with the 'overrun' port on the
USRP Rx block?
> 5. Have you tried running in Rapid Accelerator mode?
>
> Once we get that info, we can diagnose a bit better.
>
> Hth,
> Mike
>
> -----Original Message-----
> From: usrp-users-bounces@...
> [mailto:usrp-users-bounces@...] On Behalf Of Vlad Stoica
> Sent: Wednesday, April 13, 2011 5:19 AM
> To: USRP-users@...
> Subject: [USRP-users] Sending data to USRP2 with Simulink, without Buffer
Overflow
>
> Hello guys
>
> I have implemented an OFDM transmitter and receiver modell in Simulink.
> It should work at 10.7MHz with the LF daughterboards.
>
> I use frame based computing, and one frame lasts 46.6msec. My signal has a
width of 40kHz.
>
> My first tests have been to write the OFDM modulated signal into a wave
file, output it via soundcard, with a
> SMIQ Modulator do a vector modulation to 10.7MHz and then give that signal
to the RX.
>
> On the computer i ran the receive modell (with frequency and time synchro)
and it worked fine !
>
> Now instead of writing a wave file i directly send the data to the USRP2.
> But it seems that some packets get lost, and i guess there is a buffer
overflow at the USRP2 input.
>
> Do you know how i can synchronize my transmitter modell with the buffer in
USRP2 ?
>
> I'm thinking about using UHD drivers, and Embedded Matlab "load libraries"
> and transmit the files with the UHD.
>
> Thanks for ideas and hints !
>
> Greetz
> Vlad
> --
> NEU: FreePhone - kostenlos mobil telefonieren und surfen!
> Jetzt informieren: http://www.gmx.net/de/go/freephone
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@...
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
Hello to anyone who can help me out. I am a total stranger, when it comes to
using GNU and SDR. I am interested in playing with a complete transmit and
receive OFDM model that can be ported into USRP. I don't mind giving my e-
mail. I would also like to put convolutional or permutation codding in the
model.
Ken
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 10
Date: Wed, 15 May 2013 21:46:17 -0700
From: Matt Ettus <[email protected]>
To: Mark McCarron <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP B100 and USB 3.0
Message-ID:
<CAN=1kn-fdu_uw4b4_o8segczpzitizscyxglcglef8hebb1...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Mark,
We are always working on new products, and will have some to announce soon.
As for "options" for owners of current products, I am not sure what you
mean. The B100 will continue to function and be fully supported by Ettus
Research long after any new products are released.
The USRP1 was released on January 1st, 2005, more than 8 years ago. We are
still supporting them, and people are still using them (and even buying new
ones!) despite our subsequent release of the USRP2, N200, N210, B100, E100,
and E110. We fully intend for that pattern to continue.
Matt Ettus
On Wed, May 15, 2013 at 11:59 AM, Mark McCarron <[email protected]>wrote:
> Does anyone know if there are any plans to update the B100 to USB 3.0?
>
> If so, does anyone know what options will exist for current B100 owners?
>
> Regards,
>
> Mark McCarron
>
> _______________________________________________
> 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/20130515/ccef3a5d/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 33, Issue 14
******************************************
