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: UHD loses GPS lock with "no GPRMC message found" - N210
and GPSDO (Neel Pandeya)
2. Re: UHD loses GPS lock with "no GPRMC message found" - N210
and GPSDO (Kathy Hertzog)
3. Re: 2 Rx antennas with CBX and USRP N210 (Andrei Stoica)
4. Re: Problem of running two channels of TVRX2 (Tai Wooi Ling)
5. UBX can not transmit signal (liu Jong)
6. Re: Frequency synchronization problem (Marc Bauduin)
7. Decaying RX energy & oscillations on N210+RFX2450 Re:
Frequency synchronization problem (Marcus M?ller)
8. How to debug the B210 by JTAG ([email protected])
9. Re: How to debug the B210 by JTAG (Marcus M?ller)
10. Re: UBX can not transmit signal (Michael West)
----------------------------------------------------------------------
Message: 1
Date: Thu, 12 May 2016 10:30:18 -0700
From: Neel Pandeya <[email protected]>
To: Kathy Hertzog <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] UHD loses GPS lock with "no GPRMC message
found" - N210 and GPSDO
Message-ID:
<CACaXmv--E0fyiQ4Yz__=-X=J6EYrGZ3M+QF5w9jCian=b+d...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Kathy:
Had this GPSDO unit been working properly before? Did it just suddenly
start showing this every-four-seconds problem at some point in time?
Do you have another N210 GPSDO unit that you could swap in, just to see if
the problem is with this specific unit?
--Neel Pandeya
On 5 May 2016 at 11:34, Kathy Hertzog via USRP-users <
[email protected]> wrote:
> Hi,
>
> I have a very simple GRC project with a UHD:USRP Source Block, a QT GUI
> Frequency Sink Block and two function probes into the UHD's function
> "get_mboard_sensor". When it works, two QT GUI Labels are filled with the
> output from calls to get the "gps_time" and "gps_lock".
>
> I'm connected to an N210 with GPSDO.
>
> GNURadio 3.7.9.1, UHD 3.09.02, Ubuntu 14.04.4 trusty
>
> Even with very slow (once every 4 seconds) access to the "gps_time" and
> "gps_lock" sensor values this example eventually loses lock and stops
> reporting time. The rest of the flowgraph keeps running.
>
> At first there are UHD Warnings: "get_time: ValueError: get_nmea(): no
> GPRMC message found". Then it throws a "RuntimeError: ValueError: Timeout
> after no valid message found" from the "get_mboard_sensor('gps_time')"
> which halts writing to the QT GUI Labels. The spectrum keeps updating.
>
> If I add a try/except for the RuntimeError in the Python code for the
> get_time function probe I eventually still get continuous UHD Warnings
> about "no GPRMC message found" but, of course, the exception is caught.
> Just adding a pass doesn't fix it though. Right now this is an
> unrecoverable error - the system never gets lock back and the time is never
> updated again.
>
> Is there anything I can do in the "except" that will allow the GPS to lock
> again?
>
> I do have a good GPS antenna and signal with re-radiators by the puck as
> well as other equipment on the same antenna that is not having a problem
> staying locked.
>
> UHD Setup:
> Device Address: addr0=192.168.10.2
> Sync: unknown PPS
> Mb0 Clock Source: O/B GPSDO
> Mb0 Time Source: O/B GPSDO
> Mb0 Subdev Spec: A:A A:B
> Num Channels: 2
>
> Thanks for any suggestions.
>
> Kathy Hertzog
>
> _______________________________________________
> 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/2553bc49/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 12 May 2016 11:08:00 -0700
From: Kathy Hertzog <[email protected]>
To: Neel Pandeya <[email protected]>, usrp-users
<[email protected]>
Subject: Re: [USRP-users] UHD loses GPS lock with "no GPRMC message
found" - N210 and GPSDO
Message-ID:
<cac9e-nes7y1suoh3pnke5ch5rv0ivd7yw2ypszmwacptupp...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Neel,
Thanks for responding!!
I have tried two different N210 with two different GPSDO add-ons. Both
exhibit the same behavior.
I tried the 4 second wait because Marcus Leech suggested that 1 second was
too soon (that didn't work for me either) since the NMEA sentence is only
produced every second there is a "complex caching system".
I suspect version problems but "GNURadio 3.7.9.1, UHD 3.09.02" seems to be
the recommended combination. I rebuilt UHD 3.09.02 from source. Then
rebuilt gnuradio from source, including the UHD libraries.
I would really like to know if someone else can re-create that simple GRC
block example with sustained "GPS Locked" success.
Cheers,
Kathy Hertzog
On Thu, May 12, 2016 at 10:30 AM, Neel Pandeya <[email protected]>
wrote:
> Hello Kathy:
>
> Had this GPSDO unit been working properly before? Did it just suddenly
> start showing this every-four-seconds problem at some point in time?
>
> Do you have another N210 GPSDO unit that you could swap in, just to see if
> the problem is with this specific unit?
>
> --Neel Pandeya
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160512/6fc7b6a8/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 12 May 2016 20:35:52 +0200
From: Andrei Stoica <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] 2 Rx antennas with CBX and USRP N210
Message-ID:
<ca+fxivqwscmavayztbvnosz-my_szjcpze8dno+krxhq8ue...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thank you Marcus for the clarification!
Regards,
Andrei
On Wed, May 11, 2016 at 7:42 AM, Andrei Stoica <
[email protected]> wrote:
> Hi,
>
> Is it possible to use the 2 antennas simultaneously to receive with the
> CBX daugtherboard on the USRP N210? I would like to leverage the
> prospective antenna diversity this would bring at a receiver side.
>
> Did someone already tried this using directly uhd or even maybe through
> gnuradio?
>
> Thanks!
>
> Best,
> Andrei
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160512/3d1ba940/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 12 May 2016 01:24:41 +0000
From: Tai Wooi Ling <[email protected]>
To: "[email protected]?=" <[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"
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 ??
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160512/f376e126/attachment-0001.html>
------------------------------
Message: 5
Date: Fri, 13 May 2016 14:58:17 +0800
From: liu Jong <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] UBX can not transmit signal
Message-ID:
<CAEui2n0s+j7Nk37k5tjvDUkAhQ1Qy9v31n-rdB=fpqpuyrd...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear all,
We have 3 pieces of UBX-40 board?one of which the part number is
158277B-01L and it send and receive signals normally.the others of part
number are all 158277A-01L and they only received signal, but couldn't send
out a signal. We tested this on the uhd3.9.4 . According to different
part number, need we to do some special settings?
thank you
best regards
Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160513/ddf86523/attachment-0001.html>
------------------------------
Message: 6
Date: Fri, 13 May 2016 10:55:01 +0200
From: Marc Bauduin <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Frequency synchronization problem
Message-ID:
<ca+ekp-b6veizkak3arb6g6+q9_xfotazm+vmzyudazye_ml...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks for the information.
I reduced decimation and interpolation factor to 4. In this case, the CIC
filter is bypassed and the decimation is only done with the help of two
half-band filters. Is that right?
In that case, I don't observe the decay anymore but each step are affected
by an important oscillation. I checked the spectrum of each step and I can
see some important peak for some specific frequencies. I still need to find
their origin.
I also changed the carrier frequency. Previously, I worked around 2.4 GHz.
Now I tried 2.43 GHz. In this case, I still observe important oscillations
with an interpolation factor of 4. If I reduce the sampling frequency, I am
now able to recover the step signal.
Any idea of why the results are so different when I change the carrier
frequency?
2016-05-10 16:17 GMT+02:00 <[email protected]>:
> It's a CIC decimator with FIR-based clean-up filters, as far as I know.
>
>
>
>
> On 2016-05-10 05:10, Marc Bauduin via USRP-users wrote:
>
> I increased the duration of each step to 1e4 samples. I made this
> simulation for several interpolation factors. Each time, I can approximate
> the decay with an exponential decay exp(-t/d) where d = 1.7e-4 seconds.
> This value is a little bit lower (1.2e-4 seconds) for an interpolation
> factor of 8.
>
> I am not surprised to see a peak at the beginning of each step. The
> problem is that the decay always go back the same value. I expected that,
> after some oscillation due to the decimation filter, I could observe the
> different steps.
>
> What kind of filter is used for the decimation?
>
> 2016-05-06 16:51 GMT+02:00 <[email protected]>:
>
>> What is the period of the decay? This may just be the decimation filters
>> reacting to a step change in the input, and it's just more obvious when the
>> devices are strictly synchronous. That's just a guess.
>>
>>
>>
>>
>>
>>
>>
>>
>> On 2016-05-06 05:09, Marc Bauduin via USRP-users wrote:
>>
>> Maybe I answered too quickly.
>>
>> I made a new test where I send a step signal (0.1, 0.2, ..., 1). Each
>> value is maintained during 1e3 samples. If I look at the amplitude of the
>> received signal in baseband, I am able to recover this step signal if the
>> USRPs are not synchronized. But if I synchronize them with the 10MHz clock,
>> I can see quick changes in amplitude followed by a decay. As if the radio
>> still tried to compensate a DC offset.
>>
>> I used the function set_rx_dc_offset(false) or
>> set_rx_dc_offset(false)(std::complex<double>(a,b)). The only difference is
>> the value reached after the decay.
>>
>>
>> 2016-04-27 22:24 GMT+02:00 Marc Bauduin <[email protected]>:
>>
>>> Thank you for your answer. It was effectively that.I used the
>>> function set_rx_dc_offset(false) to remove the algorithm and I don't
>>> observe this effect anymore when I send a signal constant in baseband.
>>>
>>> 2016-04-27 15:39 GMT+02:00 Marcus D. Leech via USRP-users <
>>> [email protected]>:
>>>
>>>> On 04/27/2016 08:40 AM, Herlook Search via USRP-users wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> I use two USRP N210 with the RFX2450. I manipulate them in C++.
>>>>>
>>>>> I would like to characterize the USRPs. In that way, I send very
>>>>> simple signals, as a constant signal in baseband. When I send this signal,
>>>>> I observe a circle in baseband due to the CFO. This is what I expected.
>>>>>
>>>>> If I send the same signal when the USRPs are synchronized with the
>>>>> same 10 MHz clock (I use an external square wave generator), I see that
>>>>> the
>>>>> amplitude of this sequence quickly decreases through time. If I use an
>>>>> alternate sequence of {-1;+1}, I also observe that its amplitude
>>>>> decreases.
>>>>>
>>>>> But it seems that the synchronisation works because, when I do an OFDM
>>>>> communication or a single carrier communication with the 10 MHz clock, I
>>>>> can recover my QAM constellation without CFO.
>>>>>
>>>>> Can you confirm that these results are expected from such a
>>>>> configuration? If it is the case, can we avoid them?
>>>>>
>>>>> Thanks in advance.
>>>>>
>>>>> Marc
>>>>>
>>>>> Make sure that your baseband tone is far enough away from DC so as not
>>>> to get swallowed by the DC-offset compensation algorithm, which takes a
>>>> while to converge.
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20160513/f06d65f5/attachment-0001.html>
------------------------------
Message: 7
Date: Fri, 13 May 2016 13:06:38 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: [USRP-users] Decaying RX energy & oscillations on
N210+RFX2450 Re: Frequency synchronization problem
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Marc,
On 13.05.2016 10:55, Marc Bauduin via USRP-users wrote:
> Thanks for the information.
>
> I reduced decimation and interpolation factor to 4. In this case, the
> CIC filter is bypassed and the decimation is only done with the help
> of two half-band filters. Is that right?
yes!
>
> In that case, I don't observe the decay anymore but each step are
> affected by an important oscillation. I checked the spectrum of each
> step and I can see some important peak for some specific frequencies.
> I still need to find their origin.
can you give us plots or samples? What kind of oscillation, is it
decaying, constant in frequency?
Like Marcus L., my first suspicion here is the rx_dc_offset filter; did
you disable that in this case?
Oscillations at a step wouldn't surprise me; after all, all linear
systems have what is called a step response, and so do our halfband
filters, and the analog baseband filters on the daughterboard.
>
> I also changed the carrier frequency. Previously, I worked around 2.4
> GHz. Now I tried 2.43 GHz. In this case, I still observe important
> oscillations with an interpolation factor of 4. If I reduce the
> sampling frequency, I am now able to recover the step signal.
How do you synchronize your signal generator to the USRP? What's the
generators' bandwidth.
Point is that you physically can't produce a proper step function
without any oscillations ? that would simply have infinite bandwidth.
My suspicion is that there might be analog non-perfections going on.
Again, can you give us a plot of what you're seeing?
How does your signal generator connect to the USRP?
What happens if you reduce the power of the signal and the gain of the
daughterboard?
Best regards,
Marcus
>
> Any idea of why the results are so different when I change the carrier
> frequency?
>
> 2016-05-10 16:17 GMT+02:00 <[email protected] <mailto:[email protected]>>:
>
> It's a CIC decimator with FIR-based clean-up filters, as far as I
> know.
>
>
>
>
>
> On 2016-05-10 05:10, Marc Bauduin via USRP-users wrote:
>
>> I increased the duration of each step to 1e4 samples. I made this
>> simulation for several interpolation factors. Each time, I can
>> approximate the decay with an exponential decay exp(-t/d) where
>> d = 1.7e-4 seconds. This value is a little bit lower (1.2e-4
>> seconds) for an interpolation factor of 8.
>>
>> I am not surprised to see a peak at the beginning of each step.
>> The problem is that the decay always go back the same value. I
>> expected that, after some oscillation due to the decimation
>> filter, I could observe the different steps.
>>
>> What kind of filter is used for the decimation?
>>
>> 2016-05-06 16:51 GMT+02:00 <[email protected]
>> <mailto:[email protected]>>:
>>
>> What is the period of the decay? This may just be the
>> decimation filters reacting to a step change in the input,
>> and it's just more obvious when the devices are strictly
>> synchronous. That's just a guess.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 2016-05-06 05:09, Marc Bauduin via USRP-users wrote:
>>
>> Maybe I answered too quickly.
>>
>> I made a new test where I send a step signal (0.1, 0.2,
>> ..., 1). Each value is maintained during 1e3 samples. If
>> I look at the amplitude of the received signal in
>> baseband, I am able to recover this step signal if the
>> USRPs are not synchronized. But if I synchronize them
>> with the 10MHz clock, I can see quick changes in
>> amplitude followed by a decay. As if the radio still
>> tried to compensate a DC offset.
>>
>> I used the function set_rx_dc_offset(false) or
>> set_rx_dc_offset(false)(std::complex<double>(a,b)). The
>> only difference is the value reached after the decay.
>>
>>
>> 2016-04-27 22:24 GMT+02:00 Marc Bauduin
>> <[email protected] <mailto:[email protected]>>:
>>
>> Thank you for your answer. It was effectively that.I
>> used the function set_rx_dc_offset(false) to remove
>> the algorithm and I don't observe this effect anymore
>> when I send a signal constant in baseband.
>>
>> 2016-04-27 15:39 GMT+02:00 Marcus D. Leech via
>> USRP-users <[email protected]
>> <mailto:[email protected]>>:
>>
>> On 04/27/2016 08:40 AM, Herlook Search via
>> USRP-users wrote:
>>
>> Hi everyone,
>>
>> I use two USRP N210 with the RFX2450. I
>> manipulate them in C++.
>>
>> I would like to characterize the USRPs. In
>> that way, I send very simple signals, as a
>> constant signal in baseband. When I send this
>> signal, I observe a circle in baseband due to
>> the CFO. This is what I expected.
>>
>> If I send the same signal when the USRPs are
>> synchronized with the same 10 MHz clock (I
>> use an external square wave generator), I see
>> that the amplitude of this sequence quickly
>> decreases through time. If I use an alternate
>> sequence of {-1;+1}, I also observe that its
>> amplitude decreases.
>>
>> But it seems that the synchronisation works
>> because, when I do an OFDM communication or a
>> single carrier communication with the 10 MHz
>> clock, I can recover my QAM constellation
>> without CFO.
>>
>> Can you confirm that these results are
>> expected from such a configuration? If it is
>> the case, can we avoid them?
>>
>> Thanks in advance.
>>
>> Marc
>>
>> Make sure that your baseband tone is far enough
>> away from DC so as not to get swallowed by the
>> DC-offset compensation algorithm, which takes a
>> while to converge.
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> <mailto:[email protected]>
>>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> <mailto:[email protected]>
>>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160513/a4fbdaa4/attachment-0001.html>
------------------------------
Message: 8
Date: Fri, 13 May 2016 09:30:41 +0800
From: <[email protected]>
To: "martin.braun" <[email protected]>
Cc: "usrp-users" <[email protected]>
Subject: [USRP-users] How to debug the B210 by JTAG
Message-ID: <[email protected]>
Content-Type: text/plain; charset="gbk"
1.After the download usrp_b210_fpga.bit on JTAG? B210 can not run?What am I to
do?
2.How to monitor the FPGA signal through CHIPSCOPE?
Your help will be appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160513/291c015f/attachment-0001.html>
------------------------------
Message: 9
Date: Fri, 13 May 2016 16:37:33 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] How to debug the B210 by JTAG
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Ddyyoo,
have you loaded the FX3 firmware?
Why are you loading the B210 image via JTAG? I've never considered doing
so, because the B210, in totally normal operation, loads its FPGA image
via USB.
You should be able to load the Image normally over USB (e.g. using
"uhd_uspr_probe --init-only") and use your favourite FPGA tools with the
bitstream that is in the same directory as the loaded FPGA image.
It seems like you try to debug something on the B210's FPGA ? which is a
fine thing to do, we encourage customers to get to know their hardware
to the fullest extent, but if there's something not working, we might be
able to help you directly, if you ask :)
Best regards,
Marcus
On 13.05.2016 03:30, ddyyoo via USRP-users wrote:
>
> 1.After the download usrp_b210_fpga.bit on JTAG? B210 can not run?
> What am I to do?
>
>
> 2.How to monitor the FPGA signal through CHIPSCOPE?
>
>
> Your help will be appreciated.
>
>
>
> _______________________________________________
> 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/20160513/68a74872/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 13 May 2016 07:42:57 -0700
From: Michael West <[email protected]>
To: liu Jong <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UBX can not transmit signal
Message-ID:
<cam4xkrrq1s2bay8t8kmhcobelsb-kk_ogozkbrmet_n04xo...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Jon,
There is an issue with some components on the bottom side of the UBX being
too close to the mounting holes and shorting out to the daughterboard
standoffs on the X300/X310. You can rotate the existing standoffs so they
provide more clearance for the components or install thinner standoffs.
I'm not sure, but I thought the UBX shipped with the thinner standoffs. If
not, you can contact [email protected] to request them.
Regards,
Michael
On Thu, May 12, 2016 at 11:58 PM, liu Jong via USRP-users <
[email protected]> wrote:
> Dear all,
> We have 3 pieces of UBX-40 board?one of which the part number is
> 158277B-01L and it send and receive signals normally.the others of part
> number are all 158277A-01L and they only received signal, but couldn't send
> out a signal. We tested this on the uhd3.9.4 . According to different
> part number, need we to do some special settings?
>
> thank you
> best regards
> Jon
>
> _______________________________________________
> 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/20160513/82d1596d/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 13
******************************************
