Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: RFNoC Polyphase Filterbank Channelizer / Synthesizer
(Jason Matusiak)
2. [UHD] 3.9.4-RC1 (Martin Braun)
3. Re: [UHD] 3.9.4-RC1 (Martin Braun)
4. X310 Timeout Error while Updating FPGA (Richard Bell)
5. Re: X310 Timeout Error while Updating FPGA (Marcus D. Leech)
6. Re: X310 Timeout Error while Updating FPGA (Richard Bell)
7. Re: N210 w/ UBX Bursting Issue (Nate Temple)
8. Re: X310 Timeout Error while Updating FPGA (Marcus D. Leech)
9. Re: X310 Timeout Error while Updating FPGA (Richard Bell)
----------------------------------------------------------------------
Message: 1
Date: Fri, 22 Apr 2016 12:27:34 -0400
From: Jason Matusiak <[email protected]>
To: [email protected], "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] RFNoC Polyphase Filterbank Channelizer /
Synthesizer
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Anselm, thanks for putting this out there to the community!!
I tried to test it out, but I had some issues. I burned the FPGA image
and moved the xml files to the appropriate folders. I then ran
"uhd_usrp_probe --init-only" and got the following error:
<snip>
-- [RFNoC Factory] Using controller key 'Block' and block name 'Channelizer'
-- block_ctrl_base()
-- base_path = "/home/jmat/target/share/uhd/rfnoc"
-- Reading XML file:
/home/jmat/target/share/uhd/rfnoc/blocks/channelizer.xml
-- Found valid blockdef
-- NOC ID: 0x11F4000000000000 Block ID: 0/Channelizer_0
-- [0/Channelizer_0] Adding port definition at
xbar/Channelizer_0/ports/in/0: type = 'sc16' pkt_size = '0' vlen = '0'
-- [0/Channelizer_0] Adding port definition at
xbar/Channelizer_0/ports/out/0: type = 'sc16' pkt_size = '0' vlen = '0'
-- [NocScript] Executing and asserting code: SR_WRITE("SR_PKT_SIZE",
$pkt_size)
Error: LookupError: Path not found in tree:
/mboards/0/xbar/Channelizer_0/args/0/pkt_size/type
</snip>
Any idea what I am missing?
TIA!
------------------------------
Message: 2
Date: Fri, 22 Apr 2016 11:32:18 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: [USRP-users] [UHD] 3.9.4-RC1
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Dear community,
we're close to another stable release of UHD. One of the reasons we are
releasing this much sooner than usual is the fact that a bug was
introduced in 3.9.3, which affects full-duplex operations. There are a
few other minor issues resolved in this release, too, so once this is
released we do recommend updating to this version.
Anyone tracking maint branch will already have all the updates. We do
appreciate any feedback on this RC!
Thanks everyone,
Martin
PS: Changelog:
## 003.009.004
- GPIO control: Fix address mismatch for RX and full duplex.
This fixes full-duplex mode for most devices.
- B200: Fixed auto rate selection (can now select 61.44 Msps)
- UBX: Fix member declaration order which could cause
segfaults for debug builds
- Manual/Docs: Numerous fixes, use dot for graphs in manual
- Utils: multiple fixes for query_gpsdo_sensors, fixed floating point
comparison
- Windows: Include registry file in installation
- Converters: Improve NEON converters
------------------------------
Message: 3
Date: Fri, 22 Apr 2016 12:42:53 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] [UHD] 3.9.4-RC1
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Forgot to point out the actual tag:
https://github.com/EttusResearch/uhd/tree/003_009_004_rc1
M
On 04/22/2016 11:32 AM, Martin Braun wrote:
> Dear community,
>
> we're close to another stable release of UHD. One of the reasons we are
> releasing this much sooner than usual is the fact that a bug was
> introduced in 3.9.3, which affects full-duplex operations. There are a
> few other minor issues resolved in this release, too, so once this is
> released we do recommend updating to this version.
> Anyone tracking maint branch will already have all the updates. We do
> appreciate any feedback on this RC!
>
> Thanks everyone,
> Martin
>
> PS: Changelog:
>
> ## 003.009.004
> - GPIO control: Fix address mismatch for RX and full duplex.
> This fixes full-duplex mode for most devices.
> - B200: Fixed auto rate selection (can now select 61.44 Msps)
> - UBX: Fix member declaration order which could cause
> segfaults for debug builds
> - Manual/Docs: Numerous fixes, use dot for graphs in manual
> - Utils: multiple fixes for query_gpsdo_sensors, fixed floating point
> comparison
> - Windows: Include registry file in installation
> - Converters: Improve NEON converters
>
------------------------------
Message: 4
Date: Fri, 22 Apr 2016 13:30:33 -0700
From: Richard Bell <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] X310 Timeout Error while Updating FPGA
Message-ID:
<cammoi3u7zif9hscm+r_bvx0krqv2qoh4zxhojagbzff3sza...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
I've been attempting to update my X310 with the latest UHD FPGA image. I'm
using the SFP+ Port 0 with an SFP+ to Ethenet adapter over 1GigE ethernet
cable directly connected to my laptop. Whenever I execute
uhd_image_loader --args="type=x310,addr=192.168.10.2,fpga=HGS"
it starts working, getting as high as 80% complete, but then the following
happens:
rbell@rbell:/$ uhd_image_loader
--args="type=x300,addr=192.168.10.2,fpga=HGS"
linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-269-g053111dc
Unit: USRP X310 (F4E68A, 192.168.10.2)
FPGA Image: /usr/local/share/uhd/images/usrp_x310_fpga_HGS.bit
-- Initializing FPGA loading...successful.
-- Loading HGS FPGA image: 35% (43/121 sectors)Error: RuntimeError: Timed
out waiting for reply from device.
You can see on this run it only made it to 35%. I re-imaged the X310 using
a JTAG cable and tried again to update the FPGA but it still fails with the
same Timed out error.
Any idea what's going wrong and how I should fix it?
Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160422/25a2ea08/attachment-0001.html>
------------------------------
Message: 5
Date: Fri, 22 Apr 2016 16:59:39 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] X310 Timeout Error while Updating FPGA
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 04/22/2016 04:30 PM, Richard Bell via USRP-users wrote:
> Hello,
>
> I've been attempting to update my X310 with the latest UHD FPGA image.
> I'm using the SFP+ Port 0 with an SFP+ to Ethenet adapter over 1GigE
> ethernet cable directly connected to my laptop. Whenever I execute
>
> uhd_image_loader --args="type=x310,addr=192.168.10.2,fpga=HGS"
>
> it starts working, getting as high as 80% complete, but then the
> following happens:
>
> rbell@rbell:/$ uhd_image_loader
> --args="type=x300,addr=192.168.10.2,fpga=HGS"
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-269-g053111dc
>
> Unit: USRP X310 (F4E68A, 192.168.10.2)
> FPGA Image: /usr/local/share/uhd/images/usrp_x310_fpga_HGS.bit
> -- Initializing FPGA loading...successful.
> -- Loading HGS FPGA image: 35% (43/121 sectors)Error: RuntimeError:
> Timed out waiting for reply from device.
>
>
> You can see on this run it only made it to 35%. I re-imaged the X310
> using a JTAG cable and tried again to update the FPGA but it still
> fails with the same Timed out error.
>
> Any idea what's going wrong and how I should fix it?
>
> Rich
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Do you happen to have an 82579LM NIC in your laptop?
Have you tried a different ethernet cable?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160422/12faba66/attachment-0001.html>
------------------------------
Message: 6
Date: Fri, 22 Apr 2016 14:42:15 -0700
From: Richard Bell <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310 Timeout Error while Updating FPGA
Message-ID:
<cammoi3vjtyxr5ykbbnqygraxxohyayqcm7jlk3ttbsrz8zv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
You somehow called out the NIC in my laptop. I have a feeling you're about
to tell me what's going on.
description: Ethernet interface
product: 82579LM Gigabit Network Connection
vendor: Intel Corporation
I tried switching out the network cable anyway, same issue.
Rich
On Fri, Apr 22, 2016 at 1:59 PM, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> On 04/22/2016 04:30 PM, Richard Bell via USRP-users wrote:
>
> Hello,
>
> I've been attempting to update my X310 with the latest UHD FPGA image. I'm
> using the SFP+ Port 0 with an SFP+ to Ethenet adapter over 1GigE ethernet
> cable directly connected to my laptop. Whenever I execute
>
> uhd_image_loader --args="type=x310,addr=192.168.10.2,fpga=HGS"
>
> it starts working, getting as high as 80% complete, but then the following
> happens:
>
> rbell@rbell:/$ uhd_image_loader
> --args="type=x300,addr=192.168.10.2,fpga=HGS"
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-269-g053111dc
>
> Unit: USRP X310 (F4E68A, 192.168.10.2)
> FPGA Image: /usr/local/share/uhd/images/usrp_x310_fpga_HGS.bit
> -- Initializing FPGA loading...successful.
> -- Loading HGS FPGA image: 35% (43/121 sectors)Error: RuntimeError: Timed
> out waiting for reply from device.
>
>
> You can see on this run it only made it to 35%. I re-imaged the X310 using
> a JTAG cable and tried again to update the FPGA but it still fails with the
> same Timed out error.
>
> Any idea what's going wrong and how I should fix it?
>
> Rich
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> Do you happen to have an 82579LM NIC in your laptop?
>
> Have you tried a different ethernet cable?
>
>
>
> _______________________________________________
> 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/20160422/471447f3/attachment-0001.html>
------------------------------
Message: 7
Date: Fri, 22 Apr 2016 17:06:02 -0700
From: Nate Temple <[email protected]>
To: Dave NotTelling <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] N210 w/ UBX Bursting Issue
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Dave,
Could you please send me the flowgraphs and any OOTs / modules / frame
synchronizer / code for this issue? Could you also send any instructions you
can put together on the process of running them to recreate this issue? (Gains,
freq, etc?)
I will be at the office this next week and will have access to a N series +
UBX-40, and X310 + UBX-160, and I will test them to try and recreate this issue.
- Nate
> On Apr 21, 2016, at 6:51 PM, Dave NotTelling via USRP-users
> <[email protected]> wrote:
>
> I am working on creating an app that transmits very short bursts (< 100
> bytes) very rapidly over a range of frequencies (FHSS). In order to
> accomplish the bursting I am using tx_time and tx_freq. The SOB and EOB
> values are being calculated automatically by the UHD library since I have a
> length tag. What I am seeing is that after a period of time (varies heavily)
> the data frame being sent will not correlate with the frequency. If 0x123456
> was to be transmitted on freq1 and 0x789012 to be transmittedon freq2 then
> what I will see is 0x123456 on freq2.
>
> I have an example attached to this message. The file (when unzipped)
> contains binary data. It is the output of the demodulator piped through a
> frame synchronizer I wrote. Two signals are transmitted at 5 MHz apart. The
> actual space between them is something around 3 MHz. I have a low pass
> filter that selects just the 1 MHz of spectrum I need to capture one of the
> signals for demodulation. One signal is transmitting: [0x00, 0xff, 0xaa,
> 0xaa, 0x00, 0x00, 0x7e, 0x7e, 121, 239, 87, 19, 23, 101, 69, 9, 187, 6, 18,
> 222, 173, 191, 180, 11, 232, 135, 250, 159, 167, 212, 215, 138, 76, 12] and
> the other is transmitting [0x00, 0xff, 0xaa, 0xaa, 0xff, 0xff, 105, 42, 121,
> 239, 87, 19, 23, 101, 69, 9, 187, 6, 18, 222, 173, 191, 180, 11, 232, 135,
> 250, 159, 167, 212, 215, 138, 76, 12]. The last 8 bytes of both are actually
> replaced with the current time in microseconds in order to synchronize both
> signals. The attached file contains just one of those signals (the first
> one). Both pattern
s are almost identical except for the 4-7th (0-based) bytes. This was
intentional so that it would be easy to see that the demod is working correctly
and that the issue is not with the actual demod steps.
>
> Anywho, the file starts off well with the correct bit pattern showing up
> (000000001111111110101010101010100000000000000000011111100111111001111001111011110101011100010011000101110110010101000101000010011011101100000110000100101101111010101101101111111011010000001011111010001000011100000000000001010011000100001000010101110010000011100101101000)
> remembering that the last 64 bits are a timestamp and change on each frame.
> If it's of any use, the time stamps should be something on the order of 5
> milliseconds apart. At frame number 8614 you can see that the pattern has
> changed to what the other channel is sending
> (000000001111111110101010101010101111111111111111011010010010101001111001111011110101011100010011000101110110010101000101000010011011101100000110000100101101111010101101101111111011010000001011111010001000011100000000000001010011000100001000010111010000101000010110111010).
> This happens again at 9745, 11619, 16219, 16376, 19266, 28360, and lots
> more.
>
> The farther you get in the file the worse things get. But, it's no longer an
> issue of the other channels data getting through, but now the bits are
> getting cut off. You'll notice that around line 39670 things start to get
> cut off bad. There are lots of ones because I am using a squelch to only let
> the bursts through which yields a much better demod. By around line 61583
> things have seriously deteriorated. It gets worse from there until line
> 81697 where I restarted the modulation graph. Now things look peachy again.
> But, you can see that right off the bat the data from the other channel is
> now in this channel.
>
> At the end of the file I was stopping and starting the modulator just to see
> if I always got data from the other channel when the modulator was starting.
>
> At no point in this file did I get any errors. No underflows, overflows,
> lates, etc.
>
> So, it appears as though either the tx_freq tag or the vector is getting
> munged somewhere before making it out of the transmitter.
>
> I discovered this oddity when my receiver was suddenly losing sync even
> though I was still transmitting. For a test I pointed my demod to a FIFO and
> ran it through the frame sync tool to see the bits live and found that the
> data on channel X was the data that should be on channel Y. Sometimes it
> takes several minutes to swap over. It's really inconsistent.
>
> If anyone from Ettus would like the flow graph and custom modules I'd be
> happy to send them. They are not in a way that I'd like to publicly release
> them at the moment though.
>
> Oh, and I have had this issue with 3.9.2 and 3.10 (what's in the Git repo as
> of today). 3.9.3 has issues with my X310 not doing simultaneous RX and TX.
> I am using an N210 with the UBX-40 for transmission and the X310 with UBX-160
> for reception. I have tried connecting the two directly together with 60 dB
> worth of attenuators and just over the air with the antennas inches apart.
> The X310 is hooked up to an Intel X710 10Gb NIC using 10Gb direct attach
> copper cables. The N210 is hooked up to my motherboard's 1 Gb NIC. The CPU
> load was stable at around 1/8th total capacity. Nothing else was going on
> while the test was running.
>
> My GNU Radio version is 885b5a75 (fresh install from Git this morning)
>
> Thank you!
>
> (I've included the actual file as well as a link to my Google Drive account
> in case the attachment gets stripped)
>
> ?
> uhd_error.txt.gz
> ?
> <uhd_error.txt.gz>_______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 8
Date: Fri, 22 Apr 2016 20:13:32 -0400
From: "Marcus D. Leech" <[email protected]>
To: Richard Bell <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310 Timeout Error while Updating FPGA
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 04/22/2016 05:42 PM, Richard Bell wrote:
> You somehow called out the NIC in my laptop. I have a feeling you're
> about to tell me what's going on.
>
> description: Ethernet interface
> product: 82579LM Gigabit Network Connection
> vendor: Intel Corporation
>
> I tried switching out the network cable anyway, same issue.
>
> Rich
The 82579LM has a notorious, unfixable, hardware bug having to do with
the FIFO controller. It will spontaneously drop packets.
For TCP-based protocols, this is more-or-less a non-issue, but for
high-speed UDP streaming, it's fatal.
If you have the ability to use a PCI-e GiGe card that should work (as
long as it isn't, again, the 82579LM chip).
>
> On Fri, Apr 22, 2016 at 1:59 PM, Marcus D. Leech via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> On 04/22/2016 04:30 PM, Richard Bell via USRP-users wrote:
>> Hello,
>>
>> I've been attempting to update my X310 with the latest UHD FPGA
>> image. I'm using the SFP+ Port 0 with an SFP+ to Ethenet adapter
>> over 1GigE ethernet cable directly connected to my laptop.
>> Whenever I execute
>>
>> uhd_image_loader --args="type=x310,addr=192.168.10.2,fpga=HGS"
>>
>> it starts working, getting as high as 80% complete, but then the
>> following happens:
>>
>> rbell@rbell:/$ uhd_image_loader
>> --args="type=x300,addr=192.168.10.2,fpga=HGS"
>> linux; GNU C++ version 4.8.4; Boost_105400;
>> UHD_003.010.git-269-g053111dc
>>
>> Unit: USRP X310 (F4E68A, 192.168.10.2)
>> FPGA Image: /usr/local/share/uhd/images/usrp_x310_fpga_HGS.bit
>> -- Initializing FPGA loading...successful.
>> -- Loading HGS FPGA image: 35% (43/121 sectors)Error:
>> RuntimeError: Timed out waiting for reply from device.
>>
>>
>> You can see on this run it only made it to 35%. I re-imaged the
>> X310 using a JTAG cable and tried again to update the FPGA but it
>> still fails with the same Timed out error.
>>
>> Any idea what's going wrong and how I should fix it?
>>
>> Rich
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> Do you happen to have an 82579LM NIC in your laptop?
>
> Have you tried a different ethernet cable?
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160422/9e50e6df/attachment-0001.html>
------------------------------
Message: 9
Date: Fri, 22 Apr 2016 20:36:46 -0700
From: Richard Bell <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310 Timeout Error while Updating FPGA
Message-ID:
<CAMMoi3s8X6BMWnk=EDhJMOM1scR1oKwow=ftvfh3wintg+o...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I just tried this on another laptop using a Qualcomm Chipset and I didn't
have this problem at all. Thanks for the heads up on my crappy laptop NIC.
Rich
On Fri, Apr 22, 2016 at 5:13 PM, Marcus D. Leech <[email protected]> wrote:
> On 04/22/2016 05:42 PM, Richard Bell wrote:
>
> You somehow called out the NIC in my laptop. I have a feeling you're about
> to tell me what's going on.
>
> description: Ethernet interface
> product: 82579LM Gigabit Network Connection
> vendor: Intel Corporation
>
> I tried switching out the network cable anyway, same issue.
>
> Rich
>
> The 82579LM has a notorious, unfixable, hardware bug having to do with the
> FIFO controller. It will spontaneously drop packets.
> For TCP-based protocols, this is more-or-less a non-issue, but for
> high-speed UDP streaming, it's fatal.
>
> If you have the ability to use a PCI-e GiGe card that should work (as long
> as it isn't, again, the 82579LM chip).
>
>
>
>
> On Fri, Apr 22, 2016 at 1:59 PM, Marcus D. Leech via USRP-users <
> [email protected]> wrote:
>
>> On 04/22/2016 04:30 PM, Richard Bell via USRP-users wrote:
>>
>> Hello,
>>
>> I've been attempting to update my X310 with the latest UHD FPGA image.
>> I'm using the SFP+ Port 0 with an SFP+ to Ethenet adapter over 1GigE
>> ethernet cable directly connected to my laptop. Whenever I execute
>>
>> uhd_image_loader --args="type=x310,addr=192.168.10.2,fpga=HGS"
>>
>> it starts working, getting as high as 80% complete, but then the
>> following happens:
>>
>> rbell@rbell:/$ uhd_image_loader
>> --args="type=x300,addr=192.168.10.2,fpga=HGS"
>> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-269-g053111dc
>>
>> Unit: USRP X310 (F4E68A, 192.168.10.2)
>> FPGA Image: /usr/local/share/uhd/images/usrp_x310_fpga_HGS.bit
>> -- Initializing FPGA loading...successful.
>> -- Loading HGS FPGA image: 35% (43/121 sectors)Error: RuntimeError: Timed
>> out waiting for reply from device.
>>
>>
>> You can see on this run it only made it to 35%. I re-imaged the X310
>> using a JTAG cable and tried again to update the FPGA but it still fails
>> with the same Timed out error.
>>
>> Any idea what's going wrong and how I should fix it?
>>
>> Rich
>>
>>
>> _______________________________________________
>> USRP-users mailing
>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> Do you happen to have an 82579LM NIC in your laptop?
>>
>> Have you tried a different ethernet cable?
>>
>>
>>
>> _______________________________________________
>> 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/20160422/228c8bed/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 68, Issue 24
******************************************
