Common Problems and Fixes

Radio Connectivity Problems	Radio Discovery Problems	Host Configuration Problems	Performance Optimization Problems
Cannot Log into Computer Ethernet Subnet Conflict Ping Command Times Out USB 2.0 Not Fast Enough with Bus Series Radios	Firmware is Incompatible with Host Build USRP Radio is Busy USRP Radio is Not Responding No devices Found Function findsdru Throws Error When VPN is ON	Unexpected Number of Samples in Burst Reception Buffer Cannot be Resized UHD Driver Cannot Set Thread Priorities Invalid MEX file	Getting Overruns or Underruns 8-bit Transport in Streaming Mode Cause libuhd Error Burst Mode Failure Data Not Transmitted or Received using SDRu Blocks Because of Large Number of Underruns or Overruns

Cannot Log into Computer

Problem

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

Possible Solution

For more information, see Using One Ethernet Port.

Ethernet Subnet Conflict

Problem

You cannot establish the host-radio connection because the IP address is on a subnet that the host computer is using for another Ethernet port or for the wireless network interface.

Possible Solution

Follow the directions provided at Resolving Ethernet Subnet Conflict.

Ping Command Times Out

Problem

The ping command returns a message 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.

Firmware is Incompatible with Host Build

Problem

MATLAB^® returns this warning message from a call to the findsdru function along with status '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.

USRP Radio is Busy

Problem

MATLAB returns this warning message from a call to the findsdru function along with status 'Radio 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 these 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.

USRP Radio is Not Responding

Problem

The function findsdru(IPAddress), where IPAddress is the IP address of a USRP radio, returns this warning message along with the status '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 can be an Ethernet connection problem between the host computer and the USRP radio. See Check Ethernet Configuration.

Unexpected Number of Samples in Burst Reception

Problem

You might get an error message similar to this 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 might not be large enough for proper communication between the radio and MATLAB or Simulink. 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 can try Intel^® chipsets, which provides high-quality connection in such cases.
The firewall or virus protection program on your system can block or slow down your connection. Turning off the firewall or virus program might eliminate this problem.

Note
Turning off your firewall can expose your host computer to unauthorized access through the Internet.
Some laptops lose their Ethernet settings when the Ethernet connection is interrupted, for example when you power cycle 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 choose a plan for maximum CPU performance.

Buffer Cannot be Resized

Problem

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

The recv buffer could not be resized sufficiently

---------- 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 sufficiently:

---------- 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

The messages from the UHD driver provide sysctl commands. To resolve the issue, run the commands in a Linux shell.

UHD Driver Cannot Set Thread Priorities

Problem

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

Possible Solution

This warning is harmless and you do not need to fix the issue. For more information, see Thread priority scheduling.

Invalid MEX file

Problem

The function findsdru might crash or throw an error similar to this:

??? 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:

You do not load a correct version of the libuhd or Boost libraries.
You load an incorrect version of libuhd or Boost libraries.

This situation can happen if 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:

Navigate to <SDRuInstallRoot>/bin/glnxa64 within the MATLAB command window. For example:
```
cd c:/work/sdr/sdru/bin/glnxa64 
```

Type this command:

!ldd libmwusrp_uhd_capi.so

You can see messages similar to these:

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 you pull all the boost libraries 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 the libraries are not 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 this 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.

Getting Overruns or Underruns

Problem

The model is not running in real time.

Possible Solution

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

Use Burst mode. See Burst-Mode Buffering.
Reduce transport data rate to 8-bit. See Change Transport Data Rate.
Use vector-based processing.
Accelerate with code generation.

No devices Found

Problem

When you plug in a radio and run the findsdru function, it might return a status 'No devices found'. However, the firmware image loads automatically and 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 and 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'

USB 2.0 Not Fast Enough with Bus Series Radios

Problem

The USB 2.0 connection is not fast enough for certain high sample rate applications when you use 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.

8-bit Transport in Streaming Mode Cause `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.

To use burst mode, see Burst-Mode Buffering.
To change the transport data type to 16-bit, see Change Transport Data Rate.

Burst Mode Failure

Problem

You encounter this 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 the 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 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 choose a plan for maximum CPU performance.

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 resolve this issue, set the Simulink configuration parameter Underspecified Initialization Detection to Classic instead of Simplified.

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

In the Simulink toolstrip, on the Modeling tab, click Model Settings to modify the Model Configuration parameters.
Select Data Validity under the Diagnostics tab and then expand the advanced parameters by clicking … at the bottom of the Data Validity tab.
Change the parameter Underspecified Initialization detection to Classic.

Function `findsdru` Throws Error When VPN is ON

Problem

The function findsdru throws these errors when the 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.