Main Content

Common Problems and Fixes

Troubleshoot Cannot Log into Computer

Problem

The host computer has only one Ethernet connection available, and you disconnected the internet connection to use the network interface card (NIC) for the host-to-radio connection. Then, you did not reconnect to the Internet using that NIC before logging out.

Possible Solution

For more information, see Using One Ethernet Port.

Troubleshoot Ethernet Subnet Conflict

Problem

The host-to-radio connection cannot be established because the IP address of the radio is on a subnet that is being used by the host computer for another Ethernet port or for the wireless network interface.

Possible Solution

Follow the directions provided at Resolving Ethernet Subnet Conflict.

Troubleshoot Ping Command Times Out

Problem

Ping command returns a message indicating it cannot reach the hardware.

Possible Solution

You can try any of the following:

  • Check Ethernet Configuration

  • Check that your firewalls are either disabled or set up to pass data from the subnet configured on your radio. The factory default subnet configuration on the radio is 192.168.10.X.

Troubleshoot Firmware is Incompatible with Host Build

Problem

The function findsdru gives the following warning message: 'Not compatible'.

Warning message stating that the device is not compatible

The firmware installed on the USRP™ radio is incompatible with the UHD™ software version of the support package.

Possible Solution

Update the firmware for your USRP radio. See USRP Radio Firmware Update.

Troubleshoot USRP Radio is Busy

Problem

MATLAB® returns the following warning message from a call to function findsdru: Busy.

Warning message stating that the device is busy

The USRP radio is in use by another MATLAB or Simulink® entity. USRP radios can become busy when any of the following conditions occur:

  • A Simulink simulation is in progress.

  • A receiver or transmitter block mask is open.

  • A locked receiver or transmitter System object™ is in memory.

Possible Solution

You can release the radio by stopping the simulation, closing the block, or calling the release method of the System object.

Troubleshoot USRP Radio is Not Responding

Problem

The function findsdru(IPAddress), where IPAddress is the IP address of a USRP radio, returns the following warning message: Not responding.

Warning message stating that the device is not responding

Possible Solution

This warning indicates that your subnet configuration is incorrect. For example, if the USRP radio has an IP address of 192.168.10.2, but the host IP address is on another subnet and has an IP address of 192.168.X.1, where X is a number other than 10.

Correct the host IP address so that it matches the subnet value of the USRP radio as described in Configure Host Computer for Ethernet-Based USRP Radio Connection .

Alternatively, there may be an Ethernet connection problem between the host computer and the USRP radio. See Check Ethernet Configuration.

Troubleshoot Unexpected Number of Samples in Burst Reception

Problem

You may get an error message similar to the following while using burst mode:

Could not execute UHD driver command in 'receiveData_c': 
libmwusrp_uhd_capi:receiveData:ErrWrongRecvSize 
Did not receive expected number of samples in a burst reception. 
This is likely due to overflow within the burst. 
Use 'sysctl' to update the OS socket buffer size.
Expected: 2752000
Found : 94120

This error occurs when the MATLAB or Simulink software does not receive the requested number of samples from the USRP radio.

Possible Reasons and Solutions

The following are known causes of this problem:

  • On Linux® systems, the OS socket buffer size may not be large enough for proper communication. Increase the socket size as described in the Ettus Research™ UHD - Transport (Sockets).

  • The Ethernet card is not able to provide high-speed communication. You may want to try Intel® chipsets, which can provide high-quality connection in such cases.

  • The firewall or virus protection program on your system may be blocking or slowing down your connection. Turning off the firewall or virus program may eliminate this problem.

    Note

    Turning off your firewall may expose your host computer to unauthorized access through the Internet.

  • Some laptops may lose their Ethernet settings when the Ethernet connection is interrupted, for example when power cycling the USRP device. Check the Ethernet connection settings as described in Configure Host Computer for Ethernet-Based USRP Radio Connection.

  • With laptops, try connecting the laptop to a power supply. Most laptops are configured for better battery life and compromise processing performance when they are not connected to a power supply. For both battery mode and AC power supply mode, make sure that you have a power setting corresponding to maximum processing performance. Some laptop manufacturers also provide advanced power settings to help chose a plan for maximum CPU performance.

Troubleshoot Buffer Can Not be Resized

Problem

You may see one of the following messages from the UHD driver in the MATLAB command window.

The recv buffer could not be resized:

---------- begin libuhd warning message output ----------
The recv buffer could not be resized sufficiently.
Target sock buff size: 50000000 bytes.
Actual sock buff size: 131071 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.rmem_max=50000000
---------- end libuhd warning message output ----------

The send buffer could not be resized:

