Re: [USRP-users] Front Panel GPIO Question

[Ryan Marlow via USRP-users]

Hey Bob,
Such a thing is possible but would require some slight modifications to the
device itself. I believe by default, RFA, channel 0 controls all the FP
GPIO. I believe it would be just a matter of modifying which fp control
ports are connected to the physical front panel pins. See this section of
x300_core.v.
https://github.com/EttusResearch/fpga/blob/master/usrp3/top/x300/x300_core.v#L780
Definitely a couple different ways you could go about having multiple
channels control the FP GPIO outputs.
Hope that helps,
Ryan

I have an X310 with 2 UBX cards.
>
> Is it possible to control one set of front panel GPIO pins from RFA and
> another set of front panel GPIO pins from RFB?
>
> Looking at the API, it just isn't clicking if that is possible?
>
> Thanks,
>

-- 
Ryan L. Marlow
R L Marlow Consulting LLC
rlmarlow.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] X300 RFNoC integer-N tuning

[Ryan Marlow via USRP-users]

Hey All,
I'm trying to figure out a way to enable integer-N tuning in my RFNoC
application. My understanding is that rfnoc radio_ctrl object that
interfaces with the Radio noc block on the device does not support the use
of a tune_request object to pass in the mode_n=integer argument. See:
https://github.com/EttusResearch/uhd/blob/UHD-3.13/host/lib/rfnoc/radio_ctrl_impl.cpp#L150
vs
https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/multi_usrp.cpp#L1917
Is there another way I can pass this setting in to an rfnoc/device3
application that I am overlooking?
Thanks,
Ryan Marlow

-- 
Ryan L. Marlow
R L Marlow Consulting LLC
rlmarlow.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC RX -> TX loopback

[Ryan Marlow via USRP-users]

Hey Jason,
That post seemed to be exactly what I was looking for.
Thanks!
Ryan

On Thu, Apr 11, 2019 at 10:55 AM Jason Matusiak <
ja...@gardettoengineering.com> wrote:

> I haven't tried it yet, but have you looked at this blog post (I //think//
> it is still relevant today)?
> https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/
>
>
> --
> *From:* USRP-users  on behalf of Ryan
> Marlow via USRP-users 
> *Sent:* Thursday, April 11, 2019 10:51 AM
> *To:* USRP-users@lists.ettus.com
> *Subject:* [USRP-users] RFNoC RX -> TX loopback
>
> Hello all,
> Quick question on a RX -> TX loopback application. Say I have a rfnoc
> graph that has been connected as Radio RX -> processing block -> Radio TX
> so there is no data samples streaming to/from the host. Can I just issue
> the "start streaming" command to the Radio block itself or do I need to use
> a
> uhd::rx_streamer to issue the command? Is there any other gotcha that I am
> overlooking?
> Thanks,
> Ryan
> --
> Ryan L. Marlow
> R L Marlow Consulting LLC
> rlmarlow.com
>


-- 
Ryan L. Marlow
R L Marlow Consulting LLC
rlmarlow.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] RFNoC RX -> TX loopback

[Ryan Marlow via USRP-users]

Hello all,
Quick question on a RX -> TX loopback application. Say I have a rfnoc graph
that has been connected as Radio RX -> processing block -> Radio TX so
there is no data samples streaming to/from the host. Can I just issue the
"start streaming" command to the Radio block itself or do I need to use a
uhd::rx_streamer to issue the command? Is there any other gotcha that I am
overlooking?
Thanks,
Ryan
-- 
Ryan L. Marlow
R L Marlow Consulting LLC
rlmarlow.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] RFNoC block destructor: this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError:

[Ryan Marlow via USRP-users]

Hey All,
I've seen this error msg come up a number of times in my experience with
RFNoC and I'm trying to get a better understanding of why it's occuring in
my custom app now.  In this app I am TX-ing data through a custom block to
the Radio block. When my app finishes, I make some register writes to my
custom block before the program ends. But the very last print out is
without fail:

