davidz

If you actually read the thread, no one is asking for any of that. We are just looking to read FMC data and be able to use the MCDU/MFD COMM page as an interface for third-party applications, such as CPDLC and ACARS. No one is asking PMDG to actually make these as it would then be tied down to one particular implementation.

Ideally, whatever system PMDG give us (if they do), would allow VAs to integrate their own systems as well. From a real world perspective, each operator actually has their own implementation of ACARS (CPDLC is, of course, the same for everyone).

A few of us have been asking PMDG to open up the MCDU to allow 3rd-party apps to use it as the interface, as well as FMC data. I doubt that it will be in the upcoming release, but hopefully one day they will explore this idea.

Ahh, didn't read that post properly; my bad.

I haven't heard this yet. Are you sure you didn't misread (like I did the first time) Ryan's post regarding CDU I/O that would allow external CDUs? Maybe I read it right the first time and then confused myself :unsure:

I'm not a hard drive engineer, but I would have guessed that each sector in the hard drive is a constant size, not dependant on the radial distance from the centre. That is, there are more sectors on the outer edges of the hard drive -> for a given angular velocity, more sectors will be passed over per unit time. True, the actual time to read the sector is a separate consideration (only real way to optimize that is to minimize the number of sectors that your file is spread over). The defraggers arrange files in alphabetical order, under the assumption that large files (textures, etc.) will be loaded in alphabetical order. If it does, then great; if it reads randomly, then oh well; if it reads in reverse alphabetical order, then you're in trouble

In addition to RF legs, full support for all ARINC 424 leg types will mean proper DME arcs (rather than extra fixes every 10 degrees) and procedure turns.

Definitely off - they only take a few minutes to align anyway, so even on a short turn, you can shut them down completely and realign from scratch.

Hard drive read/write speed is largely limited by rotational speed of the seeker head (e.g. 7200 rpm on regular 3.5" hard drives). For a given angular velocity, the tangential velocity of the seeker head increases with radius. So if you want greatest read/write speed, you want maximum radius, which corresponds to the outer edge of the hard drive. The seeker head does not really "start" from any where. It starts from where ever it last parked itself. That really doesn't matter much because if you are reading a lot of data that is at the other edges anyway, it will move to the other edges to read file 1, and then already be at the outer edges to read file 2, file 3, etc. Nowadays, if you run a hard drive performance test, it would be highly unlikely that it would be limited by other components. Look at the "Windows Experience Index" on any computer with only a hard drive and there is a good chance that the lowest score will be the storage device. Also, not sure where you got that 65% rule from; it logically does not make any sense on a well sorted hard drive (with a good third-party defragger). All your fast-access files (game data) go to the outer edges, all other files go after that. The hard drive being full shouldn't affect access times. The only reason you might not want to fill up the hard drive is that if your pagefile is of variable size, you may run out of space for the pagefile - not so much of a concern these days with people running huge amounts of RAM.

If there is enough data out there to make a full-motion simulator, there's definitely enough for PMDG.

Probably not fitted with ADFs like many new aircraft aren't! I believe many operators have exemptions to allow them to fly NDB and VOR NPAs using RNP 0.3 or similar.

So with my pedant hat firmly bolted onto my head... I'm going to point out that the term "HD" refers to screen/video resolutions of 1280x720 or 1920x1080. Even 1920x1080 is only two megapixels! Also, if you use the stitching option, you'll quickly run into the problem that your image quality is limited by the texture quality and super/multisampling quality. If you've ever zoomed right into e.g. the MCP, you'll know exactly what I'm talking about.

Not sure how you get Zulu = 0 (I would have thought that it would be 26 given that it's the 26th letter in the alphabet). For those unfamiliar... http://en.wikipedia.org/wiki/Bravo_Zulu

The FCOM's Performance Dispatch chapter contains enough information to plan an entire flight using a Flap 15 take-off, LRC climb, cruise and descent and Flap 30 landing.

Kudos for turning the light back on at the end... I think the poor guy after you would trip over everything if you left it as dark as you had it during the flight B)

1) The blue and white rings are part of the off-path descent system. You hit "OFF PATH DES" on the VNAV DES page. They give you an idea of your energy state relative to your target fix/altitude. Inside the inner ring, you have no hope of making it (unless you do some S-turns). Between the two rings, you will need a degree of speedbrake to make it. Outside the outer ring, you will make it with a clean aircraft. They don't actually rotate - it just looks like that because the rings are expanding/contracting. 2) Packs are automagically managed for the start - you turn the switch to "START" and a system will turn off the packs for you. 3) Blue arrows indicate alternate airports that are off-scale (e.g. if you are in Europe and set YSSY and KJFK in the alternates page, you will get an arrow pointing to each of Sydney and New York) 4) The CABIN READY message disappears after a certain amount of time. This is triggered by the cabin crew (or through certain actions/logic in the sim) 5) A white box next to an EICAS Caution indicates that there is an associated electronic non-normal checklist. For example, if you get [] ENG FAIL L (for which there are no memory items), once the aircraft's flight path is stabilized, you hit ECL and it will bring up the checklist for an engine failure.

Too bad Brisbane only has one suitable runway so EU-OPS wouldn't let you do that... time to use CASA's CAAP 234-1 rules and hope the weather doesn't go south like it did for Qantas the other month :Whistle:

Ah, that would be our neighbours across the Tasman. Last time we had anything that resembled an earthquake, this happened:

If you have a JeppView subscription, you can download the JeppView app onto your iPad and you will have an EFB solution that will be 100 times better than anything anyone could do inside the sim where you have to pan and zoom to be able to see it.

This isn't entirely true. As I mentioned, some of the performance tables are included as part of FCOM Volume 1 (Performance Dispatch and Performance In-flight chapters) and I just double checked - definitely included with the NGX.

Laser gyros have been used for decades. ADIRU stands for Air Data Inertial Reference Unit. Basically, all your IRS and air data inputs (static temperature, pitot tube pressure, static pressure, alpha vane, etc.) feed into a computer which then outputs to flight control computers, flight instrumentation, FMC, etc.

Ah the flightorg guys... it's a shame that they took down some of their other videos.

Looks like they've used anti-aliasing to remove the Moiré. Most digital cameras actually also include an anti-aliasing filter over the sensor to remove this same effect which happens any time you have something with a fine pattern (e.g. a flyscreen or a wire fence).

That's true... serves me right for not checking. Well at least Boeing are kind enough to supply the information in tables rather than a chart (nothing worse than wasting time plotting lines against interpolated curves).

We did see a discount when the NGX was released... I think it was something like US$10 off the current price?