Laptop-1 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (4) I219-LM (rev 21) Laptop-2 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (Lewisville) (rev 04)
On both the laptop the problem persists. Regards Sumit On Wed, Jul 17, 2019 at 8:19 PM Sumit Kumar <cog...@gmail.com> wrote: > Hi Nate, I left office, so will be able to tell you tomorrow. It happened > in two laptops. One I remember is a brand new Dell latitude 5490. I will > let you know the details tomorrow. > Regards > Sumit > > On Wed, Jul 17, 2019 at 6:27 PM Nate Temple <nate.tem...@ettus.com> wrote: > >> Hi Sumit, >> >> What ethernet controller do you have in your laptop? >> >> lspci | grep Ethernet >> >> Regards, >> Nate Temple >> >> On Wed, Jul 17, 2019 at 9:16 AM Sumit Kumar <cog...@gmail.com> wrote: >> >>> Hi Nate, >>> >>> john@john-Precision-M4600:~/pybombs/src/uhd/host/build/examples$ sudo >>> ./benchmark_rate --rx_rate 10e6 --tx_rate 10e6 --duration 600 >>> >>> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; >>> UHD_3.15.0.git-1-gf83faf28 >>> [00:00:00.000024] Creating the usrp device with: ... >>> [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: N200r4 >>> 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 >>> >>> [00:00:01.788223] Setting device timestamp to 0... >>> [00:00:01.788784] Testing receive rate 10.000000 Msps on 1 channels >>> [00:00:01.799861] Testing transmit rate 10.000000 Msps on 1 channels >>> SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSUSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS[00:00:01.905237] >>> Tx timeouts: 1 >>> [00:10:01.932746] Benchmark complete. >>> >>> >>> Benchmark rate summary: >>> Num received samples: 6000102237 >>> Num dropped samples: 0 >>> Num overruns detected: 0 >>> Num transmitted samples: 258456 >>> Num sequence errors (Tx): 624 >>> Num sequence errors (Rx): 0 >>> Num underruns detected: 1 >>> Num late commands: 0 >>> Num timeouts (Tx): 5993 >>> >>> On Wed, Jul 17, 2019 at 5:36 PM Nate Temple <nate.tem...@ettus.com> >>> wrote: >>> >>>> Hi Sumit, >>>> >>>> Actually, I had a typo in the command, that previous benchmark_rate >>>> command only tested RX, can you try passing the --tx_rate param and see if >>>> it will produce sequence errors using benchmark_rate >>>> >>>> ./benchmark_rate --tx_rate 10e6 --duration 600 >>>> >>>> Regards, >>>> Nate Temple >>>> >>>> On Wed, Jul 17, 2019 at 8:27 AM Sumit Kumar <cog...@gmail.com> wrote: >>>> >>>>> Ok I will do this.. but why the transmission with other USRP is >>>>> working fine ? >>>>> >>>>> On Wed, Jul 17, 2019 at 5:22 PM Nate Temple <nate.tem...@ettus.com> >>>>> wrote: >>>>> >>>>>> Hi Sumit, >>>>>> >>>>>> So it looks like you have multiple version of UHD installed: >>>>>> >>>>>> john@john-Precision-M4600:~/pybombs/src/gnuradio/gr-digital/examples/narrowband$ >>>>>> sudo ./benchmark_tx.py -f 2.45G -S 10 >>>>>> linux; GNU C++ version 5.3.1 20151219; Boost_105800; >>>>>> UHD_003.009.002-0-unknown >>>>>> >>>>>> >>>>>> john@john-Precision-M4600:~/pybombs/src/uhd/host/build/examples$ >>>>>> sudo ./benchmark_rate --rx_rate 10e6 --duration 600 >>>>>> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; >>>>>> UHD_3.15.0.git-1-gf83faf28 >>>>>> >>>>>> >>>>>> I would recommend to stick to a single UHD version and use the latest >>>>>> stable tagged released (currently 3.14.1.0) you will need to modify the >>>>>> pybombs recipe to use the correct git tag (v3.14.1.0). The 'master' >>>>>> branch >>>>>> can be unstable at times. >>>>>> >>>>>> Also, if you have a FPGA image of say 3.15.x.x flashed on the N210 >>>>>> and then revert back to using 3.9.2, and UHD does not catch the mismatch, >>>>>> it will likely cause flow control errors and unstable performance. >>>>>> >>>>>> The gr-digital/examples/narrowband/benchmark_tx.py example is also >>>>>> buggy, and is being removed from GR 3.8. Using the UHD benchmark_rate >>>>>> utility will test the hardware with a limited scope. >>>>>> >>>>>> Regards, >>>>>> Nate Temple >>>>>> >>>>>> >>>>>> On Wed, Jul 17, 2019 at 8:10 AM Sumit Kumar <cog...@gmail.com> wrote: >>>>>> >>>>>>> Sorry, here it is. >>>>>>> >>>>>>> Benchmark rate summary: >>>>>>> Num received samples: 5999986436 >>>>>>> Num dropped samples: 0 >>>>>>> Num overruns detected: 0 >>>>>>> Num transmitted samples: 0 >>>>>>> Num sequence errors (Tx): 0 >>>>>>> Num sequence errors (Rx): 0 >>>>>>> Num underruns detected: 0 >>>>>>> Num late commands: 0 >>>>>>> Num timeouts (Tx): 0 >>>>>>> Num timeouts (Rx): 0 >>>>>>> >>>>>>> >>>>>>> On Wed, Jul 17, 2019 at 5:08 PM Nate Temple <nate.tem...@ettus.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Sumit, >>>>>>>> >>>>>>>> It will take 10 minutes for that run to complete. Does it produce a >>>>>>>> report at the end of the run? >>>>>>>> >>>>>>>> Regards, >>>>>>>> Nate Temple >>>>>>>> >>>>>>>> On Wed, Jul 17, 2019 at 8:06 AM Sumit Kumar <cog...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Nate, >>>>>>>>> No there are not. At the end of the last line, cursor keeps >>>>>>>>> blinking, no sequence errors. >>>>>>>>> >>>>>>>>> john@john-Precision-M4600:~/pybombs/src/uhd/host/build/examples$ >>>>>>>>> sudo ./benchmark_rate --rx_rate 10e6 --duration 600 >>>>>>>>> >>>>>>>>> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; >>>>>>>>> UHD_3.15.0.git-1-gf83faf28 >>>>>>>>> [00:00:00.000024] Creating the usrp device with: ... >>>>>>>>> [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: N200r4 >>>>>>>>> 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 >>>>>>>>> >>>>>>>>> [00:00:01.796895] Setting device timestamp to 0... >>>>>>>>> [00:00:01.797430] Testing receive rate 10.000000 Msps on 1 channels >>>>>>>>> >>>>>>>>> On Wed, Jul 17, 2019 at 4:39 PM Nate Temple <nate.tem...@ettus.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi Sumit, >>>>>>>>>> >>>>>>>>>> If you run benchmark_rate for an extend period of time, do you >>>>>>>>>> see any sequence errors? >>>>>>>>>> >>>>>>>>>> /usr/local/lib/uhd/examples/benchmark_rate --rx_rate 10e6 >>>>>>>>>> --duration 600 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Nate Temple >>>>>>>>>> >>>>>>>>>> On Wed, Jul 17, 2019 at 7:34 AM Sumit Kumar <cog...@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Nate, >>>>>>>>>>> Yes I addressed the first 2 points you mentioned. >>>>>>>>>>> >>>>>>>>>>> john@john-Precision-M4600:~/pybombs/src/gnuradio/gr-digital/examples/narrowband$ >>>>>>>>>>> sudo ./benchmark_tx.py -f 2.45G -S 10 >>>>>>>>>>> linux; GNU C++ version 5.3.1 20151219; Boost_105800; >>>>>>>>>>> UHD_003.009.002-0-unknown >>>>>>>>>>> >>>>>>>>>>> Using Volk machine: avx_64_mmx_orc >>>>>>>>>>> -- Opening a USRP2/N-Series device... >>>>>>>>>>> -- Current recv frame size: 1472 bytes >>>>>>>>>>> -- Current send frame size: 1472 bytes >>>>>>>>>>> >>>>>>>>>>> No gain specified. >>>>>>>>>>> Setting gain to 15.750000 (from [0.000000, 31.500000]) >>>>>>>>>>> >>>>>>>>>>> ..............................................................................................SS.SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS.SSSS..S......SS.S......SS.....S....S...S.S.......S....S........^C >>>>>>>>>>> >>>>>>>>>>> I am using ./benchmark_tx.py located >>>>>>>>>>> in gnuradio/gr-digital/examples/narrowband >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Jul 17, 2019 at 4:25 PM Nate Temple < >>>>>>>>>>> nate.tem...@ettus.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Sumit, >>>>>>>>>>>> >>>>>>>>>>>> A couple things to address: >>>>>>>>>>>> >>>>>>>>>>>> 1) Enable Thread priority scheduling on your host >>>>>>>>>>>> >>>>>>>>>>>> Note it is throwing a warning in the output: "[WARNING] [UHD] >>>>>>>>>>>> Unable to set the thread priority. Performance may be negatively >>>>>>>>>>>> affected." >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux#Thread_priority_scheduling >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2) Adjust your network buffers >>>>>>>>>>>> >>>>>>>>>>>> " >>>>>>>>>>>> [WARNING] [UDP] The send buffer could not be resized >>>>>>>>>>>> sufficiently. >>>>>>>>>>>> Target sock buff size: 2500000 bytes. >>>>>>>>>>>> Actual sock buff size: 1048576 bytes. >>>>>>>>>>>> See the transport application notes on buffer resizing. >>>>>>>>>>>> Please run: sudo sysctl -w net.core.wmem_max=2500000 >>>>>>>>>>>> [WARNING] [UDP] The send buffer could not be resized >>>>>>>>>>>> sufficiently. >>>>>>>>>>>> Target sock buff size: 2500000 bytes. >>>>>>>>>>>> Actual sock buff size: 1048576 bytes. >>>>>>>>>>>> See the transport application notes on buffer resizing. >>>>>>>>>>>> Please run: sudo sysctl -w net.core.wmem_max=2500000 >>>>>>>>>>>> " >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks#N2xx >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> What is the command you're using to transmit(which utility and >>>>>>>>>>>> args?) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Nate Temple >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Jul 17, 2019 at 7:06 AM Sumit Kumar via USRP-users < >>>>>>>>>>>> usrp-users@lists.ettus.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Following is what I am getting after the command you asked to >>>>>>>>>>>>> run. The 192.168.10.5 gives SSSSSSS. >>>>>>>>>>>>> >>>>>>>>>>>>> john@john-Precision-M4600:~/pybombs/src/uhd/host/build/utils$ >>>>>>>>>>>>> ./usrp_burn_mb_eeprom --read-all --args "addr=192.168.10.5" >>>>>>>>>>>>> Creating USRP device from address: addr=192.168.10.5 >>>>>>>>>>>>> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; >>>>>>>>>>>>> Boost_105800; UHD_3.15.0.git-1-gf83faf28 >>>>>>>>>>>>> [INFO] [USRP2] Opening a USRP2/N-Series device... >>>>>>>>>>>>> [INFO] [USRP2] Current recv frame size: 1472 bytes >>>>>>>>>>>>> [INFO] [USRP2] Current send frame size: 1472 bytes >>>>>>>>>>>>> [WARNING] [UDP] The send buffer could not be resized >>>>>>>>>>>>> sufficiently. >>>>>>>>>>>>> Target sock buff size: 2500000 bytes. >>>>>>>>>>>>> Actual sock buff size: 1048576 bytes. >>>>>>>>>>>>> See the transport application notes on buffer resizing. >>>>>>>>>>>>> Please run: sudo sysctl -w net.core.wmem_max=2500000 >>>>>>>>>>>>> [WARNING] [UDP] The send buffer could not be resized >>>>>>>>>>>>> sufficiently. >>>>>>>>>>>>> Target sock buff size: 2500000 bytes. >>>>>>>>>>>>> Actual sock buff size: 1048576 bytes. >>>>>>>>>>>>> See the transport application notes on buffer resizing. >>>>>>>>>>>>> Please run: sudo sysctl -w net.core.wmem_max=2500000 >>>>>>>>>>>>> [WARNING] [UDP] The send buffer could not be resized >>>>>>>>>>>>> sufficiently. >>>>>>>>>>>>> Target sock buff size: 2500000 bytes. >>>>>>>>>>>>> Actual sock buff size: 1048576 bytes. >>>>>>>>>>>>> See the transport application notes on buffer resizing. >>>>>>>>>>>>> Please run: sudo sysctl -w net.core.wmem_max=2500000 >>>>>>>>>>>>> [WARNING] [UHD] Unable to set the thread priority. Performance >>>>>>>>>>>>> may be negatively affected. >>>>>>>>>>>>> Please see the general application notes in the manual for >>>>>>>>>>>>> instructions. >>>>>>>>>>>>> EnvironmentError: OSError: error in pthread_setschedparam >>>>>>>>>>>>> >>>>>>>>>>>>> Fetching current settings from EEPROM... >>>>>>>>>>>>> EEPROM ["hardware"] is "2576" >>>>>>>>>>>>> EEPROM ["revision"] is "" >>>>>>>>>>>>> EEPROM ["product"] is "" >>>>>>>>>>>>> EEPROM ["mac-addr"] is "a0:36:fa:26:34:44" >>>>>>>>>>>>> EEPROM ["ip-addr"] is "192.168.10.5" >>>>>>>>>>>>> EEPROM ["subnet"] is "255.255.255.255" >>>>>>>>>>>>> EEPROM ["gateway"] is "255.255.255.255" >>>>>>>>>>>>> EEPROM ["gpsdo"] is "none" >>>>>>>>>>>>> EEPROM ["serial"] is "E4R14V4UN" >>>>>>>>>>>>> EEPROM ["name"] is "" >>>>>>>>>>>>> >>>>>>>>>>>>> Power-cycle the USRP device for the changes to take effect. >>>>>>>>>>>>> >>>>>>>>>>>>> Done >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> john@john-Precision-M4600:~/pybombs/src/uhd/host/build/utils$ >>>>>>>>>>>>> ./usrp_burn_mb_eeprom --read-all --args "addr=192.168.10.3" >>>>>>>>>>>>> Creating USRP device from address: addr=192.168.10.3 >>>>>>>>>>>>> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; >>>>>>>>>>>>> Boost_105800; UHD_3.15.0.git-1-gf83faf28 >>>>>>>>>>>>> [INFO] [USRP2] Opening a USRP2/N-Series device... >>>>>>>>>>>>> [INFO] [USRP2] Current recv frame size: 1472 bytes >>>>>>>>>>>>> [INFO] [USRP2] Current send frame size: 1472 bytes >>>>>>>>>>>>> [WARNING] [UDP] The send buffer could not be resized >>>>>>>>>>>>> sufficiently. >>>>>>>>>>>>> Target sock buff size: 2500000 bytes. >>>>>>>>>>>>> Actual sock buff size: 1048576 bytes. >>>>>>>>>>>>> See the transport application notes on buffer resizing. >>>>>>>>>>>>> Please run: sudo sysctl -w net.core.wmem_max=2500000 >>>>>>>>>>>>> [WARNING] [UDP] The send buffer could not be resized >>>>>>>>>>>>> sufficiently. >>>>>>>>>>>>> Target sock buff size: 2500000 bytes. >>>>>>>>>>>>> Actual sock buff size: 1048576 bytes. >>>>>>>>>>>>> See the transport application notes on buffer resizing. >>>>>>>>>>>>> Please run: sudo sysctl -w net.core.wmem_max=2500000 >>>>>>>>>>>>> [WARNING] [UDP] The send buffer could not be resized >>>>>>>>>>>>> sufficiently. >>>>>>>>>>>>> Target sock buff size: 2500000 bytes. >>>>>>>>>>>>> Actual sock buff size: 1048576 bytes. >>>>>>>>>>>>> See the transport application notes on buffer resizing. >>>>>>>>>>>>> Please run: sudo sysctl -w net.core.wmem_max=2500000 >>>>>>>>>>>>> [WARNING] [UHD] Unable to set the thread priority. Performance >>>>>>>>>>>>> may be negatively affected. >>>>>>>>>>>>> Please see the general application notes in the manual for >>>>>>>>>>>>> instructions. >>>>>>>>>>>>> EnvironmentError: OSError: error in pthread_setschedparam >>>>>>>>>>>>> >>>>>>>>>>>>> Fetching current settings from EEPROM... >>>>>>>>>>>>> EEPROM ["hardware"] is "2576" >>>>>>>>>>>>> EEPROM ["revision"] is "" >>>>>>>>>>>>> EEPROM ["product"] is "" >>>>>>>>>>>>> EEPROM ["mac-addr"] is "a0:36:fa:26:34:42" >>>>>>>>>>>>> EEPROM ["ip-addr"] is "192.168.10.3" >>>>>>>>>>>>> EEPROM ["subnet"] is "255.255.255.255" >>>>>>>>>>>>> EEPROM ["gateway"] is "255.255.255.255" >>>>>>>>>>>>> EEPROM ["gpsdo"] is "none" >>>>>>>>>>>>> EEPROM ["serial"] is "E4R14V2UN" >>>>>>>>>>>>> EEPROM ["name"] is "" >>>>>>>>>>>>> >>>>>>>>>>>>> Power-cycle the USRP device for the changes to take effect. >>>>>>>>>>>>> >>>>>>>>>>>>> Done >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Jul 17, 2019 at 3:19 PM Jason Matusiak < >>>>>>>>>>>>> ja...@gardettoengineering.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> You are right, the table of revisions was for the X-series >>>>>>>>>>>>>> >>>>>>>>>>>>>> try running the command from your prefix: >>>>>>>>>>>>>> src/uhd/host/build/utils/usrp_burn_mb_eeprom --args="type=n200" >>>>>>>>>>>>>> --read-all >>>>>>>>>>>>>> >>>>>>>>>>>>>> don't quote me on the type portion, I don't have a board in >>>>>>>>>>>>>> front of me to see if it is n200 or something else. I //think// >>>>>>>>>>>>>> that will >>>>>>>>>>>>>> report the major and minor revision values (I am grasping at >>>>>>>>>>>>>> straws here, >>>>>>>>>>>>>> just trying to figure out what the differences might be). >>>>>>>>>>>>>> >>>>>>>>>>>>>> You are connecting the ethernet connections to the two >>>>>>>>>>>>>> devices through the exact same port on your PC? >>>>>>>>>>>>>> >>>>>>>>>>>>>> ------------------------------ >>>>>>>>>>>>>> *From:* Sumit Kumar <cog...@gmail.com> >>>>>>>>>>>>>> *Sent:* Wednesday, July 17, 2019 8:24 AM >>>>>>>>>>>>>> *To:* Jason Matusiak <ja...@gardettoengineering.com> >>>>>>>>>>>>>> *Cc:* usrp-users@lists.ettus.com <usrp-users@lists.ettus.com> >>>>>>>>>>>>>> *Subject:* Re: [USRP-users] Sequence Errors N200 >>>>>>>>>>>>>> >>>>>>>>>>>>>> The sticker for sbx shows F33612 and F33814. >>>>>>>>>>>>>> How will this help ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Jul 17, 2019 at 1:50 PM Jason Matusiak < >>>>>>>>>>>>>> ja...@gardettoengineering.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sumit, >>>>>>>>>>>>>> >>>>>>>>>>>>>> OK, the last idea I have: >>>>>>>>>>>>>> >>>>>>>>>>>>>> There is a sticker on the back of the N-series devices it >>>>>>>>>>>>>> *usually* says the version there, but not always. This has >>>>>>>>>>>>>> a little info: >>>>>>>>>>>>>> https://kb.ettus.com/About_the_Motherboard_and_Daughtercard_EEPROM_on_USRP_Devices#N200.2F210_EEPROM >>>>>>>>>>>>>> >>>>>>>>>>>>>> Do they match? >>>>>>>>>>>>>> >>>>>>>>>>>>>> ------------------------------ >>>>>>>>>>>>>> *From:* Sumit Kumar <cog...@gmail.com> >>>>>>>>>>>>>> *Sent:* Wednesday, July 17, 2019 7:45 AM >>>>>>>>>>>>>> *To:* Jason Matusiak <ja...@gardettoengineering.com> >>>>>>>>>>>>>> *Cc:* usrp-users@lists.ettus.com <usrp-users@lists.ettus.com> >>>>>>>>>>>>>> *Subject:* Re: [USRP-users] Sequence Errors N200 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Jason, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes they are consistent, I mean the output of uhd_usrp_probe >>>>>>>>>>>>>> for both N200 is exactly the same (except the ip, serial and mac >>>>>>>>>>>>>> addr). >>>>>>>>>>>>>> I do not know where the problem is! Hardware or software >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards >>>>>>>>>>>>>> Sumit >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Jul 17, 2019 at 1:19 PM Jason Matusiak < >>>>>>>>>>>>>> ja...@gardettoengineering.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am not really an N-series guy, so this probably won't be >>>>>>>>>>>>>> helpful. Have you tried doing a uhd_usrp_probe on both devices >>>>>>>>>>>>>> and seen >>>>>>>>>>>>>> that the responses are consistent? >>>>>>>>>>>>>> >>>>>>>>>>>>>> ------------------------------ >>>>>>>>>>>>>> *From:* USRP-users <usrp-users-boun...@lists.ettus.com> on >>>>>>>>>>>>>> behalf of Sumit Kumar via USRP-users < >>>>>>>>>>>>>> usrp-users@lists.ettus.com> >>>>>>>>>>>>>> *Sent:* Wednesday, July 17, 2019 7:15 AM >>>>>>>>>>>>>> *To:* usrp-users@lists.ettus.com <usrp-users@lists.ettus.com> >>>>>>>>>>>>>> *Subject:* [USRP-users] Sequence Errors N200 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> I am trying transmit using Ettus N200 (call it A) but getting >>>>>>>>>>>>>> this error message on the console >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSUSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS.................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................... >>>>>>>>>>>>>> >>>>>>>>>>>>>> I looked for it on google and found these links >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-May/037495.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2012-July/032838.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> Both the links suggested problem related to the gigabit >>>>>>>>>>>>>> port. Then I connected another USRP N200 (call it B) to the same >>>>>>>>>>>>>> laptop and >>>>>>>>>>>>>> tried transmitting using that as there were no such sequence >>>>>>>>>>>>>> error messages. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This makes me believe there is some problem with the first >>>>>>>>>>>>>> USRP, i.e., A. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Further I tried with different versions of UHD 3.11, UHD >>>>>>>>>>>>>> 3.15.. but its the same. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Receive is good only transmit is throwing error. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Not only with UHD, even in labview, when I transmit, I see >>>>>>>>>>>>>> nothing coming out from the N200 (A). >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am using SBXv2 daughter board. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Any clue! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Sumit kumar >>>>>>>>>>>>>> Postdoc >>>>>>>>>>>>>> SnT, Luxembourg >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Sumit kumar >>>>>>>>>>>>>> Postdoc >>>>>>>>>>>>>> SnT, Luxembourg >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Sumit kumar >>>>>>>>>>>>>> Postdoc >>>>>>>>>>>>>> SnT, Luxembourg >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> -- >>>>>>>>>>>>> Sumit kumar >>>>>>>>>>>>> Postdoc >>>>>>>>>>>>> SnT, Luxembourg >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> USRP-users mailing list >>>>>>>>>>>>> USRP-users@lists.ettus.com >>>>>>>>>>>>> >>>>>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> -- >>>>>>>>>>> Sumit kumar >>>>>>>>>>> Postdoc >>>>>>>>>>> SnT, Luxembourg >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> -- >>>>>>>>> Sumit kumar >>>>>>>>> Postdoc >>>>>>>>> SnT, Luxembourg >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> -- >>>>>>> Sumit kumar >>>>>>> Postdoc >>>>>>> SnT, Luxembourg >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> -- >>>>> -- >>>>> Sumit kumar >>>>> Postdoc >>>>> SnT, Luxembourg >>>>> >>>>> >>>>> >>> >>> -- >>> -- >>> Sumit kumar >>> Postdoc >>> SnT, Luxembourg >>> >>> >>> > > -- > -- > Sumit kumar > Postdoc > SnT, Luxembourg > > > -- -- Sumit kumar Postdoc SnT, Luxembourg
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