> [ERROR] [UHD] Exception caught in safe-call.
>   in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with
> uhd::endianness_t _endianness = (uhd::endianness_t)0]
>   at /home/rynmrlw/Documents/PRA/uhd/host/lib/rfnoc/ctrl_iface.cpp:60
> this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block ctrl
> (CE_00_Port_30) packet parse error - EnvironmentError: IOError: Expected
> SID: 02:30>00:00  Received SID: 02:40>00:00
>
 Now I can trace the this->send_cmd_pkt(0, 0, true); to the destructor in
ctrl_iface.cpp. In my rfnoc arrangement, the DmaFIFO is SID 02:30 and
Radio_0 is 02:40. Is this indicating that there is some cleanup to the
Radio that I am missing? This error only occurs in my custom app and not
when I run the example rfnoc_rx_to_file. The error does not seem to be
effecting the device or UHD in any negative way because I am still able to
re run the app after the error occurs too. Just want to understand what I
may be overlooking or doing wrong.
Thanks,
Ryan Marlow

-- 
Ryan L. Marlow
R L Marlow Consulting LLC
rlmarlow.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X300 TX Pulse odd behavior

[Ryan Marlow via USRP-users]

I'm using a UBX-160. I did a quick dig and didn't see anything on the spec
sheet or daughterboard section of the manual.

Ryan

On Tue, Oct 16, 2018 at 7:59 PM, Brian Padalino  wrote:

> It would depend on the daughterboard being used with the X300 I believe.
>
> Which daughterboard are you using?
>
> Brian
>
> On Tue, Oct 16, 2018 at 7:23 PM Ryan Marlow  wrote:
>
>> Hey Brian,
>> Thanks for the suggestion. I think that idea should work for me. Is there
>> anywhere that documents the X300 TX ramp up time?
>> Best,
>> Ryan
>>
>> On Tue, Oct 16, 2018 at 6:28 PM, Brian Padalino 
>> wrote:
>>
>>> Maybe ramp up time for the transmitter?
>>>
>>> If you send 2.5us worth of 0's before your 1000 samples, do you see the
>>> appropriate number of pulse burst length?
>>>
>>> This method would be a compromise between the two methods you
>>> described.  Does that work for you?
>>>
>>> Brian
>>>
>>> On Tue, Oct 16, 2018 at 6:19 PM Ryan Marlow via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
>>>> Hey All,
>>>> I am trying to transmit a series of pulses with the X300 and am seeing
>>>> some odd behavior. I want to transmit a set number of samples in a pulse,
>>>> let's say 1000. At 200 MSPS (the tx rate in the radio core) I would expect
>>>> this burst to last approximately 5us. Yet, when I receive the data, I see a
>>>> burst that is shorter by half, approx 2.5 us.  To send these bursts, I am
>>>> sending a timed burst of 1000 samples to the Radio with significant space
>>>> in between. Odder still, when I increase my pulse to 2000 samples,
>>>> expecting a pulse of 10 us, it is shortened again by 2.5 us, making the
>>>> pulse 7.5 us. I can confirm with an ILA that the Radio core is receiving
>>>> all pulsed samples and they are passed to the daughterboard interface. Is
>>>> there an obvious explanation for this behavior that I am overlooking?
>>>> One solution I have devised is generating a constant stream of data in
>>>> place of the gaps between pulses that contain zero'd data. So it would look
>>>> like this
>>>> Data x 1000 -> zeroes in place of gaps -> repeat.
>>>> In my original method, the transmitter is only active during the
>>>> pulses. In the alternative solution, the transmitter is active the whole
>>>> time.
>>>> This solution gives me the behavior that I want but I am curious as to
>>>> why the pulses are shortened.
>>>>
>>>> Thanks,
>>>> Ryan Marlow
>>>>
>>>> --
>>>> Ryan L. Marlow
>>>> R L Marlow Consulting LLC
>>>> rlmarlow.com
>>>> ___
>>>> USRP-users mailing list
>>>> USRP-users@lists.ettus.com
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>
>>
>>
>> --
>> Ryan L. Marlow
>> R L Marlow Consulting LLC
>> rlmarlow.com
>>
>


-- 
Ryan L. Marlow
R L Marlow Consulting LLC
rlmarlow.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X300 TX Pulse odd behavior

[Ryan Marlow via USRP-users]

Hey Brian,
Thanks for the suggestion. I think that idea should work for me. Is there
anywhere that documents the X300 TX ramp up time?
Best,
Ryan

