NI-USRP 17.2 Known Issues

Overview

This document contains the NI-USRP 17.2 known issues that were discovered before and since the release of NI-USRP 17.2. Not every issue known to NI appears on this list; it is intended to show the most severe and common issues that can be encountered.

Each issue appears as a row in the table and includes the following fields:

  • Issue ID - The number in at the top of each of the cells in the first column. When you report an issue to NI, you may be given this ID, you can also find IDs posted by NI on the discussion forums or in Knowledge Base articles.  "N/A" indicates that there is no ID assigned to the issue.
  • Issue Title (in italics) - Describes the issue in one sentence or less.
  • Problem Description - A few sentences which describe the problem in further detail. The brief description given does not necessarily describe the problem in full detail, and it is expected that you may want more information on an issue. If you would like more information on an issue, contact NI and reference the ID number given in the document.
  • Workaround - Possible ways to work around the problem. The workarounds that appear in the document are not always tested by NI and are not guaranteed to resolve the issue. If a workaround refers you to the NI KnowledgeBase, visit www.ni.com/kb/ and enter the KnowledgeBase number in the search field to locate the specific document.
  • Reported Version - The earliest version of NI-USRP in which the issue was reported. If you discover the issue appears in an earlier version of NI-USRP than is reported in this field, report the discrepancy to NI to have the field updated.
  • Resolved Version - Version in which the issue was resolved or was no longer applicable. "N/A" indicates that the issue has not been resolved.
  • Date Added - The date the issue was added to the document (not the reported date).

Known Issues

696360Intermittent parsing errors when fetching GPS NMEA strings from USRP-2974 device.
692623Device State in software of a USRP RIO device connected to a USRP-2974 through the PCIe port changes when using LabVIEW Communications System Design Suite.
691935USRP devices may enter a bad state and require restarting when an error occurs during transmission.
690803Certain uses of Advanced Configure Power and Mixer on USRP-2944/2954 force the receiving antenna selection to RX2.
686898When attempting to generate an NI-USRP Sample Project, error 1073 appears intermittently.
682721When changing the Host Data Type in a NI-USRP session in between acquisitions, an overflow is falsely reported.
649538Tx Underflow Error (-1074118645) occurs at low I/Q rates on USRP RIO devices when using the NI-USRP API.
626202When opening multiple new streaming sessions using the NI-USRP API to the same device, you may receive an error.
614923LabVIEW may crash when using USRP-2945/2955 and the NI-USRP API if configure frequency is called with a command time too far in the future.
610228On the USRP-2945/2955, a second harmonic LO spur may be observed when sharing LOs.
600668 Rx transients when using the USRP-2944/2954 devices.
595649When using LabVIEW Communications 2.0, the Rx Custom Sample Type and Size example is broken.
586927Subsequent configurations of the LO frequency require a delay to allow the clock to settle.
562870NI-USRP Configuration Utility seems to hang when updating the image of a USRP.
542084Invalid samples received after retuning the LO on a USRP-2944/2954 device.
540599When you open an NI-USRP API session to a device that is already being used as a LabVIEW FPGA device with the niUsrpRio Configuration Instrument Design Library, errors result from the existing session.
539338The status of the USRP RIO Local Oscillator (LO) lock may be true even when the LO has not been configured.
532349Timed commands do not work with the USRP-2900/2901 device.
529907Configuring I/Q rate on two simultaneous sessions to the same USRP-2900/2901 device can result in incorrect coerced I/Q rate values.
528194Incorrect frequency coercion can result when you set the LO frequency to a non-default value on an USRP-2900/2901 device.
527016Setting the LO Frequency property node to the default value of -1 results in wrong carrier frequency coercion on the USRP-2901 device.
519572Changing the I/Q rate can cause discontinuity in the time reported by the device.
518489Repeatedly aborting and then initiating an NI-USRP session occasionally causes a packet timeout error with USRP-2900/2901 devices.
488044Error -61083 and corrupted data can occur when you use clocks derived from the data clocks.
487251The NI-USRP Configuration Utility may incorrectly report that an image update is needed for USRP-2920/2921/2922/2930/2932 devices already in use.
487061USRP-2920/2921/2922/2930/2932 devices may not return an error if an external reference signal is missing.
469466Errors occur when you use multiple devices on different buses in a single session.
467209Error -107411864 "A stream command was issued in the past" occurs when you set Timebase Clock Source to PpsIn and do not provide a timebase clock source to the PPS IN port.
460810Runtime errors occur when you open one session to multiple devices and another session to a subset of those devices.
460704Out-of-sequence errors occur when you use NI-USRP over an Ethernet connection.
460113Hibernation is not supported for the USRP-2940/2942/2943/2944/2945/2950/2952/2953/2954/2955 (USRP RIO) devices over PCI Express.
460109Sleep is not supported for the USRP RIO devices over PCI Express.
458782There is a large transient time at the beginning of a Tx session or Rx session when you use the USRP-2943/2953 device.
458163When you use NI-USRP and the USRP RIO devices, 24 samples of the previous acquisition are present at the beginning of a new acquisition.
456625The niUSRP Fetch Rx Data VIs do not respect "channel list" control.
442853Opening an FPGA reference fails with error -63150 on USRP RIO devices.
360108The niUSRP Write Tx Data VI sometimes ignores timeout if end of data? is TRUE.
349079Streaming performance for multi-device sessions is sometimes low.
340767NI-USRP Configuration Utility fails to reset after you upgrade the firmware or FPGA.
310810NI-USRP returns one of the following errors during Tx: "Packet loss between host and device." or "Packet loss within a burst."
295724Transients exist for both Tx and Rx.



