| ID | Known Issue |
|---|
466351
| "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.
| Reported Version: 1.3 | | Resolved Version: N/A | | Added: 05/19/2014 |
|
465821
| The NI-USRP help does not contain an AUX I/O front panel connect pin-out diagram for the NI USRP-294x/295x devices.
The documentation does not contain a pin-out diagram for the AUX I/O connector.
Workaround: Refer to http://files.ettus.com/uhd_docs/manual/html/gpio_api.html for a pin-out diagram for the NI 294x/295x AUX I/O connector.
| Reported Version: 1.3 | | Resolved Version: N/A | | Added: 05/19/2014 |
|
460810
| 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<ERR>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/19/2014 |
|
460704
| 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:1) 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.
2) You call the niUSRP Set Time VI after you call the niUSRP Initiate VI when receiving.
Workaround: 1) Refer to the Data Streaming Performance Tips topic in the NI-USRP Help for more information about improving streaming performance over Ethernet.
2) 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/2014 |
|
460113
| 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.
| Reported Version: 1.3 | | Resolved Version: N/A | | Added: 05/19/2014 |
|
460109
| 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.
| Reported Version: 1.3 | | Resolved Version: N/A | | Added: 05/19/2014 |
|
458782
| 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-130 μs transient at the beginning of a Tx session or Rx session using 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.
| Reported Version: 1.3 | | Resolved Version: N/A | | Added: 05/19/2014 |
|
458163
| 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.This issue is present only when you use the NI-USRP API and the NI 294x/295x devices.
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/19/2014 |
|
456805
| 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 return a value of 1 in the fractional seconds 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.
| Reported Version: 1.3 | | Resolved Version: N/A | | Added: 05/19/2014 |
|
456625
| 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/19/2014 |
|
456268
| If a corrupt image exists on the flash of the NI USRP-294xR/295xR device, the NI-USRP Configuration Utility might crash and the PC might also crash. The behavior of the device when a corrupt image exists on its flash is undefined and can cause software or system crashes. Exercise extreme caution when writing an image other than the one shipped with the driver to the flash of a device.
Workaround: Complete the following steps to recover your system.
- Connect the USRP device using the PCI Express bus.
- Use the Write Bitfile to Flash VI found here: <Program Files (x86)>\National Instruments\<LabVIEW>\vi.lib\LabVIEW Targets\FPGA\USRP\niusrprio_tools.llb\ to write the image to the flash of the device.
- Use the usrp_x310_fpga_HGS.lvbitx image typically found at this location: <Program Files (x86)>\National Instruments\NI-USRP\images.
- Reboot the device and the system.
| Reported Version: 1.3 | | Resolved Version: N/A | | Added: 05/19/2014 |
|
360108
| 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: 05/19/2014 |
|
349079
| 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/10/2012 |
|
340767
| 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 cycle power to the device and complete the reset action.
| Reported Version: 1.1 | | Resolved Version: N/A | | Added: 05/10/2012 |
|
311843
| 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 to 2.2 GHz.
NI 2921: 2.4 GHz to 2.5 GHz; 4.9 GHz to 4.9 GHz.
| Reported Version: 1.0 | | Resolved Version: N/A | | Added: 09/16/2011 |
|
310810
| 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/2011 |
|
295724
| Transients exist for both Tx and Rx.
For I/Q sampling rates that are divisible by two, 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/2011 |
|