Let’s do some quick math, shall we? 5msps with 16-bit complex == 160Mbit/second 1.25msps with 16-bit complex samples == an additional 40mbit-second
Unless you have super reliable 1Gig wireless infrastructure, this just isn’t going to work. Sent from my iPhone > On Jan 28, 2020, at 6:23 PM, Austin Adam via USRP-users > <usrp-users@lists.ettus.com> wrote: > > Hey Nate, > Thanks for the quick response as always! I tried editing those files in the > past, but I remember having issues because they were locked or I wasn’t able > to actually save any changes that I made. Is there a way to do it directly > via the jtag and using the screen command to speak with the N310? > > Also, unfortunately for the current project I am working on, we really need > to have a wireless connection to the USRPs via the router. I am sure there is > some way to make it work because we can still get data that looks good, it > just starts to get clunky after a few seconds of streaming. > > >>> On Jan 28, 2020, at 3:07 PM, Nate Temple <nate.tem...@ettus.com> wrote: >>> >> >> Hi Austin, >> >> The MTUs on your host and N310 must match. You should modify the systemd >> configuration on the N310 are restart the whole device or restart >> systemd-networkd >> >> https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide#Updating_the_Network_Configurations >> >> It is not recommended to stream over a wireless connection as the additional >> delay will cause flow control errors. It is also generally recommended to >> not have a switch in line as some switches can reorder packets. You should >> directly connect to the USRP for the streaming interfaces. On the N3xx, it's >> fine to access the RJ45 management port via a switch. >> >> Regards, >> Nate Temple >> >> >> >>> On Tue, Jan 28, 2020 at 2:52 PM Austin Adam via USRP-users >>> <usrp-users@lists.ettus.com> wrote: >>> Hi everyone, >>> I have a very basic GNU script with just a USRP block and a time sink that >>> when I run, there are tons of streaming errors with the tx and rx. In GNU, >>> the console is being filled with 'D's and the console for the N210 is >>> getting filled with 'U's and 'S's. >>> >>> My setup is just a USRP N210 connected to the RX LO ports of the N310. I am >>> sending the following command to the N210: >>> >>> "sudo '/home/austin/workarea-uhd/uhd/host/build/examples/tx_waveforms' >>> --args "addr=192.168.10.15,type=usrp2" --freq 3.90000e9 --ant "TX/RX" >>> --subdev "A:0" --channels 0 --rate 1.25e6 --gain 29.5" >>> >>> The USRPs are connected to a router via cat 5e cables, and then my laptop >>> is connected to the router via wifi. Something I noticed is that when I >>> connect to the router via ethernet to my laptop, I don't get any of the >>> performance issues. It seems to only happen over the wifi. >>> >>> When I run ifconfig on my laptop, my MTU is set to 1500, and on the USRP >>> N310 the MTU on the sfp0 port that we are using is 8000. I wasn't able to >>> change the MTU on the N310 because it said the device was in use, but those >>> values seem to work fine over ethernet so I didn't look too much into it. >>> >>> The sample rate on my GNU script is set to 5M for now, and lowering it does >>> seem to reduce the amount of 'D's that I get, but also negatively affects >>> our data. >>> >>> Lastly, here is some output from the N210 that shows the error: >>> >>> austin@Austin-Blade:~$ sudo >>> '/home/austin/workarea-uhd/uhd/host/build/examples/tx_waveforms' --args >>> "addr=192.168.10.15,type=usrp2" --freq 3.90000e9 --ant "TX/RX" --subdev >>> "A:0" --channels 0 --rate 1.25e6 --gain 29.5 >>> >>> Creating the usrp device with: addr=192.168.10.15,type=usrp2... >>> [INFO] [UHD] linux; GNU C++ version 8.3.0; Boost_106700; >>> UHD_3.14.0.HEAD-0-g6875d061 >>> [INFO] [USRP2] Opening a USRP2/N-Series device... >>> [INFO] [USRP2] Current recv frame size: 1472 bytes >>> [INFO] [USRP2] Current send frame size: 1472 bytes >>> Using Device: Single USRP: >>> Device: USRP2 / N-Series Device >>> Mboard 0: N210r4 >>> RX Channel: 0 >>> RX DSP: 0 >>> RX Dboard: A >>> RX Subdev: SBXv3 RX >>> TX Channel: 0 >>> TX DSP: 0 >>> TX Dboard: A >>> TX Subdev: SBXv3 TX >>> >>> Setting TX Rate: 1.250000 Msps... >>> Actual TX Rate: 1.250000 Msps... >>> >>> Setting TX Freq: 3900.000000 MHz... >>> Setting TX LO Offset: 0.000000 MHz... >>> Actual TX Freq: 3900.000000 MHz... >>> >>> Setting TX Gain: 29.500000 dB... >>> Actual TX Gain: 29.500000 dB... >>> >>> Setting device timestamp to 0... >>> Checking TX: LO: locked ... >>> Press Ctrl + C to stop streaming... >>> UUUSUUUU[ERROR] [USRP2] Control packet attempt 0, sequence number 470: >>> RuntimeError: no control response, possible packet loss >>> UUUSUUUUSUUUUUU^C >>> Done! >>> >>> I appreciate any help that anyone has to offer! >>> >>> Best, >>> Austin >>> _______________________________________________ >>> 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 mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
