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
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
