[USRP-users] Re: Rx Packet Drop in N321 USRP

[zhou via USRP-users]

 Hi Marcus, The LLL errors happened in host when it talks to N321.N321 is 
connected to the host through two 10GigE SFP cables directly; these is no other 
device in the middle. N321 has one extra RJ45 1GigE cable for management. This 
cable is connected to a switch; host is also connected to this switch.
If N321 receives unsupported protocols on the management port (RJ45) and then 
generated Rx drop, it is reasonable. But on SFP ports, I don't know what 
protocol they receive apart from broadcast from host when running 
uhd_find_device and the configuration commands.
Does UHD use IRQ or polling method to retrieve data from NIC?
For the ULLL error in host, I doubt on two things:- tx buffer size: because of 
the high sampling rate, the tx buffer needs to be bigger to tolerate 
fluctuation and interruption during processing. What command can be used to 
check tx buffer size?- cpu core allocation, NIC binding. There are 8 cores in 
host; I use separate cores for Tx and Rx. In my program, there are four threads 
which use 3 cores, but in htop, I can see 8 threads in my process. Are the 
extra threads created by UHD? 

On Tuesday, 7 September 2021, 22:47:44 BST, Marcus D. Leech 
 wrote:  
 
  On 2021-09-07 3:59 p.m., zhou wrote:
  
 
 Thanks a lot, Marcus. The kernel version I am using in host is 5.4.0-81, but 
there is no packet drop. It is still strange that packet drop happened in USRP. 
 In my test, sometimes there are U errors. I am wondering if there is 
something wrong with network buffer.  L means "late packet', which means that 
the thing that's producing packets isn't "keeping up" with the required
   cadence of samples being consumed by the radio.
 
 Do you get this when talking to the N321 from your host, or when using the 
N321 in embedded mode (using the
   Linux OS running on the N321).
 
 How are your N321 and host computer connected?  Are they connected via a 
switch or direct connected?
 
 It's not clear to me how the "RX drops" is triggered for the "unsupported 
protocols" case--whether that's just unsupported
   *ETHERNET* protocols, or any protocol packet for which there isn't a service 
registered on the system--in this case your
   N321.  If it's the latter, then it may just be the case that your host PC is 
sending perhaps broadcast or other packets for
   which there are no services registered on your N321 system to process them, 
so it drops them, and just logs it.  Unless
   your host PC is doing a LOT of this, it's of no consequence.
 
 
 
  
  
  On Tuesday, 7 September 2021, 14:39:54 BST, Marcus D. Leech 
 wrote:  
  
 On 2021-09-07 7:54 a.m., zhou wrote:
  
 
Thanks Marcus. What is the reason for Rx packet drop in N321? I have 
configured the same MTU on both ends of the connection. Interestingly, there is 
no Tx packet loss but Rx.  Hmmm, so, just found this:
 
 
 
Beginning with kernel 2.6.37, it has been changed the meaning of dropped packet 
count. Before, dropped packets was most likely due to an error. Now, the 
rx_dropped counter shows statistics for dropped frames because of:

   - Softnet backlog full
   - Bad / Unintended VLAN tags
   - Unknown / Unregistered protocols
   - IPv6 frames when the server is not configured for IPv6
 
[...]
 
If the rx_dropped counter stops incrementing while tcpdump is running; then it 
is more than likely showing drops because of the reasons listed earlier.
 

 
 

 
 
IN other words, mostly harmless. At some point, the semantics of "dropped 
packets" changed, and I didn't even notice.
 
   

 
 

 
  
  
  
  On Tuesday, 7 September 2021, 00:05:57 BST, Marcus D. Leech 
 wrote:  
  
 On 2021-09-06 6:59 p.m., zhou wrote:
  
 
Hi Marcus, 
  Could you please help on this? I find some confusing information on MTU 
configuration in different ettus web pages: 
https://files.ettus.com/manual/page_transport.html :  MTU=8000 for 10GigE
  https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks : MTU=9000 