IDKnown Issue
696360

Return
Intermittent parsing errors when fetching GPS NMEA strings from USRP-2974 device.
Parsing errors occur due to NULL characters coming in from the USRP-2974 FPGA when fetching NMEA strings on the host.

Workaround: Fetch the NMEA strings after longer intervals so that the parsing errors are not as frequent. At the device level, the GPS NMEA data gets renewed only once every second, so the maximum fetch interval can be fixed to once per second. Also, clear the parsing error when it occurs from Get GPS Nmea Strings using Clear Errors.
Reported Version: 17.2  Resolved Version: N/A  Added: 05/24/18
692623

Return
Device State in software of a USRP RIO device connected to a USRP-2974 through the PCIe port changes when using LabVIEW Communications System Design Suite.
When using LabVIEW Communications System Design Suite, the Device State in software of a USRP RIO device that is externally connected to a USRP-2974 device through the PCIe port changes from Connected to Not Mapped when the same connection is made in SystemDesigner.

Workaround: Do not connect the PCIe ports of a USRP-2974 device and the external USRP RIO device on SystemDesigner.
Reported Version: 17.2  Resolved Version: N/A  Added: 05/24/18
691935

Return
USRP devices may enter a bad state and require restarting when an error occurs during transmission.
If an error occurs while the "end of data" control is set to true on an niUSRP Write Tx API VI, the device may enter a bad state. You may receive additional errors related to RIO or a busy FPGA on subsequent runs of the application. To return the device to a good state, restart the device and system.

Workaround: Set the end of data control to false on write calls. If you are using continuous write calls in a loop, set end of data to false on the last call when you stop the application.
Reported Version: 17.1  Resolved Version: N/A  Added: 04/24/18
690803

Return
Certain uses of Advanced Configure Power and Mixer on USRP-2944/2954 force the receiving antenna selection to RX2.
Using the Advanced Configure Power and Mixer to enable both the mixer and power functions for both the transmitting and receiving channels forces the antenna configuration to TX1 RX1 transmitting and RX2 receiving.

Workaround: For the USRP-2944/2954, use Advanced Configure Power Mode instead of Advanced Configure Power and Mixer to customize the power state of components in the inactive signal path (e.g. set the inactive transmitting channel to be powered while receiving is active). You can find Advanced Configure Power Mode in one of the following locations.

If you are using LabVIEW:
<instr.lib>\niUsrpRio\Config\v1\Host\Private\Advanced Configure Power Mode.vi

If you are using LabVIEW Communications:
<LabVIEW Comms 2.0>\Resources\vi.lib\Native\niUsrpRio Config v1 Host.lvlib__Advanced Configure Power Mode.gvi

Reported Version: 17.1  Resolved Version: N/A  Added: 03/14/18
686898

Return
When attempting to generate an NI-USRP Sample Project, error 1073 appears intermittently.
Attempts to generate a sample project may fail with an error that reads: "Error 1073 occurred at ... This property is writable only when the VI is in edit mode, or this method is available only when the VI is in edit mode. Property Name: Automatic Error Handling"

