Re: [USRP-users] Trouble getting custom RFNoC block to work with gnuradio 3.8 / uhd 4.0
Hi Jim, I have also been playing around with UHD-4.0, but mostly in testbenches. I've only built one image (for the N310) with one of my custom blocks. The errors you mentioned seem very strange. A few questions/comments: - can you send your "XXX_x310_rfnoc_image_core.yml" contents? - would it be helpful to run directly with UHD examples (removing gnuradio and gr-ettus from the equation)? You could try "rfnoc_rx_to_file" as-is where you specify on the command line the desired "block-id" to insert between the Radio and the rx_streamer. With the X310, the Radio rate might be too high with your custom "thru" block so perhaps you could modify the example (in-tree would be easiest) to automatically include the DDC and then insert the command line "block-id" optionally after the DDC. - In my testbenches, I have occasionally seend CHDR error messages like you mentioned and it seemed to solve them if I set "s_out_payload_tkeep=1". I didn't think this was needed if there was only 1 output port, but I seem to recall that this fixed my CHDR error issue for my 1 port block. Rob On Wed, Sep 30, 2020 at 10:39 AM Jim Palladino via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello, > > Several weeks ago I went through the tutorial for producing the example > "gain" block using rfnoc 3.8 and uhd 3.15. There were some bumps, but I did > get that working fine. For the past couple weeks, I've been working with > UHD 4.0 and the latest gr-ettus repo. > > I posted a question a week or two ago since I couldn't get UHD to > recognize my custom block, as UHD doesn't look for the block yml file in > the latest uhd 4.0 build. It just shows up as "0/Block#0" when probing. > Thanks to Wade F. for the quick response to that question and for > suggesting I either just continue OOT and use the "Block" name to interface > with it or build in-tree for now. I chose to stick with OOT and just use > the "Block" naming. > > I started with the gain example, but ended up simplifying it to literally > just using what was generated by rfnocmodtool (just a pass through block in > the FPGA) with no modifications. I made an rfnoc block, called "Block". I > built this for an E320, so I did have to modify the > "XXX_x310_rfnoc_image_core.yml" file accordingly. > > I built/installed everything, but this is what is happening. When I create > a gnuradio-companion "waveform", it does run, but I get the following > behavior: > > 1) If my setup is RFNoC_RX_Radio -> RFNoC_DDC_Block -> RFNoC_Block -> > RFNoC_RX_Streamer -> QT_GUI_Freq_Sink: > > Everything runs, but the following repeats over and over and the output > plot doesn't change: > > gr::log :WARN: rfnoc_rx_streamer0 - RFNoC Streamer block received error > ERROR_CODE_BAD_PACKET (Code: 0xf) > [ERROR] [STREAMER] The receive transport caught a value exception. > ValueError: Bad CHDR header or invalid packet length. > gr::log :WARN: rfnoc_rx_streamer0 - RFNoC Streamer block received error > ERROR_CODE_BAD_PACKET (Code: 0xf) > [ERROR] [STREAMER] The receive transport caught a value exception. > ValueError: Bad CHDR header or invalid packet length. > > > I put in some ILA probes and it seems that "ep4_to_xb_tready" is stuck > low. ep4 is the endpoint tied to the in and out of my custom "Block." I'm > guessing it didn't start low but a FIFO or something filled up somewhere. > > I should mention that if I use this same setup, but remove my custom > RFNoC_Block and directly connect the DDC to the RX_Streamer, everything > works fine. No errors, the spectrum looks fine, etc. > > > 2) If my setup is Constant_Source(set to 4+9j) -> RFNoC_TX_Streamer -> > RFNoC_Block -> RFNoC_RX_Streamer -> QT_GUI_Time_Sink: > > Everything runs and I do not have a problem with any gnuradio warnings. > Also, TReady is high the entire time. But, the output plot for I and Q sit > mostly constant stuck at "1", with non-periodic blips down to "0". I'm not > seeing the complex constant I set in gnuradio. If I look at the > payload_tdata in an ILA for my "Block" when tvalid is high and tready is > high, I see that the data is sitting at 0x7fff7fff except when TLAST is > high, tdata switches to 0xfffc7ff7. > > I'm at a bit of a loss trying to figure out what is happening. Could it be > that UHD is not interfacing properly to my block (given that UHD doesn't > look for my OOT yml file)? I did not change any block controller code or > anything else. Oh, and the user_register that is included as part of the > default design designated by rfnocmodtool seems to work fine. I can change > the register value in gnuradio and I can see it change appropriately via > and ILA. > > For reference, this is what I've been working with: > 1) UHD (v4.0.0.0 tag) > 2) gnuradio (3.8.2.0 tag) > 3) gr-ettus (maint-3.8-uhd4.0 branch) > > RFNoC is new to me, so any thoughts on what could be wrong or how I could > go about debugging this would be greatly appreciated. Hopefully, I'm just > missing something simple. > > Thanks, > Jim > > _
Re: [USRP-users] E320 SFP and RJ45 port problems/confusion
Hi Andrew, I'm definitely no expert on networking, but the one thing that caught my eye in the config below was the "netmask" for the enp30s0 port on the PC. Why is this 0.0.0.0 instead of 255.255.255.0? Rob On Wed, Sep 30, 2020 at 3:00 PM Andrews, Mark J. via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello, > > I am getting started with an Ettus E320 on Ubuntu and am having some > issues communicating over the streaming port that I have been unable to > solve. Based on what I'm seeing, I believe it has something to do with my > PCs network settings because I can communicate with one port at a time > without any problems. > My current setup is a PC with one Ethernet connection on the motherboard > and a separate WiFi PCIe card. I connected the E320's RJ45 port to my WiFi > router and the Ethernet connection is connected to the RJ45-to-SFP adapter > on the E320's SFP+ port. I am able to ssh into the E320 and run the > example programs on there, but when I try to run uhd_find_devices or > uhd_usrp_probe on my PC, there are issues. I am running UHD 3.15 on both > my PC and the E320. I will separate what I think is relevant information > with lines of equal signs for readability = > > = > > > The ifconfig -a info for my PC: > > > ifconfig -a > enp30s0: flags=4163 mtu 1500 > inet 192.168.10.1 netmask 0.0.0.0 broadcast 255.255.255.255 > inet6 fe80::93f1:af0c:251:4642 prefixlen 64 scopeid 0x20 > ether b0:6e:bf:c1:18:57 txqueuelen 1000 (Ethernet) > RX packets 53 bytes 5865 (5.8 KB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 180 bytes 26338 (26.3 KB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > device memory 0xf760-f761 > > lo: flags=73 mtu 65536 > inet 127.0.0.1 netmask 255.0.0.0 > inet6 ::1 prefixlen 128 scopeid 0x10 > loop txqueuelen 1000 (Local Loopback) > RX packets 2019 bytes 203709 (203.7 KB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 2019 bytes 203709 (203.7 KB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > wlp37s0: flags=4163 mtu 1500 > inet 192.168.1.20 netmask 255.255.255.0 broadcast 192.168.1.255 > inet6 fe80::44e4:2e51:6e8f:9d35 prefixlen 64 scopeid 0x20 > ether 60:f6:77:96:f6:8b txqueuelen 1000 (Ethernet) > RX packets 78 bytes 146464516 (146.4 MB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 51515 bytes 21064148 (21.0 MB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > === > > The ifconfig -a on the E320 is: > > > eth0 Link encap:Ethernet HWaddr 00:80:2F:28:B9:3E > inet addr:192.168.1.18 Bcast:192.168.1.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:10667 errors:0 dropped:114 overruns:0 frame:0 > TX packets:3142 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:14041114 (13.3 MiB) TX bytes:233123 (227.6 KiB) > Interrupt:27 Base address:0xb000 > > loLink encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > UP LOOPBACK RUNNING MTU:65536 Metric:1 > RX packets:23 errors:0 dropped:0 overruns:0 frame:0 > TX packets:23 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:2337 (2.2 KiB) TX bytes:2337 (2.2 KiB) > > sfp0 Link encap:Ethernet HWaddr 00:80:2F:28:B9:3F > inet addr:192.168.10.2 Bcast:192.168.10.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:38 errors:0 dropped:3 overruns:0 frame:0 > TX packets:51 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:4118 (4.0 KiB) TX bytes:5475 (5.3 KiB) > == > > If I try to ping the SFP port just using the 'ping' command, it does not > work > > ping -c 4 192.168.10.2 > PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data. > > --- 192.168.10.2 ping statistics --- > 4 packets transmitted, 0 received, 100% packet loss, time 3063ms > > == > > But if I force it to use the hardwaired interface, ping works fine. > > ping -I enp30s0 -c 4 192.168.10.2 > PING 192.168.10.2 (192.168.10.2) from 192.168.10.1 enp30s0: 56(84) bytes > of data. > 64 bytes from 192.168.10.2: icmp_seq=1 ttl=64 time=1.43 ms > 64 bytes from 192.168.10.2: icmp_seq=2 ttl=64 time=1.44 ms > 64 bytes from 192.168.10.2: icmp_seq=3 ttl=64 time=1.42 ms > 64 bytes from 192.168.10.2: icmp_seq=4 ttl=64 time=0.961 ms > > --- 192.168.10
Re: [USRP-users] E300 sg3 images with uhd 4.0
Ping? Anyone noticed sg3 units running slower with the uhd 4.0 image? Philip On 9/24/20 1:28 PM, Philip Balister via USRP-users wrote: > I booted an image from: > > https://files.ettus.com/binaries/cache/e3xx/meta-ettus-v4.0.0.0/ > > on a sg3 unit. The BogoMIPS display suggests the clocks are set to what > I expect for a sg1 unit though. I couldn't find any knobs in /sys or > /proc. I compared with the ancient release-4 image and that has the > number of BogoMIPS expected from that unit. > > Anyone at Ettus have any insite into how cpu clock speed is handled with > that image. Diffing the ps7 files didn't show many diffs in clock setup. > (And they looked like they came from a source besides vivado) > > Philip > > ___ > 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
Re: [USRP-users] Trouble getting custom RFNoC block to work with gnuradio 3.8 / uhd 4.0
Hi Rob,
Thanks very much for the response. I checked and by default, in the
rfnocmodtool generated verilog for my block, s_out_payload_tkeep is tied to
'1'. Also, the autogenerated testbench runs just fine (all tests pass). I
poked around at rfnoc_rx_to_file a while ago but didn't spend much time with
it. I'll follow your suggestion and work with that some more.
Also, the second flowgraph case I described in my original email works just
fine now. This is the case where my flowgraph looks like:
Constant_Source -> RFNoC_TX_Streamer -> RFNoC_Block -> RFNoC_RX_Streamer ->
QT_GUI_Time_Sink
Once I set the constant source to values between 0 and 1, I had no problems (it
was a mistake on my part initially setting the values greater than 1). I also
replaced the Constant_Source with a Signal_Source (cosine) and everything works
just fine -- no errors and the plot looks good. So, this works, but the setup
with RFNoC_RX_Radio as the source (followed by a DDC before my block) still
does not work -- I get the CHDR errors with tready stuck low.
Here is a copy of my Block_x310_rfnoc_image_core.yml. Even though the file name
has x310 in it, I'm building for the e320 (and it is building for the e320). I
wanted to change as little of what rfnocmodtool automatically generated as
possible.
### Start of Block_x310_rfnoc_image_core.yml
# General parameters
# -
schema: rfnoc_imagebuilder_args # Identifier for the schema used to
validate this file
copyright: '' # Copyright information used in file
headers
license: 'SPDX-License-Identifier: LGPL-3.0-or-later' # License information
used in file headers
version: 1.0# File version
rfnoc_version: 1.0 # RFNoC protocol version
chdr_width: 64 # Bit width of the CHDR bus for this
image
device: 'e320'
default_target: 'E320_XG'
# A list of all stream endpoints in design
#
stream_endpoints:
ep0: # Stream endpoint name
ctrl: True # Endpoint passes control traffic
data: True # Endpoint passes data traffic
buff_size: 32768# Ingress buffer size for data
ep1: # Stream endpoint name
ctrl: False # Endpoint passes control traffic
data: True # Endpoint passes data traffic
buff_size: 32768# Ingress buffer size for data
ep2: # Stream endpoint name
ctrl: False # Endpoint passes control traffic
data: True # Endpoint passes data traffic
buff_size: 8192 # Ingress buffer size for data
ep3: # Stream endpoint name
ctrl: False # Endpoint passes control traffic
data: True # Endpoint passes data traffic
buff_size: 8192 # Ingress buffer size for data
ep4: # Stream endpoint name
ctrl: False # Endpoint passes control traffic
data: True # Endpoint passes data traffic
buff_size: 32768# Ingress buffer size for data
# A list of all NoC blocks in design
# --
noc_blocks:
duc0: # NoC block name
block_desc: 'duc.yml'# Block device descriptor file
parameters:
NUM_PORTS: 2
ddc0:
block_desc: 'ddc.yml'
parameters:
NUM_PORTS: 2
radio0:
block_desc: 'radio_2x64.yml'
fifo0:
block_desc: 'axi_ram_fifo_2x64.yml'
parameters:
# These parameters correspond to the memory interface on the E320
MEM_ADDR_W: 31
MEM_DATA_W: 64
MEM_CLK_RATE: "300e6"
# Create two non-overlapping 32 MB buffers by default
FIFO_ADDR_BASE: "{31'h0200, 31'h}"
FIFO_ADDR_MASK: "{31'h01FF, 31'h01FF}"
Block0:
block_desc: 'Block.yml'
# A list of all static connections in design
# --
# Format: A list of connection maps (list of key-value pairs) with the
following keys
# - srcblk = Source block to connect
# - srcport = Port on the source block to connect
# - dstblk = Destination block to connect
# - dstport = Port on the destination block to connect
connections:
# ep0 to radio0(0) - RF0 TX
- { srcblk: ep0,srcport: out0, dstblk: duc0, dstport: in_0 }
- { srcblk: duc0, srcport: out_0, dstblk: radio0, dstport: in_0 }
# radio0(0) to ep0 - RF0 RX
- { srcblk: radio0, srcport: out_0, dstblk: ddc0, dstport: in_0 }
- { srcblk: ddc0, srcport: out_0, dstblk: ep0,dstport: in0 }
# ep1 to radio0(1) - RF1 TX
- { srcblk: ep1,srcport: out0, dstblk: duc0, dstport: in_1 }
- { srcblk: duc0, srcport: out_1, dstblk: radio0, dstport:
Re: [USRP-users] Trouble getting custom RFNoC block to work with gnuradio 3.8 / uhd 4.0
So, the only other thing I can think of for now relates to issues that I have had in connecting blocks that are not statically connected. For example, the newest default images for the X310 and N310 contain a "Replay" block where the Replay block is connected to/from an end-point in the same way as your example. In my UHD graph connection process, I never have an issue connecting "DUC=>Radio" because this is a static connection. But, I sometimes get a timeout error when connecting "Replay=>DUC" because this is a dynamic connection. I wonder if you are getting any connection error messages in the UHD log when you run from gnuradio. I'm guessing not, but wanted to mention it. In any case, if you run using "rfnoc_rx_to_file", you might be able to set the master clock rate low enough that you don't need a DDC to avoid overruns when using the graph "Radio30=>Block#0=>rx_streamer" (meaning that you might not need to modify the default example). I don't know a lot about the E320 so I'm not really sure what control you have over the master clock rate (and ultimately the radio output rate). On Thu, Oct 1, 2020 at 11:10 AM Jim Palladino via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi Rob, > > Thanks very much for the response. I checked and by default, in the > rfnocmodtool generated verilog for my block, s_out_payload_tkeep is tied to > '1'. Also, the autogenerated testbench runs just fine (all tests pass). I > poked around at rfnoc_rx_to_file a while ago but didn't spend much time > with it. I'll follow your suggestion and work with that some more. > > Also, the second flowgraph case I described in my original email works > just fine now. This is the case where my flowgraph looks like: > Constant_Source -> RFNoC_TX_Streamer -> RFNoC_Block -> RFNoC_RX_Streamer > -> QT_GUI_Time_Sink > > Once I set the constant source to values between 0 and 1, I had no > problems (it was a mistake on my part initially setting the values greater > than 1). I also replaced the Constant_Source with a Signal_Source (cosine) > and everything works just fine -- no errors and the plot looks good. So, > this works, but the setup with RFNoC_RX_Radio as the source (followed by a > DDC before my block) still does not work -- I get the CHDR errors with > tready stuck low. > > Here is a copy of my Block_x310_rfnoc_image_core.yml. Even though the file > name has x310 in it, I'm building for the e320 (and it is building for the > e320). I wanted to change as little of what rfnocmodtool automatically > generated as possible. > > ### Start of Block_x310_rfnoc_image_core.yml > > # General parameters > # - > schema: rfnoc_imagebuilder_args # Identifier for the schema used > to validate this file > copyright: '' # Copyright information used in > file headers > license: 'SPDX-License-Identifier: LGPL-3.0-or-later' # License > information used in file headers > version: 1.0# File version > rfnoc_version: 1.0 # RFNoC protocol version > chdr_width: 64 # Bit width of the CHDR bus for > this image > device: 'e320' > default_target: 'E320_XG' > > # A list of all stream endpoints in design > # > stream_endpoints: > ep0: # Stream endpoint name > ctrl: True # Endpoint passes control traffic > data: True # Endpoint passes data traffic > buff_size: 32768# Ingress buffer size for data > ep1: # Stream endpoint name > ctrl: False # Endpoint passes control traffic > data: True # Endpoint passes data traffic > buff_size: 32768# Ingress buffer size for data > ep2: # Stream endpoint name > ctrl: False # Endpoint passes control traffic > data: True # Endpoint passes data traffic > buff_size: 8192 # Ingress buffer size for data > ep3: # Stream endpoint name > ctrl: False # Endpoint passes control traffic > data: True # Endpoint passes data traffic > buff_size: 8192 # Ingress buffer size for data > ep4: # Stream endpoint name > ctrl: False # Endpoint passes control traffic > data: True # Endpoint passes data traffic > buff_size: 32768# Ingress buffer size for data > > # A list of all NoC blocks in design > # -- > noc_blocks: > duc0: # NoC block name > block_desc: 'duc.yml'# Block device descriptor file > parameters: > NUM_PORTS: 2 > ddc0: > block_desc: 'ddc.yml' > parameters: > NUM_PORTS: 2 > radio0: > block_desc: 'rad
[USRP-users] Maximize MIMO Collection with X310
Hello, I am looking to maximize my MIMO collection utilizing a single X310 radio with either 2 TwinRxs installed or 2 UBX-160s installed. In some cases, I have a GPSDO at my disposal. For tasking the radios, I am using python code which creates and runs a GNURADIO Flowgraph. Ultimately, I would like to know what to set the following parameter to in order to have the optimal collection. In the instances I have a GPSDO installed in the X310, I would guess I should choose the GPSDO option, but what if I don't? sync (options are: don't sync, unknown pps, PC Clock) clock source (options are: Default, Internal, External, MIMO Cable, O/B GPSDO) time source (options are: Default, External, MIMO Cable, O/B GPSDO) Thanks, Mark ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Maximize MIMO Collection with X310
On 10/01/2020 12:28 PM, Mark Koenig via USRP-users wrote: Hello, I am looking to maximize my MIMO collection utilizing a single X310 radio with either 2 TwinRxs installed or 2 UBX-160s installed. In some cases, I have a GPSDO at my disposal. For tasking the radios, I am using python code which creates and runs a GNURADIO Flowgraph. Ultimately, I would like to know what to set the following parameter to in order to have the optimal collection. In the instances I have a GPSDO installed in the X310, I would guess I should choose the GPSDO option, but what if I don't? sync (options are: don't sync, unknown pps, PC Clock) clock source (options are: Default, Internal, External, MIMO Cable, O/B GPSDO) time source (options are: Default, External, MIMO Cable, O/B GPSDO) Thanks, Mark You'll have to define what you mean by "optimal collection". If you're just using a single X310 you don't need to worry so much about synchronization to external sources--just use the internal/Default sources, and perhaps choose "unknown PPS" for the sync option. If you are using TwinRX and want really-good phase-coherence you should explore the LO-sharing functions, which I don't think are exposed in GRC. You might want to read the following ap-note on TwinRX here: https://kb.ettus.com/Direction_Finding_with_the_USRP%E2%84%A2_X-Series_and_TwinRX%E2%84%A2 ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] E320 SFP and RJ45 port problems/confusion
Hi Rob, Good catch! When I go to the Network Settings under IPv4, I have it set to manual with the static IP 192.168.10.2 and the netmask to 255.255.255.0, but the ifconfig shows that the netmask is still 0.0.0.0.I set it to 255.255.255.0 with a sudo ifconfig command, and after a restart I can now run uhd_usrp_probe! I still get some warnings that I might have to take a closer look at, but this is at least a step past the logjam, thank you! Mark From: Rob Kossler Sent: Thursday, October 1, 2020 10:25 AM To: Andrews, Mark J. Cc: usrp-users@lists.ettus.com Subject: Re: [USRP-users] E320 SFP and RJ45 port problems/confusion Hi Andrew, I'm definitely no expert on networking, but the one thing that caught my eye in the config below was the "netmask" for the enp30s0 port on the PC. Why is this 0.0.0.0 instead of 255.255.255.0? Rob On Wed, Sep 30, 2020 at 3:00 PM Andrews, Mark J. via USRP-users mailto:usrp-users@lists.ettus.com>> wrote: Hello, I am getting started with an Ettus E320 on Ubuntu and am having some issues communicating over the streaming port that I have been unable to solve. Based on what I'm seeing, I believe it has something to do with my PCs network settings because I can communicate with one port at a time without any problems. My current setup is a PC with one Ethernet connection on the motherboard and a separate WiFi PCIe card. I connected the E320's RJ45 port to my WiFi router and the Ethernet connection is connected to the RJ45-to-SFP adapter on the E320's SFP+ port. I am able to ssh into the E320 and run the example programs on there, but when I try to run uhd_find_devices or uhd_usrp_probe on my PC, there are issues. I am running UHD 3.15 on both my PC and the E320. I will separate what I think is relevant information with lines of equal signs for readability = = The ifconfig -a info for my PC: ifconfig -a enp30s0: flags=4163 mtu 1500 inet 192.168.10.1 netmask 0.0.0.0 broadcast 255.255.255.255 inet6 fe80::93f1:af0c:251:4642 prefixlen 64 scopeid 0x20 ether b0:6e:bf:c1:18:57 txqueuelen 1000 (Ethernet) RX packets 53 bytes 5865 (5.8 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 180 bytes 26338 (26.3 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device memory 0xf760-f761 lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 1000 (Local Loopback) RX packets 2019 bytes 203709 (203.7 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 2019 bytes 203709 (203.7 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 wlp37s0: flags=4163 mtu 1500 inet 192.168.1.20 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::44e4:2e51:6e8f:9d35 prefixlen 64 scopeid 0x20 ether 60:f6:77:96:f6:8b txqueuelen 1000 (Ethernet) RX packets 78 bytes 146464516 (146.4 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 51515 bytes 21064148 (21.0 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 === The ifconfig -a on the E320 is: eth0 Link encap:Ethernet HWaddr 00:80:2F:28:B9:3E inet addr:192.168.1.18 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:10667 errors:0 dropped:114 overruns:0 frame:0 TX packets:3142 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:14041114 (13.3 MiB) TX bytes:233123 (227.6 KiB) Interrupt:27 Base address:0xb000 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:23 errors:0 dropped:0 overruns:0 frame:0 TX packets:23 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2337 (2.2 KiB) TX bytes:2337 (2.2 KiB) sfp0 Link encap:Ethernet HWaddr 00:80:2F:28:B9:3F inet addr:192.168.10.2 Bcast:192.168.10.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:38 errors:0 dropped:3 overruns:0 frame:0 TX packets:51 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4118 (4.0 KiB) TX bytes:5475 (5.3 KiB) == If I try to ping the SFP port just using the 'ping' command, it does not work ping -c 4 192.168.10.2 PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data. --- 192.168.10.2 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 306
[USRP-users] Loading B210 firmware takes forever (i.e. hang) after installing NI-USRP driver
I am running on the latest release of UHD (3.15.0.0) from github. Using Windows 10, installed with the UHD binary installer. Typically, running ./uhd_usrp_probe takes only a few moments for the firmware to be loaded onto the USRP. However, recently I have installed labview runtime and NI-USRP and after that, I am no longer able to use UHD to communicate to the USRP. Running uhd_usrp_probe or any of the uhd_xx_xx commands will result in an endless wait for 'Loading firmware image'. I suspect that installing NI-USRP has resulted in a clash with my UHD. Anyone have any suggestions? ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Benchmarking RFNoC Blocks
Hi everyone, I wanted to know if there is a way to benchmark the performance of different RFNoC blocks? Basically, I want to compare the performance (time taken) by the RFNoC blocks as compared to their counterparts in GNURadio. Also, what factors should I keep in mind that might affect the benchmarking results, for example, streaming samples from blocks to sending as vectors (GNURADIO) or the mtu size, etc. Thanks, Jayant ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