On Tue, Oct 16, 2018 at 6:28 PM, Brian Padalino  wrote:

> Maybe ramp up time for the transmitter?
>
> If you send 2.5us worth of 0's before your 1000 samples, do you see the
> appropriate number of pulse burst length?
>
> This method would be a compromise between the two methods you described.
> Does that work for you?
>
> Brian
>
> On Tue, Oct 16, 2018 at 6:19 PM Ryan Marlow via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hey All,
>> I am trying to transmit a series of pulses with the X300 and am seeing
>> some odd behavior. I want to transmit a set number of samples in a pulse,
>> let's say 1000. At 200 MSPS (the tx rate in the radio core) I would expect
>> this burst to last approximately 5us. Yet, when I receive the data, I see a
>> burst that is shorter by half, approx 2.5 us.  To send these bursts, I am
>> sending a timed burst of 1000 samples to the Radio with significant space
>> in between. Odder still, when I increase my pulse to 2000 samples,
>> expecting a pulse of 10 us, it is shortened again by 2.5 us, making the
>> pulse 7.5 us. I can confirm with an ILA that the Radio core is receiving
>> all pulsed samples and they are passed to the daughterboard interface. Is
>> there an obvious explanation for this behavior that I am overlooking?
>> One solution I have devised is generating a constant stream of data in
>> place of the gaps between pulses that contain zero'd data. So it would look
>> like this
>> Data x 1000 -> zeroes in place of gaps -> repeat.
>> In my original method, the transmitter is only active during the pulses.
>> In the alternative solution, the transmitter is active the whole time.
>> This solution gives me the behavior that I want but I am curious as to
>> why the pulses are shortened.
>>
>> Thanks,
>> Ryan Marlow
>>
>> --
>> Ryan L. Marlow
>> R L Marlow Consulting LLC
>> rlmarlow.com
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>


-- 
Ryan L. Marlow
R L Marlow Consulting LLC
rlmarlow.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] X300 TX Pulse odd behavior

[Ryan Marlow via USRP-users]

Hey All,
I am trying to transmit a series of pulses with the X300 and am seeing some
odd behavior. I want to transmit a set number of samples in a pulse, let's
say 1000. At 200 MSPS (the tx rate in the radio core) I would expect this
burst to last approximately 5us. Yet, when I receive the data, I see a
burst that is shorter by half, approx 2.5 us.  To send these bursts, I am
sending a timed burst of 1000 samples to the Radio with significant space
in between. Odder still, when I increase my pulse to 2000 samples,
expecting a pulse of 10 us, it is shortened again by 2.5 us, making the
pulse 7.5 us. I can confirm with an ILA that the Radio core is receiving
all pulsed samples and they are passed to the daughterboard interface. Is
there an obvious explanation for this behavior that I am overlooking?
One solution I have devised is generating a constant stream of data in
place of the gaps between pulses that contain zero'd data. So it would look
like this
Data x 1000 -> zeroes in place of gaps -> repeat.
In my original method, the transmitter is only active during the pulses. In
the alternative solution, the transmitter is active the whole time.
This solution gives me the behavior that I want but I am curious as to why
the pulses are shortened.

Thanks,
Ryan Marlow

-- 
Ryan L. Marlow
R L Marlow Consulting LLC
rlmarlow.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] X300 FP GPIO with RFNoC API

[Ryan Marlow via USRP-users]

Working on a project with custom RFNoC blocks where I need to use the FP
GPIO. I've searched the mailing lists and seen previously suggested options
like reconnecting fp gpio to the custom block, or generating timed command
packets from my block to send to the radio block. Both those options seem
feasible but what seems to be the most straightforward option is to just
use the uhd api call: set_gpio_attr. Like in this example:
https://files.ettus.com/manual/page_gpio_api.html
I tried instantiating a multi_usrp object in my rfnoc app, but that doesn't
seem like the right path and produces some unexpected results.
I noticed that the radio_ctrl API includes that function but all it does is