Workaround: Generate the same sample project again. The error is intermittent and you should be successful eventually.
Reported Version: 17.1  Resolved Version: N/A  Added: 02/16/18
682721

Return
When changing the Host Data Type in a NI-USRP session in between acquisitions, an overflow is falsely reported.
When acquiring with the NI-USRP API, changing the Host Data Type property after aborting an acquisition and then running another acquisition in the same session results in the false report of an overflow on the first packet.

Workaround: To avoid the error, close your session and open a new session before changing the Host Data Type. To ignore the error for the first packet only, run niUSRP Clear Error and then continue acquiring.
Reported Version: 16.1  Resolved Version: N/A  Added: 02/12/18
649538

Return
Tx Underflow Error (-1074118645) occurs at low I/Q rates on USRP RIO devices when using the NI-USRP API.
When running a continuous transmit application, an underflow error (-1074118645) may occur even at a low I/Q rate if the size of the data used at each niUSRP Write call is not the ideal data frame size multiple.

Note: Users of the USRP RIO API are not affected. Thus, projects created using LabVIEW Communications Application Frameworks (802.11, LTE, MIMO, etc...), USRP RIO sample projects, or LabVIEW FPGA will not be affected.

Workaround: Implement one of the following solutions:
  • Ensure that the number of samples per write size is ideal. For PCIe-based streaming, the ideal number of samples per write is a multiple of 1,020. For Ethernet-based streaming, the ideal number of samples is calculated based on the configured MTU. Refer to the "Data Streaming Performance Tips" section in the NI-USRP Help at ni.com/manuals for more information.

    Note: If your waveform must contain a fixed number of samples, consider using zeros as padding before or after the waveform until you have a multiple of 1,020. If the waveform must be continuous and cannot be padded with zeros, consider repeating the waveform multiple times to make the overall write size larger. A larger waveform may avoid the problem even if it is not a multiple of the ideal number of samples per write.
  • If you do not require LabVIEW 2017 or support for the USRP-2945/2955 device, downgrade your NI-USRP driver to NI-USRP 16.0.
  • Use the USRP RIO API in your project.
Reported Version: 17.0  Resolved Version: N/A  Added: 06/22/17
626202

Return
When opening multiple new streaming sessions using the NI-USRP API to the same device, you may receive an error.
When opening a streaming session, a DMA channel is reserved. If you try to open more sessions than there are DMA channels, you will receive the following error: "Trying to allocate more DMA channels than are available." This affects the transceiver USRP RIO devices when connected using PCIe.

Workaround: Implement one of the following solutions:
  • Use finite acquisitions for your USRP RIO rather than opening and closing sessions to the same device.
  • Stop and close all sessions to the USRP RIO.
  • Use 1 Gb Ethernet or 10 Gb Ethernet, which do not use DMA channels instead of the PCIe.
Reported Version: 16.1  Resolved Version: N/A  Added: 02/08/17
614923

Return
LabVIEW may crash when using USRP-2945/2955 and the NI-USRP API if configure frequency is called with a command time too far in the future.
When using the USRP-2945/2955 with the NI-USRP API, LabVIEW will crash if there is an attempt to configure the frequency on a channel that has not yet been configured. This crash will only occur if the command time has been set more than 10 seconds in future and if an acquisition on another channel is already in progress.

Workaround: Implement one of the following solutions:
  • Configure a frequency on the channel before starting any other acquisitions.
  • Use a shorter command time such that the configure frequency will be executed within 10 seconds.
Reported Version: 16.1  Resolved Version: N/A  Added: 09/12/16
610228

Return
On the USRP-2945/2955, a second harmonic LO spur may be observed when sharing LOs.
On the USRP-2945/2955, if a channel's LO source is set to companion during an acquisition, there may be a spur observed in the received signal of that channel at twice the center frequency of the original channel settings.

Workaround: Before setting an LO source to companion, tune the LO to a frequency such that the spur will not be near the new frequency of interest, or abort acquisition before attempting to change the LO source.

Reported Version: 16.1  Resolved Version: N/A  Added: 02/16/18
600668

Return
Rx transients when using the USRP-2944/2954 devices.
Transients are observed on the received data when doing finite acquisitions using the USRP-2944/2954 devices.
These transients are hardware-specific and have been observed to be around 20 ms to 50 ms in duration.

