Jump to content

Will C

Members
  • Posts

    23
  • Joined

  • Last visited

About Will C

Recent Profile Visitors

648 profile views

Will C's Achievements

Rookie

Rookie (2/14)

  • Dedicated Rare
  • First Post Rare
  • Collaborator Rare
  • Conversation Starter Rare
  • Week One Done

Recent Badges

0

Reputation

  1. Also, just in case anyone finds it helpful... to switch from ISA deviation to outside air temperature in the existing flight plan template of your choice: 1. Back up the template you want to change. 2. In your template file, locate the data field <&ISADev> and replace it with <&OAT>. Note that <ISADev> may have a number inside it, like this: <ISADev:3>. To preserve formatting, carry that number into <&OAT>, like this: <&OAT:3>. Pay attention to capitalization. And make sure not to change the number of leading and following spaces, or else the formatting will change. 3. Re-select your template within PFPX. You should then be good to go. Note that neither of these data fields are listed in the Flight Plan Template Guide 2.0, which makes them something to think about if there is ever a Guide 3.0.
  2. Thanks, that's helpful. I remember a real-life dispatcher once said (on another aviation forum) that the real-life professional flight-planning software sometimes got too zealous about changing altitudes up and down to "chase tailwinds." He said that he tended to smooth things out into orderly step climbs, since that was what was most compatible with ATC clearances anyway.
  3. Thank you Andrej, that seems to work. Can you (or someone else) check my workflow and let me know if I'm doing this in the best way? 1. "Compute" the flight. 2. Check the OFP, note that the altitude needs fixing (Init Alt = 17999 feet, there is a descent immediately after departure, etc.). 3. Note the preferred initial cruise altitude (FL310). 4. Note the first waypoint past the altitude issues (e.g. CGT). 5. Hit Re-Plan. 6. Go to Advanced > Speed/Altitude/Holding, enter initial waypoint under "From," enter first waypoint past the altitude issues under "To", and enter the preferred initial cruise altitude under "Fixed Altitude/FL." For this flight, this pane now looks like the illustration below: 7. Hit "Compute" again. 8. Now the problematic section has been smoothed over, and the aircraft climbs to the initial cruise altitude without issues, and continues to climb on schedule without further manual inputs, see below (compare this illustration to the one in the original post): Operationally, this solves my problem. But I'm wondering if this is the best workflow? Is there a more efficient or a more preferred way to get to the same result? Thanks.
  4. I'm sure this is an easy fix, but I can't find it. As you can see, PFPX wants the aircraft to climb to just below 20,000 feet for a microsecond (actually it's 4 minutes), then descend back down to 16,000 feet for another microsecond, and then climb up to FL310. On the OFP, the initial cruise altitude (the value of <&InitCruiseAlt>) is 17,999 feet. Clearly odd. To fix this, first I put in a Min Alt/FL of FL250 and hit Compute again, but I get the same result: 4 minutes of level cruise at 17,999 feet followed by a descent. So then I next looked for a way to edit only the altitudes in the advanced route editor and I'm not seeing it. One thing I noticed were that the initial waypoints were on a low-altitude Victor airway. So I hit the button that said Upper Airways, and still got the same result. Then I removed the airways between the initial waypoints and made each waypoint just DCT to the next. Still the same result. Any suggestions? Thanks for your help.
  5. Thanks Stephen. I also read somewhere that by choosing alternates strategically, you can often find airports such that ETP ADD=0. Reducing ETP ADD to zero serves two purposes: one is to maximize payload, and the other to avoid an unsightly gap in the OFP's fuel ladder... 🙂
  6. UPDATE: Resolved. I think I had a nesting error with the section tabs. That said, <&TimeEllapsed> does seem to reset to zero when you divert at the end of the main route, perhaps because the initial point of the alternate route is an airport. But it is incrementing properly to show cumulative time since departing the destination airport, and the planned time matches the predicted time. Which is another way of saying that <&TimeEllapsed> at the end of the diversion matches <&Altn1Time>. Good to go!
  7. The data field <&TimeEllapsed> seems to reset after the destination. The problem is that I have a "Diversion" NavLog (for the route from the destination to the alternate) that is working correctly in other respects, except that the <&TimeEllapsed> is no longer a cumulative counter recording the time elapsed from takeoff. Instead, on the diversion NavLog, <&TimeEllapsed> shows only the time from one leg to the next. By way of example, the final four legs of the main route (origin to destination) count up cumulatively, like this: 12:30, 12:45, 13:05, 13:27. But after diverting, <&TimeEllapsed> only shows values like this between legs: 5, 5, 5, 5, where each leg is hypothetically 5 minutes from the previous one. In other words, it resets to only show just the time from the previous leg, not the cumulative time elapsed since takeoff. Everything works well in the main trip NavLog, and in the re-dispatch NavLog; it's only the diversion NavLog from destination to the alternate that is giving me this behavior. I'm using <&TimeEllapsed> for each of the three NavLogs above. Should I be using a different data field for the cumulative trip time from takeoff to the alternate? Or is there a better way? I should add that I copied and pasted the data fields for the three NavLogs (trip, re-dispatch, and diversion) so they look identical except for their section headers. And every data field works as expected, except <&TimeEllapsed> for the diversion. Thanks.
  8. The Flight Plan Template Guide allows for <&EROPSFuel> with data type "weight," but there is no corresponding <&EROPSTime> with data type "time." Thus there's a missing line in the endurance column of the fuel summary chart. If I read the Fuel Policy section correctly, <&EROPSFuel> corresponds to EDTO Reserve Fuel and it would make sense to me that this would be expressed as endurance, along with the other fuel types. Can anyone shed any light on this? Thanks.
  9. Lo and behold, after a year and a half, I found a solution. If anyone would like to have inHg on the OFP, then just go to the window seen on the very first post in this thread. Then, FIRST enter and check all your performance data and hit Calculate (but not Apply) until you have your final results. Once you are through with the Calculate feature, then go down to the Pressure field and re-enter your pressure in inHg. (Just type over the existing entry, even if it's the same, but don't Return or Tab out of that field.) Now, Calculate one final time, hit Apply, and the pressure will show up on your OFP as an altimeter setting, with an "A" preceding it (as in "A30.06"). A minor thing, but if someone wants the feature, that's how to use it. Note that this may only work for airports where the METAR reports InHg in the first place. If the METAR is in hectopascals, this may not work. [Edited because I made a mistake in describing the process; it works as written now.]
  10. That option was a little hard to find, so thank you. I see it now.
  11. Hello, maybe I'm missing something obvious, but I was recently flight-planning a route and the closest fit to the great circle distance ended up requiring EDTO rules, because the threshold time was exceeded. However, it would have been possible to fly a non-EDTO route that stayed entirely within the threshold time, but this would have been less direct, and would have required more fuel. Is it possible to tell PFPX to pick a route that stays within the threshold time the whole way, or would such a route need to be built manually? Thanks.
  12. Hi all, I saw the recent thread about enroute charts but I just noticed something with airport charts. The airport in question is Seoul/Incheon (RSKI), the approach is "ILS or LOC 33R." I looked at the same approach charts from Aerosoft and Navigraph tonight, side by side. The Navigraph (Jeppesen) chart clearly shows an AIRAC cycle of 21-5, and the date of the chart is 5 Feb 21. Under changes, it says "communications." The Aerosoft NavDataPro (Lido) chart is older, with a date of 8 Oct 2020. Under changes, it says "completely revised." I'm a new customer here, and I'm curious, not complaining: does the Lido source data lag Jeppesen source data? Or does Aerosoft lag Navigraph when it comes to updates? Or does Jeppesen issue proprietary updates independent of AIRAC revisions? Or one final thought is that the AIRAC format includes dozens of fields, some of which may be irrelevant to certain operators, so the 21-5 cycle may be different than the 20-8 cycle in a way that triggers an update for Jeppesen but not for Lido. That's all I can think of. Can anyone else shed light on why Navigraph has a more recent RSKI ILS 33R chart than Aerosoft? (If this post belongs in a different forum, please feel free to move it if you are a moderator, or else tell me where to repost. Thanks.)
  13. I've seen some FAA-style routes on dispatch paperwork from USA domestic regional carriers... but they're from several years ago. As for making a PFPX OFP with an FAA style route -- It's probably not worth the trouble, but thanks for the offer.
  14. Similar to the issue of TOPCAT importing only values in hectopascals (and not inHg) into PFPX flight plans, it looks like the ATC ROUTE is permanently stuck in ICAO format as well? I can change "Output" to "FAA" in preferences, and then within the PFPX route window, the flight plan shows up in FAA format, but when it comes to the OFP, the version reverts back to ICAO. Not a big deal, I suppose.
  15. Thank you, that's very helpful. Regarding the boldface parts of the ATC ROUTE, are they supposed to be intelligible to the flight crew? Here's the first one again: N0501F350 Given what you said about changes in speed and/or altitude, I'll deduce that the F350 indicates an initial climb to FL350. That indeed fits with the flight plan. And the subsequent xxxxxF370, xxxxxF370, and xxxxxF410 all make sense now. (Except that I would have expected an intermediate segment at FL390, but that's a question for another day perhaps.) But what about the first five characters (N0501)? Some kind of code? Again, is the flight crew intended to understand it? Thanks for your time.
×
×
  • Create New...