I use iFMS (a standalone FMC integrated into FSX and MSFS) on my Android device. The Navdata has to be manually downloaded onto my PC as a compressed fileand then transferred into the proper Android tablet folder. No problems there. However, I noticed for all STAR’s that when there is an altitude constraint, the “above” or “below” indicator is incorrect. As an example, the following downloaded data is from AIRAC cycle 2209 and is for the ANJLL 4 Arrival into KLAX:
ANJLL
Normal
34.211203
-116.982778
0
**24000**
** 19000**
** above**
Fly-by
25
Auto
The error is in the keyword “above”. It should be “below”. The keyword applies to the 24000 XML code line, not the 19000 XML code line.
As a result, for all Arrival waypoints where there is a constraint and you are required to remain below the ceiling altitude but above a given floor altitude, like at the ANJLL waypoint, the FMC programs you to fly above the ceiling altitude and you then violate the altitude restriction on the approach. This actually occurs on every approach so you have to manually go into the FMC and change every “above” to “below” when there are two altitudes given.
Seems like Navigraph could implement a very simple coding change when creating the data. For all arrivals (not departures) where there is an altitude given in the code line that is not “0” (zero), the code line should state “below”, not “above”. When the = 0, no change is necessary as that “0” indicates there is no constraining altitude.
I have not seen this type of issue on any departures but then I haven’t been on a SID departure where you were required to remain between two altutudes at a particular waypoint.
This is just a forum for users so how can I get Navigraph to implement this change?
Hi again,
sorry for the delay of this answer but I have found not the time for the detail analyzes in the past days due our yearly kick-off meeting.
The problem here is, that ANJLL has exactly a constraint BETWEEN, means below 24000 ft and above 19000 ft. You also see this on the charts
Indeed there is/was an implementation error, to set such constraints to “AT” or “BELOW” instead of “BETWEEN”. The issue now is, that iFMS doesn´t support such “betweens” what is a little bit difficult because the origin addon which uses the data is the LevelD and here this constraint works as expected with BETWEEN …
It´s exactly what I have described above … below 24000ft and above 19000ft.
I have now fixed this in the LevelD dataset but the iFMS doesn´t recognize it, therefore I assume such constraints are not implemented in iFMS.
That means, we have fixed this, but this fix will not shown in the iFMS. We also can´t offer any other solution (as you have described in your posting) because as I have written - the base dataset is the LevelD dataset and iFMS uses this LevelD dataset. Also, it´s not an issue in the STARs only there are also such constraints in SIDs in some areas, so this was an important hint and therefore we have immediately fixed this now.
So, please report this to the iFMS developer that they implement the “between” restriction also?
So the AltitudeRestriction element can be at, below or between
Here the example of the ANJLL4 arrival (the result do you see in the screenshots above):
The changes will effective with the next cycle 2210, release date OCT/06 and this “between” will also be added in the iFMS dataset than because as I wrote, it uses the LevelD dataset.
