Re: [USRP-users] rfnoc loopback

[Nick Foster via USRP-users]

It should still apply. Is there something specific you're having trouble
with?

On Wed, Nov 29, 2017, 10:06 PM Jack Ziegler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Has anyone recently tried rfnoc loopback?
> I tried following these directions:
> https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/
> they are dated from last April.  Not sure if I missed a step or maybe
> there is something new in gr-ettus and uhd-devel?
>
> Thanks,
>
> Jack Ziegler
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] rfnoc loopback

[Jack Ziegler via USRP-users]

Has anyone recently tried rfnoc loopback?
I tried following these directions:
https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/
they are dated from last April.  Not sure if I missed a step or maybe there
is something new in gr-ettus and uhd-devel?

Thanks,

Jack Ziegler
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Reading file sink for USRP N210 usding gnuradio

[이성복 via USRP-users]

Hi list,

I tried to transmit text file and recieve it using GMSK mod/demod

Tx: file source -> packet encoder ->GMSK mod ->multiply const -> usrp sink
Rx: usrp source -> multiply const -> Low pass filter ->GMSK demod ->packet
decoder ->files sink

input data type of file sink is byte. so i create receive.txt file but i
can't read the file.
I want to read text message. what should i do for read message?
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Netgear 10GB switch XS728T

[Ian Buckley via USRP-users]

Kevin, 
Glad to hear you are up and running. Daisy chaining (aka stacking) switches is 
actually perfectly good practice. For you as an SDR user the only potential 
impact is potentially a latency increase…there’s one or two applications where 
that might be a factor. Report back if you ever get resolution from Netgear, 
we’d all like to stay away from known problematic equipment.
-Ian

