From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
Each issue appears as a row in the table and includes the following fields:
| ID | Known Issue | |||||
|---|---|---|---|---|---|---|
| 494912 Return | You cannot use RIO aliases to identify NI 294x/295x devices in the NI-USRP API. You can create a RIO alias in NI MAX for NI 294x/295x devices connected using the MXI Express interface. RIO aliases are usable when you open a LabVIEW FPGA reference to these devices but they are not usable from the NI-USRP API in the device names input in the niUSRP Open Rx Session VI and the niUSRP Open Tx Session VI. Workaround: Use the standard RIO name, such as "rio0", in the device names input of the niUSRP Open Rx Session VI and the niUSRP Open Tx Session VI.
| |||||
| 492685 Return | After you run a NI-USRP VI which commits an existing niUSRP Tx session, opening a second niUSRP session occasionally takes more than 60 seconds. Running a VI which commits settings to an existing Tx session, such as niUSRP Configure Signal.vi, may delay the opening of another niUSRP session (using niUSRP Open Rx Session.vi or niUSRP Open Tx Session.vi). Workaround: Call niUSRP Open.vi on all of the sessions that you want to open before calling any other niUSRP VI.
| |||||
| 492219 Return | Tx sessions may underflow after you start an Rx session with NI 294x/295x devices connected using MXI Express cables. If you start an Rx session with an outstanding Tx session already streaming, the Tx session may underflow if both sessions are on NI 294x/295x devices connected using MXI Express cables. Workaround: Start the Rx and Tx sessions before you start streaming.
| |||||
| 489197 Return | An LO locking error occurs on channel one on your NI 294x/295x devices. When you query an attribute from the NI-USRP driver before you configure any parameters, an LO locking error occurs on channel one on your NI 294x/295x devices. Workaround: Set the Enabled Channels property before you query any attribute and immediately after opening a session.
| |||||
| 488044 Return | Error -61083 and corrupted data can occur when you use clocks derived from the data clocks. The data clock of the NI 294x/295x 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.
| |||||
| 487251 Return | The NI-USRP Configuration Utility may incorrectly report that an image update is needed for NI USRP-292x/293x devices already in use. If an NI 292x/293x 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.
| |||||
| 487061 Return | NI 292x/293x devices may not return an error if an external reference signal is missing. When an NI 292x/293x 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.
| |||||
| 486961 Return | The niUSRP Find Devices VI will occasionally return incorrect information when a session is open to a USRP device. When running the niUSRP Find Devices VI while a session is open to a USRP device connected to the system, it will occasionally return incorrect information. Workaround: Ensure all sessions are closed when you run the niUSRP Find Devices VI.
| |||||
| 485027 Return | Alternating use of NI 293x/292x devices connected with MIMO cables in LabVIEW 32-bit and LabVIEW 64-bit can cause the USRP devices to appear disconnected from the system. This issue may occur when you run applications on multiple NI 293x/292x devices connected with MIMO cables, alternating between LabVIEW 32-bit and LabVIEW 64-bit. The devices appear to be disconnected from your system. This is due to improper releasing of the USRP resources. Workaround: Close both LabVIEW instances and cycle power to the USRP devices.
| |||||
| 484898 Return | Configuring the Rx Reference Level on NI 294x/295x devices results in an incorrect reference level setting. When you configure the Rx reference level, as demonstrated in the Simple NI-USRP Streaming Sample Project, using the Configure Signal (Level) VI, the niUsrpRio Configuration IDL may report the following error: Error -1074100585 occurred at niUsrpRio Config v1 Host.lvlib:Calculate Gain Setting.vi: "Specified reference level or output power exceeds the characterized capabilities of the device." In other cases, no error is reported, but the resulting reference level may be incorrect. In this case, the "Coerced Vertical Range [Vpp]" returned by the Configure Signal (Level) VI may be off by 7 dB to 20 dB and the niUsrpRio Configuration IDL will program the hardware gain incorrectly by the same factor. Workaround: 1) Use Configure Signal (Gain).vi and set a gain of 0 dB to 30 dB. Do not configure the Rx reference level. 2) Install NI-USRP 14.0 and run \LabVIEW Targets\FPGA\USRP\niusrprio_tools.llb\Update Device Correction Data.vi. This VI will correct the Rx gain correction data in persistent storage on the device to correct the problem. You need only to run this VI once per device.
| |||||
| 478482 Return | Two channel acquisition (Rx) on a single NI 294x/295x device is not aligned. When you configure a single device for a multi-channel acquisition (Rx), if you use a Time Start Trigger (niUSRP Configure Trigger.vi) the time must be set on both channels of the device using niUSRP Set Time.vi. If the "apply timestamp" parameter is set to "Now" there may be a misalignment between the channels. Set the "apply timestamp" parameter to "Next Timebase Edge". Workaround: Set the "apply timestamp" parameter of the niUSRP Set Time.vi to "Next Timebase Edge" for a single-device, multi-channel acquisition with a Time Start Trigger.
| |||||
| 470359 Return | NI-USRP may return incorrect or empty GPS NMEA strings. If you repeatedly query the GPS Sentence GGA and GPS Sentence RMC properties from the NI-USRP driver, the driver may return an incorrect or empty string. Workaround: Query the property again if it returns an empty or obviously incorrect string. Alternately, always query the attributes in this order: GPS Time (seconds) GPS Sentence RMC GPS Sentence GGA GPS Lock Status
| |||||
| 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.
| |||||
| 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.
| |||||
| 466351 Return | "A stream command was issued in the past" or "Packet had timestamp that was late (or too early)" errors can occur with MIMO synchronization. In an Rx session, the error message reads "A stream command was issued in the past." In a Tx session, the error message reads "Packet had timestamp that was late (or too early)." This issue occurs only when all of the following conditions are met: The slave device has a GPSDO. The niUSRP Set Time VI is called only on the master. The timestamp is applied immediately. Workaround: Avoid this error by implementing any of the following solutions: Add a one-second wait anywhere after you open a Tx or Rx session but before the niUSRP Initiate VI. Configure the niUSRP Set Time VI to apply the timestamp at the next timebase edge. Call the niUSRP Set Time VI on both channels.
| |||||
| 465821 Return | The NI-USRP help does not contain an AUX I/O front panel connector pin-out diagram for the NI 294x/295x devices. Workaround: Refer to http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_hw_gpio. The AUX I/O lines in LabVIEW FPGA correspond to the Data[xx] lines in the Pin Mapping section.
| |||||
| 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.
| |||||
| 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:
Workaround:
| |||||
| 460113 Return | Hibernation is not supported for the NI 294x/295x devices over PCI Express. NI 294x/295x devices do not support hibernation when connected over PCI Express. When resuming from hibernation, NI 294x/295x devices may not work. Workaround: Cycle power to the NI 294x/295x devices and the host machine.
| |||||
| 460109 Return | Sleep is not supported for the NI 294x/295x devices over PCI Express. NI 294x/295x devices do not support sleep when connected over PCI Express. When resuming from sleep, NI 294x/295x devices may not work or the host machine may become unstable. Workaround: Cycle power to the NI 294x/295x devices and the host machine.
| |||||
| 458782 Return | There is a large transient time at the beginning of a Tx session or Rx session when you use the NI 2943R/2953R. There is a ~110 μs to 130 μs transient at the beginning of a Tx session or Rx session when you use the NI 2943R/2953R 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.
| |||||
| 458163 Return | When you use NI-USRP and the NI 294x/295x 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.
| |||||
| 456805 Return | The niUSRP Get Time VI returns a fractional seconds value of 1. If you use the niUSRP Get Time VI with the when input set to previous timebase edge, the VI may incorrectly return a value of 1 in the fractional seconds element of the USRP Timestamp output. This output is incorrect and should be taken to mean 0. Workaround: Interpret a value of 1 in the fractional seconds output as a value of 0.
| |||||
| 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.
| |||||
| 442853 Return | Opening an FPGA reference fails with error -63150 on NI 294x/295x devices. The Open FPGA VI Reference and Open Dynamic Bitfile Reference nodes fail with error -61350 on NI 294x/295x 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.
| |||||
| 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.
| |||||
| 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
| |||||
| 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.
| |||||
| 311843 Return | NI-USRP incorrectly coerces carrier frequency for the NI 292x. If you set the carrier frequency to a value that is out of range for the NI 292x, NI-USRP does not coerce the carrier frequency to a value within range of the NI 292x. Workaround: Set the carrier frequency to a value within range of your device. Select values within the following ranges: NI-2920: 50 MHz - 2.2 GHz. NI-2921: 2.4 GHz - 2.5 GHz; 4.9 GHz - 4.9 GHz.
| |||||
| 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.
| |||||
| 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.
|
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.