Workaround: Throw away the initial transient samples after a finite acquisition.

Reported Version: 15.5  Resolved Version: N/A  Added: 08/15/16
595649

Return
When using LabVIEW Communications 2.0, the Rx Custom Sample Type and Size example is broken.
The Rx Custom Sample Type and Size example is broken in LabVIEW Communications 2.0.

Workaround: Change the broken property nodes from Active Channel to All Active Channel. Alternatively, you can save the project, close LabVIEW Communications 2.0, and reopen the project.

Reported Version: 15.5  Resolved Version: N/A  Added: 07/21/16
586927

Return
Subsequent configurations of the LO frequency require a delay to allow the clock to settle.
Configuring the LO can require some transient time to settle. Data that was fetched or written during this settling period will be corrupted. This affects the niUSRP Configure Signal VI on the host side, as well as Configure Rx VI and Configure LO VI for USRP RIO sessions. Due to the race condition nature of the issue, the problem may not present itself in every application depending on parallel tasks running in the VI.

Workaround: Place a delay on the order of 20 ms to 50 ms following configurations to the LO. These numbers were experimentally found, and may differ depending on the hardware or application.

Reported Version: 15.5  Resolved Version: N/A  Added: 07/21/16
562870

Return
NI-USRP Configuration Utility seems to hang when updating the image of a USRP.
When updating an image on a USRP, the NI-USRP Configuration Utility seems to hang, and the application must be forced to close.

Workaround: Updating the image can take up to 20 minutes, during which time the utility currently seems to hang. Please wait at least 20 minutes when attempting to update the image.

Reported Version: 15.0  Resolved Version: N/A  Added: 07/21/16
542084

Return
Invalid samples received after retuning the LO on a USRP-2944/2954 device.
When retuning the receiver side of a USRP-2944/2954 device from a frequency above 1.5 GHz to a frequency below 1.5 GHz, the received signal takes around 200 ms to stabilize.

Workaround: Either wait 200 ms between retuning the device and acquiring samples or discard the samples acquired during that period.

Reported Version: 15.5  Resolved Version: N/A  Added: 07/21/16
540599

Return
When you open an NI-USRP API session to a device that is already being used as a LabVIEW FPGA device with the niUsrpRio Configuration Instrument Design Library, errors result from the existing session.
If you attempt to use the NI-USRP API to open a session to anUSRP RIO device when it is already being used as LabVIEW FPGA device, for example through a NI-USRP Simple Streaming sample project, your action can cause the session to terminate with an error. When you open an NI-USRP session to a device, the custom LV FPGA image on the device will be replaced with a default FPGA image that works with the NI-USRP driver, which will invalidate an open LV FPGA session open to that device.

Workaround: Using both driver APIs (NI-USRP and the niUsrpRIO Configuration Instrument Design Library in the LabVIEW FPGA environment) simultaneously to configure the same device is not a supported use case.

Reported Version: 14.5  Resolved Version: N/A  Added: 09/03/15
539338

Return
The status of the USRP RIO Local Oscillator (LO) lock may be true even when the LO has not been configured.
The LO lock status may be true even before you configure the LO frequency. The LO lock status is indeterminate before you configure any frequency.

Workaround: Do not check the LO Locked status before you configure the frequency, because the status is indeterminate until the LO is configured. It is valid to check the status only after a frequency configuration is made.

Reported Version: 14.5  Resolved Version: N/A  Added: 09/03/15
532349

Return
Timed commands do not work with the USRP-2900/2901 device.
Timed commands are currently not supported with the USRP-2900/2901 device.

Workaround: N/A

Reported Version: 14.1  Resolved Version: N/A  Added: 06/11/15
528194

Return
Incorrect frequency coercion can result when you set the LO frequency to a non-default value on an USRP-2900/2901 device.
If you set the LO frequency to a non-default value, an incorrect carrier frequency coercion can result if the absolute difference (offset) between the carrier frequency and the LO frequency is greater than half the data clock rate. For example, setting a LO frequency to 2 GHz and configuring a carrier frequency of 2.02 GHz or 20 MHz offset will result in incorrect carrier frequency coercion if the data clock rate is 32 MHz (which permits only 16 MHz offset). The maximum allowed offset is also limited by the maximum configurable DSP frequency and thus can be lower than the data clock rate/2 limit.

