Big_Les

I used to test RAT deployments on VC10's during air tests. The problem is the critters tend to run out of the avionics bay beforde you could poke them with your voltmeter probes.

V1 and Vr speeds obviously depend on the flap config and the weight of the aircraft (and possibly wind, runway length, runway condition, slope etc) Its quite common to have V1 the same or very close to Vr.

Ahhhhh, now I get it, typo obviously unless I was using a solid rocket booster add on. LOL Your probably correct, I don't recall a pacs on call from the FO after takeoff.

mmmm, what? autopilot being on? in lnav and vnav ? why's that my problem? or am I missing something?

This may be pilot error, I'm still not sure...... Notable circumstances: FS2Crew was being used It was a packs off take off (handled by fs2crew) CMD A On in vnav and lnav modes FLT ALT was set to 350000 on the pressurization panel Step to FL370 was entered into the the FMC MCP was then set to FL370 Aircraft continued climb pas initial FL350 to FL370 At this point I got a master caution but was confused by the lack of any system annunciator lights. It took me a while to figure out that the "Auto Fail" was lit on the pressurization panel and the pax oxy had deployed. Rather than carry out an emergency decent (which of course I would do in the real world;)) I decided to try and figure out what was going on, I set the pressurization mode selector from Auto to ALTN, then manual and altered the dump valve position until I got an acceptable cabin pressure and differential. (All good so far) I then noticed that for some reason the APU was on, strange I thought as I didn't think it ran at FL370.... after checking that the APU generators were off and the Engine generators were on, I shut down the APU at which point I departed from controlled flight and crashed (very quickly) The PMS WAS set to auto wen I took off. So Questions: Why did the auto pressurization fail? could the setting of 35000 in the panel and climbing past that level to FL370 cause it to fail? Why was the APU on? possible fs2crew failed to turn it off? Why did I depart when I switched off the APU? I'm not expecting a full explanation of any of this as I cant give you my exact actions and system states, unfortunately there is no flight data recorder.... I would however appreciate feedback from anyone who has had a similar experience and uses FS2Crew.

This may be pilot error, I'm still not sure...... Notable circumstances: FS2Crew was being used It was a packs off take off (handled by fs2crew) CMD A On in vnav and lnav modes FLT ALT was set to 350000 on the pressurization panel Step to FL370 was entered into the the FMC MCP was then set to FL370 Aircraft continued climb pas initial FL350 to FL370 At this point I got a master caution but was confused by the lack of any system annunciator lights. It took me a while to figure out that the "Auto Fail" was lit on the pressurization panel and the pax oxy had deployed. Rather than carry out an emergency decent (which of course I would do in the real world;)) I decided to try and figure out what was going on, I set the pressurization mode selector from Auto to ALTN, then manual and altered the dump valve position until I got an acceptable cabin pressure and differential. (All good so far) I then noticed that for some reason the APU was on, strange I thought as I didn't think it ran at FL370.... after checking that the APU generators were off and the Engine generators were on, I shut down the APU at which point I departed from controlled flight and crashed (very quickly) The PMS WAS set to auto wen I took off. So Questions: Why did the auto pressurization fail? could the setting of 35000 in the panel and climbing past that level to FL370 cause it to fail? Why was the APU on? possible fs2crew failed to turn it off? Why did I depart when I switched off the APU? I'm not expecting a full explanation of any of this as I cant give you my exact actions and system states, unfortunately there is no flight data recorder.... I would however appreciate feedback from anyone who has had a similar experience and uses FS2Crew.

Had the same problem on an old Piper PA 28, forget to set the handbrake, rolled forward when I started the engine and nearly hit the hanger as I had my head in the Cockpit... ;)

I have had problems activating the 600/700 product since I purchased it last year. I've been away for a while and haven't pursued the problem as I thought SP1c MAY fix it. It hasn't and now I've run out of activations.Symptoms/Method:Start FSXselect NGX 600 variant from free flightD box prompts for keyI enter the keyFSX starts, everything works and product reports it's been activatedThe next time I start the product I'm prompted for the activation key againDo....LoopEventually I run out of keys

