Cruise altitude vs airway upper limit

[JohnsonPBX 0]

Hello. I'm experiencing an issue which got me scratching my head for a while now.

First I'll provide the route: From Cali (SKCL) to San Andrés Island (SKSP), route is SIGI2C BUSMO UA321 MORLI A321 BIXOX BIXO1C. Bold segments are the SID and STAR respectively, and red one is the transition from a high altitude airway (UA321) to a lower altitude one (A321), in order to comply with the STAR, BIXO1C.

What's the problem? When computing the route, (after having gone through the advanced planner, un-ticking the Cruise Altitude/FL restrictions option, selecting Upper airspace, selecting OPT in the Aircraft -> Cruise Altitude/FL tab and setting Step Climb to No), the OFP shows me something strange: due to BIXOX being a lower altitude airway intersection (A321), and since A321's upper limit is FL195, the OFP shows a descent (DES) BEFORE the TOD, and the TOD, which is between BIXOX and NEPET, is shown at 18.000 feet. Something's going wrong there since the TOD is supposed to be calculated from the cruise altitude, not the airway's upper limit, isn't it? I was also earlier experiencing some issue with the flightplan and the cruise altitude being restricted because of the airway's upper limit, while in some cases (due to some specific routes in my country being possible only by using low altitude segments) it becomes necessary to use low altitude airways.

Am I missing something? What's the correct way to totally get rid of / ignore airway upper limits in order to avoid situations like the one exposed above? Thanks in advance.

Attached is a picture of what I just explained, being the shaded area the TOD, which is actually shown AFTER a descent.

[Frank Schrewe 5]

I think due to the fact that A321 is alower Airway PFPX plans a Flightlevel change to FL180 to get that altitude restriction. So FL180 becomes your new Flightlevel and your TOD is the point where you start your descent from this new Flightlevel...

[JohnsonPBX 0]

... That is my question precisely, how can the airway's upper limit be overriden / ignored so that the planner doesn't calculate the descent this way? I've seen real flight plans using low altitude airways (because the sector isn't covered by high altitude ones, for example), while cruising at FL350 and this issue isn't present.

[JohnsonPBX 0]

Any reply to this please?

[Pierre95 14]

Hi,

In real life, you can't override the Altitude range of an airway.
The OPF you've seen probably use high altitude away often using same # but with "U" perfix.
Another tip to avoid this is using direct instead fo low altitude airway.

Hope this help

Best Regards

Pierre

[JohnsonPBX 0]

I think there's a misunderstanding here. I have a copy of a real OFP created by the airline I work for (Avianca) with the exact same route using JetPlan. Only difference is the SID which is irrelevant in this case. In said OFP the TOD is shown normally at FL340, which is the final cruise altitude- it does not plan a descent to 18.000 in order to match the airway's upper limit and then place the TOD from there like PFPX does. Also, as I said before, it becomes necessary to make a transition from a high level altitude (UA321) to low altitude one (A321), since BIXOX, which is the intersection at which the STAR begins, only connects with A321.

Today, while planning another short flight in my country (around 172NM long), this time with PMDG's 777F, I found another weird issue. The flight was planned using low altitude airways only, and the airplane was very lightly loaded (2 passengers and 32.000Kg of cargo). This time, even though the airways' upper limit is FL245, PFPX calculated a cruise altitude of FL390, where the TOD was (ironically this time properly placed right from the final cruise altitude) immediately next to the TOC. Here's a picture:

For information purposes, this flight was: SKCL - SKBO, being the route ULQ5B ULQ W1 ABL ABL3B.

After reading both flightplans it appears that PFPX is contradicting itself regarding airway altitude restrictions, seeing that in the second one it totally ignores W1's upper limit of FL240. Is there a way to solve this? Or is it possible to add an option to respect / ignore airway upper / lower limits in order to avoid what happened in both flight plans discussed?

Thanks in advance.

[Torben Andersen 15]

Don't know if this helps, but A321 altitude restrictions ought to be FL245 according to the Columbia AIP:

http://www.aerocivil.gov.co/AIS/AIP/AIP%20Generalidades/En%20Ruta/20%20ENR%203.1.pdf

Torben

[JohnsonPBX 0]

