Each issue appears as a row in the table and includes the following fields:
| ID | Known Issue | |||||
|---|---|---|---|---|---|---|
| 538847 Return | 802.11 and LTE Application Frameworks Examples with Video Streaming Does Not Work with Latest Version of VLC. When running the commands specified in the help to launch the VLC receiver and transmitter, the 802.11 and LTE Application Frameworks example shows a blank screen in the receive window. Workaround: Use an older version of VLC (2.1.5 or earlier).
| |||||
| 535393 Return | The 802.11 Application Framework uses an 80 MHz bandwidth during measurements and may detect energy from adjacent channels. The CCA-energy-detection (CCA-ED) is based on a simple power measurement at a sample rate of 80 MS/s. That setup means CCA-ED is performed based on the energy within the smaller value of either the available RF bandwidth of the device or 80 MHz, regardless of the selected subcarrier format. Workaround: Implement a filter in front of the energy detection that performs filtering according to the selected subcarrier format.
| |||||
| 527925 Return | High packet error rate for MCS 9 with Subcarrier Format IEEE 802.11ac 40 MHz. When using the Subcarrier Format IEEE 802.11ac 40 MHz and MCS 9 (256-QAM and code rate 5/6), a high packet error rate may be observed. That outcome is related to the non-adaptive configuration of the LLR demapper noise coefficient. It might also be related to the general receiver performance. Workaround: You can lower the packet error rate by configuring the noise coefficient for the LLR demapper according to the actual channel conditions.
| |||||
| 507338 Return | A high load on the host PC may result in data loss. If there is a high load on the host machine, the host may be unable to read data from the RX FIFO FPGA sufficiently fast. Workaround: Avoid using remote desktop connections to access the host. When performing video streaming, try to avoid rendering the video on the host system.
| |||||
| 506349 Return | Data transmission gets corrupted if the system is affected by other WiFi traffic. WiFi traffic from nearby commercial networks can cause the system to run into decoding issues. You may see these issues as a permanent byte shift in the received payload data. The system remains stable despite the shift, so the effect accumulates over time. Workaround: If possible, use a cabled setup with short cables. Also, put the attenuator near the RX port.
| |||||
| 506019 Return | RF performance degradation can be experienced on the high and low ends of the NI USRP RIO frequency range Close to the upper and lower limits of the NI USRP frequency range, there are degradations on the RF perfomance from the NI USRP device. For the 802.11 Application Framework, these degradations result in a noisy RX constellation even at high signal power levels. You can see the certain peaks in the subcarrier channel magnitude plot where the amplitude is usually flat. Workaround: Avoid using frequencies at the high and low endpoints of the frequency range.
| |||||
| 504858 Return | BLER display shows a comb shape in UDP mode. The BLER is calculated by dividing the number of sent packets by number of received ACKs over a fixed time interval. A received ACK may not be counted within the interval of the corresponding packet. This uncertainty leads to a small fluctuation even if the error rate stays constant, which appears as a comb shape in the plot. Workaround: None
|
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.