Am I glad I don't work in a market where software gets exposed to end users.... It's not usual to release a bugs fixed list until you have fixed the bugs AND they have been tested and resolved. So no bugs fixed list does not surprise me. It's also not usual to give customers sight of the internal workings of the development team and their progress on fixing and QA for specific issues. An SP release schedule based on realistic assumptions and contingency, is however usual, that, I'm not seeing and am saddened

Absolutely agree with you

I wish people would actually read posts properly before replying to them..... Ho hum if I must.....I did not say that FS2Crew would not be available for FS2Crew, I said that the ifly has an API (True) and indicated that the PMDG did not (Also true as of this moment in time) SP1 has not been released for the PMDG and we have no firm date. You can only based assessments on what is actually there, not what may be there or may be fixed in the next SP which may be coming in a few days (or may not) Systems modeling....Mmmm thats a big one, you may be correct in saying the systems modeling is better in the PMDG. Or then again, it may be fair to say the systems modeling is more expansive, thats to say it may do more, more accurately. "Better" would say to me that it's been implemented better, functions better and is more performant. You can't really model real time embedded systems that well on normal PC hardware, so all this is rather subjective. I knew this was going to be contentious with the PMDG fan boys (which I am normally one) but it's good to have some dialouge around the comparison. I'd rather have less than perfect simulated turbulence than no turbulence at all. Unfortunately I don't have regular access to a 6 DOF level D sim.

I second etrjazz, the ifly is more predicable and I have less issues with other addons than the PMDG. The PMDG is graphically very very good (far better than the ifly)I'm not sure about the systems modeling although the PMDG does have more systems functionality. I've actually encountered more issues with PMDG systems modeling than IFly: Brake temp, CWS autopilot mode, VNAV descent path calcs.The ifly IS less frame rate hungryThe ifly has an API, so I can fly with FS2Crew (This is a big plus for me)The Ifly appears to be less resource hungry than the PMDG.The PMDG still has some major issues: crashing, LNAV hold instability in cross winds (Very bad at cruise altitudes unless you tweak the turbulence and wind settings which results in very little turbulence at all, not very realistic) All in all, the PMDG is not worth the extra money (Yet) if you like eye candy, then sure buy it, for me it would be better with less attention to detail and more attention to programmatic integrity, software performance and less bugs.....

I don't think its usual to use AOA in civil aircraft for approach and flare. However, military jets (fighters) do use it for approach and landing in some cases (UK Tornado is one case) They call it "Alpha"