Colombia* and yes, I've seen that chart. Weird thing is that PFPX's route editor (in the advanced tab) shows a maximum altitude of 19.500 feet for that segment. I also checked the AIP's upper airways document, and it shows that UA321's lower limit is FL195, so I assume PFPX is taking the upper airway's lower limit as the lower airway's upper limit, since it's a descent in this case.

Either way I think it wouldn't make much of a difference. Due to the way PFPX calculates the descent, even if the segment's maximum altitude was 24.500 feet in accordance to the AIP, it'd first show a DEScent to FL240 and then show the TOD from there, just like the case mentioned in my first post. That precisely is what I consider is wrong and there should be an option to override / ignore said airway restrictions since real flight planners such as JetPlan allow it with no issues at all. Just like PFPX itself did ignore the airway's upper limit in the second example I posted (which shouldn't have happened either ).

[FlightSimSoft.com 283]

• The segment from MORLI to BIXOX has an altitude restriction between 3000ft and 19500ft
• PFPX schedules a descent at MORLI to 18000ft
• The TOD is shown at the final descent to destination
• If you want to force PFPX not to plan this descent, just enter an initial altitude or an Altitude constraint of e.g. FL380

[FlightSimSoft.com 283]

After reading both flightplans it appears that PFPX is contradicting itself regarding airway altitude restrictions, seeing that in the second one it totally ignores W1's upper limit of FL240. Is there a way to solve this? Or is it possible to add an option to respect / ignore airway upper / lower limits in order to avoid what happened in both flight plans discussed?

Found an issue, causing PFPX to ignore maximum altitudes in certain circumstances. Fixed in v1.10

[Torben Andersen 15]

• The segment from MORLI to BIXOX has an altitude restriction between 3000ft and 19500ft

Strange, as the AIP says A321 is from 2500' - FL245, but UA321 FL195 - UNL. Is your restrictions taken from the AIP, a RAD document or the AS/NG database? And how can one chose between upper/lower airspace, when they overlap?

Torben

[FlightSimSoft.com 283]

Restrictions are from the database provider. As written before, I'll take a closer look into that issue.

[JohnsonPBX 0]

• The segment from MORLI to BIXOX has an altitude restriction between 3000ft and 19500ft
• PFPX schedules a descent at MORLI to 18000ft
• The TOD is shown at the final descent to destination
• If you want to force PFPX not to plan this descent, just enter an initial altitude or an Altitude constraint of e.g. FL380

Entering an altitude constraint on BIXOX to FL380 (or whatever final altitude that was calculated) wouldn't work since the original descent is planned BEFORE BIXOX, which means that PFPX calculates a descent BEFORE BIXOX, then a climb again in order to comply with the manually entered constraint, then the TOD on FL207 and the final descent to the runway. In other words, it goes crazy acting as a rollercoaster

Here's a screenshot of what I'm talking about:

HOWEVER, if I set the altitude manually in the Aircraft -> Cruise Altitude/FL tab, the OFP shows everything as it should, with the TOD shown from the final cruise altitude. So the trick would be first calculate the route using OPT (or just checking the aircraft's performance charts for optimum cruise altitude according to gross weight) and then enter that altitude manually. Here's a second screenshot:

I got one final question: in the Route tab there're two fields, Circuit Out and Circuit In Dist, I suppose (correct me if I'm wrong) that those are used to enter an extra distance for expected delays / procedures on both departure and arrival airports, right?

If that's the case, it could be useful that both fields allowed either a Circuit Out / In Distance or Time, in order to predict delays / extra times not included in the orginal route. Just like on the Fuel tab, where it allows to enter either an Extra time or Extra fuel (one is replaced by the other).

Thanks in advance!

[FlightSimSoft.com 283]

If that's the case, it could be useful that both fields allowed either a Circuit Out / In Distance or Time, in order to predict delays / extra times not included in the orginal route. Just like on the Fuel tab, where it allows to enter either an Extra time or Extra fuel (one is replaced by the other).

If you plan for a delay upon arrivel, the HOLD TIME field should be used.

[JohnsonPBX 0]

Are you talking about the Hold time in the Fuel tab? If so, this would be different as Hold time fuel is added to the release fuel and endurance time respectively, but it is not reflected in the OFP as it is counted as a reserve fuel, not as an actual enroute extension, unlike the Circuit Out / In Dist (which is the one I was asking for the time figure addition), that actually adds the input distance as an elongation of the actual route flown, and is reflected in both OFP Route distance and time...