Workaround: Set the Data Clock Rate to a value higher than twice the maximum offset that you intend to use. However, the Data Clock Rate has a maximum limit too. Or Do not use the LO frequency property node and instead use only the carrier frequency property, which will automatically set the LO frequency to a value appropriate to achieve the requested carrier frequency.

Reported Version: 14.1  Resolved Version: N/A  Added: 06/11/15
527016

Return
Setting the LO Frequency property node to the default value of -1 results in wrong carrier frequency coercion on the USRP-2901 device.
When you set the LO Frequency property node to the default value of -1 and then set the carrier frequency, a wrong carrier frequency configuration may result on the USRP-2901 device.

Workaround: Set the LO frequency property in the context of an active channel. For example, using the niusrp property node, first set the active channel and then set the LO frequency property below it.

Reported Version: 14.1  Resolved Version: N/A  Added: 06/11/15
519572

Return
Changing the I/Q rate can cause discontinuity in the time reported by the device.
A change in I/Q rate value can cause a discontinuity in the time reported by the USRP-2900/2901 device. Change in the I/Q rate can cause an automatic change in the data clock rate, which influences the time maintained by the device.

Workaround: Set the data clock rate property to a fixed value for e.g. 32M or 48M explicitly if you intend to change the I/Q rate in an application and rely on the time-stamps from the device to be continuous. Setting the the data clock rate however will restrict the I/Q rates that can be achieved. Another workaround is to explicitly set the time after making a change to the I/Q rate. You can use the niUSRP Set Time VI to do this. For example, read the time from the device using the niUSRP Get Time VI before changing the I/Q rate and set the time to that value after you change the I/Q rate using the niUSRP Set Time VI.

Reported Version: 14.1  Resolved Version: N/A  Added: 06/11/15
518489

Return
Repeatedly aborting and then initiating an NI-USRP session occasionally causes a packet timeout error with USRP-2900/2901 devices.
Repeatedly initiating and aborting your NI-USRP session when using an USRP-2900/2901 device will occasionally result in a timeout error -1074118650.

Workaround: Catch the error, then close and reconfigure your session.

Reported Version: 14.1  Resolved Version: N/A  Added: 06/11/15
488044

Return
Error -61083 and corrupted data can occur when you use clocks derived from the data clocks.
The data clock of the USRP RIO is generated outside of the FPGA . You must configure the data clock before it is used by any FPGA logic, otherwise logic running from the derived clock could execute while the data clock configures, resulting in undefined behavior. The ability to derive clocks from the data clock has been disabled in NI-USRP 14.0.

Workaround: Create derived clocks from the 40 MHz onboard clock instead of the data clocks. Because the onboard clock is not phase-locked to the data clock, you must add and test logic to ensure the clocks perform as intended.

Reported Version: 14.0  Resolved Version: N/A  Added: 09/23/14
487251

Return
The NI-USRP Configuration Utility may incorrectly report that an image update is needed for USRP-2920/2921/2922/2930/2932 devices already in use.
If an USRP-2920/2921/2922/2930/2932 device is already in use, the NI-USRP Configuration Utility normally does not display the device. In some cases, the utility may show the device but display UPDATE NEEDED in the Image Status column. If the device is in use by another process or system, the FPGA/Firmware update may not be required.

Refresh the devices list to verify that the device is visible and requires image updating.

Workaround: Ensure that a device is not in use by another application or system before updating the FPGA and Firmware images with the NI-USRP Configuration Utility.

Reported Version: 14.0  Resolved Version: N/A  Added: 09/23/14
487061

Return
USRP-2920/2921/2922/2930/2932 devices may not return an error if an external reference signal is missing.
When an USRP-2920/2921/2922/2930/2932 device is configured to use REF IN as the reference frequency source, but a reference signal is not applied on the REF IN port, the device may not generate an error in LabVIEW.

Workaround: Provide a reference frequency source to the REF IN port.

Reported Version: 14.0  Resolved Version: N/A  Added: 09/23/14
469466

Return
Errors occur when you use multiple devices on different buses in a single session.
When you use the NI-USRP API to open a session to multiple devices on different buses, for example one with Ethernet and one with PCI Express, various errors occur during execution after opening the session. The errors vary depending on whether the session is Rx or Tx.

Workaround: Use devices only on a single bus in a single session.

Reported Version: 1.3  Resolved Version: N/A  Added: 09/23/14
467209