I'm seeing a lot of Cntrl events being logged in the FSUIPC log which are puzzeling me. I've checked other aircraft (including PMDG Md11 and JS41) for similar log entries and can't find any. NGX is the latest patch version. ********* FSUIPC4, Version 4.703 by Pete Dowson *********User Name="XXXXX"User Addr="XXXXX"FSUIPC4 Key is providedWIDEFS7 not user registered, or expired[Continuation log requested by user]Running inside FSX on Windows 7 (using SimConnect Acc/SP2 Oct07)Module base=61000000Wind smoothing fix is fully installed 229259 System time = 02/09/2011 17:29:22, Simulator time = 16:26:56 (15:26Z) 229259 LogOptions changed, now F0000000 0000001D 230601 Ready Flags: Ready-To-Fly=Y, In Menu=N, In Dlg=N 232785 *** EVENT: Cntrl= 69981 (0x0001115d), Param= 4194304 (0x00400000) <unknown> 232816 *** EVENT: Cntrl= 69980 (0x0001115c), Param= 4194304 (0x00400000) <unknown> 232988 *** EVENT: Cntrl= 70522 (0x0001137a), Param= 4194304 (0x00400000) <unknown> 234563 *** EVENT: Cntrl= 69979 (0x0001115b), Param= 4194304 (0x00400000) <unknown> 234610 *** EVENT: Cntrl= 69979 (0x0001115b), Param= 4194304 (0x00400000) <unknown> 234641 *** EVENT: Cntrl= 69980 (0x0001115c), Param= 4194304 (0x00400000) <unknown> 235109 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 361 (0x00000169) ROTOR_BRAKE 235109 *** AXIS: Cntrl= 66162 (0x00010272), Param= 3 (0x00000003) COWLFLAP1_SET 235250 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 392 (0x00000188) ROTOR_BRAKE 235250 *** AXIS: Cntrl= 66162 (0x00010272), Param= 3 (0x00000003) COWLFLAP1_SET 236045 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 355 (0x00000163) ROTOR_BRAKE 236045 *** AXIS: Cntrl= 66162 (0x00010272), Param= 3 (0x00000003) COWLFLAP1_SET 246388 *** EVENT: Cntrl= 70240 (0x00011260), Param= 4194304 (0x00400000) <unknown> 249773 *** EVENT: Cntrl= 70167 (0x00011217), Param= 4194304 (0x00400000) <unknown> 249773 *** EVENT: Cntrl= 70167 (0x00011217), Param= 4194304 (0x00400000) <unknown> 250163 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 395 (0x0000018b) ROTOR_BRAKE 250163 *** AXIS: Cntrl= 66162 (0x00010272), Param= 3 (0x00000003) COWLFLAP1_SET 260069 *** EVENT: Cntrl= 70614 (0x000113d6), Param= 4194304 (0x00400000) <unknown> 260101 *** EVENT: Cntrl= 70614 (0x000113d6), Param= 4194304 (0x00400000) <unknown> 260147 *** EVENT: Cntrl= 70614 (0x000113d6), Param= 4194304 (0x00400000) <unknown> 260179 *** EVENT: Cntrl= 70614 (0x000113d6), Param= 4194304 (0x00400000) <unknown> 260210 *** EVENT: Cntrl= 70614 (0x000113d6), Param= 4194304 (0x00400000) <unknown> 260257 *** EVENT: Cntrl= 70614 (0x000113d6), Param= 4194304 (0x00400000) <unknown> 260288 *** EVENT: Cntrl= 70614 (0x000113d6), Param= 4194304 (0x00400000) <unknown> 260335 *** EVENT: Cntrl= 70614 (0x000113d6), Param= 4194304 (0x00400000) <unknown> 260335 *** EVENT: Cntrl= 70614 (0x000113d6), Param= 4194304 (0x00400000) <unknown> 260943 *** EVENT: Cntrl= 70178 (0x00011222), Param= 4194304 (0x00400000) <unknown> 260943 *** EVENT: Cntrl= 70178 (0x00011222), Param= 4194304 (0x00400000) <unknown>

Hi ARM, I have a question... do RW pilots usually pre set vnav and lnav before takeoff if they have a runway specific SID?

I empathize with the folks who are having problems, if it were me, I wait for around 1 month to see if the problem gets fixed or someone figures out a workaround that works. If that didn't happen I'd ask for a refund if: My system met the minimum hardware and software specs I'd tried workarounds suggested by commercial members

