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. Link LED blinking RED (El Ouni, Naceur (IntlAssoc))
2. making multiple NI 2901 radios work simultaneously with GNU
Radio Framework (Ammar Mahmood)
3. Re: Setting up N210 on virtual machine (Marcus M?ller)
4. Re: making multiple NI 2901 radios work simultaneously with
GNU Radio Framework ([email protected])
5. Re: USRP B200 (Rohit Dilip)
6. Re: USRP B200 (Rob Kossler)
7. Re: making multiple NI 2901 radios work simultaneously with
GNU Radio Framework (Fernando)
8. Re: USRP B200 (Rohit Dilip)
9. E310 User defined data in header? (Parth Vakil)
10. X300 becomes unresponsive (Perelman, Nathan)
11. Re: X300 becomes unresponsive (Marcus D. Leech)
12. Re: X310/UBX Retuning Performance (Dave NotTelling)
13. Re: Link LED blinking RED (Nicolas Cuervo)
14. Re: Asymmetry in achievable TX/RX rates (Claudio Cicconetti)
15. RFNoC Signal Generator extension (Rob Kossler)
16. Re: X310/UBX Retuning Performance (Michael West)
----------------------------------------------------------------------
Message: 1
Date: Tue, 7 Mar 2017 16:59:54 +0000
From: "El Ouni, Naceur (IntlAssoc)" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Link LED blinking RED
Message-ID:
<mwhpr09mb11685e2bf72d91be87f764889e...@mwhpr09mb1168.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Hello,
What does a Blinking Red LINK LED means.
I am using an NI branded X310 (NI 2942R) with Windows Server 2012 R2.
Ethernet port 0 is connected to a 1G Ethernet interface and port 1 is connected
to a High Speed 10GB Interface using a fiber optic cable.
PS: the blinking is happenning regardless of the port 1 connection i.e.
blinking persists if I disconnect the 10GB Ethernet cable.
Thanks and Regards,
Naceur El Ouni
NIST - Wireless Networks Division (673)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170307/75af5f75/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 7 Mar 2017 21:50:10 +0500
From: Ammar Mahmood <[email protected]>
To: [email protected]
Subject: [USRP-users] making multiple NI 2901 radios work
simultaneously with GNU Radio Framework
Message-ID:
<caozxrwhnzcmlfs_t-jn9a1y2mmycpc6s_kdqahuc+x+hjoy...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear all,
I am trying to make multiple NI 2901 USRPs work simultaneously (on a single
workstation) with GNU Radio framework. As NI 2901 is inferfaced via USB so
I am connecting both of my NI 2901 radios to USB 3.0 ports on my
workstation. The uhd_find_devices command detects both the USRPs but I am
unable to make them work simultaneously on GNU Radio framework. GNU Radio
Companion works fine when only one radio is attached but when both are
attached then the flowgraph does not run. Also, when the flowgraph is
running correctly with only one radio attached, the moment I inferface the
2nd radio, running of that flowgraph immediately stops. Can anybody help me
out in this process? Thanks in advance.
Regards,
Ammar
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170307/acfddd7e/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 7 Mar 2017 18:07:08 +0100
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Setting up N210 on virtual machine
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Fernando, Jithesh,
I can not stress this enough:
On 03/07/2017 12:42 AM, Fernando via USRP-users wrote:
> Maybe you should use othenr network configuration in your vm
> different to NAT
NAT is definitely the wrong choice. USRPs push through data at high
rates, and there's simply no use having the host PC touch each packet,
masquerade everything, and so on. It will limit your possible rate, and
it might lead to confusion (UHD doesn't like reordered packets). Every
serious virtualization solution has a "bridged" or native mode, so use that.
Best regards,
Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170307/4dc4291d/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 07 Mar 2017 12:30:15 -0500
From: [email protected]
To: Ammar Mahmood <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] making multiple NI 2901 radios work
simultaneously with GNU Radio Framework
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
How are you naming the two devices in your Gnu Radio flow-graph?
If you have more than one device on the system, you need to be able to
be explicit about which device(s) you want to talk to:
https://files.ettus.com/manual/page_identification.html
On 2017-03-07 11:50, Ammar Mahmood via USRP-users wrote:
> Dear all,
>
> I am trying to make multiple NI 2901 USRPs work simultaneously (on a single
> workstation) with GNU Radio framework. As NI 2901 is inferfaced via USB so I
> am connecting both of my NI 2901 radios to USB 3.0 ports on my workstation.
> The uhd_find_devices command detects both the USRPs but I am unable to make
> them work simultaneously on GNU Radio framework. GNU Radio Companion works
> fine when only one radio is attached but when both are attached then the
> flowgraph does not run. Also, when the flowgraph is running correctly with
> only one radio attached, the moment I inferface the 2nd radio, running of
> that flowgraph immediately stops. Can anybody help me out in this process?
> Thanks in advance.
>
> Regards, Ammar
> _______________________________________________
> 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/20170307/6aaeea16/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 7 Mar 2017 13:27:56 -0500
From: Rohit Dilip <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP B200
Message-ID:
<calumccczwmf4twi+3fpuak0j_5qpfcyrjpdtjhtgklqx94c...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I think I better understand now -- thanks for all of your guys' patience.
If I may ask one more question, if I want to vary the amplitudes, phases,
and frequencies as functions of time (that would change on the order of
ms), is that still doable within gnuradio?
On Thu, Mar 2, 2017 at 11:34 AM, Marcus M?ller via USRP-users <
[email protected]> wrote:
> Rohit,
>
> that pretty much boils down to a complete introduction to HDL programming.
>
> As Martin repeatedly said, there's simply no good reason to do this in the
> FPGA. Especially, there's mathematically and technically absolutely no
> difference between running the signal synthesis in your computer (which was
> what Ettus had in mind when designing the B200) and doing it in the FPGA.
> It's all just a series of numbers, and numbers don't care *where* they get
> calculated.
>
> Also, have a look at the offset tuning that every USRP offers. I don't
> even think you need to write a single line of code to generate what you
> want, but to be fair, I think we're all still pretty confused by why you
> insist on doing this in the FPGA. It just seems technologically unwise.
>
> Best regards,
>
> Marcus
>
> On 03/02/2017 02:28 AM, Rohit Dilip via USRP-users wrote:
>
> Do you have specific resources for programming a DDS solution with the
> FPGA?
>
> On Wed, Mar 1, 2017 at 8:26 PM, Martin Braun via USRP-users <
> [email protected]> wrote:
>
>> With GNU Radio, you'll pretty much get arbitrary resolution. With a DDS,
>> it depends on your implementation.
>>
>> -- M
>>
>> On 03/01/2017 05:25 PM, Rohit Dilip wrote:
>> > A couple of further questions, firstly, how is the frequency resolution
>> > in using the GNURadio solution compared to DDS? Do you have any advice
>> > on if I wanted to directly reprogram the FPGA and use DDS?
>> >
>> > Really appreciate all the help!
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
>
> --
> -Rohit Dilip
>
>
> _______________________________________________
> USRP-users mailing
> [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
>
>
--
-Rohit Dilip
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170307/c702de03/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 7 Mar 2017 16:02:08 -0500
From: Rob Kossler <[email protected]>
To: Rohit Dilip <[email protected]>
Cc: Marcus M?ller <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP B200
Message-ID:
<cab__httwwry+cmudvpaashzhbwhkrcthjp68wjhfg3an-rd...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Are the variations known in advance or are they changing dynamically with
some conditions? If known in advance and of finite duration, you could
create a baseband waveform with all desired dynamic behavior and simply
play out this file from gnuradio or even direct from UHD utilities. If
changing dynamically, gnuradio is still a good choice, but not using a
pre-made waveform file.
Rob
On Tue, Mar 7, 2017 at 1:27 PM, Rohit Dilip via USRP-users <
[email protected]> wrote:
> I think I better understand now -- thanks for all of your guys' patience.
> If I may ask one more question, if I want to vary the amplitudes, phases,
> and frequencies as functions of time (that would change on the order of
> ms), is that still doable within gnuradio?
>
> On Thu, Mar 2, 2017 at 11:34 AM, Marcus M?ller via USRP-users <
> [email protected]> wrote:
>
>> Rohit,
>>
>> that pretty much boils down to a complete introduction to HDL programming.
>>
>> As Martin repeatedly said, there's simply no good reason to do this in
>> the FPGA. Especially, there's mathematically and technically absolutely no
>> difference between running the signal synthesis in your computer (which was
>> what Ettus had in mind when designing the B200) and doing it in the FPGA.
>> It's all just a series of numbers, and numbers don't care *where* they get
>> calculated.
>>
>> Also, have a look at the offset tuning that every USRP offers. I don't
>> even think you need to write a single line of code to generate what you
>> want, but to be fair, I think we're all still pretty confused by why you
>> insist on doing this in the FPGA. It just seems technologically unwise.
>>
>> Best regards,
>>
>> Marcus
>>
>> On 03/02/2017 02:28 AM, Rohit Dilip via USRP-users wrote:
>>
>> Do you have specific resources for programming a DDS solution with the
>> FPGA?
>>
>> On Wed, Mar 1, 2017 at 8:26 PM, Martin Braun via USRP-users <
>> [email protected]> wrote:
>>
>>> With GNU Radio, you'll pretty much get arbitrary resolution. With a DDS,
>>> it depends on your implementation.
>>>
>>> -- M
>>>
>>> On 03/01/2017 05:25 PM, Rohit Dilip wrote:
>>> > A couple of further questions, firstly, how is the frequency resolution
>>> > in using the GNURadio solution compared to DDS? Do you have any advice
>>> > on if I wanted to directly reprogram the FPGA and use DDS?
>>> >
>>> > Really appreciate all the help!
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>>
>>
>> --
>> -Rohit Dilip
>>
>>
>> _______________________________________________
>> USRP-users mailing
>> [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
>>
>>
>
>
> --
> -Rohit Dilip
>
> _______________________________________________
> 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/20170307/53fe0b04/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 7 Mar 2017 22:03:00 +0100
From: Fernando <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] making multiple NI 2901 radios work
simultaneously with GNU Radio Framework
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Could you send the log on the gnu-radio log window?
regards
El 07/03/17 a las 17:50, Ammar Mahmood via USRP-users escribi?:
> Dear all,
>
> I am trying to make multiple NI 2901 USRPs work simultaneously (on a
> single workstation) with GNU Radio framework. As NI 2901 is inferfaced
> via USB so I am connecting both of my NI 2901 radios to USB 3.0 ports
> on my workstation. The uhd_find_devices command detects both the USRPs
> but I am unable to make them work simultaneously on GNU Radio
> framework. GNU Radio Companion works fine when only one radio is
> attached but when both are attached then the flowgraph does not run.
> Also, when the flowgraph is running correctly with only one radio
> attached, the moment I inferface the 2nd radio, running of that
> flowgraph immediately stops. Can anybody help me out in this process?
> Thanks in advance.
>
>
> Regards,
> Ammar
>
>
> _______________________________________________
> 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/20170307/af324e5f/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 7 Mar 2017 16:04:36 -0500
From: Rohit Dilip <[email protected]>
To: Rob Kossler <[email protected]>
Cc: Marcus M?ller <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP B200
Message-ID:
<calumcccc2urp3kg2g-m9q9t+74dp2zmja+aqrnunqe6dlsh...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Changing dynamically -- I would have a feedback loop going back to the
board, based on which I would need to change the amplitudes and phases. The
timescale would need to be on the order of a few ms.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170307/c8a9a7d6/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 7 Mar 2017 22:13:42 +0000
From: Parth Vakil <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] E310 User defined data in header?
Message-ID:
<bn6pr07mb2900cd028e92479dcfc5d205c5...@bn6pr07mb2900.namprd07.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Hello,
I would like to tag the data coming off the Z7020 on the E310 into GNU Radio
with the state of the GPIO lines. In relation to this, I have a couple of
questions:
1. I noticed that the CHDR/VITA header has 64 bits for time tagging. Is it
possible for me to use this to pass the data back from the FPGA back to GNU
Radio? My application requires me to switch the state of the GPIO lines at
precise times, i.e. doing that off of counting samples would work great.
However, given that the GNU Radio application needs this information, what
would be the best way to get the information back from the FPGA.
2. Would it work better to use one of the computational engines instead? The
data from the CE would go to the crossbar and the arbitration would be taken
care of there. However, how does the data show up in GNU Radio on the host side
if this is the path I go down on? Would I need to create my own source?
Note that I have modified the FPGA image to be able to do the state switching
based off of counting samples.
Thank you.
PV
------------------------------
Message: 10
Date: Tue, 7 Mar 2017 23:27:00 +0000
From: "Perelman, Nathan" <[email protected]>
To: Ben Hilburn via USRP-users <[email protected]>
Subject: [USRP-users] X300 becomes unresponsive
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
I'm running UHD 3.10.1.1 and sometimes after exiting my program I see my X300
become unresponsive. It is no longer found by uhd_find_devices and does not
respond to pings until I manually reboot it. I haven't been able to determine
any steps to reproduce, but has anyone else seen this issue?
-Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170307/90ff6ac6/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 07 Mar 2017 19:31:09 -0500
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] X300 becomes unresponsive
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 03/07/2017 06:27 PM, Perelman, Nathan via USRP-users wrote:
>
> I?m running UHD 3.10.1.1 and sometimes after exiting my program I see
> my X300 become unresponsive. It is no longer found by uhd_find_devices
> and does not respond to pings until I manually reboot it. I haven?t
> been able to determine any steps to reproduce, but has anyone else
> seen this issue?
>
> -Nathan
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
My X310 is unresponsive for a few seconds after I terminate a flow-graph
that uses it. But it wakes up again shortly after.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170307/d0351730/attachment-0001.html>
------------------------------
Message: 12
Date: Wed, 8 Mar 2017 07:54:14 -0500
From: Dave NotTelling <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310/UBX Retuning Performance
Message-ID:
<CAK6GVuNbS-drq2a6vtk90g=z2ot5j49mjpsp51hjqudwh4s...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Anyone have any information about whether or not changing to performance
mode from power save will help speed up the transition between the two
bands?
On Mon, Mar 6, 2017 at 12:37 PM, Dave NotTelling <[email protected]>
wrote:
> *bump*
>
> On Fri, Mar 3, 2017 at 10:27 AM, Dave NotTelling <[email protected]>
> wrote:
>
>> Can performance mode help with the > 100ms tuning time between the two
>> bands? I seem to recall the performance mode setting relating to when the
>> unused PA is powered off. Also, is the long tuning time something that the
>> UHD code causes or is that just a number that the developer should keep in
>> mind when switching bands?
>>
>> Thanks!
>>
>> On Fri, Feb 24, 2017 at 3:41 PM, Dave NotTelling <[email protected]>
>> wrote:
>>
>>> Thanks!
>>>
>>> On Fri, Feb 24, 2017 at 3:32 PM, Marcus M?ller via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> Largely: Yes; the UBX160 and UBX40 only differ in their baseband
>>>> filters' passive component values (see the schematics).
>>>>
>>>> There's a bit of a difference on how you can clock the UBX on N210, but
>>>> that won't change behaviour all that much. Also, due to the 100 MHz instead
>>>> of X3xx's 200 MHz master clock rate, your timing granularity is twice as
>>>> bad :)
>>>>
>>>> Best regards,
>>>>
>>>> Marcus
>>>> On 24.02.2017 21:24, Dave NotTelling via USRP-users wrote:
>>>>
>>>> Do these tuning/settling times also hold true for the UBX-40 in an N210?
>>>>
>>>> On Fri, Feb 24, 2017 at 2:47 PM, Derek Kozel via USRP-users <
>>>> [email protected]> wrote:
>>>>
>>>>> Hi Jason,
>>>>>
>>>>> If you use the set_command_time function to cause the tune to occur at
>>>>> a specific time then you can use the in-band timestamps from the recv call
>>>>> to identify the sample when the tune action started. The 500us of samples
>>>>> following that timestamp are the ones you would want to discard.
>>>>>
>>>>> An example of setting the execution time for a command:
>>>>> https://github.com/EttusResearch/uhd/blob/master/host/exampl
>>>>> es/test_timed_commands.cpp#L96
>>>>>
>>>>> An example of starting streaming at a set time:
>>>>> https://github.com/EttusResearch/uhd/blob/master/host/exampl
>>>>> es/test_timed_commands.cpp#L129
>>>>>
>>>>> Regards,
>>>>> Derek
>>>>>
>>>>>
>>>>> On Fri, Feb 24, 2017 at 11:27 AM, Jason Roehm via USRP-users <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> On 02/24/2017 01:24 PM, Michael West via USRP-users wrote:
>>>>>>
>>>>>>> Hi Devin,
>>>>>>>
>>>>>>> I have measured the UBX tune time. The SPI writes to tune the LO
>>>>>>> take ~30-60us and the LO lock time is 400us. I recommend discarding at
>>>>>>> least 500us of samples after the LO tune. I also recommend continuous
>>>>>>> streaming of samples so the frontend components are not switched on and
>>>>>>> off, which can cause long transients. For the UBX-160, set the
>>>>>>> dboard_clock_rate to 20e6 and tune the LO in steps of 160 MHz. If
>>>>>>> using a
>>>>>>> sample rate <200 Msps, use DSP tuning (which takes < 1us) for the
>>>>>>> frequencies between the 160MHz steps. With that, you should be able to
>>>>>>> tune across the full 6GHz in ~18ms in theory. There is one caveat.
>>>>>>> There
>>>>>>> are 2 LNAs on the UBX, one for <1.5 GHz and one for above. Only one
>>>>>>> can be
>>>>>>> powered on at a time and the warm up time is significant (in the 100s of
>>>>>>> milliseconds for the low band LNA and 10s of milliseconds for the high
>>>>>>> band
>>>>>>> LNA),, so you would be best suited using one daughterboard for the low
>>>>>>> band
>>>>>>> and one for the high band for the fastest sweep time.
>>>>>>>
>>>>>>> Unfortunately, I do not have the same experience with the TwinRX, so
>>>>>>> i cannot advise on it.
>>>>>>>
>>>>>>
>>>>>> Not to hijack this thread, but do you have any recommendations on the
>>>>>> most effective way to properly time the "discard 500us of samples after
>>>>>> the
>>>>>> LO tune?" One of the drawbacks of using the USRP family for applications
>>>>>> that require fast retuning is that there isn't (from what I can tell) any
>>>>>> in-band indication of what center frequency the radio is tuned to. The
>>>>>> control interface (e.g. through multi_usrp::set_rx_center_freq()) is
>>>>>> completely separate from the data streaming interface, so if I call
>>>>>> set_rx_center_freq() at time T, I have no way of accurately estimating
>>>>>> when
>>>>>> the tune will actually be complete in the data stream.
>>>>>>
>>>>>> This seems to be a disadvantage of the CHDR protocol that
>>>>>> contemporary USRPs use; they seem to carry data samples and timetags, but
>>>>>> nothing else. VITA 49 is nice in that it can provide full context in
>>>>>> timetagged packets, so you can get updates as to the radio state (e.g.
>>>>>> frequency, gain) that are aligned as closely as possible with the
>>>>>> associated samples from the SDR.
>>>>>>
>>>>>> Jason
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>> [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/20170308/21c3167e/attachment-0001.html>
------------------------------
Message: 13
Date: Wed, 8 Mar 2017 14:18:20 +0100
From: Nicolas Cuervo <[email protected]>
To: "El Ouni, Naceur (IntlAssoc)" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Link LED blinking RED
Message-ID:
<CAOuPCviryAhjhgYrzjnc=gtsap+11mectzo2gh0hexutuuk...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Naceur,
could you please be more specific on which led is the one you are referring
to? In general, the front panel led will blink red on the TX ports when a
transmission is undergoing [1]. On the same port, being TX/RX, it will
blink green when it is receiving instead.
Are you transmitting with your USRP?
Regards,
-Nicolas
[1] https://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_hw_on_board_leds
On Tue, Mar 7, 2017 at 5:59 PM, El Ouni, Naceur (IntlAssoc) via USRP-users <
[email protected]> wrote:
> Hello,
>
>
>
> What does a Blinking Red LINK LED means.
>
> I am using an NI branded X310 (NI 2942R) with Windows Server 2012 R2.
>
> Ethernet port 0 is connected to a 1G Ethernet interface and port 1 is
> connected to a High Speed 10GB Interface using a fiber optic cable.
>
>
>
> PS: the blinking is happenning regardless of the port 1 connection i.e.
> blinking persists if I disconnect the 10GB Ethernet cable.
>
>
>
> Thanks and Regards,
>
>
>
> Naceur El Ouni
>
> NIST - Wireless Networks Division (673)
>
>
>
> _______________________________________________
> 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/20170308/10a7f687/attachment-0001.html>
------------------------------
Message: 14
Date: Wed, 8 Mar 2017 14:42:50 +0100
From: Claudio Cicconetti <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Asymmetry in achievable TX/RX rates
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Dear Stefano,
I tried:
- send size = 496 * 500 (as you suggest)
- target size = 1 Msamples
- rate = 1 MS/s
I still get underruns.
As before, there are no underruns with target size = 2 Msamples.
Anyway, in my application I always do tx for an indefinite amount of
time, so this is not a problem for me.
It just remains a very odd issue, which likely will disappear in future
releases (as Martin said they have "a bunch of changes in the pipeline").
Best regards,
Claudio
On 03/02/2017 02:25 AM, Martin Braun via USRP-users wrote:
> Guys,
>
> I can barely keep up. Hopefully this answers some of the questions:
>
> - send()-ing an integer multiple of the packet size is the most
> performant. Internally, it's not a big difference if you call send()
> with N times the packet size, or 1 times the packet size. However, if
> you don't have an integer multiple, some packets will be smaller than
> the maximum packet size, thus bringing down performance.
>
> - The *thread* that calls send() indeed shouldn't also be doing lots of
> other stuff. GNU Radio does this, for example. We have producer/consumer
> threads.
>
> - The MTU throttling value of 2000 bytes is something we might be able
> to take out, but we're not quite convinced yet. It depends on the exact
> buffer sizes we have on the FPGA. Please note, we are currently actively
> optimizing the Tx performance. We have a bunch of changes in the
> pipeline, and bringing this value back up is one of them. For 200 Msps,
> an MTU of 2000 is definitely problematic, so eventually it will need to
> go up again.
>
> Cheers,
> Martin
>
>
> On 03/01/2017 11:21 AM, Stefano Bettelli via USRP-users wrote:
>> Dear Claudio,
>>
>> I have found a noticeable improvement when fixing the buffer size to an
>> integer multiple of the "natural" buffer size.
>> Try replacing the samples-per-channel settings as follows:
>>
>> const size_t natural_spp = tx_stream->get_max_num_samps();
>> const size_t min_spp = natural_spp*500;
>> const size_t max_spp = natural_spp*500;
>>
>> (natural_spp is 496 I believe, so we are talking here of 248'000 samples,
>> i.e. 992'000 bytes). With these settings I can TX on 2 channels at 100MS/s
>> for tens of seconds without errors. But 200MS/s still fails miserably.
>>
>> I have also another finding. I have noticed that while in RX streams the UDP
>> packets have 8000 bytes payload, in TX the payload is reduced to something
>> around 2000. Also setting the send_frame_size to 8000 doesn't change this
>> behavior. I was wondering whether I had something wrong in my hardware
>> configuration, when I found the following very interesting lines in
>> host/lib/usrp/x300/x300_impl.hpp :
>>
>> //static const size_t X300_PCIE_TX_DATA_FRAME_SIZE = 8192; // bytes
>> // This is a temporary solution: We're throttling PCIe MTU to avoid
>> // underruns on Tx. Once we solve it on the FPGA side, need revert this
>> commit.
>> static const size_t X300_PCIE_TX_DATA_FRAME_SIZE = 3000; // bytes
>> [...]
>> // MTU throttling for Ethernet/TX (see above)
>> static const size_t X300_ETH_DATA_FRAME_MAX_TX_SIZE = 2000;
>>
>> with 2000 bytes payload at 200MS/s one need to send a packet every 2.5us,
>> which is why the TX at this rate is failing so easily. With 8000 bytes it
>> would be 10us, which is quite manageable. So, if anyone from Ettus is
>> listening, is this still an actual problem in the FPGA firmware or is it a
>> forgotten commit?
>>
>> Regards,
>> Stefano
>>
>> -----Original Message-----
>> From: Claudio Cicconetti [mailto:[email protected]]
>> Sent: Mittwoch, 1. M?rz 2017 18:05
>> To: Stefano Bettelli <[email protected]>
>> Cc: [email protected]
>> Subject: Re: [USRP-users] Asymmetry in achievable TX/RX rates
>>
>> Dear Stefano,
>> Fascinating issue.
>>
>> I tried your example with a slightly different environment (X300, single
>> 10 GbE connection to host, single WBX-120, uhd-3.10.1.1) but the result is
>> the *same*.
>>
>> Basically the use case is:
>> - tx rate = 1 MS/s
>> - send size = 200 kS
>>
>> * Scenario1
>>
>> Sending a total of 1 MS (= 5 calls to send).
>> A burst ack is received after all sends have been done.
>> There are a lot of underflows.
>>
>> * Scenario2
>>
>> Same as above but sending a total of 2 MS (= 10 calls to send).
>> No burst ack is received, no underflows.
>>
>> I tried disabled the time specification in the send() metadata, but the
>> result is the same. You can find the modified example at:
>>
>> https://www.dropbox.com/s/m619yrox03cebuj/mybenchmark2.cpp?dl=0
>>
>> By commenting / uncommenting lines 8 and 9 in the example you can switch
>> between Scenario1 and Scenario2.
>>
>> Unfortunately, I could not spot any obvious flaws in your example.
>>
>> Best regards,
>> Claudio
>>
>> On 03/01/2017 01:41 PM, Stefano Bettelli wrote:
>>> Hi Claudio,
>>>
>>> -----Original Message-----
>>>> From: USRP-users [mailto:[email protected]] On
>>>> Behalf Of Claudio Cicconetti via USRP-users
>>>> Subject: Re: [USRP-users] Asymmetry in achievable TX/RX rates Hello
>>>> Stefano, Do you mind sharing the source code of your modified
>>>> benchmark_rate?
>>>
>>> In the spirit of the minimal working example I have prepared a simplified
>>> code that I attach at the end of this message.
>>> You have to recompile it to change parameters, because I have stripped out
>>> all option parsing, but it is a quick thing.
>>> In the main you can change the args string, the transmit rate, the # of
>>> channels and the init delay.
>>> In the send() subthread called b_tx_rate() you can change mainly how many
>>> samples per channel you send with each individual send().
>>> This benchmark runs till "target" (global variable) samples per channel
>>> have been sent, or till the send() returns 0.
>>>
>>> Compile it with the following command line:
>>> g++ -std=c++14 -Wall -Wextra -O3 -s -o mybenchmark mybenchmark.cpp
>>> g++ -luhd -lpthread -lboost_system
>>>
>>> I have an X310 with the XG firmware, and 2 10G cables, and I have tried it
>>> in the following configurations:
>>> 1) 2 ch, 1MS/s, 200'000 S/ch, target = 16'000'000 --> OK
>>> 2) like in 1) but target = 200'000 --> errors
>>> 3) like in 1) but the # of S/ch is randomly chosen between 200'000 and
>>> 200'500 --> errors
>>> 4) same as 1),2) and 3) with only one channel --> same results
>>>
>>> Analysing the traffic with Wireshark doesn't show any specific anomaly, nor
>>> large fluctuations in packet deltas (the transport tends to use UDP packet
>>> with about 2000B of payload, with a delta of 5-20 microseconds, while one
>>> packet needs 1ms to be processed by the USRP.
>>>
>>> I would be very interested to know whether you get the same results, and
>>> whether you spot any error in the program workflow.
>>> Thanks in advance,
>>> Stefano
>>>
>>> --------------- start of mybenchmark.cpp --------- cut here
>>> ------------------- #include <uhd/utils/thread_priority.hpp> #include
>>> <uhd/utils/safe_main.hpp> #include <uhd/usrp/multi_usrp.hpp> #include
>>> <iostream> #include <thread>
>>>
>>> std::vector<size_t> counts(256, 0); // async message counts size_t
>>> target { 16000000 }; // total # samples per channel to be TXed
>>>
>>> #include <chrono>
>>> #define NOW std::chrono::high_resolution_clock::now()
>>> #define DIF
>>> ((std::chrono::high_resolution_clock::now()-start).count()/1000)
>>>
>>> /*********************************************************************
>>> **
>>> * Attempt transmission with multiple send()'s
>>> **********************************************************************
>>> / void b_tx_rate(uhd::tx_streamer::sptr tx_stream,
>>> uhd::time_spec_t start_time, double tx_rate) {
>>> uhd::tx_metadata_t md;
>>> md.time_spec = start_time;
>>> md.has_time_spec = true;
>>> // const size_t natural_spp = tx_stream->get_max_num_samps();
>>> const size_t min_spp = 200000;//199600; // samples per channel
>>> const size_t max_spp = 200000; // samples per channel
>>> std::cout << "Using " << max_spp << " samples in send()" << std::endl;
>>> std::vector<char> buff(4 * max_spp); // sc16 is 4 bytes per sample
>>> const auto num_ch = tx_stream->get_num_channels();
>>> std::vector<const void *> pts(num_ch, &buff.front());
>>> auto start { NOW }; size_t accum { 0 };
>>> while (target > 0) {
>>> size_t act_spp = min_spp + (double(rand())/RAND_MAX)*(max_spp -
>>> min_spp);
>>> if (act_spp > target) act_spp = target;
>>> auto rel_time { md.time_spec }; rel_time -= start_time;
>>> std::cout << " spp " << act_spp << " alsent " << accum
>>> << " to send " << target << " time spec "
>>> << rel_time.get_real_secs() << std::endl;
>>> start = NOW;
>>> auto n = tx_stream->send(pts, act_spp, md);
>>> std::cout << "Send call time " << DIF << " sent= " << n << std::endl;
>>> accum += n; target -= n;
>>> start = NOW;
>>> md.time_spec += uhd::time_spec_t::from_ticks(n, tx_rate);
>>> md.has_time_spec = false;
>>> if (n == 0) { target = 0; break; /* stop on error */ } }
>>> md.has_time_spec = false;
>>> md.end_of_burst = true; // EOB packet
>>> tx_stream->send(pts, 0, md); }
>>>
>>> /*********************************************************************
>>> **
>>> * Handle asynchronous messages
>>>
>>> **********************************************************************
>>> / void b_tx_async(uhd::tx_streamer::sptr tx_stream) {
>>> uhd::async_metadata_t amd;
>>> size_t termination = 10; // delayed exit to catch late messages
>>> while (target > 0 || termination > 0) {
>>> if (not tx_stream->recv_async_msg(amd)) { // 100ms timeout
>>> if (target == 0) --termination; continue; }
>>> ++counts[amd.event_code]; } }
>>>
>>> /*********************************************************************
>>> **
>>> * Main code + dispatcher
>>>
>>> **********************************************************************
>>> / int UHD_SAFE_MAIN(int argc, char *argv[]){
>>> (void)argc; (void)argv;
>>> // ---------------------------------------------------------------
>>> std::string args { "addr=192.168.30.2,second_addr=192.168.40.2" };
>>> std::vector<size_t> tx_channels { 0,1 };
>>> double init_delay { 0.5 }; // 500mS
>>> double tx_rate { 1.0e6 };
>>> // ---------------------------------------------------------------
>>> uhd::set_thread_priority_safe();
>>> std::cout << "Creating the usrp device with: " << args << std::endl;
>>> auto usrp = uhd::usrp::multi_usrp::make(args);
>>> std::cout << "Using Device: " << usrp->get_pp_string() << std::endl;
>>> usrp->set_tx_rate(tx_rate);
>>> //usrp->set_tx_gain(20,0);
>>> usrp->set_time_unknown_pps(uhd::time_spec_t(0.0));
>>> uhd::stream_args_t stream_args("sc16", "sc16");
>>> stream_args.channels = tx_channels;
>>> auto tx_stream = usrp->get_tx_stream(stream_args);
>>> std::cout << "\nTX subdev_spec=" << usrp->get_tx_subdev_spec().to_string()
>>> << "\nTesting tx_rate=" << (usrp->get_tx_rate()/1.0e6) << "MS/s"
>>> << " chan=" << tx_stream->get_num_channels() << "\n\n";
>>> auto start_time = usrp->get_time_now() + uhd::time_spec_t(init_delay);
>>> std::thread tx { b_tx_rate , tx_stream, start_time, tx_rate };
>>> std::thread as { b_tx_async, tx_stream };
>>> tx.join(); as.join();
>>> #define CC(s) std::endl << #s": " << \
>>> counts[uhd::async_metadata_t::event_code_t::EVENT_CODE_ ## s]
>>> std::cout << CC(BURST_ACK) << CC(UNDERFLOW) << CC(SEQ_ERROR)
>>> << CC(TIME_ERROR) << CC(UNDERFLOW_IN_PACKET)
>>> << CC(SEQ_ERROR_IN_BURST) << CC(USER_PAYLOAD) << std::endl;
>>> return EXIT_SUCCESS; }
>>>
>>
>>
>> _______________________________________________
>> 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
>
------------------------------
Message: 15
Date: Wed, 8 Mar 2017 10:35:58 -0500
From: Rob Kossler <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] RFNoC Signal Generator extension
Message-ID:
<cab__httticdtsmhwrtbw_ixfhqk2kpdv6yzw1os-trsgawr...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I am looking to extend the RFNoC Signal Generator block or create a new
block to provide capability for transmission of arbitrary I/Q data (finite
length record which gets repeated) from the FPGA. Such a block would
enable transmission of arbitrary data at 160 MHz bandwidth on both channels
(X310/UBX160) which presently is not really possible (see other posts about
transmitting at 200 MS/s even on one channel). Also, it would free up CPU
cycles from having to send this finite block over and over.
I am considering reserving a block of FPGA memory to hold the samples or
alternatively using DRAM for this purpose. I am considering a ballpark
sample depth of perhaps 100K samples. Before diving deeply into it, I am
wondering if such a block already exists. If not, I am wondering if anyone
has advice on the best way to implement this capability.
Thanks.
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170308/7e6d039d/attachment-0001.html>
------------------------------
Message: 16
Date: Wed, 8 Mar 2017 08:28:19 -0800
From: Michael West <[email protected]>
To: Dave NotTelling <[email protected]>
Cc: Marcus M?ller <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310/UBX Retuning Performance
Message-ID:
<CAM4xKrqj1RGpA-a4yrYTVePkHkNOwXBNA=vt17jg7-gvkyf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Dave,
Sorry for the delay. Performance mode is the default mode and will not
help speed up the transition. One option is to have a pair of UBX boards
with one on the low band and one on the high band.
Regards,
Michael
On Wed, Mar 8, 2017 at 4:54 AM, Dave NotTelling via USRP-users <
[email protected]> wrote:
> Anyone have any information about whether or not changing to performance
> mode from power save will help speed up the transition between the two
> bands?
>
> On Mon, Mar 6, 2017 at 12:37 PM, Dave NotTelling <[email protected]>
> wrote:
>
>> *bump*
>>
>> On Fri, Mar 3, 2017 at 10:27 AM, Dave NotTelling <[email protected]>
>> wrote:
>>
>>> Can performance mode help with the > 100ms tuning time between the two
>>> bands? I seem to recall the performance mode setting relating to when the
>>> unused PA is powered off. Also, is the long tuning time something that the
>>> UHD code causes or is that just a number that the developer should keep in
>>> mind when switching bands?
>>>
>>> Thanks!
>>>
>>> On Fri, Feb 24, 2017 at 3:41 PM, Dave NotTelling <[email protected]>
>>> wrote:
>>>
>>>> Thanks!
>>>>
>>>> On Fri, Feb 24, 2017 at 3:32 PM, Marcus M?ller via USRP-users <
>>>> [email protected]> wrote:
>>>>
>>>>> Largely: Yes; the UBX160 and UBX40 only differ in their baseband
>>>>> filters' passive component values (see the schematics).
>>>>>
>>>>> There's a bit of a difference on how you can clock the UBX on N210,
>>>>> but that won't change behaviour all that much. Also, due to the 100 MHz
>>>>> instead of X3xx's 200 MHz master clock rate, your timing granularity is
>>>>> twice as bad :)
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Marcus
>>>>> On 24.02.2017 21:24, Dave NotTelling via USRP-users wrote:
>>>>>
>>>>> Do these tuning/settling times also hold true for the UBX-40 in an
>>>>> N210?
>>>>>
>>>>> On Fri, Feb 24, 2017 at 2:47 PM, Derek Kozel via USRP-users <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Hi Jason,
>>>>>>
>>>>>> If you use the set_command_time function to cause the tune to occur
>>>>>> at a specific time then you can use the in-band timestamps from the recv
>>>>>> call to identify the sample when the tune action started. The 500us of
>>>>>> samples following that timestamp are the ones you would want to discard.
>>>>>>
>>>>>> An example of setting the execution time for a command:
>>>>>> https://github.com/EttusResearch/uhd/blob/master/host/exampl
>>>>>> es/test_timed_commands.cpp#L96
>>>>>>
>>>>>> An example of starting streaming at a set time:
>>>>>> https://github.com/EttusResearch/uhd/blob/master/host/exampl
>>>>>> es/test_timed_commands.cpp#L129
>>>>>>
>>>>>> Regards,
>>>>>> Derek
>>>>>>
>>>>>>
>>>>>> On Fri, Feb 24, 2017 at 11:27 AM, Jason Roehm via USRP-users <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> On 02/24/2017 01:24 PM, Michael West via USRP-users wrote:
>>>>>>>
>>>>>>>> Hi Devin,
>>>>>>>>
>>>>>>>> I have measured the UBX tune time. The SPI writes to tune the LO
>>>>>>>> take ~30-60us and the LO lock time is 400us. I recommend discarding at
>>>>>>>> least 500us of samples after the LO tune. I also recommend continuous
>>>>>>>> streaming of samples so the frontend components are not switched on and
>>>>>>>> off, which can cause long transients. For the UBX-160, set the
>>>>>>>> dboard_clock_rate to 20e6 and tune the LO in steps of 160 MHz. If
>>>>>>>> using a
>>>>>>>> sample rate <200 Msps, use DSP tuning (which takes < 1us) for the
>>>>>>>> frequencies between the 160MHz steps. With that, you should be able to
>>>>>>>> tune across the full 6GHz in ~18ms in theory. There is one caveat.
>>>>>>>> There
>>>>>>>> are 2 LNAs on the UBX, one for <1.5 GHz and one for above. Only one
>>>>>>>> can be
>>>>>>>> powered on at a time and the warm up time is significant (in the 100s
>>>>>>>> of
>>>>>>>> milliseconds for the low band LNA and 10s of milliseconds for the high
>>>>>>>> band
>>>>>>>> LNA),, so you would be best suited using one daughterboard for the low
>>>>>>>> band
>>>>>>>> and one for the high band for the fastest sweep time.
>>>>>>>>
>>>>>>>> Unfortunately, I do not have the same experience with the TwinRX,
>>>>>>>> so i cannot advise on it.
>>>>>>>>
>>>>>>>
>>>>>>> Not to hijack this thread, but do you have any recommendations on
>>>>>>> the most effective way to properly time the "discard 500us of samples
>>>>>>> after
>>>>>>> the LO tune?" One of the drawbacks of using the USRP family for
>>>>>>> applications that require fast retuning is that there isn't (from what I
>>>>>>> can tell) any in-band indication of what center frequency the radio is
>>>>>>> tuned to. The control interface (e.g. through
>>>>>>> multi_usrp::set_rx_center_freq())
>>>>>>> is completely separate from the data streaming interface, so if I call
>>>>>>> set_rx_center_freq() at time T, I have no way of accurately estimating
>>>>>>> when
>>>>>>> the tune will actually be complete in the data stream.
>>>>>>>
>>>>>>> This seems to be a disadvantage of the CHDR protocol that
>>>>>>> contemporary USRPs use; they seem to carry data samples and timetags,
>>>>>>> but
>>>>>>> nothing else. VITA 49 is nice in that it can provide full context in
>>>>>>> timetagged packets, so you can get updates as to the radio state (e.g.
>>>>>>> frequency, gain) that are aligned as closely as possible with the
>>>>>>> associated samples from the SDR.
>>>>>>>
>>>>>>> Jason
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>> [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/20170308/42513bbc/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 79, Issue 8
*****************************************