Return

Error -107411864 "A stream command was issued in the past" occurs when you set Timebase Clock Source to PpsIn and do not provide a timebase clock source to the PPS IN port.
If you set Timebase Clock Source to PpsIn and do not provide a timebase clock source to PPS IN, the USRP device will revert back to its internal timebase clock source. This may result in error -1074118649 "A stream command was issued in the past."

Workaround: Provide a timebase clock source to the PPS IN port.

Reported Version: 14.0  Resolved Version: N/A  Added: 09/23/14
460810

Return
Runtime errors occur when you open one session to multiple devices and another session to a subset of those devices.
The order in which you call the Open Tx Session VI and the Open Rx Session VI affects which error appears. For example, if you call the Open Tx Session VI with the names of device A and device B and then you call the Open Rx Session VI with the name of device A, the Write Tx Data VI returns the following error:
"niUSRP Write Tx Data (2D CDB).vi. A runtime or configuration error occurred. Code: 1440 Details: RuntimeError: fifo ctrl timed out looking for acks"

If you call the Open Rx Session VI with the names of device A and device B and then you call the Open Tx Session VI with the name of device A, the Fetch Rx Data VI returns the following error:
"1074118650: Timeout exceeded before packet received or sent. Not all samples may have been received or sent. Consider increasing timeout."

Workaround: Open an Rx and Tx session to the same list of devices. You can disable the unused channel in the session where you added it.

Reported Version: 1.3  Resolved Version: N/A  Added: 05/07/14
460704

Return
Out-of-sequence errors occur when you use NI-USRP over an Ethernet connection.
The driver may report out-of-sequence errors in either of the following scenarios:
  • High network traffic or high streaming rates are occurring over Ethernet. Some network cards collate network packets out-of-order in these situations, and the NI-USRP driver reports errors in this case. For example, the Intel 82579LM network controller chipset is known to exhibit this behavior with the NI-USRP driver.
  • You call the niUSRP Set Time VI after you call the niUSRP Initiate VI when receiving.

Workaround: 

  • Refer to the Data Streaming Performance Tips topic in the NI-USRP Help for more information about improving streaming performance over Ethernet.
  • Do not call the niUSRP Set Time VI after calling the niUSRP Initiate VI.
Reported Version: 1.3  Resolved Version: N/A  Added: 05/19/14
460113

Return
Hibernation is not supported for the USRP RIO devices over PCI Express.
USRP RIO devices do not support hibernation when connected over PCI Express. When resuming from hibernation, USRP-294x/295x devices may not work.

Workaround: Cycle power to the USRP RIO devices and the host machine.

Reported Version: 1.0  Resolved Version: N/A  Added: 05/19/14
460109

Return
Sleep is not supported for the USRP RIO devices over PCI Express.USRP RIO devices do not support sleep when connected over PCI Express. When resuming from sleep, USRP RIO devices may not work or the host machine may become unstable.

Workaround: Cycle power to the USRP RIO devices and the host machine.

Reported Version: 1.0  Resolved Version: N/A  Added: 05/19/14
458782

Return
There is a large transient time at the beginning of a Tx session or Rx session when you use the USRP-2943/2953.
There is a ~110 μs to 130 μs transient at the beginning of a Tx session or Rx session when you use the USRP-2943/2953 devices.

Workaround: For Tx or Rx, pad the waveforms with sufficient 0 samples to cover the transient time and then throw out these 0 samples.

Reported Version: 1.3  Resolved Version: N/A  Added: 05/07/14
458163

Return

When you use NI-USRP and the USRP RIO devices, 24 samples of the previous acquisition are present at the beginning of a new acquisition.
When you configure an Rx session, the first set of data retrieved from a fetch call will contain invalid data. Twenty-four samples and about 130 μs of transient data are left over from the previous Rx acquisition.

Workaround: Design your application to discard the first 24 samples and 130 μs of transient data.

Reported Version: 1.3  Resolved Version: N/A  Added: 05/07/14
456625

Return
The niUSRP Fetch Rx Data VIs do not respect "channel list" control.
The niUSRP Fetch Rx Data VI always returns data for all of the channels specified in the Enabled Channels property. You cannot enable multiple channels and then fetch data only from a single channel at a time.

Workaround: Enable only the channels that you want to fetch data from at the same time.

Reported Version: 1.3  Resolved Version: N/A  Added: 05/07/14
442853

