Frequently Asked Questions

When I run a simulation, I get a few/many "uO" or "uU" messages on the MATLAB command line. What does that mean?

"uO" stands for "USRP overrun" and means that the host PC could not receive data from the USRP as fast as new samples were captured off the air. This message is produced by usrp_source blocks.

"uU" stands for "USRP underrun" and means that the host PC could not produce new samples as fast as the USRP sended them out. This message is produced by usrp_sink blocks.

In both cases, these messages mean that data was lost and discontinuitites were introduced into the signal. The following options reduce the overruns/underruns:

  • If possible, increase the Decimation Factor and Interpolation Factor of sources and sinks, thus lowering the data rate across the USB and the amount of data to process on the host computer.
  • Accelerate simulations by using the simulation mode Rapid Accelerator. This will make Simulink compile your model into one executable file, thus reducing overhead of the simulation. Depending on your installed MATLAB products, the Rapid Accelerator mode might not be available to you. (from R2007b)
  • Reduce the computational complexity of your model.
  • If the USB bus is the bottleneck, set the Sample Width parameter of usrp_source blocks to 8 Bit. The drawback is that this reduces the dynamic range of the signal.

If the "uO" or "uU" messages appear right away when the simulation is started, but no new overruns occur, it is highly likely that these messages are incorrect and no overrun occured at all. This is a known bug in the USRP.

When I open any block from the USRP blockset, something like "usb_control_msg failed: usb_control_msg: sending control message failed [...]" gets displayed on the MATLAB command line. What does this mean?

This happens when a USRP board with empty daughterboard slots is connected to the computer. Put a daughterboard into every slot or ignore this message.

The Serial Number of my USRP devices sometimes only gets displayed as "S/N: ." - what's wrong?

This is a know bug, the cause has not been found yet. This seems to happen most often when we are dealing with unconfigured USRPs without firmware/bitstream. Disconnecting and reconnecting the USB cable of the USRP and issuing clear mex; on the MATLAB command promt often helps.

Why don't you provide binary files for the Simlink-USRP interface? I don't like installing a C++ compiler on my computer.

libusrp, the library which is used to talk to the USRP, configure its daughterboards etc., is released by the Free Software Foundation/GNU Radio under the GNU General Public License (GPL). Speaking simplified, it may therefore not be linked with any binary libraries for which the source code is not freely available to everyone. Since Simulink-USRP links against MATLAB libraries, which are only available in binary format, we are not allowed to give out binary files for Simulink-USRP.