> throw uhd::not_implemented_error("set_gpio_attr was not defined for
> this radio");
>
Is there some other way using the device3/RFNoC api to use the
set_gpio_attr or some similar function to configure the gpio from software?
Or more importantly is it even possible when using RFNoC to use those
software functions?
Thanks,
Ryan Marlow

-- 
Ryan L. Marlow
R L Marlow Consulting LLC
rlmarlow.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC TX Examples

[Ryan Marlow via USRP-users]

Hey Leo,
Glad to hear you were able to work things out. One quick note about the
code I attached previously. Located a minor typo/bug that you'll want to
fix if you want to actually transmit useful data.

> 219 radio_ctrl->set_rx_frequency(freq, radio_chan);
>
should be:

> 219 radio_ctrl->set_tx_frequency(freq, radio_chan);
>
Notice the change from rx->tx.
Best,
Ryan Marlow


On Thu, Sep 20, 2018 at 10:35 AM, Leandro Echevarría <
leoechevar...@gmail.com> wrote:

> Hey Ryan,
>
> Thanks a lot! I actually ended up doing pretty much the exact same things
> you described, and came up with a piece of code very similar to yours.
> Yours is neater though, so I will keep it ;-).
>
> Regards,
>
> Leo
>
> On Wed, Sep 19, 2018 at 7:52 PM Ryan Marlow  wrote:
>
>> Hey Leo,
>> I haven't seen anyone respond yet and I recently needed to develop a TX
>> RFNoC example of my own. I worked off the rfnoc_rx_to_file.cpp example. Far
>> from perfect, but it gets the job done (transmits data). The main changes
>> are:
>> - copied send_from_file function from tx_samples_from_file.cpp example to
>> handle the streaming of data from the input file
>> - reversed the order that blocks are connected in the graph->connect()
>> function. Now connects optional arg block -> radio. Was radio -> optional
>> arg block.
>> - uses tx_stream instead of rx_stream.
>> Just add this cpp file to the CMake file in the host/examples dir to
>> build it then try it out.
>> I ran it with:
>> build/examples$ ./rfnoc_tx_from_file --block-id DUC_0 --block-args
>> output_rate=200e6,input_rate=5e6 --duration 5 --file usrp_samples.dat
>>
>> Hope that helps,
>> Ryan
>> --
>> Ryan L. Marlow
>> R L Marlow Consulting LLC
>> rlmarlow.com
>>
>


-- 
Ryan L. Marlow
R L Marlow Consulting LLC
rlmarlow.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC TX Examples

[Ryan Marlow via USRP-users]

Hey Leo,
I haven't seen anyone respond yet and I recently needed to develop a TX
RFNoC example of my own. I worked off the rfnoc_rx_to_file.cpp example. Far
from perfect, but it gets the job done (transmits data). The main changes
are:
- copied send_from_file function from tx_samples_from_file.cpp example to
handle the streaming of data from the input file
- reversed the order that blocks are connected in the graph->connect()
function. Now connects optional arg block -> radio. Was radio -> optional
arg block.
- uses tx_stream instead of rx_stream.
Just add this cpp file to the CMake file in the host/examples dir to build
it then try it out.
I ran it with:
build/examples$ ./rfnoc_tx_from_file --block-id DUC_0 --block-args
output_rate=200e6,input_rate=5e6 --duration 5 --file usrp_samples.dat

Hope that helps,
Ryan
-- 
Ryan L. Marlow
R L Marlow Consulting LLC
rlmarlow.com
//
// Copyright 2014-2016 Ettus Research LLC
//
// This program is free software: you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program.  If not, see .
//

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

namespace po = boost::program_options;

static bool stop_signal_called = false;
void sig_int_handler(int){stop_signal_called = true;}


typedef boost::function get_sensor_fn_t;