Return
Opening an FPGA reference fails with error -63150 on USRP RIO devices.
The Open FPGA VI Reference and Open Dynamic Bitfile Reference nodes fail with error -61350 on USRP RIO devices if the FPGA image stored in the flash of the device is bad.

Workaround: Update the FPGA image stored in the flash of the device with a known good image by running\vi.lib\LabVIEW Targets\FPGA\USRP\niusrprio_tools.llb\Write Bitfile to Flash.vi. The default FPGA image is stored at \NI-USRP\images\usrp_x310_fpga_HGS.lvbitx. Cycle power to the device and the host after you update the FPGA image of the device.

Reported Version: 1.0  Resolved Version: N/A  Added: 05/07/14
360108

Return
The niUSRP Write Tx Data VI sometimes ignores timeout if end of data? is TRUE.
If you call the niUSRP Write Tx Data VI with end of data? set to TRUE, the driver might ignore the timeout. If you configured the device to start generating at a time that is later than the timeout, the driver will wait for the device to start generating, even if the wait time exceeds the timeout.

Workaround: Do not set Start Trigger times that are further in the future than you want to wait.

Reported Version: 1.1  Resolved Version: N/A  Added: 09/23/14
349079

Return
Streaming performance for multi-device sessions is sometimes low.
NI-USRP sessions configured to control multiple devices exhibit lower than expected streaming performance. The streaming rate for multi-device sessions should be approximately half that of single device sessions, but actual performance is less than half. For multi-device sessions, it is sometimes not possible to stream at high I/Q rates.

Workaround: N/A

Reported Version: 1.1  Resolved Version: N/A  Added: 05/07/14
340767

Return
NI-USRP Configuration Utility fails to reset after you upgrade the firmware or FPGA.
The utility reports that it was unable to reset the device after a firmware or FPGA upgrade. The upgrade was successful, but the reset action did not complete.

Workaround: Unplug and replug the device to manually power cycle the device and complete the reset action.

Reported Version: 1.1  Resolved Version: N/A  Added: 05/10/12
310810

Return
NI-USRP returns one of the following errors during Tx: "Packet loss between host and device." or "Packet loss within a burst."
A continuous Tx operation that uses a high I/Q sampling rate and a small waveform size per write creates a very large number of underflows. The underflows cause the operation to eventually error out with one of the packet loss errors. When one of these errors occurs, a packet has actually been dropped between the host and the device.

Workaround: Implement one or more of the following changes:
-Use a larger write size in each write call.
-Use a smaller I/Q sampling rate, if possible.
-Use a finite Tx operation that provides all the data in a single write call and sets the end of data? input of the write VI to TRUE, if possible.

Reported Version: 1.0  Resolved Version: N/A  Added: 09/16/11
295724

Return
Transients exist for both Tx and Rx.
For I/Q sampling rates that are divisible by 2, transients may appear in the first 20 or so samples for both Rx and Tx.

Workaround: For Tx, pad the end of each generated waveform with zeros to eliminate the transient samples at the beginning of the subsequent waveform generation.
For Rx, acquire sufficient extra data before the expected beginning of the packet and discard the first 20 samples.

Reported Version: 1.0  Resolved Version: N/A  Added: 09/16/11

Contacting NI

Contact NI regarding this document or issues in the document. If you contact NI in regards to a specific issue, reference the ID number given in the document. The ID number contains the current issue ID number as well as the legacy ID number (use the current ID number when contacting NI). You can contact us through any of the normal support channels including phone, email, or the discussion forums. Visit the NI Website to contact us. Also contact us if you find a workaround for an issue that is not listed in the document.

Glossary of Terms

 

  • Bug ID - When an issue is reported to NI, you may be given this ID or find it on ni.com.  You may also find IDs posted by NI on the discussion forums or in KnowledgeBase articles.
  • Legacy ID – An older issue ID that refers to the same issue.  You may instead find this issue ID in older known issues documents.
  • Description - A few sentences which describe the problem. The brief description given does not necessarily describe the problem in full detail.
  • Workaround - Possible ways to work around the problem.
  • Reported Version - The earliest version in which the issue was reported.
  • Resolved Version - Version in which the issue was resolved or was no longer applicable. "N/A" indicates that the issue has not been resolved.
  • Date Added - The date the issue was added to the document (not the reported date).