Spencer, Hope this helps and does not confuse..... when you enter a STAR in the FMC, the FMC may or may not enter the correct altitude constraints. Real pilots (I'm a small one, not commercial) have to check the FMC constraints against the charts as sometimes the data in the db for the fmc is wrong or out of date. If the FMC complains about "DES PATH UNACHIEVABLE" it could have many reasons but the main one I've found is that the altitude and/or speed constraints in the STAR are not correct. Lets look at the possible constraint types: /10000 or /FL100 or /100 “ AT FL 100 “ = Bold large text in FMC- /10000B or /FL100B or /100B “ AT FL 100 OR BELOW “- /10000A or /FL100A or /100A “ AT FL 100 OR ABOVE “- /8000A10000B or /FL080AFL100B or /080A100B “ BETWEEN FL80 AND FL100 “ The most inflexible type of constraint here is the AT constraint which means the FMC has to calculate the AC MUST be AT that height at that point.Example:If your first STAR way-point has an AT or ABOVE constraint of 15000 and you have an AT constraint of 5000 just 3 miles on, there is no way the AC can make it and you'll get "DES PATH UNACHIEVABLE" (This was an extreme example but demonstrates the issue) In order to get rid of the " "DES PATH UNACHIEVABLE" you would need to change the constraint to an AT or ABOVE constraint by entering /5000A on the vnav page for the way-point. This gives the FMC enough flexibly to plot a descent path which is achievable inside normal operations from the aircraft.

I think the freezing issue is unlikely to be a download issue although it could be something to do with the install and permissions. If the downloaded file is corrupt in any way, windows would I think report this when you tried to execute it.

So to summarize: A significant minority of users are seeing the freeze issue (I feel a poll coming on) PMDG are looking at the problem but haven't managed to reproduce it yet No one really knows were the problem area might be This kind of issue isn't that unusual in the software world and is always the hardest to fix, so firstly, I'd give them (pmdg) a little time. The second thing I'd do is try to identify what happens with resources just before and during the problem. I'm not seeing any issues so also could not reproduce it. As a start I would setup windows perfmon to log all the usual suspects (mem, page file, cpu usage, threads yadayadayada) and look at the results after the crash/freeze. With any luck, you should be able to identify the area thats causing the problem. Once you think you've got what your looking for, do it again at least three times. If you look at the graphs produced by the data collector sets in perfmon, you should be able to figure out what was happening at the time the issue occurred. Perfmon can be complex to use, but basically you should use the performance template data collector set, make a copy, set the schedule and stop condition and run FSX with you're best scenario at seeing the problem. Please see the help topics and ms website if you need info on how to use perfmon. It's a bit of a pain to do all this, but if I were seeing the problem and it was stopping me from using the product, I would do it and try to help debug the problem.

Please note this depends on:Thrust setting (N1%)weightSpeedAir pressure (height) and probably a bunch of other stuff I can't be bothered to look up..... It works something like this if you want to use it in a climb: 1. Set a pitch angle to achieve 1800 fpm climb (depends on speed, altitude etc) using the control column with cmd A VNAV selected flying straight and level (should then auto switch to CWS A)2. Hold pitch angle until stabilized3. Set climb power (92% N1 ish...)4. CWS A should now be active and hold the established pitch angle Note it will hold the pitch regardless of your actual climb rate, you need to keep an eye on speed and set power and/or alter pitch (by manual intervention on control column) in order to keep within the flight envelope. I haven't actually tried this myself but may do so tonight to see if it works as I think it should and according to the documented logic.

Functionally, with no failures, nothing. There just different semi autonomous systems for safety.

From what I've read, CWS mode is used by some pilots while climbing or descending to set pitch attitude. Apparently, the climb established from this approach is smoother as the aircraft does not change attitude much, when using vnav or fpm the attitude may change more due to atmospheric conditions.

From PMDG 737NG - AOM "What is Control Wheel Steering?:CWS can be used to control pitch and or roll of the aircraft. CWS provides full control authority to the pilot and pitch and roll can be changed by applying pressure to the yoke. When pressure is released, the autopilot will maintain the pitch and roll attitude established by the control inputs. CWS Mode can be entered in three ways:1) Pressing a CWS autopilot engage button on the MCP.2) Application of sustained pressure on the controls while the autopilot is engaged in CMD mode.3) Engage the autopilot with no previously selected pitch/roll modes. When the AFDS enters CWS mode, CWS P and/or CWS R will be displayed on the FMC and the current pitch and roll attitude will be maintained until changed by control pressures, or selecting an alternate pitch/roll mode on the MCP" Also see this:http://forum.avsim.net/topic/118507-cws-mode-for-hand-flying-the-737/

I observed similar behavior but with tank2. At cruise I accelerated to x4 time compression for a while and then noticed a fuel unbalanced warning with tank 2 about 1000 kg below tank 1. APU was off, center tank was empty and pumps were off, cross-feed was closed. had to re balance fuel before landing. I wasn't sure at the time if it was a fuel leak (random serviced based failures on)

I've notice that my break temps do not seem to increase (or read anything other than 0) after prolonged breaking. Is this modeled?