for 10GigE
  
  Which one is correct? :  
  Thanks.  They're both valid, in that a larger MTU tends to improve bulk 
performance at high sample rates.
 
 The caveat is that BOTH SIDES of the connection have to "agree" on the MTU, 
and some host controllers
   will happily accept a large MTU, but be unable to actually support it, 
although that situation is NOT one
   that I have seen in 10GiGe controllers--they inherently want to support 
"jumbo frames". 
 
 
 
  
  
  On Monday, 6 September 2021, 22:33:35 BST, zhou via USRP-users 
 wrote:  
  
 Hi,   
  I have a problem with the N321 USRP. I find packet dropped in USRP but not in 
host. In host, I am running Ubuntu 18.04. 
  
 Below is the ifconfig result in N321:
 
root@ni-n3xx-320CAAB:~# ifconfig
 
eth0  Link encap:Ethernet  HWaddr 00:80:2F:32:36:BA
 
  inet addr:192.168.10.165 Bcast:192.168.255.255  Mask:255.255.255.0
 
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 
  RX packets:618374 errors:0 drop

[USRP-users] Re: Reading E310 temperatures

[Rich Gopstein]

FYI - I ended up reading the raw temp values from the E310's /sys file
system.  I had to estimate the offset value for the Zynq temp sensor, so it
might not be accurate.

Here's the code I ended up using. It runs on UHD 3.15, but I don't know
about UHD 4.x.

Rich


On Wed, Aug 25, 2021 at 5:06 PM Rich Gopstein  wrote:

