Jgid

Sounds good! That will be Very useful. Related to the updating of the weather, in SP1, will ASN give winds based on the flightplan that is put into it, or will it see the flightplan in the FMC, and give wind data based on that? For example: If the route is changed inflight, and a new wind uplink is requested.

I didn't look that closely into the options, but I found it and problem solved! Thanks for the help!

So to confirm, if I have ASN running with my flight plan loaded, and I request wind data in the 777, ASN will create a new weather file real time, and update the CDU with the most up to date wind forecasts in flight? When looking at the WX file in the WX folder, the date modified stays the same, even when I request the wind data at a later time. Are the forecasts still updating, but the wind file stays the same?

When flying, you can either descend or slow down, but not both at the same time. In this case, choosing LVL/CGH would have done what you wanted, except, it will take much longer that what would be needed. Level change is a pitch to maintain speed mode. It works in combination with the auto throttle to reach the selected altitude at the desired speed as quickly as possible. In the case of large descents, such as this one, flight level change will reduce the throttles to idle, and pitch the nose to reduce speed to 250kts. The reason that you are only getting a V/S of 100-200 is because that is the most the aircraft can pitch down and still reduce speed to the 250kts. Once the aircraft is slowed to the selected speed, the descent rate can increase, because it is easier to maintain a speed while descending. If you are using default ATC, it is possible that you are simply not being given enough time to descend to that altitude with that speed. For the most part, if VNAV is left on, and you begin your descent at the top of descent, you should be able to maintain approach altitude restrictions, etc. If you must descend after the top of descent as per ATC instruction, try using LVL/CHG with a higher seed selected. This may help increase the rate of descent. VNAV descent paths are just like LVL change with the pitch to maintain speed function. You could try descending with a V/S that will descend faster, also increasing speed, but then reducing that speed once reaching the selected altitude. The below YouTube video is by another AVSIM member, and explains planning descents in greater detail.

That sounds like whats going on. Thanks for the help. That is my goal, but from the above post, that may not be possible.

Hi I have been noticing that on takeoff using TOGA, once reaching 80-100kts, my thrust will instantly reduce to about 60% N1, and I have to re-advance the throttles to takeoff thrust. It appears that it is the throttle on my joystick is making very small movements that are overriding the auto throttle. The auto throttle is not overridden before 80-100kts, and moving the hardware makes no difference, but when I reach that speed, the hardware throttle regains control to adjust the throttle in the sim. Once gaining about a thousand feet of altitude, my hardware looses the ability to override the auto throttle, and all is normal. Also, when I do have control over the throttles using hardware, when I shouldn't, I am not able to move the throttles above the thrust limit set for takeoff. The setting in the CDU for hardware overriding the auto throttle is OFF. Any way to fix this, or am I doing something wrong? Thanks

Thanks for the great explanation! As Kyle said previously, the flight aware route would change closer to the departure time to update to the current track, and indeed it did. That was causing me a lot of confusion with the discrepancies between flight aware and the track messages. Thanks for the help!

In the past, the track messages have had 2 waypoints for the entry. An example from the beginning of this year: U COLOR RONPO 47/50 49/40 50/30 50/20 SOMAX ATSUR. Why are tracks only showing one waypoint and not the transition to the entry. If not listed on the track message, how do you know which transition you fly over for a given entry. As said in a NYC Aviation article: "If you fly over one of the points, you must fly to its buddy point, which is intended to line everyone up before going oceanic". Do I just guess based off of what the chart says? Thanks for the quick response.

