davidz

For info, autopilot is not recommended below MDA+50 or DA on a non-precision approach. Boeing FCTM recommends that VNAV only be used as a reference below this level with visual references as the primary means of vertical guidance (which really requires you to hand-fly). A note for PMDG, while data for RNP approaches with RF legs is still generally unavailable now, these will be increasingly easier to access in the coming years as these approaches are available to a wider range of operators. Furthermore, there are other leg types (other than RF) than are currently unavailable in the current database format (e.g. AF legs, or DME arcs, must be crudely constructed; PI procedure turn legs are also unavailable and are impossible to program at the moment).

FSX market is alive and strong. Do I need to remind people of the kind of momentum FS9 had? Addons were still being developed for it well past the FSX release date. Addons have been released for it this year and possibly even next year, but it is finally slowing down. Developers are still pushing FSX - this evidenced by the fact that people are still struggling to build "super-FSX machines". Many people can get great frames in default scenery/aircraft, but the addon market is still challenging today's hardware. Some people view Prepar3D as a future. However, some developers/groups are approaching it very cautiously as Lockheed Martin are apparently unable to explicitly license it for "entertainment use", something that the likes of PMDG and VATSIM will ONLY license their software for (legal liability, etc.) As LM want to develop Prepar3D, it is likely that less and less of FSX content will be compatible and unless all developers just on that ship, it will sail away with only half of the industry on board. But what if FSX doesn't work on the OS of the future? Don't upgrade Matt Sheil, builder and owner of what was probably the first self-built 6-degrees-of-freedom motion flight simulator still has a couple of computers running Windows 95 so that the base simulator software will run!

I think that that was meant to be a tongue-in-cheek reference.

You will also find that turbojet aircraft produce little reverse thrust at low airspeeds. The mechanism for "reverse" thrust is to simply stop bypass air from going out the back, by deflecting it to the sides (only a small component is deflected forwards). It works by having a mass of air hit a wall and pushing that wall in the opposite direction to the aircraft's movement. To get enough thrust, you will have to run the engine at high power settings, which is not fuel efficient or safe...

What I'd like to see, is an API to allow third-parties to produce applications that use the MCDU and/or MFD as the input/output device, as well as reading/writing data to the FMC (e.g. writing: COROUTE UPLINK or ATC ROUTE UPLINK; reading: progress data for position reports, crosstrack error/legs page for ADS-C deviation events) This would allow ACARS and CPDLC to be implemented without requiring PMDG to select a particular implementation and lock out everyone who doesn't use that implementation.

All you have to do on this SID is turn onto the appropriate heading... you might find that HDG SEL is a much better tool for this than LNAV! As others have mentioned, this is a Radar SID. It is of absolutely no use unless there is a radar controller present. If there is no appropriate SID for your departure (highly like at Cairns ) simply take off, avoid the hills off to the west and south and join the magenta line!

These people: http://www.youtube.com/watch?v=uk2sPl_Z7ZU

This was my second clue... what the ????? is a "Cloudmaster"!?

I don't have a B744 FCOM and I haven't checked where it is for other Boeing types, but I would start my search in FCOM Vol. 2 Landing Gear.

I doubt that the coordinates for a fix have changed. Normally they will define a brand new fix with a new name if they need a new one as moving an existing fix and keeping the name could potentially be a safety issue. There are, of course, exceptions to this (e.g. in Australia, RNAV Approach fixes are named systematically. When the approach is redesigned due to a new obstacle, etc., they can't give it a new name, otherwise it won't be following the system anymore!)

The omission of the "M" fix is an error on the part of Navigraph/EAD. On most approaches, the "M" fix is co-located with the runway threshold so normally the "M" fix is displayed as "RW12" (or similar). This is not the case for this approach, but it seems they haven't adjusted appropriately. The VAPAP link Ron posted should provide you with corrected data (it's manually produced by the author).

RTA is used to reach a fix at a certain time. This can be used for a few reasons, including ATC request. In non-radar areas, when 10 minute separation is close to being broken (and for whatever reason, you can't use RNAV distance separation), the pilot may be required to cross a fix at or after/before a certain time. For arrival sequencing, Australia uses a "feeder fix" concept, where each aircraft is assigned a time to cross a fix located ~30-50NM from the aerodrome. Once the controller has done speed control, vectoring and holding as required, the feeder fix time will be given to the pilot so that the aircraft can cross the fix precisely on time (very important as there may only be ~2 minutes between each aircraft's scheduled runway time).

