Home Support Documentation Bugs

LabVIEW Communications LTE Application Framework 2.5 and 3.0 Known Issues

Updated Mar 10, 2020

Overview

This document contains the LTE Application Framework 2.5 and 3.0 known issues that were discovered before and since the release of LTE 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 LTE Application Framework in which the issue was reported. If you discover the issue appears in an earlier version of the LTE 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
708745—The LTE Application Framework may stop when running on RT targets
505728—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.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
708745

Return		The LTE Application Framework may stop when running on RT targets
When running the LTE Application Framework on an RT target with high throughput (MCS 28, all PRB enabled, 75MBit/s user traffic over UDP) the application might stop unexpectedly and you may receive one of these error messages:
  • Timing Indication missed
  • FIFO write to Transport Layer failed

Workaround: Restart the application.

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

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 LTE Application Framework, these degradations result in a noisy PDSCH constellation even at high signal power levels. In this situation, on the Advanced tab, the PDCCH constellation looks like small crosses. You can see the certain peaks in the channel estimation indicator where the normalized amplitude is usually flat when the framework is used in the RF Loopback use case described in the project documentation.

Workaround: Move the carrier frequency away from the limits. The distance to obtain a clean spectrum and constellation can be in the order of several hundred MHz.

Reported Version: 1.0  Resolved Version: N/A  Added: 11/25/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 theocument. 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).