Okay, you didn't ask for it, but for the record here's what I know about the CS implementation of the 727 pressurization system.  If you aren't into lots of technical details, you can just skip over this!

First, it almost works, and sometimes, randomly, it almost appears to be right on the money!  But you have to be lucky to see this.

Captain Sim correctly (and bravely I might add) decided to use the built-in FSX pressurization system rather than write their own code.  I always like it when companies use standard stuff because it makes the airplane compatible with other add-ons that monitor the pressurization system - like FSCaptain.

The first thing that's wrong is the differential/cabin altitude gauge -- the one where the docs say that the big outer needle shows the differential and the inner smaller one shows the cabin altitude.  In fact, the outer gauge tracks the cabin altitude and the inner one shows the same as the regular altimeter.

This was pretty easy to fix by changing the code to track the actual FSX variables rather than the ones calculated by the CS systems.

The rate of climb indicator works as it should, it accurately shows the internal FSX rate of climb.

The knobs all appear to work as they should.  The only minor complaint is that the default setting of the rate knob is way too high -- something around 1400 feet per minute.  But you can adjust this down easily -- although the knob isn't marked turning it to the left (decrease in rate) until the indicator line on is horizontal will result in a 500 FPM rate, which is more reasonable.

Once these corrections are made, the readings are correct on the ground.  But when you rotate and the airplane clears the ground, hell breaks loose.

Ordinarily, at the moment of positive rate of climb of the airplane, the internal FSX rate of climb shows an immediate large negative number and therefore the FSX cabin altitude is forced to a huge negative altitude.  Typically, I've seen rates of -35,000 FPM and a cabin altitude of -200,000.

I say ordinarily, because this effect appears to be random.  Sometimes, a large positive rate of climb appears, and the cabin altitude shoots way up there.   And sometimes, amazingly, and randomly, the rate isn't out of kilter and the pressurization system will stabilize and work correctly!!!  But this is rare.  It has happened to me in maybe 1 in 20 test flights.

Once the initial crazy numbers appear, the system settles down and starts correcting the cabin altitude towards the goal at the rate you set.  If the cabin altitude isn't too borked by the random number generator, and given enough time, the numbers will come back into reasonable range and you'll have a correctly operating system.  The one error here is that the rate knob doesn't appear to change the rate once the system has started moving the cabin altitude.  Once the goal is obtained and the change rate goes to zero, you can change the rate knob and the next time the system makes an adjustment it will be at the new rate.

What's happening?  It seems like a bug when the CS code initializes the system when the airplane leaves the ground.   But not exactly.

I believe the bug is actually in FSX.   FSX has an internal pressurization dump switch.  When you toggle this, it should modify the rate of change so as to force a rapid depressurization -- so that very quickly the cabin altitude will equal the real altitude.  

In doing research, the dump switch works great on the ground.  But if triggered while you are in the air the crazy random numbers appear in the rate and altitude.  It appears there's a bug in the calculation inside FSX.  This happens in non-CS airplanes too.  Normally if you leave the pressurization alone in an FSX aircraft that has it, it will quietly and automatically handle the numbers reasonably.  But if you trigger a dump in the air, the randomness appears.

It's obvious that the CS code quite reasonably toggles the pressure dump switch as a part of starting up the pressurization system during takeoff.  But when it does this -- WHAM! -- the FSX bug puts the cabin at 25,849 feet below sea level, and how long does it take at -500 FPM for this to get back to your goal?  You probably will run out of fuel or land first!  But if the random number generator is kind to you, you'll be able to see the needles looking reasonable (assuming the differential/cabin altitude gauge is fixed.)

Since the CS code is part of a compiled C gauge and is not XML, it's not possible for us outside to fix this problem by taking out the toggle of the pressure dump switch.

I hope this is helpful to the CS programmers.

Dutch

Hi Coolp and thanks.  Yes I am a programmer with a fairly decent knowledge of MSFS systems and quirks.

I should within a day or so have up a fix to get the pressurization system working acceptably, with Lou's excellent help in my other post about this.

The info I got from this forum here fixed most of the other showstopper bugs.  The only thing that's still annoying me is the refusal of the pitch/turn adjustment knob on the autopilot to adjust anything.  Other than that the autopilot works just fine.

Dutch

Same here. I always use the 2D popup for the AP and, there. the thing works.
The VC use may be more realistic, but to be able to use it, the unrealistic head movement with e. g. TrackIR has to be made, so that's why I avoid it and still look out of the window or on the instruments when using it.