> On Nov 29, 2017, at 11:12 AM, Kevin Krieger  wrote:
> 
> Hi Ian,
> 
> Just as an update, we've purchased 3 XS708E's. We've daisy chained them and 
> we have all 16 N200 devices plugged in, a 10G intel card in the computer, and 
> the tx_bursts example runs flawlessly on all the devices at once. It's 
> cheaper than buying one XS728T, but it takes up more space and I suspect 
> daisy-chaining 3 switches together isn't best practice...
> NETGEAR is currently looking into the issue with why the XS728T doesn't work, 
> so hopefully they figure that out.
> 
> In the meantime, we move on with 3 switches.
> 
> Kevin
> 
> On 11/10/2017 05:52 PM, Ian Buckley wrote:
>> Kevin,
>> I wouldn’t expend more effort at the moment on the dissector, the UDP ports 
>> and packet sizes pretty much tell you whats going on if you understand UHD. 
>> It may be that the dissector for the old UHD protocol was never 
>> complete/perfect.
>> 
>> Interesting that it was the monitoring port that was 10G and the host 
>> 1G….this kind of illustrates my point about using a dedicated non rate 
>> converting monitoring switch since the 10G port delivered bursts of packets 
>> to Wireshark at intervals that were much too close to have been the original 
>> 1G timing.
>> 
>> Maybe your route forward is two XS708E’s if that’s robust…frustrating to not 
>> solve the issue but a better use of your time I suspect. 
>> -Ian
>> 
>> 
>>> On Nov 10, 2017, at 9:17 AM, Kevin Krieger >> > wrote:
>>> 
>>> Hi Ian,
>>> 
>>> OK - is there code for the dissector available to build a new version? Or 
>>> do you think it's worth it?
>>> 
>>> Also - our host sending the samples was actually only 1Gbps ethernet (we 
>>> weren't using the 10Gbps card for that), so I'm not sure that the samples 
>>> would be going into the switch faster than this. We were using the 10G card 
>>> for wireshark.
>>> Thanks for the info about the N210 ethernet port, maybe we can try forcing 
>>> the switch ports to 1G and see if that helps.
>>> Also adding a 1G switch in between the USRP and 10G will be a good test if 
>>> we can get our hands on a 1G switch.
>>> We discussed just getting four 4port 1G cards, we would need to upgrade our 
>>> motherboard though.
>>> 
>>> Thanks, If we figure anything out we'll post back here.
>>> 
>>> Regards,
>>> Kevin
>>> 
>>> On 11/09/2017 09:14 AM, Ian Buckley wrote:
 
 Kevin, 
 I glanced through Captures 0,1,2 and could see the general gist of where 
 it all goes wrong, but it’s not really clear why. The dissector seems out 
 of date, at least it isn’t decoding correctly but I can still follow it.
 
 Capture 0:
 Packets 2551 through 2606 are the actual sample data packets. 
 Then there is an approx 1.2second pause before UHD, having timed out 
 waiting for ACK’s begins some basic control interaction initiated by the 
 host.
 
 Contrast that with Capture 2, where you will see a nicely paced stream of 
 ACK’s (starts at packet 2609) flowing back from the USRP at exact 
 intervals pacing the real time TX operation as the DSP consumes the 
 samples.
 
 Capture 1:
 This goes to the weeds early, streaming never gets close to starting. At 
 around packet 1324 you suddenly see a series of pauses for exactly 0.5 
 secs each.
 
 So a couple of thoughts bordering on guesses:
  
 Rate conversion in switches is always a little bit of a minefield when you 
 have a single stream that is faster than the skinny pipe. In this case, 
 operations like the sample burst are streaming from the host faster than 
 1Gbs into the switch forcing the switch to buffer samples. It’s surprising 
 sometimes how quick these lower cost single chip switches can get buffer 
 starved. Try using 'ethtool' on the Linux host to force the host port to 
 1Gbps to eliminate rate conversion in the switch as a cause.
 
 N210 in general is the most reliable of all USRP’s but it has one quirk, 
 which is that the ethernet port is forced to be 1Gbps and it does no auto 
 negotiation. This often trips up people who connect it to a 100mbit switch 
 or host. I have never actually tried connecting it to 10GBase-T 
 switches…there may be some (switch implementation specific) gotcha’s.
 
 Mirroring multiple ports to a single port can affect how the problem 
 manifests because you create new bottle necks in the switch …if the 10G 
 switch is suspect then I suggest 

Re: [USRP-users] Netgear 10GB switch XS728T

[Kevin Krieger via USRP-users]

Hi Ian,

Just as an update, we've purchased 3 XS708E's. We've daisy chained them 
and we have all 16 N200 devices plugged in, a 10G intel card in the 
computer, and the tx_bursts example runs flawlessly on all the devices 
at once. It's cheaper than buying one XS728T, but it takes up more space 
and I suspect daisy-chaining 3 switches together isn't best practice...
NETGEAR is currently looking into the issue with why the XS728T doesn't 
work, so hopefully they figure that out.


In the meantime, we move on with 3 switches.

Kevin

On 11/10/2017 05:52 PM, Ian Buckley wrote:

Kevin,
I wouldn’t expend more effort at the moment on the dissector, the UDP 
ports and packet sizes pretty much tell you whats going on if you 
understand UHD. It may be that the dissector for the old UHD protocol 
was never complete/perfect.


Interesting that it was the monitoring port that was 10G and the host 
1G….this kind of illustrates my point about using a dedicated non rate 
converting monitoring switch since the 10G port delivered bursts of 
packets to Wireshark at intervals that were much too close to have 
been the original 1G timing.


Maybe your route forward is two XS708E’s if that’s robust…frustrating 
to not solve the issue but a better use of your time I suspect.

-Ian


On Nov 10, 2017, at 9:17 AM, Kevin Krieger > wrote:


Hi Ian,

OK - is there code for the dissector available to build a new 
version? Or do you think it's worth it?


Also - our host sending the samples was actually only 1Gbps ethernet 
(we weren't using the 10Gbps card for that), so I'm not sure that the 
samples would be going into the switch faster than this. We were 
using the 10G card for wireshark.
Thanks for the info about the N210 ethernet port, maybe we can try 
forcing the switch ports to 1G and see if that helps.
Also adding a 1G switch in between the USRP and 10G will be a good 
test if we can get our hands on a 1G switch.
We discussed just getting four 4port 1G cards, we would need to 
upgrade our motherboard though.


Thanks, If we figure anything out we'll post back here.

Regards,
Kevin

On 11/09/2017 09:14 AM, Ian Buckley wrote:


Kevin,
I glanced through Captures 0,1,2 and could see the general gist of 
where it all goes wrong, but it’s not really clear why. The 
dissector seems out of date, at least it isn’t decoding correctly 
but I can still follow it.


Capture 0:
Packets 2551 through 2606 are the actual sample data packets.
Then there is an approx 1.2second pause before UHD, having timed out 
waiting for ACK’s begins some basic control interaction initiated by 
the host.


Contrast that with Capture 2, where you will see a nicely paced 
stream of ACK’s (starts at packet 2609) flowing back from the USRP 
at exact intervals pacing the real time TX operation as the DSP 
consumes the samples.


Capture 1:
This goes to the weeds early, streaming never gets close to 
starting. At around packet 1324 you suddenly see a series of pauses 
for exactly 0.5 secs each.


So a couple of thoughts bordering on guesses:
Rate conversion in switches is always a little bit of a minefield 
when you have a single stream that is faster than the skinny pipe. 
In this case, operations like the sample burst are streaming from 
the host faster than 1Gbs into the switch forcing the switch to 
buffer samples. It’s surprising sometimes how quick these lower cost 
single chip switches can get buffer starved. Try using 'ethtool' on 
the Linux host to force the host port to 1Gbps to eliminate rate 
conversion in the switch as a cause.


N210 in general is the most reliable of all USRP’s but it has one 
quirk, which is that the ethernet port is forced to be 1Gbps and it 
does no auto negotiation. This often trips up people who connect it 
to a 100mbit switch or host. I have never actually tried connecting 
it to 10GBase-T switches…there may be some (switch implementation 
specific) gotcha’s.


Mirroring multiple ports to a single port can affect how the problem 
manifests because you create new bottle necks in the switch …if the 
10G switch is suspect then I suggest interposing a cheap 1G switch 
that supports mirroring between USRP and 10G switch, that way you’ll 
have higher confidence exactly what and when went onto the wire. 
This is also an interesting experiment because it isolates the 
N210’s ethernet port from the 10G switch…curious to see if it now 
starts to work OK. I have had this happen when debugging other products.


The ICMP port unreachable is likely a red herring, some spurious 
Linux service rather than UHD originating those packets I suspect.


Might be worth looking at the switch internal counters to see if any 
physical layer error counters are increasing.


No smoking gun I’m afraid; your fall back plan might be to stuff 
quad port 1G cards in your host, they’re cheap if you have the PCIe 
slots free.


-Ian

On Nov 6, 2017, at 3:13 PM, Kevin Krieger via USRP-users 

[USRP-users] Controlling the temperature controlled oscillator/clock gen

[Pratik Chatterjee via USRP-users]

Hi,
I have a X310. I am wondering if there is a way to control/access the 10
MHz temperature controlled oscillator/clock gen block using Labview. Thank
you in advance.

Pratik
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Announcing USRP/GNU Radio and RFNoC Workshops in the Los Angeles Area

[Neel Pandeya via USRP-users]

==
Ettus Research will be running a series of free, hands-on,
technical workshops in the Los Angeles area.

USRP, UHD, GNU Radio Workshop
Tuesday December 12, from 09:00 to 17:00
El Segundo, California, USA

RFNoC Workshop
Wednesday December 13, from 09:00 to 16:00
El Segundo, California, USA

USRP, UHD, GNU Radio Workshop
Thursday December 14, from 09:00 to 17:00
Santa Ana, California, USA

RFNoC Workshop
Friday December 15, from 09:00 to 16:00
Santa Ana, California, USA

==
Descriptions of the Workshops:

Title:
Introduction to the USRP, UHD, and GNU Radio (Open-Source Toolchain)

Abstract:
This workshop will provide a thorough and practical introduction to
the USRP hardware and the open-source software toolchain (UHD and
GNU Radio). We will examine the hardware and architecture of the
entire USRP family of software-defined radios. We will discuss topics
such as how to get started using a new USRP device, how to install and
configure the open-source software toolchain, programming the USRP
using the UHD API from C++, using GNU Radio with the USRP and creating
and running flowgraphs, using GNU Radio from both GRC and Python, and
various debugging techniques. Several exercises will be performed,
such as implementing an FM transmitter and receiver. Various
demonstrations of wireless systems will be shown. A discussion of the
embedded E310 radio and using embedded SDR will be included. Several
other open-source tools will be discussed, such as GQRX, Fosphor,
Inspectrum, and several Out-of-Tree (OOT) modules. A discussion of
cellular applications, including OpenBTS and LTE stacks, as well as
GPS/GNSS applications will be presented. Several other miscellaneous
topics such as 10 Gigabit Ethernet networking, host system performance
tuning, X300/X310 device recovery, and some best practices will be
discussed. Attendees should come away with a solid foundation and
practical understanding of how to configure, program, and use the USRP
to implement a wide range range of wireless systems.

Title:
FPGA Programming on the USRP with the RFNoC Framework

Abstract:
Ettus Research's RFNoC (RF Network-on-Chip) software framework is
designed to decrease the development time for experienced FPGA
engineers seeking to integrate IP into the USRP FPGA signal
processing chain. RFNoC is the framework for USRP devices that use
Xilinx 7-series FPGAs (E310, E312, X300, X310). RFNoC is built around
a packetized network infrastructure in the FPGA that handles the
transport of control and sample data between the host CPU and the
radio. Users target their custom algorithms to the FPGA in the form
of Computation Engines (CE), which are processing blocks that attach
to this network. CEs act as independent nodes on the network that can
receive and transmit data to any other node (e.g., another CE, the
radio block, or the host CPU).  Users can create modular,
FPGA-accelerated SDR applications by chaining CEs into a flow graph.
RFNoC is supported in UHD and GNU Radio. In this workshop, we will
present an interactive hands-on tutorial on RFNoC, including a
discussion on its design and capabilities, demonstrations of several
existing examples, and a walk-through on implementing a user-defined
CE and integrating the CE into GNU Radio.

==
Addresses of the two workshop locations:

AWR Corporation / National Instruments
1960 E Grand Avenue, Suite 430
El Segundo, California, 90245
http://www.awrcorp.com/company/contact-us/locations

WinSoft
1932 E Deere Avenue, Suite 110
Santa Ana, California, 92705
http://www.winsoft.com/
http://www.ni.com/training/locations/

==
Details and Logistics:

* The workshops are free, technical, and hands-on.

* The content of the two sessions of the USRP, UHD, GNU Radio Workshop
and the RFNoC Workshop will be the same between El Segundo
and Santa Ana.

* Each day, coffee and donuts/bagels will be provided at 08:30,
as well as lunch around 12:00, and an afternoon snack.

* In both workshops, laptop computers and USRP radios will be
provided for use. Attendees do not need to bring or prepare anything.

* Space is limited and will be allocated on a first-come,
first-serve basis.

* Registration is required in advance.
To register, please email "supp...@ettus.com".

* Be sure to specify your (1) full name, (2) email address,
(3) telephone number, (4) company/organization, and (5) which
workshop(s) you will attend.

* Your registration information will not be shared with any external
third-parties whatsoever.

* You are not considered to be registered until you have received
a confirmation email.

* For the USRP/GNU Radio Workshop, attendees should have some previous
experience with Linux and using the Linux command line, and basic
familiarity with a 

Re: [USRP-users] B210 simultaneous Tx and Rx at 32 MS/s

[Marcus D. Leech via USRP-users]

On 11/29/2017 05:07 AM, Joan Olmos wrote:

Thanks Marcus for your response.
I know my setup is asking for about 1Gbit/s USB bit rate in both 
directions. But this should be supported by USB 3.

I'm not familiar with the best USB 3 controllers for USRP.
The hardware is an ASUS mother board (model H170M-PLUS).
I'm using the standard kernel modules that come with Debian 9 (stretch).
This is the info I can get about the USB 3 controller (I send you the 
output of "lsusb -v").
I don't fully understand the output, but it seems that the USRP 
reports a maximum packet size of 1024 bytes.
I'm configuring the Tx/Rx streamers with "spp=2044"complex samples per 
packet and "otw_format=sc16" (4 bytes per complex sample) => 8176 
bytes per packet ... Could this be a problem?
It is the case that not all USB 3 host controllers are of equal quality 
and performance, which is why I asked.


Something you might try is to specify:

num_recv_frames=128
num_send_frames=128

In your device arguments, and see if that makes a difference.

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B210 simultaneous Tx and Rx at 32 MS/s

[Joan Olmos via USRP-users]

  
  
Thanks Marcus for your response.
I know my setup is asking for about 1Gbit/s USB bit rate in both
directions. But this should be supported by USB 3.
I'm not familiar with the best USB 3 controllers for USRP.
The hardware is an ASUS mother board (model H170M-PLUS).
I'm using the standard kernel modules that come with Debian 9
(stretch).
This is the info I can get about the USB 3 controller (I send you
the output of "lsusb -v").
I don't fully understand the output, but it seems that the USRP
reports a maximum packet size of 1024 bytes.
I'm configuring the Tx/Rx streamers with "spp=2044"complex samples
per packet and "otw_format=sc16" (4 bytes per complex sample)  =>
8176 bytes per packet ... Could this be a problem?

  Bus 002 Device 002: ID 2500:0020  
  Device Descriptor:
    bLength    18
    bDescriptorType 1
    bcdUSB   3.00
    bDeviceClass  255 Vendor Specific Class
    bDeviceSubClass 0 
    bDeviceProtocol 0 
    bMaxPacketSize0 9
    idVendor   0x2500 
    idProduct  0x0020 
    bcdDevice    0.00
    iManufacturer   1 Ettus Research LLC
    iProduct    2 USRP B200
    iSerial 3 30CD3EC
    bNumConfigurations  1
    Configuration Descriptor:
      bLength 9
      bDescriptorType 2
      wTotalLength  106
      bNumInterfaces  5
      bConfigurationValue 1
      iConfiguration  0 
      bmAttributes 0x80
    (Bus Powered)
      MaxPower    2mA
      Interface Descriptor:
    bLength 9
    bDescriptorType 4
    bInterfaceNumber    0
    bAlternateSetting   0
    bNumEndpoints   0
    bInterfaceClass   255 Vendor Specific Class
    bInterfaceSubClass  0 
    bInterfaceProtocol  0 
    iInterface  2 USRP B200
      Interface Descriptor:
    bLength 9
    bDescriptorType 4
    bInterfaceNumber    1
    bAlternateSetting   0
    bNumEndpoints   1
    bInterfaceClass   255 Vendor Specific Class
    bInterfaceSubClass  0 
    bInterfaceProtocol  0 
    iInterface  2 USRP B200
    Endpoint Descriptor:
      bLength 7
      bDescriptorType 5
      bEndpointAddress 0x02  EP 2 OUT
      bmAttributes    2
    Transfer Type    Bulk
    Synch Type   None
    Usage Type   Data
      wMaxPacketSize 0x0400  1x 1024 bytes
      bInterval   0
      bMaxBurst  15
      Interface Descriptor:
    bLength 9
    bDescriptorType 4
    bInterfaceNumber    2
    bAlternateSetting   0
    bNumEndpoints   1
    bInterfaceClass   255 Vendor Specific Class
    bInterfaceSubClass  0 
    bInterfaceProtocol  0 
    iInterface  2 USRP B200
    Endpoint Descriptor:
      bLength 7
      bDescriptorType 5
      bEndpointAddress 0x86  EP 6 IN
      bmAttributes    2
    Transfer Type    Bulk
    Synch Type   None
    Usage Type   Data
      wMaxPacketSize 0x0400  1x 1024 bytes
      bInterval   0
      bMaxBurst  15
      Interface Descriptor:
    bLength 9
    bDescriptorType 4
    bInterfaceNumber    3
    bAlternateSetting   0
    bNumEndpoints   1
    bInterfaceClass   255 Vendor Specific Class
    bInterfaceSubClass  0 
    bInterfaceProtocol  0 
    iInterface  2 USRP B200
    Endpoint Descriptor:
      bLength 7
      bDescriptorType 5
      bEndpointAddress 0x04  EP 4 OUT
      bmAttributes    2
    Transfer Type    Bulk
    Synch Type   None
    Usage Type   Data
      wMaxPacketSize 0x0400  1x 1024 bytes
      bInterval   0
      bMaxBurst  15
      Interface Descriptor:
    bLength 9
    bDescriptorType 4
    bInterfaceNumber    4
    bAlternateSetting   0