---------- begin libuhd warning message output ----------
The send buffer could not be resized sufficiently.
Target sock buff size: 1048576 bytes.
Actual sock buff size: 131071 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.wmem_max=1048576
---------- end libuhd warning message output ----------

Possible Solution

If you encounter either of these messages, run the sysctl commands provided in the message in a Linux shell.

Troubleshoot UHD Driver Can Not Set Thread Priorities

Problem

You may see a warning stating that the UHD driver was not able to set the thread priority.

Possible Solution

This warning is harmless. You can get more information on this subject at Thread priority scheduling.

Troubleshoot Invalid MEX file

Problem

The function findsdru may crash or throw an error similar to the following:

??? Invalid MEX-file

<SDRuInstallRoot>/bin/glnxa64/usrp_uhd_mapi.mexa64':
<SDRuInstallRoot>/bin/glnxa64/libmwusrp_uhd_capi.so: 
    undefined symbol:_ZN3uhd7warning16register_handlerERKSsRKN5boost8functionIFvSsEEE
Error in ==> mapiPrivate at 19
[retStr, errStat, errStr] = usrp_uhd_mapi(cmd);
Error in ==> findsdru at 25
[flatAddrList, errStat, errStr] = mapiPrivate('findsdru');

Possible Reasons and Solutions

This type of error usually occurs when:

  • A correct version of the libuhd or Boost libraries was not loaded.

  • An incorrect version of these libraries was loaded.

This situation may happen if either the system path does not contain the correct path information for these libraries or a previously installed version of these libraries shadows the Support Package for USRP Radio required libraries.

You can diagnose this issue by following these steps:

  1. Navigate to <SDRuInstallRoot>/bin/glnxa64 within the MATLAB command window. For example:

    cd c:/work/sdr/sdru/bin/glnxa64 
  2. Type the following command:

    !ldd libmwusrp_uhd_capi.so

    You should see messages similar to the following:

    linux-vdso.so.1 => (0x00007ffff35ff000)
    libuhd.so.003=> 
    <SDRuInstallRoot>/glnxa64/commusrp/bin/glnxa64/./libuhd.so.003 (0x00007fc9476bb000)
    
    libstdc++.so.6=> 
    <MATLABROOT>>/sys/os/glnxa64/libstdc++.so.6 (0x00007fc9473b4000)
    
    libm.so.6 => /lib/libm.so.6 (0x00007fc947113000)
    
    libgcc_s.so.1 => 
    <MATLABROOT>>/sys/os/glnxa64/libgcc_s.so.1 (0x00007fc946efd000)
    
    libpthread.so.0 => /lib/libpthread.so.0 (0x00007fc946ce0000)
    
    libc.so.6 => /lib/libc.so.6 (0x00007fc94697f000)
    
    
    libboost_date_time.so.1.44.0=><MATLABROOT>>/bin/glnxa64/libboost_date_time.so.1.44.0 
    (0x00007fc94676d000)
    
    libboost_filesystem.so.1.44.0=><MATLABROOT>/bin/glnxa64/libboost_filesystem.so.1.44.0 
    (0x00007fc946549000)
    
    libboost_program_options.so.1.44.0=><MATLABROOT>/bin/glnxa64/
    libboost_program_options.so.1.44.0 (0x00007fc9462ef000)
    
    libboost_regex.so.1.44.0=><MATLABROOT>/bin/glnxa64/
    libboost_regex.so.1.44.0 (0x00007fc945fdd000)
    
    libboost_system.so.1.44.0=><MATLABROOT>/bin/glnxa64/
    libboost_system.so.1.44.0 (0x00007fc945dd9000)
    
    l/ibboost_thread.so.1.44.0=><MATLABROOT>/bin/glnxa64/
    libboost_thread.so.1.44.0 (0x00007fc945bc2000)
    
    libboost_unit_test_framework.so.1.44.0=><MATLABROOT>/bin/glnxa64/...
    ... libboost_unit_test_framework.so.1.44.0 (0x00007fc945906000)
    
    librt.so.1 => /lib/librt.so.1 (0x00007fc9456fd000)
    
    libdl.so.2 => /lib/libdl.so.2 (0x00007fc9454f9000)
    
    /lib64/ld-linux-x86-64.so.2 (0x00007fc947d73000)
    
    libicuuc.so.44=><MATLABROOT>/bin/glnxa64/libicuuc.so.44 (0x00007fc945196000)
    
    libicui18n.so.44=><MATLABROOT>/bin/glnxa64/libicui18n.so.44(0x00007fc944d9e000)
    
    libicudata.so.44=><MATLABROOT>/bin/glnxa64/libicudata.so.44 (0x00007fc943d5e000)

    Make sure that all the boost libraries are pulled from the MATLAB installation locations but not from the system (for example, /usr/lib or /lib), or some other local installation.

    If you do not get these results, for example if either the libraries are not being found or different versions of boost or libuhd are found, then the LD_LIBRARY_PATH is likely incorrect. You can check the value of the LD_LIBRARY_PATH by typing the following command in the MATLAB command window.

    getenv('LD_LIBRARY_PATH')
    ans =
    <MATLABROOT>/sys/os/glnxa64:
    
    <MATLABROOT>/bin/glnxa64:
    
    <MATLABROOT>/extern/lib/glnxa64:
    
    <MATLABROOT>/sys/java/jre/glnxa64/jre/lib/amd64/native_threads:
    
    <MATLABROOT>/sys/java/jre/glnxa64/jre/lib/amd64/server:
    
    <MATLABROOT>/sys/java/jre/glnxa64/jre/lib/amd64:
    
    <SDRuInstallRoot>/glnxa64/commusrp/bin/glnxa64

    This example shows the default value as created by MATLAB and the setupsdru function.

