RNAV incorrect logic or AIRAC 1908 broken?

edited August 2019 in Customer support

After activating the APPR phase, the incorrect height at the point is calculated, can this be fixed?

not yet APPR phase, at point WI103 the height is not calculated,so far so good
dash1

now APPR arm, at a point WI103 calculated incorrect height 9500ft...
dash2
Charts
charts

Comments

  • This has nothing to to with the AIRAC, it has been broken since the MJC Q400 released the the developer does not seem to ever fix it (or know how to). The thing is, any RNAV/RNP approach that has an intermediate course correction or just a simple fix/waypoint between the FAF and the runway gets messed up. It can't calculate the proper descent profile. Most RNAV approaches are simply not possible in our MJC Q400.

  • edited August 2019

    what a pity to hear this is really bad news :/ :'(
    for example, pmdg b737 calculates the correct height at this point: 3343ft
    737OK
    Well, It’s enough to use math and find the formula,let's hope that someday they will fix it ...

  • Whether the approach can be flown using VNAV can be seen on the Approach Plan in the FMS.
    There you can see the structure of the approach and with the Dash at least the course and the heights. Really the distance and the glideslope angle could be seen here. But missing just for one or more waypoints the heights, the approach is not flyable with VNAV. This may also be intentional (for example, circling only approach or visual approaches) or depends on the software version of the FMS.
    For the approach in LOWI, the height specification for the FIX WI103 is missing. The Majestics is also different, you can see on the RNAV 07 approach in Floro, here should work despite additional 2 FIXES between IF and Rwy, since all the necessary information is available.


    Incidentally, Austrian Airlines does not fly the LOC DME EAST in LOWI with VNAV but with VS. I suspect that also applies to the RNAV approach.

  • a little off topic, I myself have never seen this mode: Appr Plan in the FMS, where to find it?

  • FPL/MENÜ/NEXT

  • edited August 2019

    I found it, but it did not seem useful to me, thanks anyway!

    And as for the problem VNAV, we will wait for the FIX from the developer o:)
    I also hope for the ARM APP phase, by default they will set the accuracy 0.30 to not 0.50(in order not to change each time manually) ;)

  • What does not mean useful? It should be part of the approach briefing to determine how to fly the approach, with which modes. When I see on the APPR plan page that an approach flown with VNAV is not possible, whether intentionally or through an error in the majestics or in the navigation data provided, I adjust accordingly and then fly the approach the possible modes.
    As I said, there are approaches, there can not and may not be a VNAV pseudo guidance, then simply missing the appropriate information in the Approach Plan. So, whether it really is a bug, I'm not sure, it may also be due to the simulated software state or reality. Theoretically, however, I would have expected in the LOWI approach that all the navigation points in the approach plan are missing the heights.
    If the example of Floro shown by me works anyway despite additional fixed points between IF and Rwy, so it can be the Dash!

  • edited August 2019
    useful to do a jeppesen chart briefing;)
    believe only the app page frivolously...
    especially since there are such serious errors in the VNAV system that even a descent is impossible where it is by default obliged to work correctly;(
    if that I can always switch to v/s mode although it will not be rnp?;)

    P.S but now, of course, I will sometimes check this page to know in advance whether the VNAV mode is available or not, although it doesn’t give any guarantees of correct operation and I haven’t seen in any of the documents and manuals so that this page should be checked...
  • So I do not really see any really serious mistakes, and from the final approach VNAV works for me, too, if the requirements are met. The only difference is that the vertical path is miscalculated since it starts with the Rwy height but should actually start with the Threshold Crossing Hight. You can get in a bit too deep, but from the manual fly onwards you can correct that manually.
    You can see that in comparison with the 737, that the Dash 50 ft is missing. (red circle)


    Otherwise, however, you should not compare the VNAV of the Dash with that of Boeing (or the managed Descend on the Airbus). Dash is Dash and has just another FMS.

    In any case, the simulated software version of the FMS should not preclude the correct function.

    Incidentally, there is no height restriction for WI103 in the PMDG for the navigation data. What you see is a predicted altitude, just like the FMS of the Boeing (very different type than the Dash) (green circle)



    The start of the final approach is the same for both (blue circle)

    Incidentally, VNAV or VS have nothing to do with RNP. RNP denotes the navigation performance, which is achieved in sum and combination of the different sensors. It is no longer specified what it must be to fly the approach.

    In this respect, the fewest RNAV approaches still have one or more intermediate points, so these are also good to fly using VNAV. If you just see that VNAV will not work (briefing) you use VS. But today, when I do, I'll practically fly the approach on Floro to see if VNAV works with the interim fix.

  • Perfectly described!

  • edited August 2019

    @FraPre said:
    You can see that in comparison with the 737, that the Dash 50 ft is missing. (red circle)
    Incidentally, there is no height restriction for WI103 in the PMDG for the navigation data. What you see is a predicted altitude, just like the FMS of the Boeing (very different type than the Dash) (green circle)
    The start of the final approach is the same for both (blue circle)

    I noticed it right away,believe this is a mistake and this should be fixed.
    If this is normal for dash, then let the developer confirm it.

    @FraPre said:
    If you just see that VNAV will not work (briefing) you use VS.

    I didn’t know this, this is news for me, that is, it’s normal for RNP to use VS?

    @FraPre said:
    But today, when I do, I'll practically fly the approach on Floro to see if VNAV works with the interim fix.

    Tell me about this experience after.

    @bravomike said:
    This has nothing to to with the AIRAC, it has been broken since the MJC Q400 released the the developer does not seem to ever fix it (or know how to). The thing is, any RNAV/RNP approach that has an intermediate course correction or just a simple fix/waypoint between the FAF and the runway gets messed up. It can't calculate the proper descent profile. Most RNAV approaches are simply not possible in our MJC Q400.

    @bravomike said:
    Perfectly described!

    +1
    and add or modify the manual final phase, I think this is unacceptable...

  • edited August 2019

    So, the flight and the VNAV flown approach to ENFL went quite well. After the published routes flown (STAR ​​and Approach Transition) she had problems with the 90 ° turn, whereby the FMS captured the VNAV Path later and indicated as planned, but had to sink more. Maybe the starting point of the Final Approaches was ignored by the tight turn, because there is no separate FACF and the turn starts right at the IF. In the end, however, she caught herself and arrived neatly. The path would have taken me right to the beginning of the Rwy, as foreseen by the missing 50 ft at the Threshold. The problem at the beginning disturbed me, so that I flew in a second flight via Vectoren something more directly to the IF. Now the VNAV approach was as it should be. So it can be, although there are 2 additional fixpoints between IF and Rwy. Attached are the pictures in order of the Final Approaches.

    Approach Chart

    Approach Plan

    before and after crossing the IF UPOSA

    before and after crossing LEDMO

    before and after crossing 25THR

    at DA

    Our Dash would not have been allowed here, of course, but it was about the correct departure of an RNAV approach using VNAV ;)

  • edited August 2019

    @FraPre said:
    Our Dash would not have been allowed here,

    yes yes, I noticed it right away B)

    @FraPre said:
    So, the flight and the VNAV flown approach to ENFL went quite well.

    what you corrected in this route? what was the problem? I did not understand ...

    by the way, on the new charts there is no lnav
    new

    it is placed on a separate page
    in our case it is better to use this option
    lnav

    P/S what program do you use to calculate landing speeds?

  • I did not change anything in the routings. In the first flight I flew completely according to the specifications in the charts, ie the STAR and the approach from POGUX. With the 90 ° turn at UPOSA, the Dash had their problem, which caused the VNAV to get a little out of hand.
    UPOSA is here directly the IF, from where the Final Approach begins laterally and vertically. No time to align properly.

    In the second flight, I then left the STAR by means of vectors and approached the approach at a more favorable angle, so that VNAV from UPOSA worked correctly.

    Incidentally, it is not permissible (in real terms) to manually change or supplement data for the deposited approach, that is, for the navigation points that constitute the approach according to APPR Plan.

    I do not understand what you mean here?
    "by the way, on the new charts there is no inav"

  • edited August 2019

    @FraPre said:
    I did not change anything in the routings.

    understand

    @FraPre said:
    In the first flight I flew completely according to the specifications in the charts, ie the STAR and the approach from POGUX. With the 90 ° turn at UPOSA, the Dash had their problem, which caused the VNAV to get a little out of hand.
    UPOSA is here directly the IF, from where the Final Approach begins laterally and vertically. No time to align properly.

    in this case, it’s better to go to the hold, I don’t understand why in the European charts, unlike the New Zealand, in the case of a right angle, there are no recommendations to enter the hold first...

    @FraPre said:
    Incidentally, it is not permissible (in real terms) to manually change or supplement data for the deposited approach, that is, for the navigation points that constitute the approach according to APPR Plan.

    Did I not say the same above?

    @FraPre said:
    I do not understand what you mean here?
    "by the way, on the new charts there is no inav"

    Only lav now on a separate page

  • Yes, in this case you descend with an conventional vertical mode, at the Dash VS

  • edited August 2019

    @FraPre said:
    Yes, in this case you descend with an conventional vertical mode, at the Dash VS

    Yes it is, I just indicated the differences in the charts, with our broken vnav, maybe VS is the best option.

    And I also wanted to clarify about the RNP mode, is it really possible to use VS there too?
    It is not forbidden as for lnav/vnav and only lnav mode?

  • edited August 2019

    For example, in Boeing FCOM, you can not use V/S when RNP app:
    Use LNAV and VNAV or other pitch mode for initial descent. VNAV is required
    FAF inbound.

    And Airbus allows NAV + FPA guidance, but this mode(FPA:Flight Path Angle) is more accurate than just V/S.

    It seems to me that for dash you also can not use the V/S mode when RNP.
    When RNPallowed only VNAV, any thoughts on this? ;)

  • I read that differently in the FCTM. Where exactly did you read this?

  • edited August 2019

    @FraPre said:
    I read that differently in the FCTM. Where exactly did you read this?

    FCOM.
    the fact of the matter is that only the approach with V/S is allowed, not RNP landing :)
    because with RNP, in FAF high accuracy is needed which cannot be obtained with V/S + to to everything said, on PFD(on Navigation Performance Scales (NPS)), we should see warnings in case of deviation.
    vnav vnav2

  • Good, then that will probably be so.

  • we turn to this topic :)

    I would like to know will this be fixed?

    1)vertical path is miscalculated since it starts with the Rwy height but should actually start with the Threshold Crossing Hight(rwy elevation+50ft)

    2)missing just for one or more waypoints the heights, the approach is not flyable with VNAV.

  • The FMS is not perfect and still as some flaws. We'll have to have a closer look into this once we are able to complete our primary focus at the present time. Having re-written its code to make it compatible with the 64bit platform could pose additional issues but it is certain worth taking a look at when it's time to address bugs/flaws.

  • Hi,
    An interesting document that I believe we can post now as Flybe does not operate anymore.
    The way it was with their Q400 (.pdf enclosed).
    JP

  • @niksan29 can you give me an concrete routing for the example 2?

  • edited August 2020
    @FraPre probably about what I was talking about at the very beginning of this topic?
    Or do you think that VNAV Dash should not calculate the heights of such/similar points? I have not found evidence of this...
  • The Universal 1E simulation of the MJC Q400 is using the Navigraph database as follows. From the FAF to MAP the altitude are set according to those published in the database exactly. When the approach course co-insides with the runway heading one will get the expected performance from the FMS by guiding the pilot all the way to MAP

    The FMS is NOT expected to guide you in 3D to the 50 ft (CATIII) in every case. For this, one really have to use the HGS

  • edited August 2020
    @Boss
    Hi!

    two questions:

    1) where did you get this information? can you somehow confirm this?

    2)why was the wrong altitude 9500ft calculated for the point WI103?
    ---

    P.S I wanted to say the addition of 50 feet(in FMS nav plan) is for reference only probably should be in all cases.
  • @niksan29

    Hello, I tried to find out your problem and had this too. One could assume that it is because the point as part of the approach has no height specification. To confirm this, I started my charts using a similar approach from another airport. So far I haven't found anything, but I'll get in touch if there's anything new.

  • edited April 2021

    Hi Guys,

    So the coding of RNP approaches is depending also on the navigation data provider. In real life, NAVBLUE DB and JEPPESEN DB have minor differences in the way of naming fixes and calculating certain descend profiles.
    I can't really comment on the coding of the approach paths I am not really aware of the certificated way it should be done.

    However, in this LOWI example: seeing WI103 associated with 9500ft doesn't seem correct.

    Maybe a bug, I don't know.
    Like Krosswynd said, the FMS is not perfect and also simulating an older FMS software version which works a bit differently in these VNAV-aspects than the newer version.


    About the RNP approach types in general. Flying an RNP Approach with:

    • LNAV/VNAV minima will require you to fly with FGM* LNAV & VNAV

    • LNAV minima if the approach glide path is encoded in the FMS, you have the choice whether to fly it with FGM* LNAV & VNAV or FGM* LNAV & VS. In any case, if no glide path is encoded, you must fly it with FGM* LNAV & VS.

    *FGM = Flight Guidance Module (fancy Bombardier-term for Flight Director/Autopilot module)


    Let's say now you're flying an LNAV/VNAV minima RNP approach through FGM* LNAV & VNAV. Suddenly, for an unknown reason, your FGM* VNAV fails (or doesn't seem correct). You are allowed to continue the approach with FGM* LNAV & VS as long as you change your approach minima to LNAV minima !

    Also, once you reach this RNP Approach minima, the FGM* VNAV will just disengage and leave you with FGM* PITCH HOLD.
    That's because it is not certified to fly you all the way to the runway. But I guess this is also simulated in the Majestic.

    Also2, The RNP Approach you're showing in LOWI : RNPz 26 (AR) is a very specific type of RNP approach. The (AR) means "Authorization required".
    It requires additionnal certifications and authorizations on the airplane navigation systems, pilots and Airline by Autrocontrol in this specific LOWI case.

    In our real planes, we don't even have a choice to select RNPz 26 (AR), because we're not certified to perform it.

    Going to LOWI via RWY 26, we will use LOCDME 26 EAST or LOCDME 26 EAST SPECIAL instead.

    I hope you'll find my answer useful. :wink:

  • edited April 2021
    @Jetairfly1
    Thank you for answering, I just want to clarify:
    the navigraph for sim does not indicate altitude at WI103 point (the same in real data) this is also confirmed by the charts...
    the altitude at this point should be calculated by vnav your plane(what does the same PMDG, FSLABS or AEROSOFT do correctly).
    and about +50 ft at the threshold, your fms adds this automatically?
  • @niksan29 said:
    and about +50 ft at the threshold, your fms adds this automatically?

    @Boss

    Hello ! =)

    So apparently yes, the TCH is added to the threshold FIXE in the FMS see here :

    On the chart, we can see the Threshold Crossing Height (the little square on the vertical approach path diagram) is equal to "57".

    If we then take the THR elevation : 691ft and add 57ft to it that's : 748ft which is exactly what the real FMS is computing in its profile. =)

    I hope this helps !

    Kind Regards,

  • With the navigation data of the Dash, the height of the airport is always shown for all available Rwy and landing procedures, for LIMC this is 768 ft, in order to stay with the current example image.

  • @Jetairfly1
    Hey!
    your screenshot is unfortunately not available...

    @FraPre
    I didn't quite understand, we talked about +50 which are not added to threshold crossing height the current version Dash, although they should.

  • I see the pictures from the FMC and the extract from the LIDO Approach Chart.

    @niksan29
    Yes, that's what we're talking about, and that's how it is shown on the picture of the real dash. For me, i.e. the Majestics Dash with AIRAC 1712, only the airport height is displayed on the Rwy. I checked this for 7 airports as an example.

  • @Jetairfly1
    @FraPre
    I don't see the picture, could you upload it to another resource?
  • Hi,
    @Jetairfly1
    Very interesting to know that this feature exists on some real FMS.
    @FraPre
    The problem that we have with the Sim (not only with the MJC Q400) is that FSX and Prepar3dv4.5 consider all runways elevation as airport elevation which most of the time is wrong.
    The best ex. that I know quite well as I used to fly a lot there is LFRN.
    Airport elev. is 124 Ft. THR elev Rwy 28 is 120 Ft (quite alright) but THR elev Rwy 10 is 77 Ft. In fact when you TOff from Rwy 10 you barely see the top of the tower.
    If you take the MJC Q400 or any other Acft and position them anywhere on this airport, the altitude shown on the altimeter is always 124 Ft.
    The FMC will show you 124 Ft for Rwy 28 and Rwy 10 as well.
    I am not sure but I think Prepar 3dv5 would give you real Rwy altitudes. If somebody could comment on that ?
    Regards,
    JP

  • edited September 2021
    > @jpgmultimodal said:
    > The FMC will show you 124 Ft for Rwy 28 and Rwy 10 as well.
    > I am not sure but I think Prepar 3dv5 would give you real Rwy altitudes. If somebody could comment on that ?
    > Regards,
    > JP

    yes, this is so, the whole problem is that the official support for sloped runway was added only in P5, but the implementation for any scene designer(developer) does not seem to be an easy task, besides, no one wants to adapt scenes created for a long time :/
    therefore, there are almost no scenes with sloped runways :#
Sign In or Register to comment.