> Thanks.  I'm out until next week, but I'll give it a try when I return.
>
> For lm-sensors, get the zip file from:
> https://github.com/lm-sensors/lm-sensors/archive/refs/tags/V3-6-0.zip
> Then:
> unzip
> make all
> make install
>
> On Wed, Aug 25, 2021 at 3:53 PM Ofer Saferman  wrote:
>
>> Hello,
>>
>> Here are some C++ code snippets for reading all the temperatures:
>> ---
>> uhd::device3::sptr usrp = uhd::device3::make(args);
>>
>> int temp_mb =
>> usrp->get_tree()->access("/mboards/0/sensors/temp_mb").get().to_int();
>> int temp_fpga =
>> usrp->get_tree()->access("/mboards/0/sensors/temp_fpga").get().to_int();
>> int temp_ad9361 =
>> usrp->get_tree()->access("/mboards/0/dboards/A/tx_frontends/0/sensors/ad9361_temperature").get().to_int();
>>
>> std::cout << "Motherboard temp=" << temp_mb << std::endl;
>> std::cout << "FPGA temp=" << temp_fpga << std::endl;
>> std::cout << "AD9361 temp=" << temp_ad9361 << std::endl;
>> ---
>> If your USRP object is multi_usrp it is easier. There is a method called
>> get_mboard_sensor() or something like that makes the code more pretty. The
>> sensor name is as above.
>>
>> How did you install lm_sensors?
>>
>> Regards,
>> Ofer Saferman
>>
>> On Wed, Aug 25, 2021 at 2:02 AM 
>> wrote:
>>
>>> Send USRP-users mailing list submissions to
>>> usrp-users@lists.ettus.com
>>>
>>> To subscribe or unsubscribe 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. Re: Reading E310 temperatures (aneesh patel)
>>>2. Re: Reading E310 temperatures (aneesh patel)
>>>3. Re: Reading E310 temperatures (Rich Gopstein)
>>>
>>>
>>>
>>> -- Forwarded message --
>>> From: aneesh patel 
>>> To: Rich Gopstein , Marcus D Leech <
>>> patchvonbr...@gmail.com>
>>> Cc: "usrp-users@lists.ettus.com" 
>>> Bcc:
>>> Date: Tue, 24 Aug 2021 22:19:49 + (UTC)
>>> Subject: [USRP-users] Re: Reading E310 temperatures
>>> Concur on verifying-- that being said I know at least one of them
>>> (possibly CPU) was available on the SG3 image a while back (I'm sure
>>> nothing much has changed there but its been a while).
>>>
>>> Then is would be very simple to write a simple custom GNURadio block
>>> (like basically a command line script to cat the sensor file descriptor
>>> [just google that as I can't recall if its in /sys or /proc]) to pull that
>>> data from the OS to pass temp messages and ingest them into your message
>>> passing or logging system. On the tougher end, depending on dev cycles, one
>>> can cross-compile or pull code from lm-sensors and then turn that into a
>>> GNURadio block (and maybe even being able to add the other sensors when
>>> reading into the ettus kernel mod code/schematics if possible). Some
>>> options exist.
>>>
>>> Going all from memory here but that should be >94.27% correct. :)
>>>
>>> Best of luck!
>>>
>>> Aneesh
>>>
>>> On Tuesday, August 24, 2021, 05:20:51 PM EDT, Marcus D Leech <
>>> patchvonbr...@gmail.com> wrote:
>>>
>>>
>>> My approach would be to see if any of those sensors are understood by
>>> the kernel lm_sensors subsystem.
>>>
>>> Sent from my iPhone
>>>
>>> > On Aug 24, 2021, at 5:12 PM, Rich Gopstein 
>>> wrote:
>>> >
>>> > 
>>> > I'm helping out on a project that's using an E310.  Someone else is
>>> doing the GNURadio code, but I need to read the temperature values
>>> periodically (once every few seconds).  My code will not be running in
>>> GNURadio.
>>> >
>>> > It looks like there are three temp sensors (Zynq, ADT7408, and the
>>> AD9361).
>>> >
>>> > What are my options for reading the temp values outside of GNURadio?
>>> If it matters, the E310 is running UHD_3.15
>>> > My code will be running on the E310 directly.
>>> >
>>> >
>>> > Thanks.
>>> >
>>> > Rich
>>> >
>>> > ___
>>> > USRP-users mailing list -- usrp-users@lists.ettus.com
>>> > To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>>
>>> ___
>>> USRP-users mailing list -- usrp-users@lists.ettus.com
>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>>
>>>
>>>
>>> -- Forwarded message --
>>> From: aneesh patel 
>>> To: Rich Gopstein , Marcus D Leech <
>>> patchvonbr...@gmail.com>
>>>

[USRP-users] Re: Rx Packet Drop in N321 USRP

[Marcus D. Leech]

On 2021-09-08 6:26 a.m., zhou wrote:

Hi Marcus,
The LLL errors happened in host when it talks to N321.
N321 is connected to the host through two 10GigE SFP cables directly; 
these is no other device in the middle. N321 has one extra RJ45 1GigE 
cable for management. This cable is connected to a switch; host is 
also connected to this switch.


If N321 receives unsupported protocols on the management port (RJ45) 
and then generated Rx drop, it is reasonable. But on SFP ports, I 
don't know what protocol they receive apart from broadcast from host 
when running uhd_find_device and the configuration commands.
You could use "WireShark" on your host computer to see what is being 
sent.  Ideally, yes, it would only involve UHD

  protocols, and perhaps ARP packets, etc.



Does UHD use IRQ or polling method to retrieve data from NIC?
IRQ vs polling configuration is the domain of your OS Kernel and its 
hardware drivers.  UHD is not involved at all other
  than "just another application".   You can use "ethtool" to query and 
set these parameters--if your hardware supports them
  there are a *large* number of parameters that can be controlled by 
ethtool, so I suggest looking at online documentation

  for it.



For the ULLL error in host, I doubt on two things:
- tx buffer size: because of the high sampling rate, the tx buffer 
needs to be bigger to tolerate fluctuation and interruption during 
processing. What command can be used to check tx buffer size?
The "sysctl" commands that you spoke of in earlier e-mails set the 
amount of memory used by the kernel drivers for

  network buffering.

sysctl net.core.rmem_max
sysctl net.core.wmem_max

Will both print out the current settings

- cpu core allocation, NIC binding. There are 8 cores in host; I use 
separate cores for Tx and Rx. In my program, there are four threads 
which use 3 cores, but in htop, I can see 8 threads in my process. Are 
the extra threads created by UHD?




There are some threading notes here:

https://files.ettus.com/manual/page_general.html#general_threading

I don't believe that UHD creates any threads of its own.  It is 
conventional for the *application* to create an RX thread, a TX thread, 
and a control thread.


For high-bandwidth networking (high sample rates) some customers have 
had success using DPDK on their system, if

  the 10G network cards they use support DPDK:

https://files.ettus.com/manual/page_dpdk.html



___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: N210 + UBX Power Calibration

[Ernest Fardin via USRP-users]

Hi,

Following up on this, the question I'm trying to answer is: "Can I
calibrate the rx power on an N210 + UBX platform?"

With the N210, has_rx_power_reference()

returns False. Can I conclude from this that an rx power calibration is not
possible on this device?

On Tue, Sep 7, 2021 at 9:00 PM Ernest Fardin  wrote:

> Hi,
>
> I'm trying to calibrate the receive power on a USRP N210 with a UBX
> daughterboard. Using UHD 4.0, I can get uhd_power_cal.py to run by adding
> an N210Calibrator class to usrp_calibrator.py. N210Calibrator overloads the
> USRPCalibratorBase class.
>
> class N210Calibrator(USRPCalibratorBase):
> """
> N210/UBX Calibration
> """
> mboard_ids = ('N210r4',)
> default_rate = 2.5e6
> min_freq = 50e6
> max_freq = 50e6
> tune_settling_time = .5
>
> When the calibration completes, the store() method in usrp_calibrator
> attempts to write the calibration table to the UBX with
>
> database.write_cal_data(
> cal_key,
> cal_serial,
> cal_data.serialize())
>
> The chan_info string returned by the N210 is:
>
> {'mboard_id': 'N210r4', 'mboard_name': '', 'mboard_serial': '318EFF3',
> 'rx_antenna': 'TX/RX', 'rx_id': 'UBX-40 v2 (0x007c)', 'rx_serial':
> '318D55F', 'rx_subdev_name': 'UBX RX', 'rx_subdev_spec': 'A:0'}
>
> What values to use for cal_key and cal_serial?
>
> Thanks in advance!
>
> Ernest
>
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: N210 + UBX Power Calibration

[Marcus D. Leech]

On 2021-09-08 5:27 p.m., Ernest Fardin via USRP-users wrote:

Hi,

Following up on this, the question I'm trying to answer is: "Can I 
calibrate the rx power on an N210 + UBX platform?"


With the N210, has_rx_power_reference() 
 
returns False. Can I conclude from this that an rx power calibration 
is not possible on this device?
It means that there is no reference calibration API available for this 
device.


The calibration reference API is fairly new, so it will only be 
available (at least initially) on newer devices.   The N2xx series is 
about 10 years old

 at this point.




On Tue, Sep 7, 2021 at 9:00 PM Ernest Fardin > wrote:


Hi,

I'm trying to calibrate the receive power on a USRP N210 with a
UBX daughterboard. Using UHD 4.0, I can get uhd_power_cal.py to
run by adding an N210Calibrator class to usrp_calibrator.py.
N210Calibrator overloads the USRPCalibratorBase class.

class N210Calibrator(USRPCalibratorBase):
    """
    N210/UBX Calibration
    """
    mboard_ids = ('N210r4',)
    default_rate = 2.5e6
    min_freq = 50e6
    max_freq = 50e6
    tune_settling_time = .5

When the calibration completes, the store() method in
usrp_calibrator attempts to write the calibration table to the UBX
with

        database.write_cal_data(
            cal_key,
            cal_serial,
            cal_data.serialize())

The chan_info string returned by the N210 is:

{'mboard_id': 'N210r4', 'mboard_name': '', 'mboard_serial':
'318EFF3', 'rx_antenna': 'TX/RX', 'rx_id': 'UBX-40 v2 (0x007c)',
'rx_serial': '318D55F', 'rx_subdev_name': 'UBX RX',
'rx_subdev_spec': 'A:0'}

What values to use for cal_key and cal_serial?

Thanks in advance!

Ernest


___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com


___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Radio Application fails to run as service on E310

[thebouleoffools]

Thanks for the tip, it helped me find what was ultimately an embarrassing 
mistake. I’ll post the explanation in case it helps someone new in the future. 
By default, gnuradio generates a python script with a try/except block in 
main() that passes on EOF. The correct solution was to replace this block with 
a simple signal.pause() and make sure a signal handler was defined.
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: E320 how use the E320 as ntp time server using its internal gpsdo as time source

[thebouleoffools]

Assuming you have ntp on your device (default img from ettus doesn’t have it), 
set /etc/ntp.conf to:

```
# GPS Serial data reference
server 127.127.28.0 minpoll 4 maxpoll 4
fudge 127.127.28.0 time1 0.0 refid GPS

# GPS PPS reference
server 127.127.28.1 minpoll 4 maxpoll 4 prefer
fudge 127.127.28.1 refid PPS

And enable the ntp service in systemd. If you don't have ntp, you'll have to 
cross compile it.
```
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: N210 + UBX Power Calibration

[Ernest Fardin via USRP-users]

Thanks Marcus,

A couple more questions on this:

[1] Would it be possible for us to buy a USRP X310 (which supports the
reference power API), run uhd_power_cal and then transfer the UBX DB to the
N210 and expect calibrated power measurements? Or does the reference power
API need to be working on the N210 in order to apply the calibration data?
[2] In order to get the reference power API to work on the N210, would that
require changes to the N210 firmware, or just UHD?

Regards,

Ernest

On Thu, Sep 9, 2021 at 7:34 AM Marcus D. Leech 
wrote:

> On 2021-09-08 5:27 p.m., Ernest Fardin via USRP-users wrote:
>
> Hi,
>
> Following up on this, the question I'm trying to answer is: "Can I
> calibrate the rx power on an N210 + UBX platform?"
>
> With the N210, has_rx_power_reference()
> 
> returns False. Can I conclude from this that an rx power calibration is not
> possible on this device?
>
> It means that there is no reference calibration API available for this
> device.
>
> The calibration reference API is fairly new, so it will only be available
> (at least initially) on newer devices.   The N2xx series is about 10 years
> old
>  at this point.
>
>
>
> On Tue, Sep 7, 2021 at 9:00 PM Ernest Fardin  wrote:
>
>> Hi,
>>
>> I'm trying to calibrate the receive power on a USRP N210 with a UBX
>> daughterboard. Using UHD 4.0, I can get uhd_power_cal.py to run by adding
>> an N210Calibrator class to usrp_calibrator.py. N210Calibrator overloads the
>> USRPCalibratorBase class.
>>
>> class N210Calibrator(USRPCalibratorBase):
>> """
>> N210/UBX Calibration
>> """
>> mboard_ids = ('N210r4',)
>> default_rate = 2.5e6
>> min_freq = 50e6
>> max_freq = 50e6
>> tune_settling_time = .5
>>
>> When the calibration completes, the store() method in usrp_calibrator
>> attempts to write the calibration table to the UBX with
>>
>> database.write_cal_data(
>> cal_key,
>> cal_serial,
>> cal_data.serialize())
>>
>> The chan_info string returned by the N210 is:
>>
>> {'mboard_id': 'N210r4', 'mboard_name': '', 'mboard_serial': '318EFF3',
>> 'rx_antenna': 'TX/RX', 'rx_id': 'UBX-40 v2 (0x007c)', 'rx_serial':
>> '318D55F', 'rx_subdev_name': 'UBX RX', 'rx_subdev_spec': 'A:0'}
>>
>> What values to use for cal_key and cal_serial?
>>
>> Thanks in advance!
>>
>> Ernest
>>
>>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: N210 + UBX Power Calibration

[Marcus D. Leech]

On 2021-09-08 7:28 p.m., Ernest Fardin wrote:

Thanks Marcus,

A couple more questions on this:

[1] Would it be possible for us to buy a USRP X310 (which supports the 
reference power API), run uhd_power_cal and then transfer the UBX DB 
to the N210 and expect calibrated power measurements? Or does the 
reference power API need to be working on the N210 in order to apply 
the calibration data?
I believe that the caibration is for the ENTIRE CHAIN (which makes 
sense), so simply moving it to an N210 would not be meaningful.


[2] In order to get the reference power API to work on the N210, would 
that require changes to the N210 firmware, or just UHD?
Probably just UHD -- taking a VERY cursory look at the CAL code, it 
looks like it can store CAL data in a host-based file database, so even if
  the hardware doesn't have enough EEPROM or FLASH storage for the 
tables, it can be stored in a file on the host.  It looks like there 
would need to be work
  in usrp_calibrator.py to define a N200Calibrator class and override 
the relevant things from the base class.   But I'm not the person who 
developed this,

  so I'm speaking entirely from a cursory inspection of the code.

What is it you ACTUALLY want to achieve?   Turn your USRP into a 
laboratory instrument?  Have some vague notion of how much power you're 
receiving at the
  antenna input?  Because for a limited parameter space, it's fairly 
easy to do that yourself.  The Cal/Reference API was only VERY recently 
added and people
  have been doing without it with USRP products since 2004 or so. It's 
a VERY young API, and provides only very limited device coverage--for 
example, I can't
  really determine if it understands the concept of pluggable 
daughtercards, so that the total index is composed of both the 
motherboard AND daughtercard
  serial numbers.  Because, without that, any calibration data are 
suspect, etc.








Regards,

Ernest

On Thu, Sep 9, 2021 at 7:34 AM Marcus D. Leech 
mailto:patchvonbr...@gmail.com>> wrote:


On 2021-09-08 5:27 p.m., Ernest Fardin via USRP-users wrote:

Hi,

Following up on this, the question I'm trying to answer is: "Can
I calibrate the rx power on an N210 + UBX platform?"

With the N210, has_rx_power_reference()


returns False. Can I conclude from this that an rx power
calibration is not possible on this device?

It means that there is no reference calibration API available for
this device.

The calibration reference API is fairly new, so it will only be
available (at least initially) on newer devices.   The N2xx series
is about 10 years old
 at this point.




On Tue, Sep 7, 2021 at 9:00 PM Ernest Fardin mailto:efar...@ieee.org>> wrote:

Hi,

I'm trying to calibrate the receive power on a USRP N210 with
a UBX daughterboard. Using UHD 4.0, I can get
uhd_power_cal.py to run by adding an N210Calibrator class to
usrp_calibrator.py. N210Calibrator overloads the
USRPCalibratorBase class.

class N210Calibrator(USRPCalibratorBase):
    """
    N210/UBX Calibration
    """
    mboard_ids = ('N210r4',)
    default_rate = 2.5e6
    min_freq = 50e6
    max_freq = 50e6
    tune_settling_time = .5

When the calibration completes, the store() method in
usrp_calibrator attempts to write the calibration table to
the UBX with

        database.write_cal_data(
            cal_key,
            cal_serial,
            cal_data.serialize())

The chan_info string returned by the N210 is:

{'mboard_id': 'N210r4', 'mboard_name': '', 'mboard_serial':
'318EFF3', 'rx_antenna': 'TX/RX', 'rx_id': 'UBX-40 v2
(0x007c)', 'rx_serial': '318D55F', 'rx_subdev_name': 'UBX
RX', 'rx_subdev_spec': 'A:0'}

What values to use for cal_key and cal_serial?

Thanks in advance!

Ernest


___
USRP-users mailing list --usrp-users@lists.ettus.com  

To unsubscribe send an email tousrp-users-le...@lists.ettus.com  



___
USRP-users mailing list -- usrp-users@lists.ettus.com

To unsubscribe send an email to usrp-users-le...@lists.ettus.com




___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com