Send USRP-users mailing list submissions to
usrp-users@lists.ettus.com
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
usrp-users-requ...@lists.ettus.com
You can reach the person managing the list at
usrp-users-ow...@lists.ettus.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. No UHD devices found (Amber zhao)
2. Re: No UHD devices found (Nate Temple)
3. B200mini and low-freq modulation of tx'd signal (Steven Knudsen)
4. Re: noc_block_split_stream.v will not run at 200 MHz in
gnuradio and we receive a warning when running uhd_usrp_probe
(Jonathon Pendlum)
5. Re: No UHD devices found (Marcus D. Leech)
6. Re: Confusion about RFNoC Block to Tx (Jonathon Pendlum)
7. Re: B200mini and low-freq modulation of tx'd signal
(Steven Knudsen)
8. Re: Latest X310 RFNoC FPGA build (Jonathon Pendlum)
9. Re: Latest X310 RFNoC FPGA build (Michael Wentz)
10. Bug (kyle.un...@l-3com.com)
11. Re: Bug (Nate Temple)
12. E310 data collect and FFT plot (Subbukutty, Olivani)
13. Re: E310 data collect and FFT plot (Marcus D. Leech)
14. Re: Latest X310 RFNoC FPGA build (Jonathon Pendlum)
----------------------------------------------------------------------
Message: 1
Date: Fri, 16 Sep 2016 02:00:17 +1000
From: Amber zhao <zhaozhen...@gmail.com>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] No UHD devices found
Message-ID:
<cad+9ongmzodna3+q8ph6wjkg6owgy3z9_me4pusoec55shw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi USRP team,
I have a problem that my Ubuntu cannot connect to USRP.
[The devices and softwares' version are USRP2920, Ubuntu 14.04, GNURadio
3.7.9 UHD 003.007.002]
I use my university lab's computer and USRP.]
Problem 1. I changed the IP address in Ubuntu. Because the two USRP's IP
address is 192.168.10.4 and 192.168.10.5 respectively, so I set my IP
address as 192.168.10.3 Netmask as 255.255.255.0.
After configurating my Ubuntu's IP address, I try to ping the USRP's IP
address. But it failed.
Solution 1. I was told that the lab's computer has two network cards. I
disconnected from the network, only connect the USRP with a cable. Then I
changed the VMware's network adopter from NAT model to Bridge model. After
these processes, I run " ping 192.168.10.4" and "ping 192.168.10.5" in
terminal. It works.
BUT I am not sure is this method right or not.
Problem 2. I run " uhd_find_devices", it returns " No UHD devices found".
Try and Error:
I recognized that the USRP in lab is used for Labview, therefore I tried to
re-burn the Firmware and FPGA image files to SD card of USRP2 so that USRP
devices can support GNURadio.
It can be seen that Image Burning Successfully and I restart the USRP.
BUT! When I run " uhd_find_devices", it still return " No UHD devices
found".
?
Could you please give me some help? I really don't know how to solve this
problem.
Best wishes
Amber
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160916/1365b0ad/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2016-09-15 01^%21^%23.png
Type: image/png
Size: 211940 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160916/1365b0ad/attachment-0001.png>
------------------------------
Message: 2
Date: Thu, 15 Sep 2016 09:39:32 -0700
From: Nate Temple <nate.tem...@ettus.com>
To: Amber zhao <zhaozhen...@gmail.com>
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] No UHD devices found
Message-ID: <0e70e4f7-37d6-411c-a64d-008b0bbe3...@ettus.com>
Content-Type: text/plain; charset=utf-8
Hi Amber,
Can you try adding the --args flag with the USRP's IP added?
For example:
uhd_find_devices --args "addr=192.168.10.5"
Regards,
Nate Temple
> On Sep 15, 2016, at 9:00 AM, Amber zhao via USRP-users
> <usrp-users@lists.ettus.com> wrote:
>
> Hi USRP team,
> I have a problem that my Ubuntu cannot connect to USRP.
>
> [The devices and softwares' version are USRP2920, Ubuntu 14.04, GNURadio
> 3.7.9 UHD 003.007.002]
> I use my university lab's computer and USRP.]
>
> Problem 1. I changed the IP address in Ubuntu. Because the two USRP's IP
> address is 192.168.10.4 and 192.168.10.5 respectively, so I set my IP address
> as 192.168.10.3 Netmask as 255.255.255.0.
> After configurating my Ubuntu's IP address, I try to ping the USRP's IP
> address. But it failed.
> Solution 1. I was told that the lab's computer has two network cards. I
> disconnected from the network, only connect the USRP with a cable. Then I
> changed the VMware's network adopter from NAT model to Bridge model. After
> these processes, I run " ping 192.168.10.4" and "ping 192.168.10.5" in
> terminal. It works.
> BUT I am not sure is this method right or not.
>
> Problem 2. I run " uhd_find_devices", it returns " No UHD devices found".
> Try and Error:
> I recognized that the USRP in lab is used for Labview, therefore I tried to
> re-burn the Firmware and FPGA image files to SD card of USRP2 so that USRP
> devices can support GNURadio.
> It can be seen that Image Burning Successfully and I restart the USRP.
> BUT! When I run " uhd_find_devices", it still return " No UHD devices found".
> <Screenshot from 2016-09-15 01^%21^%23.png>
> ?
> Could you please give me some help? I really don't know how to solve this
> problem.
>
> Best wishes
> Amber
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 3
Date: Thu, 15 Sep 2016 10:46:46 -0600
From: Steven Knudsen <ee.k...@gmail.com>
To: USRP-users <usrp-users@lists.ettus.com>
Cc: Knud <k...@ieee.org>
Subject: [USRP-users] B200mini and low-freq modulation of tx'd signal
Message-ID: <328ad6af-4b81-4b2b-938b-cb39ba507...@ieee.org>
Content-Type: text/plain; charset="utf-8"
Hi,
I have a TDMA flowgraph that defines packets using tx_time and tx_sob + tx_eob.
Packets are sent to a B200mini every 10 ms (which is not important). Below I
have the packet format from GRC followed by 3 oscilloscope captures that show
the effect I?m seeing.
The B200mini is connected to an Octoclock 1 PPS reference.
The modulation is BPSK, 2x oversampled, RRC.
Image 1 - the GRC waveform that is input to the USRP sink
Image 2 - this time the transmitted signal looks pretty good. Note the leading
zeros so that the transmit power rises to full before samples are applied.
Image 3 - it appears that some form of slow modulation has been applied
Image 4 - same again, but obviously at a different offset
(oops, forgot to turn off stupid network config menu in scope caps)
I am a bit stumped. A ?theory? is that maybe I?m seeing a window of some kind
being convolved with the signal.
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen
Der entscheidende Augenblick der menschlichen Entwicklung ist immerw?hrend.
Darum sind die revolution?ren geistigen Bewegungen, welche alles Fr?here f?r
nichtig erkl?ren, im Recht, denn es ist noch nichts geschehen. - Franz Kafka
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160915/e3f18e5d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: to_USRP_2016-09-15.png
Type: image/png
Size: 64148 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160915/e3f18e5d/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tx02.jpg
Type: image/jpeg
Size: 66504 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160915/e3f18e5d/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tx01.jpg
Type: image/jpeg
Size: 64420 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160915/e3f18e5d/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tx03.jpg
Type: image/jpeg
Size: 66249 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160915/e3f18e5d/attachment-0005.jpg>
------------------------------
Message: 4
Date: Thu, 15 Sep 2016 12:24:37 -0500
From: Jonathon Pendlum <jonathon.pend...@ettus.com>
To: "Swanson, Craig" <craig.swan...@gtri.gatech.edu>
Cc: Nicolas Cuervo <nicolas.cue...@ettus.com>, Marcus M?ller
<marcus.muel...@ettus.com>, Martin Braun <martin.br...@ettus.com>,
"usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] noc_block_split_stream.v will not run at 200
MHz in gnuradio and we receive a warning when running uhd_usrp_probe
Message-ID:
<CAGdo0uQ+U1Mg=+_6h6urbew_eepbtljqdcb06uo-tg-mcgy...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Craig,
We have merged some updates. Are you still seeing this issue?
Jonathon
On Sun, Aug 28, 2016 at 11:27 PM, Swanson, Craig <
craig.swan...@gtri.gatech.edu> wrote:
> Jonathon,
>
> Both Luon Tan Phong have confirmed that when we run uhd_usrp_probe
> --init-only, we get the following UHD Warning:
> -- [RFNOC] ------- Block Setup -----------
> -- Setting up NoC-Shell Control for port #0 (SID: 00:0c>02:a0)...OK
> -- Port 160: Found NoC-Block with ID 5757000000000000.
> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/splitstream.xml
> -- Setting up NoC-Shell Control for port #1 (SID: 00:0d>02:a1)...OK
> -- [RFNoC Factory] block_ctrl_base::make()
> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/splitstream.xml
> -- [RFNoC Factory] Using controller key 'Block' and block name
> 'SplitStream'
> -- block_ctrl_base()
> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/splitstream.xml
> -- Found valid blockdef
> -- NOC ID: 0x5757000000000000 Block ID: 0/SplitStream_0
> -- [0/SplitStream_0] block_ctrl_base::clear()
> -- [0/SplitStream_0] node_ctrl_base::clear()
> -- [0/SplitStream_0] block_ctrl_base::_clear()
> -- [0/SplitStream_0] block_ctrl_base::_clear()
> -- [0/SplitStream_0] Adding port definition at
> xbar/SplitStream_0/ports/in/0: type = '' pkt_size = '0' vlen = '0'
> -- [0/SplitStream_0] Adding port definition at
> xbar/SplitStream_0/ports/out/0: type = '' pkt_size = '0' vlen = '0'
> -- [0/SplitStream_0] Adding port definition at
> xbar/SplitStream_0/ports/out/1: type = '' pkt_size = '0' vlen = '0'
>
> UHD Warning:
> [0/SplitStream_0] defines 2 input buffer sizes, but 1 input ports
> -- Performing timer loopback test... pass
> -- Performing timer loopback test... pass
>
> ?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/20160915/794948d3/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 15 Sep 2016 13:31:55 -0400
From: "Marcus D. Leech" <mle...@ripnet.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] No UHD devices found
Message-ID: <57dadb0b.8070...@ripnet.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 09/15/2016 12:00 PM, Amber zhao via USRP-users wrote:
> Hi USRP team,
> I have a problem that my Ubuntu cannot connect to USRP.
>
> [The devices and softwares' version are USRP2920, Ubuntu 14.04,
> GNURadio 3.7.9 UHD 003.007.002]
> I use my university lab's computer and USRP.]
>
> Problem 1. I changed the IP address in Ubuntu. Because the two USRP's
> IP address is 192.168.10.4 and 192.168.10.5 respectively, so I set my
> IP address as 192.168.10.3 Netmask as 255.255.255.0.
> After configurating my Ubuntu's IP address, I try to ping the USRP's
> IP address. But it failed.
> Solution 1. I was told that the lab's computer has two network cards.
> I disconnected from the network, only connect the USRP with a cable.
> Then I changed the VMware's network adopter from NAT model to Bridge
> model. After these processes, I run " ping 192.168.10.4" and "ping
> 192.168.10.5" in terminal. It works.
> BUT I am not sure is this method right or not.
>
> Problem 2. I run " uhd_find_devices", it returns " No UHD devices found".
> Try and Error:
> I recognized that the USRP in lab is used for Labview, therefore I
> tried to re-burn the Firmware and FPGA image files to SD card of
> USRP2 so that USRP devices can support GNURadio.
> It can be seen that Image Burning Successfully and I restart the USRP.
> BUT! When I run " uhd_find_devices", it still return " No UHD devices
> found".
>
> ?
> Could you please give me some help? I really don't know how to solve
> this problem.
>
> Best wishes
> Amber
>
What happens when you:
uhd_usrp_probe --args addr=<address of desired USRP>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160915/7d5193be/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 211940 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160915/7d5193be/attachment-0001.png>
------------------------------
Message: 6
Date: Thu, 15 Sep 2016 12:42:39 -0500
From: Jonathon Pendlum <jonathon.pend...@ettus.com>
To: Zhihong Luo <zh...@umich.edu>
Cc: Martin Braun <martin.br...@ettus.com>, Zhihong Luo via USRP-users
<usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Confusion about RFNoC Block to Tx
Message-ID:
<CAGdo0uSMo-E=7dgbluaohsjcrxgx9qou6wzqu1ba9xuhrxg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Zhihong,
Please check out noc_block_skeleton.v and follow that design flow. Using
chdr_framer / chdr_deframer directly can be confusing. Using AXI Wrapper is
the preferred approach. You can also look at noc_block_invert.v to see an
example of a one input, two output block.
Relaying RX->TX with your block can work, but you'll need to adjust the
VITA time. The RX data packets from the radio core have a VITA time field
set to the time when they were received. When the radio core receives
packets with TX data and a VITA time, it uses the VITA time to know when to
transmit. The problem in your case is that the RX data packet's VITA time
is AFTER the current VITA time after you do the RX->TX loopback via your
block. The radio core drops TX data packets with VITA time that is later
than the current VITA time, so it makes sense you do not see any
transmission. Also, since the radio core is receiving 'late' timed packets,
you should be seeing Ls in the terminal as the radio core reports 'late'
packet errors back to the host.
To fix this issue, either strip out the VITA time or add an offset so the
packet transmit time is in the future. If you choose the later option,
don't make the offset too large or you'll encounter an overrun condition
(due to the radio core's window buffer being filled). In either case, you
can use the tuser output of AXI Wrapper along with cvita_hdr_modify.v to
make this task easier.
Jonathon
On Fri, Aug 26, 2016 at 9:58 PM, Zhihong Luo via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi all,
>
> We streamed out the o_valid and o_ready of the port 1, which is shown in
> the graph below ( blue for o_tvalid, red for o_tready). As you can see, the
> o_tready signal from Tx is constantly high, and there are two bursts of
> valid data. We think that the valid data is consumed by the Tx (may be into
> the TX buffer?), but Tx doesn't transmit any signal out.
>
> So is there any signal that we forget to assert that can "trigger" the Tx
> (like a eob signal)? Or maybe is about packet size (tlast signal)?
>
> Thanks A LOT for any help!
> (Zoom in)
> ?
> ?Thanks,
> Zhihong
> ?
>
> On Fri, Aug 26, 2016 at 12:34 PM, Zhihong Luo <zh...@umich.edu> wrote:
>
>> Hi Martin,
>>
>> Thank you so much for the reply! I guess it is timestamped, but I am not
>> sure. I wrote the block similar as the noc_block_split_stream:
>>
>> chdr_deframer deframer
>> (.clk(ce_clk), .reset(ce_rst), .clear(1'b0),
>> .i_tdata(str_sink_tdata), .i_tlast(str_sink_tlast),
>> .i_tvalid(str_sink_tvalid), .i_tready(str_sink_tready),
>> .o_tdata(in_tdata), .o_tuser(in_tuser), .o_tlast(in_tlast),
>> .o_tvalid(in_tvalid), .o_tready(in_tready));
>>
>> wire [15:0] next_destination[0:NUM_OUTPUTS-1];
>>
>> assign out_tuser[0] = { in_tuser[127:96], in_tuser[79:68], 4'b0000,
>> next_destination[0], in_tuser[63:0] };
>> assign out_tuser[1] = { in_tuser[127:96], in_tuser[79:68], 4'b0001,
>> next_destination[1], in_tuser[63:0] };
>>
>> genvar i;
>> generate
>> for(i=0; i<NUM_OUTPUTS; i=i+1)
>> begin
>> setting_reg #(.my_addr(SR_NEXT_DST+i), .width(16)) new_destination
>> (.clk(ce_clk), .rst(ce_rst), .strobe(set_stb), .addr(set_addr),
>> .in(set_data),
>> .out(next_destination[i]));
>> chdr_framer framer
>> (.clk(ce_clk), .reset(ce_rst), .clear(clear_tx_seqnum),
>> .i_tdata(out_tdata[i]), .i_tuser(out_tuser[i]),
>> .i_tlast(out_tlast[i]), .i_tvalid(out_tvalid[i]), .i_tready(out_tready[i]),
>> .o_tdata(str_src_tdata[i*64+63:i*64]),
>> .o_tlast(str_src_tlast[i]), .o_tvalid(str_src_tvalid[i]),
>> .o_tready(str_src_tready[i]));
>> end
>> endgenerate
>>
>> My block generates some output on port 0 according to the input data
>> (which is correctly received at PC), once the output data of port 0 meets
>> some requirement, it will generate some hard-coded valid data on port 1.
>>
>> Therefore:
>> 1) output data on port 1 doesn't use any i_tdata, i_tvalid, i_tready or
>> i_tlast.
>> 2) In most of the time, o_tvalid on port 1 is low, it will only be
>> asserted for a short time when the condition is met.
>>
>> Thanks,
>> Zhihong
>>
>>
>> On Fri, Aug 26, 2016 at 12:14 PM, Martin Braun via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hm, is the data going to the Tx timestamped? It may be late.
>>>
>>> Cheers,
>>> M
>>>
>>> On 08/25/2016 10:59 PM, Zhihong Luo via USRP-users wrote:
>>> > To be clear, what really confuses me is that the output data from port
>>> 0
>>> > to PC is correct, but there is no data coming out from port 1 to Tx (Tx
>>> > light is off). Running the program on PC doesn't give me any error. In
>>> > the code, I have these lines:
>>> >
>>> > connect(radio-id?my-block-id);
>>> > connect(my-block-id, 1, radio-id, 0) ; //Rx Tx on the same Radio
>>> > set-rx-channel( my-block-id);
>>> >
>>> > I have no clue what may be going wrong and I can't similar examples of
>>> > RFNoC block directly sending data to Tx. So any help will be
>>> > much appreciated.
>>> >
>>> > Thanks,
>>> > Zhihong
>>> >
>>> > 2016?8?25?????Zhihong Luo <zh...@umich.edu
>>> > <mailto:zh...@umich.edu>> ???
>>> >
>>> > Hi Jonathon,
>>> >
>>> > I have a RFNoC block that has two output ports as shown in this
>>> diagram:
>>> >
>>> > RX -----> My Block ------> PC
>>> > |
>>> > Tx <--------
>>> >
>>> > I can receive correct data on the PC, so the Rx channel is working.
>>> > However, I have never transmitted signal out directly from a FPGA
>>> > block before, and now it is not working.
>>> >
>>> > On the FPGA side, when the block sends the data, it writes to
>>> > o_tdata, asserts the o_tvalid, and asserts o_tlast on the last
>>> > sample. I am not sure whether there is a requirement on the packet
>>> > length?
>>> >
>>> > I have more confusion on the PC side. I set the Rx sampling rate,
>>> > frequency, and connect the output port1 to Tx_radio. Do I need to
>>> do
>>> > more configuration to somehow "enable" the Tx? Previously I only
>>> > transmitted signal from PC using the tx_streamer.
>>> >
>>> > Also, my block will send a burst of data to Tx only when some
>>> > condition is met, so what should the Tx sampling rate be, the
>>> larger
>>> > the better?
>>> >
>>> > Any help will be much appreciated :)
>>> >
>>> > Thanks,
>>> > Zhihong
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > USRP-users mailing list
>>> > USRP-users@lists.ettus.com
>>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>> >
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20160915/ea2c5f1f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: valid&ready.jpg
Type: image/jpeg
Size: 48090 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160915/ea2c5f1f/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: valid&ready_zoom.jpg
Type: image/jpeg
Size: 83971 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160915/ea2c5f1f/attachment-0003.jpg>
------------------------------
Message: 7
Date: Thu, 15 Sep 2016 11:54:19 -0600
From: Steven Knudsen <ee.k...@gmail.com>
To: "Torell, Kent" <kent.tor...@gd-ms.com>
Cc: USRP-users <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] B200mini and low-freq modulation of tx'd
signal
Message-ID: <ce56f199-9151-4624-95da-b129270d3...@gmail.com>
Content-Type: text/plain; charset="utf-8"
Ah, excellent. I believe you are correct. If I up the frequency, the period
reduces, so I can see more of the imposed modulation.
So, forgive my ignorance, but how does one correct this?
thanks very much!
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca <http://techconficio.ca/>
www.linkedin.com/in/knudstevenknudsen
<http://www.linkedin.com/in/knudstevenknudsen>
Von einem gewissen Punkt an gibt es keine R?ckkehr mehr. Dieser Punkt ist zu
erreichen. - Franz Kafka
> On Sep 15, 2016, at 10:57, Torell, Kent <kent.tor...@gd-ms.com
> <mailto:kent.tor...@gd-ms.com>> wrote:
>
> It?s a low frequency carrier error, so you are seeing the bpsk roll into the
> other quadrature, then invert data.
>
> From: USRP-users [mailto:usrp-users-boun...@lists.ettus.com
> <mailto:usrp-users-boun...@lists.ettus.com>] On Behalf Of Steven Knudsen via
> USRP-users
> Sent: Thursday, September 15, 2016 9:50 AM
> To: USRP-users
> Cc: Knud
> Subject: [USRP-users] B200mini and low-freq modulation of tx'd signal
>
> Hi,
>
> I have a TDMA flowgraph that defines packets using tx_time and tx_sob +
> tx_eob. Packets are sent to a B200mini every 10 ms (which is not important).
> Below I have the packet format from GRC followed by 3 oscilloscope captures
> that show the effect I?m seeing.
>
> The B200mini is connected to an Octoclock 1 PPS reference.
>
> The modulation is BPSK, 2x oversampled, RRC.
>
> Image 1 - the GRC waveform that is input to the USRP sink
> Image 2 - this time the transmitted signal looks pretty good. Note the
> leading zeros so that the transmit power rises to full before samples are
> applied.
> Image 3 - it appears that some form of slow modulation has been applied
> Image 4 - same again, but obviously at a different offset
>
> (oops, forgot to turn off stupid network config menu in scope caps)
>
> I am a bit stumped. A ?theory? is that maybe I?m seeing a window of some kind
> being convolved with the signal.
>
> <image001.png>
>
> <image002.jpg>
>
> <image003.jpg>
>
> <image004.jpg>
>
>
> Steven Knudsen, Ph.D., P.Eng.
> www. techconficio.ca <http://techconficio.ca/>
> www.linkedin.com/in/knudstevenknudsen
> <http://www.linkedin.com/in/knudstevenknudsen>
>
> Der entscheidende Augenblick der menschlichen Entwicklung ist immerw?hrend.
> Darum sind die revolution?ren geistigen Bewegungen, welche alles Fr?here f?r
> nichtig erkl?ren, im Recht, denn es ist noch nichts geschehen. - Franz Kafka
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160915/994f3812/attachment-0001.html>
------------------------------
Message: 8
Date: Thu, 15 Sep 2016 13:10:38 -0500
From: Jonathon Pendlum <jonathon.pend...@ettus.com>
To: Michael Wentz <mchlw...@gmail.com>
Cc: Martin Braun <martin.br...@ettus.com>,
"USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Latest X310 RFNoC FPGA build
Message-ID:
<cagdo0utmf_nvm58v_9k42umfwhgbdky0k+hymmcwx1cok4b...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Michael,
Rating changes in RFNoC can be very easy or fairly difficult depending on
what you want.
If you don't care about VITA time or EOB, rate changes are pretty simple.
You need to generate the header s_axis_data_tuser (since you cannot use
SIMPLE_MODE), but generating it is not difficult to do. You can use
cvita_hdr_encoder.v or cvita_hdr_modify.v along with m_axis_data_tuser.
However, most people care about VITA time and others care about EOB. When
you have those fields in a rate change block, there are several corner
cases that make things difficult (for example, what should happen when
decimating by 10 but you receive a packet with only 9 samples?) To make it
easier on the user, I wrote axi_rate_change.v. AXI rate change handles both
the header and the packet sizing for the user. All you have to do is
process the sample data with your algorithm.
Jonathon
On Fri, Aug 26, 2016 at 5:21 PM, Michael Wentz via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Regarding rate changes, are there issues I could have trying to
> manage that in my component? For example, if I decimate by 10, the valid
> out is asserted once for every 10 valid inputs, and I keep the
> input/output packet sizes identical by counting the number of valid outputs
> and asserting tlast when the counter reaches 364 (assuming samples from the
> radio). I've tested blocks that do this in sim and hardware and they appear
> to work but now I'm wondering if there's more to a rate change than I
> thought?
>
> Thanks,
> Michael
>
>
> On Friday, August 26, 2016, Martin Braun via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 08/26/2016 12:44 PM, Michael Wentz wrote:
>> > Hi Martin,
>> >
>> > I did have NUM_CE set correctly, it ended up being NUM_CHAINS = 1 that
>> > was the problem. Good to know that I can update the NOC ID to get around
>> > that too.
>> >
>> > Totally understand that by making things more modular they'll have a
>> > larger footprint - I'll try building with fewer radios and a single
>> DDC/DUC.
>> >
>> > I also had a question regarding the axi_rate_change module that is in
>> > the new DDC and DUC. When should someone include that in their design?
>> > If I am dealing with a sample stream (no sensitivities to packetization,
>> > EOB, timing, etc.) is it necessary?
>>
>> No, this module is to facilitate writing blocks that actually change
>> rates. There is never a requirement to use it, but if you have a block
>> that takes N input packets for every 1 output packet, this module will
>> take care of handling the headers etc.
>>
>> Cheers,
>> M
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20160915/de47c0af/attachment-0001.html>
------------------------------
Message: 9
Date: Thu, 15 Sep 2016 21:00:28 -0400
From: Michael Wentz <mchlw...@gmail.com>
To: Jonathon Pendlum <jonathon.pend...@ettus.com>
Cc: Martin Braun <martin.br...@ettus.com>,
"USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Latest X310 RFNoC FPGA build
Message-ID:
<caftrpl0colu-+zi5ny-xbyn4g3rdi0ys_us6ge091lwia2m...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Jonathon,
Thanks for the feedback, it's clear to me what axi_rate_change.v provides
now. In my components so far I haven't done anything that cares about time
or EOB so I just did something like what's in the old version of the
keep_one_in_n block:
// Output CHDR packet header data, same as input except SRC / DST SID
fields.
assign s_axis_data_tuser =
{m_axis_data_tuser[127:96],m_axis_data_tuser[79:64],next_dst,m_axis_data_tuser[63:0]};
That seems to be working. Interestingly, I had gone without that and used
SIMPLE_MODE in the AXI wrapper, and that also worked, but only in the
receive path (transmit had problems).
-Michael
On Thu, Sep 15, 2016 at 2:10 PM, Jonathon Pendlum <
jonathon.pend...@ettus.com> wrote:
> Hi Michael,
>
> Rating changes in RFNoC can be very easy or fairly difficult depending on
> what you want.
>
> If you don't care about VITA time or EOB, rate changes are pretty simple.
> You need to generate the header s_axis_data_tuser (since you cannot use
> SIMPLE_MODE), but generating it is not difficult to do. You can use
> cvita_hdr_encoder.v or cvita_hdr_modify.v along with m_axis_data_tuser.
>
> However, most people care about VITA time and others care about EOB. When
> you have those fields in a rate change block, there are several corner
> cases that make things difficult (for example, what should happen when
> decimating by 10 but you receive a packet with only 9 samples?) To make it
> easier on the user, I wrote axi_rate_change.v. AXI rate change handles both
> the header and the packet sizing for the user. All you have to do is
> process the sample data with your algorithm.
>
>
>
> Jonathon
>
>
>
> On Fri, Aug 26, 2016 at 5:21 PM, Michael Wentz via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Regarding rate changes, are there issues I could have trying to
>> manage that in my component? For example, if I decimate by 10, the valid
>> out is asserted once for every 10 valid inputs, and I keep the
>> input/output packet sizes identical by counting the number of valid outputs
>> and asserting tlast when the counter reaches 364 (assuming samples from the
>> radio). I've tested blocks that do this in sim and hardware and they appear
>> to work but now I'm wondering if there's more to a rate change than I
>> thought?
>>
>> Thanks,
>> Michael
>>
>>
>> On Friday, August 26, 2016, Martin Braun via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> On 08/26/2016 12:44 PM, Michael Wentz wrote:
>>> > Hi Martin,
>>> >
>>> > I did have NUM_CE set correctly, it ended up being NUM_CHAINS = 1 that
>>> > was the problem. Good to know that I can update the NOC ID to get
>>> around
>>> > that too.
>>> >
>>> > Totally understand that by making things more modular they'll have a
>>> > larger footprint - I'll try building with fewer radios and a single
>>> DDC/DUC.
>>> >
>>> > I also had a question regarding the axi_rate_change module that is in
>>> > the new DDC and DUC. When should someone include that in their design?
>>> > If I am dealing with a sample stream (no sensitivities to
>>> packetization,
>>> > EOB, timing, etc.) is it necessary?
>>>
>>> No, this module is to facilitate writing blocks that actually change
>>> rates. There is never a requirement to use it, but if you have a block
>>> that takes N input packets for every 1 output packet, this module will
>>> take care of handling the headers etc.
>>>
>>> Cheers,
>>> M
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> 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/20160915/77052b77/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 16 Sep 2016 03:21:42 +0000
From: <kyle.un...@l-3com.com>
To: <USRP-users@lists.ettus.com>
Subject: [USRP-users] Bug
Message-ID:
<25d6125fb568f54699e315276ed4d36c614fa...@slxmbx01.csw.l-3com.com>
Content-Type: text/plain; charset="us-ascii"
Generating: '/Users/kyle/src/gr-C2E_L3/top_block.py'
Executing:
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
-u /Users/kyle/src/gr-C2E_L3/top_block.py
Mac OS; Clang version 7.3.0 (clang-703.0.31); Boost_105900;
UHD_003.010.000.000-MacPorts-Release
-- Detected Device: B205mini
-- Loading FPGA image: /opt/local/share/uhd/images/usrp_b205mini_fpga.bin...
done
-- Operating over USB 2.
-- Initialize CODEC control...
Traceback (most recent call last):
File "/Users/kyle/src/gr-C2E_L3/top_block.py", line 158, in <module>
main()
File "/Users/kyle/src/gr-C2E_L3/top_block.py", line 146, in main
tb = top_block_cls()
File "/Users/kyle/src/gr-C2E_L3/top_block.py", line 69, in __init__
channels=range(1),
File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/uhd/__init__.py",
line 122, in constructor_interceptor
return old_constructor(*args)
File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/uhd/uhd_swig.py",
line 2681, in make
return _uhd_swig.usrp_source_make(*args)
RuntimeError: RuntimeError: fifo ctrl timed out getting a send buffer
>>> Done
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160916/16fee280/attachment-0001.html>
------------------------------
Message: 11
Date: Thu, 15 Sep 2016 22:27:36 -0700
From: Nate Temple <nate.tem...@ettus.com>
To: kyle.un...@l-3com.com
Cc: USRP-users@lists.ettus.com
Subject: Re: [USRP-users] Bug
Message-ID: <c4796d3c-6e96-480b-b9d4-02016e0b4...@ettus.com>
Content-Type: text/plain; charset=us-ascii
Hello Kyle:
Did you use Macports to install UHD + GNU Radio? Can you try deactivating the
"uhd" port and installing the "uhd-devel" port ?
To do so you'll need to run the following commands:
sudo port -f deactivate uhd
sudo port install uhd-devel
Does it still produce the error with the uhd-devel port?
Regards,
Nate Temple
> On Sep 15, 2016, at 8:21 PM, kyle.unice--- via USRP-users
> <usrp-users@lists.ettus.com> wrote:
>
> Generating: '/Users/kyle/src/gr-C2E_L3/top_block.py'
>
> Executing:
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
> -u /Users/kyle/src/gr-C2E_L3/top_block.py
>
> Mac OS; Clang version 7.3.0 (clang-703.0.31); Boost_105900;
> UHD_003.010.000.000-MacPorts-Release
>
> -- Detected Device: B205mini
> -- Loading FPGA image: /opt/local/share/uhd/images/usrp_b205mini_fpga.bin...
> done
> -- Operating over USB 2.
> -- Initialize CODEC control...
> Traceback (most recent call last):
> File "/Users/kyle/src/gr-C2E_L3/top_block.py", line 158, in <module>
> main()
> File "/Users/kyle/src/gr-C2E_L3/top_block.py", line 146, in main
> tb = top_block_cls()
> File "/Users/kyle/src/gr-C2E_L3/top_block.py", line 69, in __init__
> channels=range(1),
> File
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/uhd/__init__.py",
> line 122, in constructor_interceptor
> return old_constructor(*args)
> File
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/uhd/uhd_swig.py",
> line 2681, in make
> return _uhd_swig.usrp_source_make(*args)
> RuntimeError: RuntimeError: fifo ctrl timed out getting a send buffer
>
> >>> Done
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 12
Date: Fri, 16 Sep 2016 11:53:29 +0000
From: "Subbukutty, Olivani" <olivani.subbuku...@commscope.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] E310 data collect and FFT plot
Message-ID:
<sn1pr0601mb1584cf8127cec63d181d0c3e93...@sn1pr0601mb1584.namprd06.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Hi ,
I have a signal generator connected to E310 rxB port and configured it to
generate a tone on 3.01 GHz.
Using the rx_samples_to_file , I collected 1 second duration of data at a
frequency of 3.00GHz at rate 20.48e6
I read the samples using fread in Matlab , plotted using pwelch command at gain
65.
The plot shows a spike on 3.01 GHz but it also shows a spike on the collected
centre frequency 3.00GHz.
Is this an expected behavior on E310. I was expecting to see only 1 peak at
3.01 GHz .
Thanks and Regards,
Olivani
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160916/3c73169e/attachment-0001.html>
------------------------------
Message: 13
Date: Fri, 16 Sep 2016 08:24:15 -0400
From: "Marcus D. Leech" <mle...@ripnet.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] E310 data collect and FFT plot
Message-ID: <57dbe46f.9040...@ripnet.com>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 09/16/2016 07:53 AM, Subbukutty, Olivani via USRP-users wrote:
>
> Hi ,
>
> I have a signal generator connected to E310 rxB port and configured it
> to generate a tone on 3.01 GHz.
>
> Using the rx_samples_to_file , I collected 1 second duration of data
> at a frequency of 3.00GHz at rate 20.48e6
>
> I read the samples using fread in Matlab , plotted using pwelch
> command at gain 65.
>
> The plot shows a spike on 3.01 GHz but it also shows a spike on the
> collected centre frequency 3.00GHz.
>
> Is this an expected behavior on E310. I was expecting to see only 1
> peak at 3.01 GHz .
>
> Thanks and Regards,
>
> Olivani
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
That's probably the DC-offset peak you're seeing. You could
investigate offset tuning:
http://files.ettus.com/manual/page_general.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160916/87fe4b29/attachment-0001.html>
------------------------------
Message: 14
Date: Fri, 16 Sep 2016 10:43:02 -0500
From: Jonathon Pendlum <jonathon.pend...@ettus.com>
To: Michael Wentz <mchlw...@gmail.com>
Cc: Martin Braun <martin.br...@ettus.com>,
"USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Latest X310 RFNoC FPGA build
Message-ID:
<CAGdo0uSAy91cr_6RuVfJD=7A17bG3POB1rOhQumss=0j6sb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey Michael,
SIMPLE_MODE instantiates a header FIFO in AXI Wrapper to store the headers
for you and it is assumed you produce a packet for every packet consumed in
a 1:1 ratio. If your block does a rate change, then either the header FIFO
will underflow (interpolating block) or overflow (decimating block) because
the FIFO is not being filled / emptied in a 1:1 ratio.
Jonathon
On Thu, Sep 15, 2016 at 8:00 PM, Michael Wentz <mchlw...@gmail.com> wrote:
> Jonathon,
>
> Thanks for the feedback, it's clear to me what axi_rate_change.v provides
> now. In my components so far I haven't done anything that cares about time
> or EOB so I just did something like what's in the old version of the
> keep_one_in_n block:
>
> // Output CHDR packet header data, same as input except SRC / DST SID
> fields.
> assign s_axis_data_tuser = {m_axis_data_tuser[127:96],m_
> axis_data_tuser[79:64],next_dst,m_axis_data_tuser[63:0]};
>
> That seems to be working. Interestingly, I had gone without that and used
> SIMPLE_MODE in the AXI wrapper, and that also worked, but only in the
> receive path (transmit had problems).
>
> -Michael
>
> On Thu, Sep 15, 2016 at 2:10 PM, Jonathon Pendlum <
> jonathon.pend...@ettus.com> wrote:
>
>> Hi Michael,
>>
>> Rating changes in RFNoC can be very easy or fairly difficult depending on
>> what you want.
>>
>> If you don't care about VITA time or EOB, rate changes are pretty simple.
>> You need to generate the header s_axis_data_tuser (since you cannot use
>> SIMPLE_MODE), but generating it is not difficult to do. You can use
>> cvita_hdr_encoder.v or cvita_hdr_modify.v along with m_axis_data_tuser.
>>
>> However, most people care about VITA time and others care about EOB. When
>> you have those fields in a rate change block, there are several corner
>> cases that make things difficult (for example, what should happen when
>> decimating by 10 but you receive a packet with only 9 samples?) To make it
>> easier on the user, I wrote axi_rate_change.v. AXI rate change handles both
>> the header and the packet sizing for the user. All you have to do is
>> process the sample data with your algorithm.
>>
>>
>>
>> Jonathon
>>
>>
>>
>> On Fri, Aug 26, 2016 at 5:21 PM, Michael Wentz via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Regarding rate changes, are there issues I could have trying to
>>> manage that in my component? For example, if I decimate by 10, the valid
>>> out is asserted once for every 10 valid inputs, and I keep the
>>> input/output packet sizes identical by counting the number of valid outputs
>>> and asserting tlast when the counter reaches 364 (assuming samples from the
>>> radio). I've tested blocks that do this in sim and hardware and they appear
>>> to work but now I'm wondering if there's more to a rate change than I
>>> thought?
>>>
>>> Thanks,
>>> Michael
>>>
>>>
>>> On Friday, August 26, 2016, Martin Braun via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
>>>> On 08/26/2016 12:44 PM, Michael Wentz wrote:
>>>> > Hi Martin,
>>>> >
>>>> > I did have NUM_CE set correctly, it ended up being NUM_CHAINS = 1 that
>>>> > was the problem. Good to know that I can update the NOC ID to get
>>>> around
>>>> > that too.
>>>> >
>>>> > Totally understand that by making things more modular they'll have a
>>>> > larger footprint - I'll try building with fewer radios and a single
>>>> DDC/DUC.
>>>> >
>>>> > I also had a question regarding the axi_rate_change module that is in
>>>> > the new DDC and DUC. When should someone include that in their design?
>>>> > If I am dealing with a sample stream (no sensitivities to
>>>> packetization,
>>>> > EOB, timing, etc.) is it necessary?
>>>>
>>>> No, this module is to facilitate writing blocks that actually change
>>>> rates. There is never a requirement to use it, but if you have a block
>>>> that takes N input packets for every 1 output packet, this module will
>>>> take care of handling the headers etc.
>>>>
>>>> Cheers,
>>>> M
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> USRP-users@lists.ettus.com
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> 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/20160916/6a46d543/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 73, Issue 14
******************************************
