Main Content

Common Problems and Fixes

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.

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.

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.

Firmware is incompatible with host build

Problem

The function findsdru gives the following warning message: '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 the following warning message from a call to function findsdru: 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.

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.

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 Radio Connection .

Alternatively, there may 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 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 ResearchTM 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 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.

Buffer could 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.

UHD driver cannot 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.

Function findsdru throws error

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.

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:

Slow Response for SDR System Objects and Blocks

Problem

It seems to take a long time to display an SDRu object, or to display an SDRu object property, or to open an SDRu block mask.

Possible Solution

When any of those operations occur, the object or block is communicating with the USRP radio to access actual device values. This process can take some seconds, and is to be expected.

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'

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.

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.

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.

Communications Toolbox Support Package for USRP Radio Documentation

Support

Bridging Wireless Communications Design and Testing with MATLAB

Bridging Wireless Communications Design and Testing with MATLAB

Download white paper