LabVIEW Communications 802.11 Application Framework 1.0 and 1.1 Known Issues

Overview

This document contains the 802.11 Application Framework 1.0 and 1.1 known issues that were discovered before and since the release of 802.11 Application Framework 1.1. 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 the 802.11 Application Framework in which the issue was reported. If you discover the issue appears in an earlier version of the 802.11 Application Framework 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).

 

538847 802.11 and LTE Application Frameworks Examples with Video Streaming Does Not Work with Latest Version of VLC.
535393 The 802.11 Application Framework uses an 80 MHz bandwidth during measurements and may detect energy from adjacent channels.
527925 High packet error rate for MCS 9 with Subcarrier Format IEEE 802.11ac 40 MHz.
507338 A high load on the host may result in data loss.
506349 Data transmission gets corruptied if the system is affected by other WiFi traffic.
506019 RF performance degradation can be experienced on the high and low ends of the NI USRP RIO frequency range.
504858 BLER display shows a comb shape in UDP mode.

 

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).

Reported Version: 1.0    Resolved Version: 2.0    Added: 9/01/2015
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.

Reported Version: 1.1    Resolved Version: 2.0    Added: 9/15/2015
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.

Reported Version: 1.1    Resolved Version: N/A    Added: 09/15/2015
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.

Reported Version: 1.0    Resolved Version: 1.1    Added: 11/27/2014
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.

Reported Version: 1.0    Resolved Version: 1.1    Added: 11/27/2014
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.

Reported Version: 1.0    Resolved Version: N/A    Added: 11/26/2014
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

Reported Version: 1.0    Resolved Version: 1.1    Added: 11/27/2014

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).