[USRP-users] Quad channel receiver operation of B210
Hi, Apology if this is a redundant question. With the latest UHD version, is it possible to use B210 as a quad channel receiver. Dual channel, I understood, it exists, and I verified also. Regards Sumit ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Quad channel receiver operation of B210
I asked because the TX/RX port can also be used as RX right. That's why I had the perception that all 4 ports can be used as RX at a time! On Fri, Sep 15, 2017 at 6:23 PM, Marcus Müller via USRP-users < usrp-users@lists.ettus.com> wrote: > A single B210 has exactly two hardware receive channels. So, I'm afraid > that no software update ever will change that! > > Best regards, > > Marcus > > On 09/15/2017 02:41 PM, Sumit Kumar via USRP-users wrote: > > Hi, > > Apology if this is a redundant question. > > With the latest UHD version, is it possible to use B210 as a quad channel > receiver. > Dual channel, I understood, it exists, and I verified also. > > Regards > > Sumit > > > > ___ > 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 > > -- -- Sumit kumar Doctoral Student, UPMC Eurecom, BIOT France ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Quad channel receiver operation of B210
Ahh I see there is a switch between TX/RX and RX2 ports ! Understood :) On Fri, Sep 15, 2017 at 9:08 PM, Marcus Müller wrote: > No, you can't. As said: There's only two RX chains. You can switch these > to /either/ rx *OR* tx/rx. > > Best regards, > > > On 15 September 2017 10:17:18 AM GMT-07:00, Sumit Kumar > wrote: >> >> I asked because the TX/RX port can also be used as RX right. That's why I >> had the perception that all 4 ports can be used as RX at a time! >> >> On Fri, Sep 15, 2017 at 6:23 PM, Marcus Müller via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> A single B210 has exactly two hardware receive channels. So, I'm afraid >>> that no software update ever will change that! >>> >>> Best regards, >>> >>> Marcus >>> >>> On 09/15/2017 02:41 PM, Sumit Kumar via USRP-users wrote: >>> >>> Hi, >>> >>> Apology if this is a redundant question. >>> >>> With the latest UHD version, is it possible to use B210 as a quad >>> channel receiver. >>> Dual channel, I understood, it exists, and I verified also. >>> >>> Regards >>> >>> Sumit >>> >>> >>> >>> ___ >>> 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 >>> >>> >> >> >> -- >> -- >> Sumit kumar >> Doctoral Student, UPMC >> Eurecom, BIOT >> France >> >> > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > -- -- Sumit kumar Doctoral Student, UPMC Eurecom, BIOT France ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] 2011 Matt's Talk Materials
Hi, I was wondering if anyone has the materials for the famous talk by Matt Ettus in 2011 GRCon. *"Why Doesn't My Signal Look Like the Textbook?"* I remember it was hosted on Tom's webpage. The link is still there, however the files are missing. http://www.trondeau.com/grc2011-abstracts/ Go to the schedule of 15th September 9-9:30 Regards Sumit ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] 2011 Matt's Talk Materials
Thanks Robin, I found the slides. However the talk which he gave in GRCon 2011 was approx 3:30 hr long. Anyways do you also have the grc files used in the slides ! Thanks much Sumit On Mon, Oct 16, 2017 at 11:21 PM, Robin Coxe wrote: > Matt gave this talk again at GR Con 2015 in Boulder. Slides here: > https://drive.google.com/file/d/0B6ccrJyAZaq3UHpEQld1YmZjbWs/view > > On Mon, Oct 16, 2017 at 1:56 PM, Sumit Kumar via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hi, >> >> I was wondering if anyone has the materials for the famous talk by Matt >> Ettus in 2011 GRCon. >> >> *"Why Doesn't My Signal Look Like the Textbook?"* >> >> I remember it was hosted on Tom's webpage. The link is still there, >> however the files are missing. >> >> http://www.trondeau.com/grc2011-abstracts/ >> >> Go to the schedule of 15th September 9-9:30 >> >> Regards >> >> Sumit >> >> ___ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> > -- -- Sumit kumar Doctoral Student, UPMC Eurecom, BIOT France ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Triggering between two transmitters
Hi, I want to create a deterministic collision scenario between wifi and zigbee. I am using gr-ieee 80211 and gr-ieee 802154 along with USRP B210. I have a constraint that my wifi preambles should always collide with an ongoing zigbee transmission. In order to do that, I am thinking of synchronizing the wifi transmitter and zigbee transmitter (both connected in the same laptop) in such a way that wifi transmits its frame only when zigbee transmission is ongoing. Is there any way that zigbee transmitter triggers the wifi transmitter whenever a zigbee frame is transmitted. Air time of zigbee is very high compared to wifi, so I am sure if zigbee transmitter triggers wifi transmitter, wifi preambles will collide with zigbee for sure. Both wifi transmitter and zigbee transmitter are connected to the same laptop and using different USRP B210. I am not sure if the solution lies in gnuradio or uhd hence posting at both places :) Regards Sumit ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] uhd build fails using pybombs
Hi, Yesterday I installed on one machine using pybombs, it was good, no issues. Today I tried in another machine it fails. Here are the logs CMakeOutput.log -- https://paste.ubuntu.com/26511650/ CMakeError.log -- https://paste.ubuntu.com/26511662/ ~~ Install tree: | \- gnuradio | +- uhd | \- apache-thrift PyBOMBS.install_manager - INFO - Phase 2: Recursively installing source packages to prefix: PyBOMBS.install_manager - INFO - Installing package: apache-thrift Cloning: (100%) [] Cloning: (100%) [] Configuring: (100%) [] Building:(100%) [] Installing: (100%) [] PyBOMBS.install_manager - INFO - Installation successful. PyBOMBS.install_manager - INFO - Installing package: uhd Cloning: (100%) [] Configuring: (100%) [] PyBOMBS.Packager.source - WARNING - Configuration failed. Re-trying with higher verbosity. -- -- Configuring the python interpreter... -- Python interpreter: /usr/bin/python -- Override with: -DPYTHON_EXECUTABLE= -- Operating on master branch. -- Using UHD Images Directory: OFF -- -- Configuring Boost C++ Libraries... -- Could NOT find Boost -- Boost include directories: /usr/include -- Boost library directories: -- Boost libraries: -- -- Python checking for Python version 2.7 or greater -- Python checking for Python version 2.7 or greater - found -- -- Python checking for Mako templates 0.4.2 or greater -- Python checking for Mako templates 0.4.2 or greater - found -- -- Configuring LibUHD support... -- Dependency Boost_FOUND = 0 -- Dependency HAVE_PYTHON_PLAT_MIN_VERSION = TRUE -- Dependency HAVE_PYTHON_MODULE_MAKO = TRUE CMake Error at cmake/Modules/UHDComponent.cmake:40 (MESSAGE): Dependencies for required component LibUHD not met. Call Stack (most recent call first): CMakeLists.txt:373 (LIBUHD_REGISTER_COMPONENT) -- Configuring incomplete, errors occurred! See also "/home/tique/1radio/src/uhd/host/build/CMakeFiles/CMakeOutput.log". See also "/home/tique/1radio/src/uhd/host/build/CMakeFiles/CMakeError.log". PyBOMBS.Packager.source - ERROR - Configuration failed after running at least twice. PyBOMBS.Packager.source - ERROR - Problem occurred while building package uhd: Configuration failed PyBOMBS.install_manager - ERROR - Error installing package uhd. Aborting. ~~ ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] uhd build fails using pybombs
Yes Indeed I fixed the issue by installing libboost-dev all. But why I was surprised because pybombs is supposed to install all the dependencies. I mean I did fresh install on many machines using pybombs, this error never occurred. On Sat, Feb 3, 2018 at 4:49 PM, Jeff Long via USRP-users < usrp-users@lists.ettus.com> wrote: > The error messages says Boost was not found. Do you have the boost dev > package installed on this machine? > > > On 02/03/2018 04:53 AM, Sumit Kumar via USRP-users wrote: > >> Hi, >> >> Yesterday I installed on one machine using pybombs, it was good, no >> issues. >> Today I tried in another machine it fails. >> >> Here are the logs >> >> CMakeOutput.log -- https://paste.ubuntu.com/26511650/ >> CMakeError.log -- https://paste.ubuntu.com/26511662/ >> >> >> ~~ >> Install tree: >> | >> \- gnuradio >> | >> +- uhd >> | >> \- apache-thrift >> PyBOMBS.install_manager - INFO - Phase 2: Recursively installing source >> packages to prefix: >> PyBOMBS.install_manager - INFO - Installing package: apache-thrift >> Cloning: (100%) [= >> >> >> ===] >> Cloning: (100%) [= >> >> >> ===] >> Configuring: (100%) [= >> >> >> ===] >> Building:(100%) [= >> >> >> ===] >> Installing: (100%) [= >> >> >> ===] >> PyBOMBS.install_manager - INFO - Installation successful. >> PyBOMBS.install_manager - INFO - Installing package: uhd >> Cloning: (100%) [= >> >> >> ===] >> Configuring: (100%) [= >> >> >> ===] >> PyBOMBS.Packager.source - WARNING - Configuration failed. Re-trying with >> higher verbosity. >> -- >> -- Configuring the python interpreter... >> -- Python interpreter: /usr/bin/python >> -- Override with: -DPYTHON_EXECUTABLE= >> -- Operating on master branch. >> -- Using UHD Images Directory: OFF >> -- >> -- Configuring Boost C++ Libraries... >> -- Could NOT find Boost >> -- Boost include directories: /usr/include >> -- Boost library directories: >> -- Boost libraries: >> -- >> -- Python checking for Python version 2.7 or greater >> -- Python checking for Python version 2.7 or greater - found >> -- >> -- Python checking for Mako templates 0.4.2 or greater >> -- Python checking for Mako templates 0.4.2 or greater - found >> -- >> -- Configuring LibUHD support... >> -- Dependency Boost_FOUND = 0 >> -- Dependency HAVE_PYTHON_PLAT_MIN_VERSION = TRUE >> -- Dependency HAVE_PYTHON_MODULE_MAKO = TRUE >> CMake Error at cmake/Modules/UHDComponent.cmake:40 (MESSAGE): >>Dependencies for required component LibUHD not met. >> Call Stack (most recent call first): >>CMakeLists.txt:373 (LIBUHD_REGISTER_COMPONENT) >> >> >> -- Configuring incomplete, errors occurred! >> See also "/home/tique/1radio/src/uhd/host/build/CMakeFiles/CMakeOutpu >> t.log". >> See also "/home/tique/1radio/src/uhd/host/build/CMakeFiles/CMakeError >> .log". >> PyBOMBS.Packager.source - ERROR - Configuration failed after running at >> least twice. >> PyBOMBS.Packager.source - ERROR - Problem occurred while building package >> uhd: >> Conf
[USRP-users] Using Dual Rx Channel B210 from GRC
I am using a UHD source in GRC. I configured it to stream from both the RX ports. The first port is tuned to 2.437 GHz and the another to 2.435 by providing a lo_offset of 2MHz. Samples from first port go under some processing and then have to be added to samples coming from the second port. When I run my set up, the green LEDs of the ports blink for once and stop receiving any more. I am attaching the grc file for reference. When I run it without the "ADD" block, it streams fine with both the channels streaming. Regards Sumit soft_decision_receiver_testing_copy.grc Description: Binary data ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Device Recovery N210: JTAG programmer
Hi, I have 3 bricked N210 to be recovered. I was following the post https://kb.ettus.com/N200/N210_Device_Recovery It says JTAG programmer and in the picture I can see the model no. is DLC9G. I found something on Amazon which has the same model number but does not looks the same. Can anyone confirm if this is correct. https://www.amazon.fr/Plate-Forme-Compatible-lautolaveuse-programmable-XILINX/dp/B07Y7PBBGQ/ref=sr_1_1?__mk_fr_FR=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=DLC9G&qid=1582884943&sr=8-1 Regards -- -- 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
Re: [USRP-users] Device Recovery N210: JTAG programmer
Thanks Nick. I have ordered HS3. Regards Sumit On Fri, Feb 28, 2020 at 7:38 PM Nick Foster wrote: > Sumit, > > Any JTAG programmer which is compatible with Xilinx iMPACT should work > fine. I can recommend the solutions from Digilent (HS2, HS3) or Xilinx > (Platform USB II). > > Nick > > On Fri, Feb 28, 2020 at 2:19 AM Sumit Kumar via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hi, >> I have 3 bricked N210 to be recovered. I was following the post >> https://kb.ettus.com/N200/N210_Device_Recovery >> >> It says JTAG programmer and in the picture I can see the model no. is >> DLC9G. >> >> I found something on Amazon which has the same model number but does not >> looks the same. Can anyone confirm if this is correct. >> >> https://www.amazon.fr/Plate-Forme-Compatible-lautolaveuse-programmable-XILINX/dp/B07Y7PBBGQ/ref=sr_1_1?__mk_fr_FR=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=DLC9G&qid=1582884943&sr=8-1 >> >> >> Regards >> -- >> -- >> 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 ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] -- GPIO on N320 --
Hi, I am also having the issue. Can anyone please help with the information :) For N310, there is FP0 available but for N320 I get following run time error: " what(): RuntimeError: The hardware has no GPIO bank `FP0' " Regards Sumit On Mon, Jan 27, 2020 at 11:02 PM Nowicki, Ed H. via USRP-users < usrp-users@lists.ettus.com> wrote: > When I call the UHD API function get_gpio_banks() > > I get the following banks: > > ‘RXB’ ‘TXB’ ‘RXA’ TXA’ but I do NOT get ‘FP0’. > > > > Thoughts? > > > > Thanks, > > Ed > > > > *From: *USRP-users on behalf of > "Nowicki, Ed H. via USRP-users" > *Reply-To: *"Nowicki, Ed H." > *Date: *Monday, January 27, 2020 at 8:45 AM > *To: *"usrp-users@lists.ettus.com" > *Subject: *[EXT] [USRP-users] -- GPIO on N320 -- > > > > *APL external email warning: *Verify sender > usrp-users-boun...@lists.ettus.com before clicking links or attachments > > > > Hi, > > > > I’m having a problem using the front panel GPIO on an N320. I reverted > back to a standard “HG” FPGA build and compiled the GPIO example program > (UHD 3.14.0). However, when I run the example program I get the following: > > > > Error: RuntimeError: The hardware has no gpio bank `FP0' > > > > Is the front panel GPIO bank on the N320 called “FP0” or something else? > I did not see a reference to this in the .dts. > > > > See below for a “uhd_uspr_probe”, “uhd_config_info” dump, and the terminal > output after running ./gpio. > > > > Thanks for any help. > > > > Regards, > > Ed Nowicki > > > > > > > > ~~ > > xku@sdr_nuc:~/workarea-uhd/uhd/host/examples/gpio/build$ uhd_usrp_probe > > [INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501; > UHD_3.14.0.HEAD-0-g6875d061 > > [INFO] [MPMD] Initializing 1 device(s) in parallel with args: > mgmt_addr=192.168.20.2,type=n3xx,product=n320,serial=31A5C5A,claimed=False,addr=192.168.20.2 > > [INFO] [MPM.PeriphManager] init() called with device args > `mgmt_addr=192.168.20.2,clock_source=internal,time_source=internal,product=n320'. > > [INFO] [MPM.Rhodium-0] init() called with args > `mgmt_addr=192.168.20.2,clock_source=internal,time_source=internal,product=n320' > > [INFO] [MPM.Rhodium-1] init() called with args > `mgmt_addr=192.168.20.2,clock_source=internal,time_source=internal,product=n320' > > [INFO] [0/Replay_0] Initializing block control (NOC ID: 0x4E91A004) > > [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1320) > > [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD1320) > > [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC1) > > [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC1) > > [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0) > > [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0) > > [INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0) > > [INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0) > > _ > > / > > | Device: N300-Series Device > > | _ > > |/ > > | | Mboard: ni-n3xx-31A5C5A > > | | eeprom_version: 2 > > | | mpm_version: 3.14.1.0-gbfb9c1c7 > > | | pid: 16962 > > | | product: n320 > > | | rev: 7 > > | | rpc_connection: remote > > | | serial: 31A5C5A > > | | type: n3xx > > | | MPM Version: 1.2 > > | | FPGA Version: 5.3 > > | | FPGA git hash: 3de8954.clean > > | | RFNoC capable: Yes > > | | > > | | Time sources: internal, external, gpsdo, sfp0 > > | | Clock sources: external, internal, gpsdo > > | | Sensors: temp, gps_tpv, gps_time, fan, gps_sky, ref_locked, > gps_gpgga, gps_locked > > | | _ > > | |/ > > | | | RX Dboard: A > > | | | ID: Unknown (0x0152) > > | | | Serial: 3191E7D > > | | | _ > > | | |/ > > | | | | RX Frontend: 0 > > | | | | Name: Rhodium > > | | | | Antennas: TX/RX, RX2, CAL, TERM > > | | | | Sensors: lo_locked > > | | | | Freq range: 1.000 to 6000.000 MHz > > | | | | Gain range all: 0.0 to 60.0 step 1.0 dB > > | | | | Bandwidth range: 25000.0 to 25000.0 step 0.0 Hz > > | | | | Connection Type: > > | | | | Uses LO offset: No > > | | | _ > > | | |/ > > | | | | RX Codec: A > > | | | | Name: ad9695-625 > > | | | | Gain Elements: None > > | | _ > > | |/ > > | | | RX Dboard: B > > | | | ID: Unknown (0x0152) > > | | | Serial: 3191E79 > > | | | _ > > | | |/ > > | | | | RX Frontend: 0 > >
Re: [USRP-users] -- GPIO on N320 --
Just now I tried to print the available GPIO available. For N310 it shows: FP0 RXA TXA RXB TXB But for N320 it shows: RXA TXA RXB TXB On Wed, Sep 2, 2020 at 7:58 PM Sumit Kumar wrote: > Hi, > > I am also having the issue. Can anyone please help with the information :) > > For N310, there is FP0 available but for N320 I get following run time > error: > " what(): RuntimeError: The hardware has no GPIO bank `FP0' " > > Regards > Sumit > > On Mon, Jan 27, 2020 at 11:02 PM Nowicki, Ed H. via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> When I call the UHD API function get_gpio_banks() >> >> I get the following banks: >> >> ‘RXB’ ‘TXB’ ‘RXA’ TXA’ but I do NOT get ‘FP0’. >> >> >> >> Thoughts? >> >> >> >> Thanks, >> >> Ed >> >> >> >> *From: *USRP-users on behalf of >> "Nowicki, Ed H. via USRP-users" >> *Reply-To: *"Nowicki, Ed H." >> *Date: *Monday, January 27, 2020 at 8:45 AM >> *To: *"usrp-users@lists.ettus.com" >> *Subject: *[EXT] [USRP-users] -- GPIO on N320 -- >> >> >> >> *APL external email warning: *Verify sender >> usrp-users-boun...@lists.ettus.com before clicking links or attachments >> >> >> >> Hi, >> >> >> >> I’m having a problem using the front panel GPIO on an N320. I reverted >> back to a standard “HG” FPGA build and compiled the GPIO example program >> (UHD 3.14.0). However, when I run the example program I get the following: >> >> >> >> Error: RuntimeError: The hardware has no gpio bank `FP0' >> >> >> >> Is the front panel GPIO bank on the N320 called “FP0” or something else? >> I did not see a reference to this in the .dts. >> >> >> >> See below for a “uhd_uspr_probe”, “uhd_config_info” dump, and the >> terminal output after running ./gpio. >> >> >> >> Thanks for any help. >> >> >> >> Regards, >> >> Ed Nowicki >> >> >> >> >> >> >> >> ~~ >> >> xku@sdr_nuc:~/workarea-uhd/uhd/host/examples/gpio/build$ uhd_usrp_probe >> >> [INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501; >> UHD_3.14.0.HEAD-0-g6875d061 >> >> [INFO] [MPMD] Initializing 1 device(s) in parallel with args: >> mgmt_addr=192.168.20.2,type=n3xx,product=n320,serial=31A5C5A,claimed=False,addr=192.168.20.2 >> >> [INFO] [MPM.PeriphManager] init() called with device args >> `mgmt_addr=192.168.20.2,clock_source=internal,time_source=internal,product=n320'. >> >> [INFO] [MPM.Rhodium-0] init() called with args >> `mgmt_addr=192.168.20.2,clock_source=internal,time_source=internal,product=n320' >> >> [INFO] [MPM.Rhodium-1] init() called with args >> `mgmt_addr=192.168.20.2,clock_source=internal,time_source=internal,product=n320' >> >> [INFO] [0/Replay_0] Initializing block control (NOC ID: >> 0x4E91A004) >> >> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1320) >> >> [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD1320) >> >> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC1) >> >> [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC1) >> >> [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0) >> >> [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0) >> >> [INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0) >> >> [INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0) >> >> _ >> >> / >> >> | Device: N300-Series Device >> >> | _ >> >> |/ >> >> | | Mboard: ni-n3xx-31A5C5A >> >> | | eeprom_version: 2 >> >> | | mpm_version: 3.14.1.0-gbfb9c1c7 >> >> | | pid: 16962 >> >> | | product: n320 >> >> | | rev: 7 >> >> | | rpc_connection: remote >> >> | | serial: 31A5C5A >> >> | | type: n3xx >> >> | | MPM Version: 1.2 >> >> | | FPGA Version: 5.3 >> >> | | FPGA git hash: 3de8954.clean >> >> | | RFNoC capable: Yes >> >> | | >> >> | | Time sources: internal, external, gpsdo, sfp0 >> >> | | Clock sources: external, internal, gpsdo >> >> | | Sensors: temp, gps_tpv, gps_time, fan, gps_sky, ref_locked, >> gps_gpgga, gps_locked >> >> | | _ >> >> | |/ >> >> | | | RX Dboard: A >> >> | | | ID: Unknown (0x0152) >> >> | | | Serial: 3191E7D >> >> | | | _ >> >> | | |/ >> >> | | | | RX Frontend: 0 >> >> | | | | Name: Rhodium >> >> | | | | Antennas: TX/RX, RX2, CAL, TERM >> >> | | | | Sensors: lo_locked >> >> | | | | Freq range: 1.000 to 6000.000 MHz >> >> | | | | Gain range all: 0.0 to 60.0 step 1.0 dB >> >> | | | | Bandwidth range: 25000.0 to 25000.0 step 0.0 Hz >> >> | | | | Connection Type: >> >> | | | | Uses LO offset: No >> >> | | | _ >> >> | | |/ >> >> | | | | RX
Re: [USRP-users] Pybombs error for gnuradio
Hello Pratik, Were you able to find the solution ? BR Sumit On Wed, Oct 17, 2018 at 9:41 PM Pratik Chatterjee via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello all, > > I have used pybombs in the past and it worked just fine. But recently I > get compatibility issues of uhd and fpga, as well as the following error > while building gnuradio. Has anyone seen this before? I am following the > getting started rfnoc guide. > > [ 87%] Building CXX object > gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o > /home/pratik/rfnoc/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: > In function ‘PyObject* _wrap_time_spec_t___addSWIG_0(PyObject*, > PyObject*)’: > /home/pratik/rfnoc/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:20964:33: > error: ‘class uhd::time_spec_t’ has no member named ‘operator+’ >result = (arg1)->operator +(*arg2); > ^ > /home/pratik/rfnoc/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: > In function ‘PyObject* _wrap_time_spec_t___addSWIG_1(PyObject*, > PyObject*)’: > /home/pratik/rfnoc/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:21009:33: > error: ‘class uhd::time_spec_t’ has no member named ‘operator+’ >result = (arg1)->operator +((uhd::time_spec_t const &)*arg2); > ^ > gr-uhd/swig/CMakeFiles/_uhd_swig.dir/build.make:70: recipe for target > 'gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o' failed > make[2]: *** > [gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o] Error 1 > CMakeFiles/Makefile2:15091: recipe for target > 'gr-uhd/swig/CMakeFiles/_uhd_swig.dir/all' failed > make[1]: *** [gr-uhd/swig/CMakeFiles/_uhd_swig.dir/all] Error 2 > Makefile:160: recipe for target 'all' failed > make: *** [all] Error 2 > [ERROR] Build failed. See output above for error messages. > [ERROR] Problem occurred while building package gnuradio: > Build failed. > [ERROR] Error installing package gnuradio. Aborting. > > Thanks, > Pratik > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > -- -- Sumit kumar Doctoral Student, UPMC Eurecom, BIOT France ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Reg: USRP N200 reset problem
Hi, I got Ettus N200 from my colleague. I din't know the ip address so I did a reset. After the reset, the ip of N200 became 192.168.10.2 and I was able to ping and do all regular stuff with it. But whenever I do a power cycle of the N200, it is undetectable at 192.168.10.2. Then again I have to reset it. I am not sure what has gone wrong. Regards Sumit ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Reg: USRP N200 reset problem
Hi Marcus, I just did the following (nothing else). What shall I do after this ? I do not have the JTAG with me. *The safe-mode button is a pushbutton switch (S2) located inside the enclosure. To boot into the safe image, hold-down the safe-mode button while power-cycling the device. Continue to hold-down the button until the front-panel LEDs blink and remain solid.* *When in safe-mode, the USRP-N device will always have the IP address 192.168.10.2.* On Thu, Jun 13, 2019 at 9:38 PM Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com> wrote: > On 06/13/2019 03:33 PM, Sumit Kumar via USRP-users wrote: > > > > Hi, > > > > I got Ettus N200 from my colleague. I din't know the ip address so I > > did a reset. After the reset, the ip of N200 became 192.168.10.2 and I > > was able to ping and do all regular stuff with it. But whenever I do a > > power cycle of the N200, it is undetectable at 192.168.10.2. Then > > again I have to reset it. > > > > I am not sure what has gone wrong. > > > > Regards > > Sumit > > > Could you describe the steps you took to reset it? > > IT sounds like you put it in "safe mode", but didn't actually download a > working image into it or force an IP address reset to a desired IP address. > > https://kb.ettus.com/N200/N210_Device_Recovery > > > > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > -- -- Sumit kumar Doctoral Student, UPMC Eurecom, BIOT France ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Reg: USRP N200 reset problem
Thanks Marcus, I tried it, works! I have a follow-up question. I have another Ettus N200. whose none of the LEDs glow. Just the fan runs. I believe it has became brick. And I do not have JTAG. Any other way/tool to recover it. Regards Sumit On Thu, Jun 13, 2019 at 10:06 PM Marcus D. Leech wrote: > On 06/13/2019 03:52 PM, Sumit Kumar wrote: > > Hi Marcus, > > I just did the following (nothing else). What shall I do after this ? I > do not have the JTAG with me. > > *The safe-mode button is a pushbutton switch (S2) located inside the > enclosure. To boot into the safe image, hold-down the safe-mode button > while power-cycling the device. Continue to hold-down the button until the > front-panel LEDs blink and remain solid.* > > *When in safe-mode, the USRP-N device will always have the IP address > 192.168.10.2.* > > > Once it is in safe-mode, use the EEPROM commands as below: > > https://files.ettus.com/manual/page_usrp2.html#usrp2_network_changeip > > To change the stored-in-eeprom IP address to whatever you want (perhaps > just back to the default 192.168.10.2). Once that works, > power-cycle, and ping the device. It should now respond to the desired > address. > > I suspect that what happened was your friend changed the IP address away > from the default, so, you use safe-mode to get it into a state > where you can change the permanent address of the device. > > > > > On Thu, Jun 13, 2019 at 9:38 PM Marcus D. Leech via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> On 06/13/2019 03:33 PM, Sumit Kumar via USRP-users wrote: >> > >> > Hi, >> > >> > I got Ettus N200 from my colleague. I din't know the ip address so I >> > did a reset. After the reset, the ip of N200 became 192.168.10.2 and I >> > was able to ping and do all regular stuff with it. But whenever I do a >> > power cycle of the N200, it is undetectable at 192.168.10.2. Then >> > again I have to reset it. >> > >> > I am not sure what has gone wrong. >> > >> > Regards >> > Sumit >> > >> Could you describe the steps you took to reset it? >> >> IT sounds like you put it in "safe mode", but didn't actually download a >> working image into it or force an IP address reset to a desired IP >> address. >> >> https://kb.ettus.com/N200/N210_Device_Recovery >> >> >> >> ___ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> > > > -- > -- > Sumit kumar > Doctoral Student, UPMC > Eurecom, BIOT > France > > > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Sequence Errors N200
Hi, I am trying transmit using Ettus N200 (call it A) but getting this error message on the console SSU 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 ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
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 on behalf of > Sumit Kumar via USRP-users > *Sent:* Wednesday, July 17, 2019 7:15 AM > *To:* 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 > > > SSU > > 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 ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
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 > *Sent:* Wednesday, July 17, 2019 7:45 AM > *To:* Jason Matusiak > *Cc:* 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 on behalf of > Sumit Kumar via USRP-users > *Sent:* Wednesday, July 17, 2019 7:15 AM > *To:* 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 > > > SSU > > 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 ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Sequence Errors N200
Yes already tried different cable. Same issue :( One usrp is good but the other says S!. On Wed, Jul 17, 2019 at 3:18 PM Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com> wrote: > On 07/17/2019 07:45 AM, Sumit Kumar via USRP-users wrote: > > 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 > > My guess is that you have a hardware issue. Have you tried simple things, > like a different ethernet cable? > > > > 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 on behalf of >> Sumit Kumar via USRP-users >> *Sent:* Wednesday, July 17, 2019 7:15 AM >> *To:* 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 >> >> >> SSU >> >> 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 > > > > > ___ > 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 > -- -- 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
Re: [USRP-users] Sequence Errors N200
- > *From:* Sumit Kumar > *Sent:* Wednesday, July 17, 2019 8:24 AM > *To:* Jason Matusiak > *Cc:* 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 > *Sent:* Wednesday, July 17, 2019 7:45 AM > *To:* Jason Matusiak > *Cc:* 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 on behalf of > Sumit Kumar via USRP-users > *Sent:* Wednesday, July 17, 2019 7:15 AM > *To:* 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 > > > SSU > > 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
Re: [USRP-users] Sequence Errors N200
Hi Robin, By doing this, the warnings of buffer size are not coming but S persists. On Wed, Jul 17, 2019 at 4:10 PM Robin Coxe wrote: > Try doing what UHD suggests and resizing the send buffer. > > *WARNING] [UDP] The send buffer could not be resized sufficiently.* > *Target sock buff size: 250 bytes.* > *Actual sock buff size: 1048576 bytes.* > *See the transport application notes on buffer resizing.* > *Please run: sudo sysctl -w net.core.wmem_max=250* > > You can also resize the receive buffer by replacing wmem with rmem. > -- > *From:* USRP-users on behalf of > Sumit Kumar via USRP-users > *Sent:* Wednesday, July 17, 2019 7:06 AM > *To:* Jason Matusiak > *Cc:* usrp-users@lists.ettus.com > *Subject:* Re: [USRP-users] Sequence Errors N200 > > Following is what I am getting after the command you asked to run. The > 192.168.10.5 gives SSS. > > 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: 250 bytes. > Actual sock buff size: 1048576 bytes. > See the transport application notes on buffer resizing. > Please run: sudo sysctl -w net.core.wmem_max=250 > [WARNING] [UDP] The send buffer could not be resized sufficiently. > Target sock buff size: 250 bytes. > Actual sock buff size: 1048576 bytes. > See the transport application notes on buffer resizing. > Please run: sudo sysctl -w net.core.wmem_max=250 > [WARNING] [UDP] The send buffer could not be resized sufficiently. > Target sock buff size: 250 bytes. > Actual sock buff size: 1048576 bytes. > See the transport application notes on buffer resizing. > Please run: sudo sysctl -w net.core.wmem_max=250 > [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: 250 bytes. > Actual sock buff size: 1048576 bytes. > See the transport application notes on buffer resizing. > Please run: sudo sysctl -w net.core.wmem_max=250 > [WARNING] [UDP] The send buffer could not be resized sufficiently. > Target sock buff size: 250 bytes. > Actual sock buff size: 1048576 bytes. > See the transport application notes on buffer resizing. > Please run: sudo sysctl -w net.core.wmem_max=250 > [WARNING] [UDP] The send buffer could not be resized sufficiently. > Target sock buff size: 250 bytes. > Actual sock buff size: 1048576 bytes. > See the transport application notes on buffer resizing. > Please run: sudo sysctl -w net.core.wmem_max=250 > [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 [&q
Re: [USRP-users] Sequence Errors N200
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.75 (from [0.00, 31.50]) ..SS.SSS...S..SS.S..SS.SS...S.S...SS^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 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: 250 bytes. > Actual sock buff size: 1048576 bytes. > See the transport application notes on buffer resizing. > Please run: sudo sysctl -w net.core.wmem_max=250 > [WARNING] [UDP] The send buffer could not be resized sufficiently. > Target sock buff size: 250 bytes. > Actual sock buff size: 1048576 bytes. > See the transport application notes on buffer resizing. > Please run: sudo sysctl -w net.core.wmem_max=250 > " > > 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 SSS. >> >> 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: 250 bytes. >> Actual sock buff size: 1048576 bytes. >> See the transport application notes on buffer resizing. >> Please run: sudo sysctl -w net.core.wmem_max=250 >> [WARNING] [UDP] The send buffer could not be resized sufficiently. >> Target sock buff size: 250 bytes. >> Actual sock buff size: 1048576 bytes. >> See the transport application notes on buffer resizing. >> Please run: sudo sysctl -w net.core.wmem_max=250 >> [WARNING] [UDP] The send buffer could not be resized sufficiently. >> Target sock buff size: 250 bytes. >> Actual sock buff size: 1048576 bytes. >> See the transport application notes on buffer resizing. >> Please run: sudo sysctl -w net.core.wmem_max=250 >> [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:
Re: [USRP-users] Sequence Errors N200
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.24] 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.00 Msps on 1 channels On Wed, Jul 17, 2019 at 4:39 PM Nate Temple 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 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.75 (from [0.00, 31.50]) >> >> ..SS.SSS...S..SS.S..SS.SS...S.S...SS^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 >> 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: 250 bytes. >>> Actual sock buff size: 1048576 bytes. >>> See the transport application notes on buffer resizing. >>> Please run: sudo sysctl -w net.core.wmem_max=250 >>> [WARNING] [UDP] The send buffer could not be resized sufficiently. >>> Target sock buff size: 250 bytes. >>> Actual sock buff size: 1048576 bytes. >>> See the transport application notes on buffer resizing. >>> Please run: sudo sysctl -w net.core.wmem_max=250 >>> " >>> >>> 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 SSS. >>>> >>>> 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: 250 bytes. >>>> A
Re: [USRP-users] Sequence Errors N200
Sorry, here it is. Benchmark rate summary: Num received samples: 586436 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 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 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.24] 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.00 Msps on 1 channels >> >> On Wed, Jul 17, 2019 at 4:39 PM Nate Temple >> 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 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.75 (from [0.00, 31.50]) >>>> >>>> ..SS.SSS...S..SS.S..SS.SS...S.S...SS^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 >>>> 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: 250 bytes. >>>>> Actual sock buff size: 1048576 bytes. >>>>> See the transport application notes on buffer resizing. >>>>> Please run: sudo sysctl -w net.core.wmem_max=250 >>>>> [WARNING] [UDP] The send buffer could not be resized sufficiently. >>>>> Target sock buff size: 250 bytes. >>>>> Actual sock buff size: 1048576 bytes. >>>>> See the transport application notes
Re: [USRP-users] Sequence Errors N200
Tried 3 different power supplies, still the same. SS :-/ On Wed, Jul 17, 2019 at 5:20 PM Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com> wrote: > On 07/17/2019 11:10 AM, Sumit Kumar via USRP-users wrote: > > Sorry, here it is. > > Benchmark rate summary: > Num received samples: 586436 > 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 > > > Purely on a hunch, try swapping power supplies. > > > On Wed, Jul 17, 2019 at 5:08 PM Nate Temple 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 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.24] 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.00 Msps on 1 channels >>> >>> On Wed, Jul 17, 2019 at 4:39 PM Nate Temple >>> 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 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.75 (from [0.00, 31.50]) >>>>> >>>>> ..SS.SSS...S..SS.S..SS.SS...S.S...SS^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 >>>>> 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 >>>&g
Re: [USRP-users] Sequence Errors N200
472 bytes >>>>>> -- Current send frame size: 1472 bytes >>>>>> >>>>>> No gain specified. >>>>>> Setting gain to 15.75 (from [0.00, 31.50]) >>>>>> >>>>>> ..SS.SSS...S..SS.S..SS.SS...S.S...SS^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 >>>>>> 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: 250 bytes. >>>>>>> Actual sock buff size: 1048576 bytes. >>>>>>> See the transport application notes on buffer resizing. >>>>>>> Please run: sudo sysctl -w net.core.wmem_max=250 >>>>>>> [WARNING] [UDP] The send buffer could not be resized sufficiently. >>>>>>> Target sock buff size: 250 bytes. >>>>>>> Actual sock buff size: 1048576 bytes. >>>>>>> See the transport application notes on buffer resizing. >>>>>>> Please run: sudo sysctl -w net.core.wmem_max=250 >>>>>>> " >>>>>>> >>>>>>> >>>>>>> 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 SSS. >>>>>>>> >>>>>>>> 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: 250 bytes. >>>>>>>> Actual sock buff size: 1048576 bytes. >>>>>>>> See the transport application notes on buffer resizing. >>>>>>>> Please run: sudo sysctl -w net.core.wmem_max=250 >>>>>>>> [WARNING] [UDP] The send buffer could not be resized sufficiently. >>>>>>>> Target sock buff size: 250 bytes. >>>>>>>> Actual sock buff size: 1048576 bytes. >>>>>>>> See the transport application notes on buffer resizing. &
Re: [USRP-users] Sequence Errors N200
duce a >>>>> report at the end of the run? >>>>> >>>>> Regards, >>>>> Nate Temple >>>>> >>>>> On Wed, Jul 17, 2019 at 8:06 AM Sumit Kumar 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.24] 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.00 Msps on 1 channels >>>>>> >>>>>> On Wed, Jul 17, 2019 at 4:39 PM Nate Temple >>>>>> 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 >>>>>>> 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.75 (from [0.00, 31.50]) >>>>>>>> >>>>>>>> ..............SS.SSS...S..SS.S..SS.SS...S.S...SS^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 >>>>>>>> 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."
Re: [USRP-users] Sequence Errors N200
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 wrote: >>>>> >>>>>> Sorry, here it is. >>>>>> >>>>>> Benchmark rate summary: >>>>>> Num received samples: 586436 >>>>>> 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 >>>>>> 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 >>>>>>> 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.24] 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.00 Msps on 1 channels >>>>>>>> >>>>>>>> On Wed, Jul 17, 2019 at 4:39 PM Nate Temple >>>>>>>> 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 >>>>>>>>> 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++ vers
Re: [USRP-users] Sequence Errors N200
d 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 >>>>>>>>>> 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.75 (from [0.00, 31.50]) >>>>>>>>>>> >>>>>>>>>>> ..SS.SSS...S..SS.S..SS.SS...S.S...SS^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: 250 bytes. >>>>>>>>>>>> Actual sock buff size: 1048576 bytes. >>>>>>>>>>>> See the transport application notes on buffer resizing. >>>>>>>>>>>> Please run: sudo sysctl -w net.core.wmem_max=250 >>>>>>>>>>>> [WARNING] [UDP] The send buffer could not be resized >>>>>>>>>>>> sufficiently. >>>>>>>>>>>> Target sock buff size: 250 bytes. >>>>>>>>>>>> Actual sock buff size: 1048576 bytes. >>>>>>>>>>>> See the t
[USRP-users] Instructions to start working with USRP-2974
Hi, I have received a brand new USRP-2974 and looking for getting started guides. I went thru https://kb.ettus.com/USRP-2974_Getting_Started_Guide but cudn't get much info apart from making connections with uhd via PCIe. There is no note on making connection with 1GB ethernet. I was able to ping at 192.168.10.2 though. I never worked with this series so I lag its functionality. I understand that it is designed to use as standalone device. But can it be used like X-310 where I can stream the samples to my laptop for processing inside laptop instead of processing inside the USRP. At this link http://www.ettus.com/all-products/usrp-2974/, in the compatible software section it says Labview only. Can I use it with GNU Radio and UHD or have to work with Labview only ? The X-310 which I have to be given to other person soon and I was wondering if I can continue my work of X-310 on 2974 without much effort on porting. Regards Sumit ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Re: UHD 4.8 set_tx_bandwidth() and set_rx_bandwidth() method no longer works
Hi Alexandre,
This was confirmed by Tom on his email on 4th June.
Link: https://www.mail-archive.com/usrp-users%40lists.ettus.com/msg18359.html
BR
Sumit Kumar
Research and Technology Scientist
https://www.linkedin.com/in/sumitstop
https://sites.google.com/view/sumit1985
https://scholar.google.com/citations?hl=en&user=-qjjN2sJ
Luxembourg Institute of Science and Technology (LIST)
5, avenue des Hauts-Fourneaux | L-4362 Esch-sur-Alzette
[cid:ee829769-e2b4-44fd-87a1-4723cf7ecbf5]
From: Alexandre José Monteiro Sério via USRP-users
Sent: Thursday, June 12, 2025 7:12 PM
To: Marcus D. Leech ; usrp-users@lists.ettus.com
Subject: [USRP-users] Re: UHD 4.8 set_tx_bandwidth() and set_rx_bandwidth()
method no longer works
Hi Marcus,
My USRPs are the USRP-2944 from NI, and the daughterboards are UBX-160.
Here i find that "set_XX_bandwidth() is used to configure the analog filter
channel:
https://files.ettus.com/manual/classuhd_1_1rfnoc_1_1rf__control_1_1core__iface.html#a71f0132ae3c35a62e793e5aab1d8f11b
With your answer, i am now in doubt. In context, at the "usrp_lib.cpp" file of
the OpenAirInterface5G software they have the following snippet of code:
--
if (device->type != USRP_N300_DEV) {
for(int i=0; i<((int) s->usrp->get_tx_num_channels()) &&
iusrp->set_tx_bandwidth(openair0_cfg[0].tx_bw,i+choffset);
for(int i=0; i<((int) s->usrp->get_rx_num_channels()) &&
iusrp->set_rx_bandwidth(openair0_cfg[0].rx_bw,i+choffset);
}
for (int i=0; iusrp->get_rx_rate(i+choffset)/1e6);
LOG_I(HW," Actual RX frequency: %fGHz...\n",
s->usrp->get_rx_freq(i+choffset)/1e9);
LOG_I(HW," Actual RX gain: %f...\n", s->usrp->get_rx_gain(i+choffset));
LOG_I(HW," Actual RX bandwidth: %fM...\n",
s->usrp->get_rx_bandwidth(i+choffset)/1e6);
LOG_I(HW," Actual RX antenna: %s...\n",
s->usrp->get_rx_antenna(i+choffset).c_str());
}
for (int i=0; iusrp->get_tx_rate(i+choffset)/1e6);
LOG_I(HW," Actual TX frequency: %fGHz...\n",
s->usrp->get_tx_freq(i+choffset)/1e9);
LOG_I(HW," Actual TX gain: %f...\n", s->usrp->get_tx_gain(i+choffset));
LOG_I(HW," Actual TX bandwidth: %fM...\n",
s->usrp->get_tx_bandwidth(i+choffset)/1e6);
LOG_I(HW," Actual TX antenna: %s...\n",
s->usrp->get_tx_antenna(i+choffset).c_str());
LOG_I(HW," Actual TX packet size:
%lu\n",s->tx_stream->get_max_num_samps());
--
From what i am understanding, this set_XX_bandwidth() functions are not doing
anything since UBX-160 daughterboards work at a fixed analog bandwidth of 160
MHz, is that right??? (In my case of these x310, the value that is passed over
"openair0_cfg[0].tx_bw" is 5 MHz)
Fact is that, when i was using v4.7.0.0 of the UHD lib, the output values from
the "get_XX_bandwidth()" were the same passed by the "set_XX_bandwidth()". That
doesn't happen when using v4.8.0.0. Thats why i'm confused by your answer.
I'm a begginer in the USRP usage, so i'm trying to understand and learn so any
"docs or references" are mostly welcome too...
Thank you Marcus
De: Marcus D. Leech
Enviado: 4 de junho de 2025 15:19
Para: usrp-users@lists.ettus.com
Assunto: [USRP-users] Re: UHD 4.8 set_tx_bandwidth() and set_rx_bandwidth()
method no longer works
Atenção: Este email foi originado fora da MEO SGPS, S.A. Por favor, não clique
em links nem abra anexos, a não ser que conheça o remetente e saiba que o seu
conteúdo é seguro.
On 2025-06-04 08:15, Alexandre José Monteiro Sério via USRP-users wrote:
I'm working with NI x310 USRPs for OAI testing and developing purposes and,
when using v4.8 of the UHD i have the same issue as well. With the v4.7, the
set_tx_bandwidth()/set_rx_bandwidth() do work, getting the values from the
get_tx_bandwidth()/get_tx_bandwidth() in accordance. In the case of v4.8, it
seems that those "set" functions are not doing anything as you say... Couldn't
find any solution or explanation for that yet...
The set_XX_bandwidth calls configure the *ANALOG* bandwidth of the RF front-end
on the USRP.
In MANY cases, those analog front-ends have no way to set the analog bandwidth,
so those calls do nothing. I can't immediately think of any X310-compatible
daughtercards that have variable analog bandwidth--which cards do you have?
De: Tommy Tsui
Enviado: 31 de maio de 2025 04:14
Para: usrp-users@lists.ettus.com
Assunto: [USRP-users] UHD 4.8 set_tx_bandwidth() and set_rx_bandwidth() method
no longer works
You don't often get email from
tommyt...@w5tech.com. Learn why this is
important