bool check_locked_sensor(std::vector sensor_names, const char* sensor_name, get_sensor_fn_t get_sensor_fn, double setup_time){
if (std::find(sensor_names.begin(), sensor_names.end(), sensor_name) == sensor_names.end())
return false;

boost::system_time start = boost::get_system_time();
boost::system_time first_lock_time;

std::cout << boost::format("Waiting for \"%s\": ") % sensor_name;
std::cout.flush();

while (true) {
if ((not first_lock_time.is_not_a_date_time()) and
(boost::get_system_time() > (first_lock_time + boost::posix_time::seconds(setup_time
{
std::cout << " locked." << std::endl;
break;
}
if (get_sensor_fn(sensor_name).to_bool()){
if (first_lock_time.is_not_a_date_time())
first_lock_time = boost::get_system_time();
std::cout << "+";
std::cout.flush();
}
else {
first_lock_time = boost::system_time();	//reset to 'not a date time'

if (boost::get_system_time() > (start + boost::posix_time::seconds(setup_time))){
std::cout << std::endl;
throw std::runtime_error(str(boost::format("timed out waiting for consecutive locks on sensor \"%s\"") % sensor_name));
}
std::cout << "_";
std::cout.flush();
}
boost::this_thread::sleep(boost::posix_time::milliseconds(100));
}
std::cout << std::endl;
return true;
}

template void send_from_file(
uhd::tx_streamer::sptr tx_stream,
const std::string ,
size_t samps_per_buff
){

uhd::tx_metadata_t md;
md.start_of_burst = false;
md.end_of_burst = false;
std::vector buff(samps_per_buff);
std::ifstream infile(file.c_str(), std::ifstream::binary);

//loop until the entire file has been read

while(not md.end_of_burst and not stop_signal_called){

infile.read((char*)(), buff.size()*sizeof(samp_type));
size_t num_tx_samps = size_t(infile.gcount()/sizeof(samp_type));

md.end_of_burst = infile.eof();

tx_stream->send((), num_tx_samps, md);
}

infile.close();
}

int UHD_SAFE_MAIN(int argc, char *argv[]){
uhd::set_thread_priority_safe();

//variables to be set by po
std::string args, file, format, ant, subdev, ref, wirefmt, streamargs, radio_args, block_id, block_args;
size_t total_num_samps, spb, radio_id, radio_chan;
double rate, freq, gain, bw, total_time, setup_time;

//setup the program options
po::options_description desc("Allowed options");
desc.add_options()
("help", "help message")
("file", po::value()->default_value("usrp_samples.dat"), "name of the file to write binary samples to")
("format", po::value()->default_value("sc16"), "File sample format: sc16, fc32, or fc64")
("duration", po::value(_time)->default_value(0), "total number of seconds to receive")
("nsamps", po::value(_num_samps)->default_value(0), "total number of samples to receive")

Re: [USRP-users] x310 ddc error

[Ryan Marlow via USRP-users]

Alternatively, upgrade your FPGA image to use the latest DDC code.
Run uhd_image_downloader to get the latest image or build your own from the
uhd fpga repo.
Best,
Ryan Marlow


Date: Fri, 19 Jan 2018 16:13:47 +
> From: Disco Daniele 
> To: "USRP-users@lists.ettus.com" 
> Subject: [USRP-users] x310 ddc error
> Message-ID: <1516382146528.81...@telecomitalia.it>
> Content-Type: text/plain; charset="iso-8859-1"
>
> HI!
>
> Today I installed in a new pc the UHD software.
>
>
> Connecting the X310 to the pc via Ethernet, the output of uhd_usrp_probe
> is:
>
>
>
>
> [INFO] [UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_3.11.0.git-0-unknown]
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Determining maximum frame size...
> [INFO] [X300] Maximum frame size: 1472 bytes.
> [INFO] [X300] Setup basic communication...
> [INFO] [X300] Loading values from EEPROM...
> [INFO] [X300] Setup RF frontend clocking...
> [INFO] [X300] Radio 1x clock:200
> [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 0...
> [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 0 MB/s)
> [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 1...
> [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 0 MB/s)
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> Error: RuntimeError: DDC software is too new for this hardware. Please
> downgrade to a driver that supports hardware revision 0.
>
>
> The question is: if I upgrade the sw of the FPGA I will solve the issue or
> I have to install a version older of the UHD?
>
>
> If the problem is related to the UHD sw, wich version I have to use?
>
> Thank you for the support
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
> abbiate ricevuto questo documento per errore siete cortesemente pregati di
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
>
> This e-mail and any attachments is confidential and may contain privileged
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the
> intended recipient, please delete this message and any attachments and
> advise the sender by return e-mail, Thanks.
>
> Rispetta l'ambiente. Non stampare questa mail se non ? necessario.
> -- next part --
> An HTML attachment was scrubbed...
> URL:  ettus.com/attachments/20180119/a424efe9/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 89, Issue 16
> **
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com