Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
Collapse
Just Flight Community Forum
  1. Home
  2. Just Flight
  3. MSFS Products
  4. F70 & F100 Professional
  5. VNAV calculations and FMS altitude constraints into LFMN (and other airports) (F70/F100)

VNAV calculations and FMS altitude constraints into LFMN (and other airports) (F70/F100)

Scheduled Pinned Locked Moved F70 & F100 Professional
2 Posts 2 Posters 56 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • H Offline
    H Offline
    HumongoDongo
    wrote last edited by HumongoDongo
    #1

    Hi gents, as already highlighted through a number of posts here and elsewhere, I've identified further airports where the FMS does not properly calculate altitude constraints and consequently VNAV behavior.

    On several STARs, procedure altitude constraints are not appearing on the FMS legs at all. On the LEGS/CDU page the coded constraint is absent, and the FMS substitutes its own computed altitude. Because the constraint never reaches the leg, no valid descent path builds and the aircraft arrives at the approach transition well above profile without manual intervention.

    The key finding: this is not the path builder mis-applying a constraint it has. The constraint is missing from the leg entirely. This points at procedure-leg ingestion / altitude-descriptor decoding rather than the descent math.

    Primary example — LFMN, BORD8R arrival (Navigraph)

    BORDI — coded FL170 (B). On the LEGS page no constraint is displayed at all — the field shows only the FMS-computed FL300. The FL170 crossing is absent, not merely mis-computed.
    MIRKU — coded FL110 (at or above) → downstream at OTOKE the FMS computes FL112, i.e. above the MIRKU floor and on a later fix. Consistent with the path being anchored to whatever sparse constraints survive ingestion (MIRKU) after the ones above it (BORDI) have been dropped.
    Consequence: by NERAS, ahead of the approach fixes, the aircraft is far too high to recover the profile without manual intervention.

    Because BORDI's constraint is entirely absent from the leg — rather than present-but-wrong — I suspect certain altitude descriptors (ARINC 424 @ / + / - / "B") or certain constraint codings on these procedures are failing to decode and being discarded during ingestion, rather than being mishandled later by the VNAV path builder.

    Other airports showing the same pattern

    EHAM (Amsterdam)
    LSZH (Zürich)
    LFMN (Nice) — numerous; BORD8R and other arrivals

    All terrain/airspace-constrained STARs with stacked step-downs (mixed hard crossings and at-or-above floors), which likely explains why the issue surfaces here and stays hidden on simpler "cross at" STARs.

    What I've checked

    Nav data: Navigraph, current cycle.
    On the LEGS page, BORDI displays no altitude constraint at all — only the computed FL300 descent. The coded FL170 is absent from the leg. (This is the finding that points to ingestion/decoding rather than the path builder.)
    Manually typing FL170 into BORDI's altitude field does then produce a correct path. — if a manually entered constraint is honored while the coded one is dropped, that confirms the decode/ingestion path as the culprit rather than the VNAV math. Worth a quick test before sending.]

    Suspected area

    Procedure-leg ingestion / altitude-constraint decoding: certain coded constraints (suspected: specific altitude descriptors, or the "at"/hard-crossing type on these STARs) are being dropped rather than attached to their legs. Downstream, the VNAV path builds from only the surviving constraints, producing the observed high path. Expected behavior: every coded constraint attaches to its leg with its correct descriptor (floor / ceiling / hard / block), and the path is built backward from the most-binding downstream constraint with the intermediate ones applied as checks.

    Just wanted to add it to the list of examples where the FMS is not respecting STARs and SIDs. Nonetheless love the plane but hope this helps in your resolution of these challenges - thanks for all your work!

    1 Reply Last reply
    0
    • MarkM Offline
      MarkM Offline
      Mark
      JF Staff
      wrote last edited by
      #2

      Thank you for the feedback. For any AFCAS/ATS related feedback, could I kindly ask you to raise a support ticket with Just Flight Support at the following link: https://www.justflight.com/support

      The F70 & F100 Professional are complex products, so in order to give our support team the best chance at offering speedy assistance, and for any potential bugs to get properly logged and addressed, could you please include any screenshots/videos of the behaviour with your ticket, as well as attaching the log file generated by the product.

      Instructions for locating the log file can be found here: https://support.justflight.com/en/support/solutions/articles/17000152594-where-to-find-the-log-file-s-

      Mark - Just Flight

      Just Flight Development Assistant

      1 Reply Last reply
      0
      Reply
      • Reply as topic
      Log in to reply
      • Oldest to Newest
      • Newest to Oldest
      • Most Votes


      • Login

      • Don't have an account? Register

      • Login or register to search.
      • First post
        Last post
      0
      • Categories
      • Recent
      • Tags
      • Popular
      • Users