In my post, I stated that the 777 flight envelope protections are more streamlined that Airbus FBW types. Airbus FBW types (in normal law) will stop or reduce control authority - this is somewhat an unnatural feeling where the machine isn't doing what you are telling it to do.. On the other hand, the 777 either increases control force (stall protection) or applies opposite roll input to the control wheel (bank angle protection), which provides tactile response to the pilot, a more natural feeling where the machine tells to "hey stop doing this", but let's you do what you want.

There are many applications (including CPDLC, ACARS) that offer an interface via the MCDU. The MCDU is mostly just a coloured LCD screen and a keyboard. Additionally, CPDLC and ACARS need some additional connectivity to the FMC (when online) in order to retrieve and insert information as necessary. I would suggest to PMDG that rather than implement a single protocol or application (of which there are many), it would be most useful to allow third-party applications to offer an MCDU interface and to also access FMC data. This is not something that is new: the PS1 community have had this since the last decade (http://www.hoppie.nl/mcdu/) An MCDU that allows other applications to register into it, and an FMC that allows data in/out, will allow third-party developers to create a variety of applications that many of the more dedicated simmers have been waiting for for years. Fully integrated ACARS systems could potentially be used by virtual airlines to create a highly realistic environment. The ability to integrate a CPDLC system will catalyse the popularity of CPDLC in online communities (at least in the South Pacific region, it will). PMDG are most definitely a heavy-weight in this industry. There actions with regard to the topic on hand will either drive innovation or allow it to continue crawling.

Car drive-by-wire steering systems are direct input systems. Airbus FBW "Direct Law" is also a direct input system. RC vehicles are direct input systems. Also as stated earlier, PMDG could already override the FSX direct input system since the MD11. The 737 also uses this override for the CWS. There is absolutely no reason to believe that PMDG will not implement flight envelope protections. However, most people will not notice these as the 777 flight envelope protection features are very streamlined compared to Airbus FBW types.

Merv Archer, the former owner of Austscene has retired from this line of work. The guy who used to do the PMDG files for the website, Jock McIntyre, is continuing to publish his work on the new VAPAP website.

I would actually strongly recommend avoiding this one - it doesn't seem to take into account standard routings, airway direction restrictions, flight planning requirements, etc. It just finds the shortest possible route along the airways system.

I think only if there is symmetrical thrust available. If it is available with asymmetric thrust, I would imagine that it would only be available in dry, non-crosswindy-gusty-blow-you-off-the-runway conditions.

The standby RMI uses IRS heading. In theory, the RMI should still point in the correct relative direction (i.e. if the station is directly left of your position, the needle should point left), but the compass card will be out if there is no IRS heading.

Autotune isn't available on the NG. It's been a while since I've checked, so I can't remember whether a valid signal from those boxes will update the FMC or not. However, it is good practice to tune any along route navaids, or if there are none, nearby navaids. This will increase your situational awareness, particularly if you were to have a dual FMC failure.

Actually, the GPS only provides 4 pieces of information: latitude, longitude, geometric altitude and UTC time. All GPS units in the world only provide this information (except military units - they're probably hiding some special Easter egg feature in those :P) The ND displayed position/heading/track is from the FMC. The FMC position is based on IRS position and updated by various sources. These other sources cannot be used by the FMC as the sole source of position information. Why? VOR/DME, DME/DME, LOC/DME, etc., are all incapable of providing an accurate enough position to avoid the FMC position jerking around. GPS doesn't update quickly enough to be smooth. Under normal conditions, it is the IRS that allows interpolation of the position as it knows what the net acceleration of the aircraft is at all times. Yes - if you lose your two spinning gyros altogether, then you have a big problem. But ask yourself - when was the last time you heard an aircraft lose it's ADIRU/IRS? Last time for me, was the QF 744 that had a total electrical failure, in which case the crew had bigger problems on their hands than just navigation. ;) In any case, it is far more likely for the FMC to fail.

Sorry, too busy enjoying the work of the dudes who made the internal textures, did the internal modelling, and programmed the systems and flight instruments! :P

Absolutely. The only time I go into the external view is for apron manoeuvring, where in reality there would either be a marshaller/docking system or a tractor.

The other developer can say what they like, but the fact is that their business practice would be fraught with legal problems under consumer law in many jurisdictions. Much consumer law would require that all purchased goods come with a non-disclaimable warranty of fit-for-purpose. Not matter how much you represent to the customer that it is an incomplete product, a buggy program is not fit-for-purpose. Having said that, I don't claim to know anything about consumer law in the jurisdiction that the other developer operates in...

Thanks for the explanation, Robert. I hadn't considered that the EECs would control the engines quite that differently for different thrust ratings.