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.
For more information, see Using One Ethernet Port.
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.
Follow the directions provided at Resolving Ethernet Subnet Conflict.
Ping command returns a message indicating it cannot reach the hardware.
You can try any of the following:
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.
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.
Update the firmware for your USRP radio. See USRP Radio Firmware Update.
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.
You can release the radio by stopping the simulation, closing the block, or calling
the release
method of the System object.
The function findsdru(IPAddress)
, where
IPAddress
is the IP address of a USRP radio, returns the following warning message: Not
responding
.
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.
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.
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.
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 ----------
If you encounter either of these messages, run the sysctl commands provided in the message in a Linux shell.
You may see a warning stating that the UHD driver was not able to set the thread priority.
This warning is harmless. You can get more information on this subject at Thread priority scheduling.
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');
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:
Navigate to <SDRuInstallRoot>/bin/glnxa64
within the
MATLAB command window. For example:
cd c:/work/sdr/sdru/bin/glnxa64
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.
Model is not running in real time.
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
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.
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.
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.
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 connection is not fast enough for certain high sample rate applications when using a Bus Series radio.
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.
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.
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 transport data type to 16-bit, see Change Transport Data Rate.
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
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.