Hi- If this topic is in the incorrect place, please move it. I rarely fly across the north atlantic, and when I have in the past, I had no issues. I would like to attempt another in the T7, but I am having some problems. I understand how the NAT system works for the most part, with entries and exits, etc. I am using PFPX, and the my first issue is the track messages only showing a single entry point, and not the pair that I have seen in the past on track messages. Has the procedure changed for flying the NAT's that now only requires flying to a single waypoint before entering the NAT? Problem #2 comes with my charting. I am using a Navigraph charts subscription, and the north atlantic charts that come with that. I am finding that the NAT waypoings are not showing on the charts. When flying the NAT's in the past, they have always been there. (The charts are up to data) When I look on skyvector, the exact opposite is the problem. I see the waypoints for the NAT's, but not the ones on the navigraph chart. Problem #3 deals with using flightaware for the route. I prefere to use flightaware to get the real world route for the flight I am flying, but I am seeing a difference in what NAT is filed, and the waypoints that are being flown. For example: NATV would be filed, but the waypoint directly before NATV would be the entry point for NATU. Lastly, if I forget the chart and flightaware, and just fly the NAT, many of the waypoints for the NAT are not in the FMC database. I am using Navigraph 1313. Would updating the database solve this problem? Do the waypoings for NAT's change on a regular basis? Thanks for the help, and once again, please move this if in the wrong location.

That would not be a RASS issue. Be sure that the takeoff calls are set to on in the simulation options under PMDG setup on the CDU.

I just tried the SID on runway 4, and had the exact same issue. Turned to about heading 330 and then turned back on course. It appeared that the Intercept waypoint remained active the entire time during the turn. It must not be a problem specific to your plane or procedure, because it is happening on other computers. It could be a navdata issue, bug, or just basic pilot error. One workaround to this problem would be using heading select and VNAV in combination until you are established on the radial. You could also attempt using VOR LOC to intercept the radial once you are on the 271 heading to intercept. As for the engagement for the autopilot, it is normal to engage at 400AGL in the NGX as per the FCTM. The minnimum altitude for autopilot engamenent in the -600/-900ER is 400 feet AGL. Sure, many pilots choose to hand fly depending on the procedures being flown, but the case or RNAV departures, LNAV and VNAV are sometimes required immediately after takeoff. Autopilot engagement at a low altitude also helps to reduce workload during during the departure profile. (As also said by the above post)

Exactly what I was thinking. When it comes to the programming the FMC, would it be realistic to enter the estimated ZFW from the OFP into the ZFC slot? I am assuming there is no way for the aircraft to know its ZFW in real life without telling it, unlike in the NGX.

As discussed Here, there is an easy way to have a precise match between a PFPX OFP and the actual wight of the aircraft. This is helpful in planning, but is this the most realistic way to plan flights? In real life, a pilot would get a final closeout with weight and performance data via a fight attendant or ACARS right before push back or during taxi. This would be an amendment of the weights that are provided in the OFP. Many factors such as more or less passengers, cargo, and fuel can change from the time that the flight plan was printed to the time of push back. Also provided in a closeout would be runway specific performance information for takeoff, and V-Speeds. Taking the updated weights from the closeout, a pilot could apply the corrections for cruise fuel usage provided in the OFP. (Ex: TRIP CORR FOR 2000 LB TOW INCR: +123 LB / 2000 LB TOW DECR: -125 LB) In the sim, one could plan a flight in PFPX using the standard wights and have the estimated load in the OFP. Once in the sim and ready for push-back or taxi, you could get your final takeoff weights, and calculate v-speeds if done externally, as well as any other performance related calculations, just as a real flight crew would do with a takeoff closeout. I am not 100% competent in this subject and others may have more information on this topic. How do most people plan their weights in PFPX or other flight planning programs. Could this be a more realistic way to flight planning instead of putting in exact weights to into PFPX, or does it cause too much hassle? Thoughts or suggestions on methods of planning weights would be appreciated.

I never even knew about the new version! I will definitely be buying ASN when it comes out. Thanks!

Hello I am planning to purchase PFPX along with Active Sky Evolution soon and I had a few questions. The primary reason I am purchasing ASE is for the real world weather engine. I am not interested in enhanced graphics, the reason I am not getting AS2012. I just want to make sure however, there is not advantage in getting AS2012 for the weather simulation. Is the only advantage better graphics? When I was researching PFPX, I noticed something about needing to purchase a weather subscription after one year of use to keep the weather features in PFPX. Is ASE able to provide the weather data (Winds, altimeter setting, etc.) in replacement of the weather subscription from PFPX? Thanks for the help!