RNAV incorrect logic or AIRAC 1908 broken?
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
now APPR arm, at a point WI103 calculated incorrect height 9500ft...
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.
what a pity to hear this is really bad news
for example, pmdg b737 calculates the correct height at this point: 3343ft
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
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
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!
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!
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.
I didn’t know this, this is news for me, that is, it’s normal for RNP to use VS?
Tell me about this experience after.
+1
and add or modify the manual final phase, I think this is unacceptable...
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
yes yes, I noticed it right away
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
it is placed on a separate page
in our case it is better to use this option
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"
understand
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...
Did I not say the same above?
Only lav now on a separate page
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?
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?
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.
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?
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
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.
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.