Troubleshoot Getting Overruns or Underruns

Problem

Model is not running in real time.

Possible Solution

If your model is not running in real time, you can:

Troubleshoot No devices Found

Problem

When you plug in a radio and run function findsdru, the function may return a message stating "No devices found". However, the firmware image is loaded automatically and it shows that the host computer is able to recognize the radio.

Possible Solution

Ettus Research has confirmed that this issue is known to occur with certain models/revisions of USB controllers. The solution is to disconnect then reconnect the radio, possibly a few times.

================== Connect radio to host computer ====================

>> x = findsdru
Loading firmware image: /Users/Shared/supportpackages/usrpradio/toolbox/shared/sdr/sdru/uhdapps ...
                        /images/usrp_b200_fw.hex...

x = 

     Platform: ''
    IPAddress: ''
    SerialNum: ''
       Status: 'No devices found'


================== Disconnect the radio and re-connect ================

>> x = findsdru
Loading firmware image: /Users/Shared/supportpackages/usrpradio/toolbox/shared/sdr/sdru/ ...
                        uhdapps/images/usrp_b200_fw.hex...
Loading FPGA image: /Users/Shared/supportpackages/usrpradio/toolbox/shared/sdr/sdru/ ...
                    uhdapps/images/usrp_b210_fpga.bin...

x = 

     Platform: 'B210'
    IPAddress: ''
    SerialNum: 'ECR04ZDBT'
       Status: 'Success'

Troubleshoot USB 2.0 Not Fast Enough with Bus Series Radios

Problem

USB 2.0 connection is not fast enough for certain high sample rate applications when using a Bus Series radio.

Possible Solution

You can use a USB 3.0 connection to get a more reliable connection for high-speed needs. See https://kb.ettus.com/B200/B210/B200mini/B205mini#FAQ.

Troubleshoot 8-bit Transport in Streaming Mode Causes libuhd Error

Problem

A UHD exception occurs when you attempt 8-bit transport in streaming mode using a Bus Series radio.

Error using comm.SDRuReceiver/stepImpl
Could not execute UHD driver command in 'receiveData_c': libmwusrp_uhd_capi:receiveData:ErrBadPacket 
The communication transport received a mal-formed packet.

Possible Solution

You can either use burst mode buffering or change the transport data type to 16-bit.

Troubleshoot Burst Mode Failure

Problem

You encounter the following error:

Error using comm.SDRuReceiver/stepImpl
Could not execute UHD driver command in 'receiveData_c': libmwusrp_uhd_capi:receiveData:ErrWrongRecvSize
Did not receive expected number of samples in a burst reception.
This is likely due to overflow within the burst.  Use 'sysctl' to update the OS socket buffer size.
Expected: 4000000
Found   : 163741 

