Hi Marcus, We have been using the same adapter since even before we sent out the device, and it always worked without fail. It makes sense what you are saying, but because we had it working before, I feel like the issue is deeper than that.
I cannot ping the device in the current state. If I don't have an ethernet port on my laptop, then what do you suggest as an alternative for the ethernet to usb3 adapter? I have a USB-C port, maybe that is better? Thank you, Austin On Fri, Sep 6, 2019 at 4:28 PM Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com> wrote: > On 09/06/2019 07:22 PM, Austin Adam via USRP-users wrote: > > Update: > I updated my host computer to UHD version 3.14.1.0 and then afterwards, > wrote that same version to the SD card. When I put the SD card back in the > USRP and ran the 'uhd_find_devices' command, it actually showed up! > Finally! But then, upon restarting the USRP by running "shutdown -h now" > via the serial console, and then pressing the power button to start it back > up, it was again unable to be read via 'uhd_find_devices'. > > I don't know if this helps or not, but I am using an ethernet to usb > adapter to connect from the sfp0 port to my laptop, which I know is not > recommended, but it worked before this issue started so I know that is not > contributing. However, I do notice that the little green light on the > adapter is not lighting up when connected to the USRP. When it worked just > a moment ago, the green light (on the adapter) was in fact on, and that's > when we got excited. However, after a reboot, the light (on the adapter) is > not on and I am unable to connect. Maybe that info will help diagnose the > issue further. Just for clarification, the green light above the SFP0 port > is green and has been on the whole time. > > So frustrating though that it worked for a second and now it doesn't... > but I feel like we are close! > > Note that only USB*3* to 1GiGe ethernet adapters have even a *hope* of > working properly in this application. > > When it's in this state, can you even *ping* the device? > > This sounds like a PHY-layer issue, if the link light on your USB adapter > isn't coming on. > > > > On Fri, Sep 6, 2019 at 11:04 AM Austin Adam <austinada...@gmail.com> > wrote: > >> I am assuming that when I run 'uhd_find_devices' it shows the current >> version in the output, so if that is the case, then my host is on version >> *UHD_3.14.0.HEAD-0-g6875d061*, and the USRP is on version >> *UHD_3.14.0.0-0-g6875d061. >> *Just based on the output here: >> >> >> *root@ni-n3xx-3177E63:~# uhd_find_devices [INFO] [UHD] linux; GNU C++ >> version 7.3.0; Boost_106600; UHD_3.14.0.0-0-g6875d061* >> >> >> >> *admin@PC:~$ uhd_find_devices [INFO] [UHD] linux; GNU C++ version 8.3.0; >> Boost_106700; UHD_3.14.0.HEAD-0-g6875d061 No UHD Devices Found* >> >> Is there a alternative way to confirm the version on each one? >> >> I can try to update my host computer to 3.14.1.0 however and see if that >> works. Because when I follow the instructions for the SD card, I don't >> necessarily choose a version. It just seems to update to whatever the >> current version is. So maybe it is on 3.14.1.0. I'll try that and get back >> to you. >> >> On Fri, Sep 6, 2019 at 7:42 AM Robin Coxe <c...@close-haul.com> wrote: >> >>> What version of UHD do you have installed on your host PC? If there is >>> a version mismatch between the host and the N310, you can have connectivity >>> issues. >>> >>> Another thing to try would be to follow the instructions in the N310 >>> Getting Started guide to upgrade the SD card to the latest filesystem >>> release (UHD v3.14.1.0, if memory serves) and then update UHD on your host >>> PC. >>> >>> RMA replaces the SD card with the latest one on the BOM, which in May >>> when I left NI was v.3.13-something. >>> >>> >>> ------------------------------ >>> *From:* USRP-users <usrp-users-boun...@lists.ettus.com> on behalf of >>> Austin Adam via USRP-users <usrp-users@lists.ettus.com> >>> *Sent:* Thursday, September 5, 2019 10:41 PM >>> *To:* Marcus D. Leech >>> *Cc:* usrp-users@lists.ettus.com >>> *Subject:* Re: [USRP-users] USRP N310 Cannot ping or connect >>> >>> Hi there, >>> Thank you for the response. I am indeed connected to the SFP0 port to a >>> 1gigE connection. Everything was working fine before I sent out the USRP >>> for repairs, so I don’t think it’s a cable or connection issue. >>> >>> I appreciate you looking into the issue further, hopefully we can figure >>> out! >>> >>> Regards, >>> Austin >>> >>> On Sep 5, 2019, at 8:01 PM, Marcus D. Leech via USRP-users < >>> usrp-users@lists.ettus.com> wrote: >>> >>> On 09/05/2019 10:28 PM, Austin Adam via USRP-users wrote: >>> >>> I recently had my USRP N310 sent out for repairs to fix one of the SMA >>> connectors, and when it came back, there was a new SD card in the slot. >>> When I turned it on after getting it back, I was unable to connect to it >>> via 'uhd_find_devices'. I figured it was something with the SD card, so I >>> eventually decided to rewrite the whole thing, in case it needed an update. >>> >>> That still did not fix the issue, and after trying just about >>> everything, and following every possible tutorial on the ettus docs, and >>> checking the forums, I have decided to ask you guys for help. >>> >>> Below you can find all the information about the UHD versions and the >>> ifconfigs... hopefully that is enough to spark some ideas! >>> >>> The USRP can find itself on localhost as you can see here: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> *root@ni-n3xx-3177E63:~# uhd_find_devices [INFO] [UHD] linux; GNU C++ >>> version 7.3.0; Boost_106600; UHD_3.14.0.0-0-g6875d061 >>> -------------------------------------------------- -- UHD Device 0 >>> -------------------------------------------------- Device Address: >>> serial: 3177E63 claimed: False mgmt_addr: 127.0.0.1 product: >>> n310 type: n3xx* >>> >>> But when I run the command from the host machine, this is what I get: >>> >>> >>> >>> * admin@PC:~$ uhd_find_devices [INFO] [UHD] linux; GNU C++ version >>> 8.3.0; Boost_106700; UHD_3.14.0.HEAD-0-g6875d061 No UHD Devices Found* >>> >>> *Here is ifconfig from the USRP:* >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> *root@ni-n3xx-3177E63:~# ifconfig eth0 Link encap:Ethernet HWaddr >>> 00:80:2F:24:01:14 UP BROADCAST MULTICAST MTU:1500 Metric:1 >>> RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX >>> packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 >>> txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) >>> Interrupt:27 Base address:0xb000 lo Link encap:Local Loopback >>> inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING >>> MTU:65536 Metric:1 RX packets:89 errors:0 dropped:0 overruns:0 >>> frame:0 TX packets:89 errors:0 dropped:0 overruns:0 carrier:0 >>> collisions:0 txqueuelen:1000 RX bytes:7480 (7.3 KiB) TX >>> bytes:7480 (7.3 KiB) sfp0 Link encap:Ethernet HWaddr >>> 00:80:2F:24:01:15 inet addr:192.168.10.2 Bcast:192.168.10.255 >>> Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:8000 >>> Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 >>> TX packets:14 errors:0 dropped:0 overruns:0 carrier:0 >>> collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:2577 >>> (2.5 KiB) sfp1 Link encap:Ethernet HWaddr 00:80:2F:24:01:16 >>> UP BROADCAST MULTICAST MTU:8000 Metric:1 RX packets:0 errors:0 >>> dropped:0 overruns:0 frame:0 TX packets:1 errors:0 dropped:0 >>> overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX >>> bytes:0 (0.0 B) TX bytes:62 (62.0 B)* >>> >>> >>> >>> *And here is ifconfig from the host machine: * >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> *ugikie@Austin-Blade:~$ ifconfig enx70886b87f283: >>> flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 8000 inet >>> 192.168.10.1 netmask 255.255.255.0 broadcast 192.168.10.255 inet6 >>> fe80::73b:c879:60cf:8127 prefixlen 64 scopeid 0x20<link> ether >>> 70:88:6b:87:f2:83 txqueuelen 1000 (Ethernet) RX packets 0 bytes >>> 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX >>> packets 46 bytes 4966 (4.9 KB) TX errors 0 dropped 0 overruns 0 >>> carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 >>> inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 >>> scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) >>> RX packets 5037 bytes 466961 (466.9 KB) RX errors 0 dropped 0 >>> overruns 0 frame 0 TX packets 5037 bytes 466961 (466.9 KB) >>> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 wlp59s0: >>> flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet >>> 172.28.229.114 netmask 255.255.240.0 broadcast 172.28.239.255 >>> inet6 fe80::c9b4:5623:34c4:ae56 prefixlen 64 scopeid 0x20<link> >>> ether 9c:b6:d0:18:53:3f txqueuelen 1000 (Ethernet) RX packets >>> 110339 bytes 123997000 (123.9 MB) RX errors 0 dropped 0 overruns >>> 0 frame 0 TX packets 47191 bytes 11048840 (11.0 MB) TX >>> errors 0 dropped 0 overruns 0 carrier 0 collisions 0* >>> >>> I tried broadcast pinging 192.168.10.255 and 192.168.10.2 from the host >>> but didn't get a response from the N310 or anything for that matter. >>> >>> I hope someone out there can help me out! Thank you in advance :) >>> >>> Best, >>> Austin >>> >>> >>> So, easy stuff first--you are plugged into the SFP0 port on the N310, >>> and not one of the two others? >>> >>> >>> >>> _______________________________________________ >>> USRP-users mailing list >>> USRP-users@lists.ettus.com >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> >>> > > _______________________________________________ > USRP-users mailing > listUSRP-users@lists.ettus.comhttp://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 mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
