Most STARs at VHHH include a AT 280KIAS and AT FL130 restriction at a waypoint. On the PMDG 737, the altitude restriction is missing entirely.
ABBEY3A shown above, MUSEL missing altitude restriction.
Hi,
the problem here is, that this altitude restriction can be modified by ATC or the altitude will be assigned by ATC and therefore such alt-restrictions are not hard-code.
You can read this also on the charts:
Cheers
Richard
Hi Richard,
Thanks for your quick response.
I do not believe this is correct. This problem extends to pretty much most STARs for VHHH.
The excerpt you have provided says to 'Cross MUSEL at FL130.". There is no condition to this. The graphical depiction marks crossing AT FL130.
The remainder of the paragraph refers to the holding over ABBEY. ‘IF holding over ABBEY is required, each flight will be instructed individually’ from my interpretation refers explicitly for the holding at ABBEY only; it should not apply to MUSEL.
Perhaps I could have been clearer in my first post. This problem is for PMDG ONLY, other aircraft program the STAR correctly. I have suspicions this issue may be due to PMDG using legacy navdata format?
Fenix A320
FBWA32NX
WT B78X
Some further examples of other STARs
CANTO1G
PMDG 73NG, GUAVA is respected but CANTO is not.
I have noticed a pattern where if the waypoint has a CROSSING AT FL, it is not respected, but only if it is defined as FLXXX. Altitudes (such as GUAVA as shown above), are not affected.
This issue extends to the following STARs,
ABBEY3A, ABBEY2B, ABBEY1G, BETTY2A, BETTY2B, BETTY1G, CANTO2B, CANTO1G, SIERA6B, SIERA6D, SIERA1G
Of note, CANTO3A is not affected as it does not contain any CROSSING AT restrictions.
Sorry, but you post only the half … On every chart of these STARs you find the explicit information in bold “Do not decent without ATC clearance”.
Right, but the last (bold) instruction implicite the infornation above, so why again as a own sentence? It contains holding information but no altitude ATC clearance. Also when you look on the text routings you find the information “Descent directed by ATC”. Another indicator, you will not find this on every chart with altitude restrictions. This is a clear and explicit instruction
This explicit information set the “ATC indicator” internally to A or S (depending the source of this information) in the data source. You don’t find this information on charts with hard coded altitude restrictions. So, this is really an explicit, important information which results to set this indicator in the data source.
Also you find this explicite information in the AIP too. Again, when this information “Do not descent without ATC clearence, or assigned by ATC, …” is missing such altitude restrictions are coded.
Correct is, that we have currently only inplemented this flag in the PMDG and therefore the difference. I will add this flag in the other datasets too in one of the next cycles to be consistant. Thanks for the hint.
Cheers
Richard
Hey Richard,
I still disagree.
the problem here is, that this altitude restriction can be modified by ATC or the altitude will be assigned by ATC and therefore such alt-restrictions are not hard-code.
If this is the case, why publish a chart showing MUSEL height at all?
Jeppesen
I believe that ’ Cross MUSEL at FL130.’ terminates as a sentence and should be interpreted at face value. You should cross MUSEL FL130, period.
Right, but the last (bold) instruction implicite the infornation above, so why again as a own sentence?
It is my belief that the last bold sentence is a general statement that applies across the board to flight in this airspace, due to the possibility of some pilots from other countries where their procedure allows them to descend via the entire STAR without explicit ATC altitude clearances. HKCAD likely does not want pilots to cross MUSEL @FL130, thence leave and continue descent without explicit ATC clearance.
HKCAD AIP
The PDF above is published by the HKCAD themselves.
Page 1, Note that MUSEL is in its own paragraph as is the bold statement.
Page 2, FMS coding for MUSEL is published with @FL130.
https://www.ais.gov.hk/eaip_20231130/2023-11-30-000000/html/eAIP/VH-AD-2-VHHH-en-US.html#i49703
The rest of the VHHH publications from HKCAD AIP is linked here.
I think, you have answered your question now by your own.
What would be happen when the leg in the FMC shows 280/FL130 or 280/13000? Yes, the airplane (VNAV mode engaged) starts the descent automatically and thats exactly what should not be.
You can’t set such restrictions only as “information” in the FMC you can code than the a/c will follow it or not. There is no condition, if then …
Therefore, the “ATC indicator” flag in the ARINC424 specification. This flag (which is coming from the official goverment) tells the source provider, that there is a restriction (13000 feet) but in the same time, you may not descent automatically - only assigned by the ATC.
That means, we have the restriction in the database yes, and you see this in the other addons but there the flag exists too and therefore, you must remove the hard-coded restriction in the FMC, that the a/c will not start the descent automatically. I know automatically is not the correct wording here … because it doesn’t do it automatically but the T/D calculation is based on that information.
There was a great discussion about this in our old forum, where we had such example with somewhere in the US area but I can’t remember what airport this was.
Fact is, agree or not agree me, that the coding itself is correct and the flag is set by the goverment. Also, you see on all charts, Jeppesen and in the AIP, that this information is explicit on only selected arrivals.
Cheers
Richard
You are misunderstanding what I meant in post above.
You are saying that the bold statement is there to prevent the aircraft from leaving its CRZ LVL without ATC clearance.
I believe the statement there for AFTER crossing MUSEL @FL130 to ensure crews do not continue descent below FL130 as there may be some pilots from countries that provide implicit clearances (i.e. once you are cleared to perform the STAR, you are allowed to descend all the way to the procedure’s bottom altitude).
I will concede as I know not of the backend with ARINC424 data, afterall it is provided from Jeppesen directly as I understand? I will try to find out more information from RL sources, though I think the thread will auto close by then.
Cheers,
I have removed the auto-close feature for this posting … but I will implement the flag in all datasets too, to be in sync with all datasets.
Cheers
Richard
Hey Richard,
Some reponses to your posts:
Bold statement interpretation
I have reviewed procedures into VHHH and it is not in fact explicitly stated on selected arrivals, it is stated on all arrivals into the airport. Not only that, it is also stated in VMMC STARs that transit VHHK airspace. I believe this bold statement to apply to any flight within VHHK airspace and is not procedurally unique/dependent.
I understand that your interpretation for the bold statement is to not allow auto descent from CRZ altitude, however
If that was such a case, why would it be written after ‘Cross MUSEL at FL130’ and not before? Once again I believe this statement to be general and applies across all altitudes and stages of flight.
Impact on descent and descent planning
I fail to see your point in this example because regardless if there is a restriction there or not, the aircraft would not initiate descent automatically unless you select a lower altitude in the autopilot. If you do, the aircraft would begin descent at calculated T/D (be it earlier with restriction or later without restriction), which is in violation of the bold statement anyway!
In any case, AIP Hong Kong ENR 1.5 Para 2 states
2.2 DESCENT PROFILE
2.2.1 To facilitate safe traffic integration and provide vertical separation between converging traffic in the Hong Kong TMA, pilots shall plan their descent profile in accordance with the published STAR procedures.
This has historically been the case even since the days of Kai Tak, as Chinese airspace directly to the north means less flexibility for ATS to plan departure and arrival routes laterally. HKCAD has always favoured arriving aircraft to descend low to allow departing aircraft to climb above and over to separate vertically.
The published procedure visible to pilots (discounting the ARINC 424 ATC indicator which is not visible on the front end) shows MUSEL 280/FL130. Does this AIP clause not imply the expectation to be ready to descend on a profile to reach MUSEL @FL130? From a pragmatic point of view, would it not be easiest to have the restriction already loaded in the FMS to calculate and show such a T/D instead of pilots having to calculate such a point in their head and having to remember where it is, or to manually insert the restriction into the FMS?
Discrepancy between pilot visible and not visible data?
How would this compare with the HKCAD AIP chart having the coding reference showing @FL130? It does not indicate this to be conditional. Would it be your opinion that pilots would then have to manually input MUSEL@FL130 in order to remain compliant with this table?
Real world database encoding examples
Universal UNS-1
Here are some photos from an irl Universal UNS-1 FMS using current Jeppesen worldwide navdata
The photo below is from the coded nav database pages, not the flight plan page, so it has not been edited. Note that it is defined as a ‘@’ and not a ‘X’, so it is a hard, unconditional constraint.
This FMS is not configured to use speed functions, so only altitude restrictions are available. MUSEL is loaded @FL130 direct from coded database.
Thales FMGC
Here are some photos from an irl Thales FMGC using current Jeppesen worldwide navdata
FPLN page
VERT REV page for MUSEL
PLAN display
These are all as loaded and not manual entries, SEC FPLN was used.
Garmin GTN750 Trainer
Here are some screenshots from the Garmin GTN Trainer for Windows. Of course this is not an actual GTN unit but should be reflective of the real unit’s behaviour.
Database is noted to be out of date
I am not sure how this relates to the data source from which Navigraph receives but I insist that this is and always has been a mandatory restriction
I am attempting to source anecdotal advice as well as photos from real life sources from additional aircraft types/FMS types/data providers. I shall post them if I am able to locate any more.
Cheers,
Hi again,
first of all, thank you VERY!! much for such detailed report with such detailed information. It’s very seldom to get such a long feedback back to an open case. Good stuff and again, thanks.
Back to our topic:
I will open a case at Jeppesen to ask the guys there too but due the holiday season at the moment, I would not expect an answer before the year ends. I guess more somedays in January.
Therefore I will keep open this topic, and mark it for a feedback from our side to you here. Please, whenever you have any news to this, let us know 
In the meanwhile, Merry Christmas and a Happy New Year 2024
Cheers from Austria
Richard
Hey Richard,
Happy new year to you. I was unable to obtain any more examples unfortunately. Have you heard any word from the good folks at Jeppesen?
Hey Richard,
I was finally able to source an image from a Boeing aircraft, B744 using latest Jeppesen Worldwide navigation database AIRAC 2402. Please review.
Thank you, I will review it again but I’m pretty sure the answer from our data provider will be the same. It looks more a tailored dataset but we will see.
A few questions to the sceeenshot:
- From which airline was this shot?
- when was it taken?
Cheers
Richard
My source is unwilling to disclose the airline unfortunately.
This was taken about a week ago.
Thanks, so we can only assume that this is a tailored dataset then, sorry.
Cheers
Richard