Possible Solution

  • Change transport data type to int8. This change can possibly double the achievable sample rate. See Change Transport Data Rate,

  • If you have a Bus Series radio, make sure that you use a USB 3 connection.

    See the recommended USB 3.0 controllers from Ettus Research: https://kb.ettus.com/About_USRP_Bandwidths_and_Sampling_Rates.

    You can use the benchmark_rate utility from UHD to test whether a transport speed can be sustained between the radio and the host PC. This example demonstrates testing the transmit rate:

     call_uhd_app('benchmark_rate','--tx_rate 20e6','-echo');
    linux; GNU C++ version 4.7.2; Boost_105600; UHD_003.009.001-vendor
    
    
    Creating the usrp device with: ...
    -- Detected Device: B210
    -- Operating over USB 3.
    -- Initialize CODEC control...
    -- Initialize Radio control...
    -- Performing register loopback test... pass
    -- Performing register loopback test... pass
    -- Performing CODEC loopback test... pass
    -- Performing CODEC loopback test... pass
    -- Asking for clock rate 16.000000 MHz... 
    -- Actually got clock rate 16.000000 MHz.
    -- Performing timer loopback test... pass
    -- Performing timer loopback test... pass
    -- Setting master clock rate selection to 'automatic'.
    Using Device: Single USRP:
      Device: B-Series Device
      Mboard 0: B210
      RX Channel: 0
        RX DSP: 0
        RX Dboard: A
        RX Subdev: FE-RX2
      RX Channel: 1
        RX DSP: 1
        RX Dboard: A
        RX Subdev: FE-RX1
      TX Channel: 0
        TX DSP: 0
        TX Dboard: A
        TX Subdev: FE-TX2
      TX Channel: 1
        TX DSP: 1
        TX Dboard: A
        TX Subdev: FE-TX1
    
    -- Asking for clock rate 20.000000 MHz... 
    -- Actually got clock rate 20.000000 MHz.
    -- Performing timer loopback test... pass
    -- Performing timer loopback test... pass
    Testing transmit rate 20.000000 Msps on 1 channels
    
    Benchmark rate summary:
      Num received samples:    0
      Num dropped samples:     0
      Num overflows detected:  0
      Num transmitted samples: 200058544
      Num sequence errors:     0
      Num underflows detected: 0
    
    

    This second example demonstrates testing the receive rate:

    call_uhd_app('benchmark_rate','--rx_rate 20e6','-echo');
    linux; GNU C++ version 4.7.2; Boost_105600; UHD_003.009.001-vendor
    
    
    Creating the usrp device with: ...
    -- Detected Device: B210
    -- Operating over USB 3.
    -- Initialize CODEC control...
    -- Initialize Radio control...
    -- Performing register loopback test... pass
    -- Performing register loopback test... pass
    -- Performing CODEC loopback test... pass
    -- Performing CODEC loopback test... pass
    -- Asking for clock rate 16.000000 MHz... 
    -- Actually got clock rate 16.000000 MHz.
    -- Performing timer loopback test... pass
    -- Performing timer loopback test... pass
    -- Setting master clock rate selection to 'automatic'.
    Using Device: Single USRP:
      Device: B-Series Device
      Mboard 0: B210
      RX Channel: 0
        RX DSP: 0
        RX Dboard: A
        RX Subdev: FE-RX2
      RX Channel: 1
        RX DSP: 1
        RX Dboard: A
        RX Subdev: FE-RX1
      TX Channel: 0
        TX DSP: 0
        TX Dboard: A
        TX Subdev: FE-TX2
      TX Channel: 1
        TX DSP: 1
        TX Dboard: A
        TX Subdev: FE-TX1
    
    -- Asking for clock rate 20.000000 MHz... 
    -- Actually got clock rate 20.000000 MHz.
    -- Performing timer loopback test... pass
    -- Performing timer loopback test... pass
    Testing receive rate 20.000000 Msps on 1 channels
    
    Benchmark rate summary:
      Num received samples:    199989048
      Num dropped samples:     0
      Num overflows detected:  0
      Num transmitted samples: 0
      Num sequence errors:     0
      Num underflows detected: 0
    
  • With laptops, try connecting the laptop to a power supply. Most laptops are configured for better battery life and compromise processing performance when they are not connected to a power supply. For both battery mode and AC power supply mode, make sure that you have a power setting corresponding to maximum processing performance. Some laptop manufacturers also provide advanced power settings to help chose a plan for maximum CPU performance.

Troubleshoot Data Not Transmitted or Received using SDRu Blocks Because of Large Number of Underruns or Overruns

Problem

SDRu blocks experience severe underruns or overruns even at low sample rates (like 200 KHz). The SDRu blocks report severe underruns or overruns even when you run the model in rapid accelerator mode.

Possible Solution

To overcome this problem, set the Simulink configuration parameter Underspecified Initialization Detection to Classic instead of Simplified.

To update this parameter in the Simulink model, follow these steps.

  1. In the Simulink toolstrip, on the Modeling tab, click Model Settings to modify the Model Configuration parameters.

  2. Select Data Validity under the Diagnostics tab and then expand the advanced parameters by clicking at the bottom of the Data Validity tab.

  3. Change the parameter Underspecified Initialization detection to Classic.

Troubleshoot Function findsdru Throws Error When VPN is ON

Problem

The function findsdru throws these errors when virtual private network (VPN) is ON.

---------- begin libuhd error output ----------
X300 Network discovery error receive_from: An existing connection was forcibly closed by the remote host
---------- end libuhd error output ----------
---------- begin libuhd error output ----------
Device discovery error: receive_from: An existing connection was forcibly closed by the remote host
---------- end libuhd error output ----------

Possible Solution

Switch off the VPN and run the findsdru function again.