Home Support Documentation Bugs

LabVIEW Communications 802.11 Application Framework 2.5 and 3.0 Known Issues

Updated Mar 10, 2020

Overview

This document contains the 802.11 Application Framework 2.5 and 3.0 known issues that were discovered before and since the release of 802.11 Application Framework 2.5. 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).

 

713742—LabVIEW becomes unresponsive when saving Application Frameworks for the first time.
688729—LabVIEW Communications reports back-end compile errors on unchanged VIs.
527925—High packet error rate for MCS 9 with Subcarrier Format IEEE 802.11ac 40 MHz.
506019—RF performance degradation can be experienced on the high and low ends of the NI USRP RIO frequency range.

 

IDKnown Issue
713742

Return		LabVIEW becomes unresponsive when saving Application Frameworks for the first time
When you create and then attempt to save an Application Framework, the LabVIEW executable becomes unresponsive. Windows reports "LabVIEW NXG is not responding" and offers to either close the program or wait for the program to respond.


Workaround: Select "wait for the program to respond" to ensure the project is saved completely.

Reported Version: 2.2  Resolved Version: N/A  Added: 10/08/2018
688729

Return		LabVIEW Communications reports back-end compile errors on unchanged VIs.
Having large and complex type definitions in a project may lead to a back-end compile error on VIs that use these type definitions. These error messages include the following:
  • "The back-end compiler for this deploy target failed with an error while processing this file. The compiler failed to update the code for a dependency. The file may be corrupt or there may be a bug in the back-end compiler. Consider undoing recent edits, closing and reloading the current project, or restarting the application. Control-clicking the run or compile buttons will force another compile attempt. For help with this issue, please contact National Instruments or the third-party vendor responsible for this target compiler."
  • "The back-end compiler for this deploy target failed with an unknown error while processing this file. The file may be corrupt or there may be a bug in the back-end compiler. Consider undoing recent edits, closing and reloading the current project, or restarting the application. Control-clicking the run or compile buttons will force another compile attempt. For help with this issue, please contact National Instruments or the third-party vendor responsible for this target compiler. Details: Maximum recompile limit reached."


Workaround:

  1. Close all VI tabs in the project.
  2. Close the project.
  3. Delete the .lvcodedb file of the project (located in the same folder as the project itself).
  4. In LabVIEW Communications, navigate to File>>Editor Preferences to open LabVIEW Communications settings.
  5. Switch to the Editor tab.
  6. Remove the checkmark from the Suppress document edits that happen as side-effects checkbox.
  7. Close the Settings window.
  8. Open the project.
  9. Open the affected VI. The VI, and possibly other VIs, will be modified, and the back-end compile errors will be gone.
  10. Wait for type propagation, that is, until the CPU utilization of the LabVIEW Communications executable drops below 5%.
  11. Select File>>Save all.
  12. Repeat steps 4 and 5.
  13. Enable the checkbox for the Supress document edits that happen as side-effects.

It may be necessary to iterate this process until all back-end compile errors are gone. 

Reported Version: 2.0  Resolved Version: N/A  Added: 03/07/2018
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
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

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.

Back to top

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