Litjan

Yes, that is essentially what I see, too. I didn´t see your mouse when you clicked the the ALT HOLD, but if you did it, then the behaviour is of course correct. The two things that are not right are: 1.) Orange speed cursor moving "up" to maximum speed (it should move down slowly in relation to "VNAV PATH ERROR" shown on the vertical deviation bar). 2.) Aircraft descending while in ALT HOLD. It looks like it is "trying" to follow the VNAV PTH, but it should not at all while in ALT HOLD. It could very well be some variable going to an extreme - this is the type of bug that is hard to troubleshoot because you often have to have the "exactly right" conditions to see it. I invite you to watch this behaviour and see if you can repeat it consistently. Of course you did the right thing - when the automation *** up, reduce the level of automation or even revert to manual flight. We are Boeing pilots, not Airbus ;-) Happy flying, Jan

It should not go down, and if you look at your video, it didn´t - it stayed at the flight level and increased speed (that was wrong). I think you maybe pushed on your yoke by accident, the autopilot went to CWS pitch for a second. Pushing on the yoke while the autopilot flies will actually change the pitch a little bit... I just tested the behaviour here on my end and it worked as it should. The speed cursor drives down slowly, while the VNAV PTH changes to ALT HOLD. Energy trading. Not sure what happened during your flight, some weird combination of values, maybe... Cheers, Jan

Hi Jaime, I have to check this behaviour again - what you see (initially) is quite normal - the aircraft will start to reduce speed to "trade energy". In other words, it assumes (if you have not reset the MCP as requested) that you need to maintain the current altitude for whatever reasone (usually ATC, some traffic below) but would later on like to regain the pre-calculated descent path. So it "helps" by reducing speed, which you can then later regain (by descending more steeply) and therefore have an easier time re-intercepting your calculated descent path. The minimum speed commanded should be green dot (minimum clean), though. Looking at your video it looks like the speed bug goes to maximum speed (and the aircraft accelerates), though. This would clearly be a bug! Thanks for bringing this to my attention, Jan

Hi Doeke, make sure you set the buttons for the speedbrake to "extend one notch" and "retract one notch". The speedbrake in the 737 has these "detents" (defined positions): Down (full forward). Here the speedbrake will only deploy automatically when the reversers are deployed, i.e. during a RTO. ARM (one step aft). Here the speedbrake will deploy on gear compression and wheel spinup (normal landing). FLIGHT (one more step aft). This is the furthest position the speedbrake should be used during flight. FULL UP (full aft). This will manually deploy all spoilers to the maximum position. Selected manually as normal operating procedure at touchdown and when doing a RTO. (Automatic deployment is just a backup in case the pilot forgets). Jan

Sounds about right! Cheers, Jan

For what it´s worth: When I was a young FO on the 737 I was flying along on a Captain´s candidate checkride. One flight was from EDDS Stuttgart to EDDF Frankfurt, and this was the one and only time when the FMC on that aircraft was INOP! Imagine his joy . Nevertheless, the FMC is a MEL item and can be inop (just like the autopilot or autothrottle...) - with some caveats, of course. We flew that flight (at least the whole SID) with conventional nav - but then soon were given vectors. But we often flew SID´s "conventional", just to stay proficient. Cheers, Jan

I will actually forward this to Tom - I personally have only a very faint idea what a dataref is

Will do! ;-)

Hi Jaime, the old "configuration" pretty much stays the same. NO "stability augmentation". As for the "response curve" - it is a bit up to the personal preference and hardware used. If you have a full yoke, you may want to go with "linear" (= a straight line, proportional displacement). The "less travel" your control device has (the shorter your "stick" ) the more "curve" I would add to the response. That way you retain relatively fine-grained control (steering surface displacement per stick displacement) near the center position, but still have full deflection when you cram that stick to the stop (like in very gusty conditions or a wake encounter). Cheers, Jan

I noticed this as well, and we are looking into this! Cheers, Jan

I haven´t tested this at your airport and those settings, but what you describe could very well be realistic behaviour. When starting the CFM56 engine you have "20 seconds" between putting the start lever to IDLE and seeing EGT rise (not even spoolup!). It could take a long time for the engine to spool up, the starter time limit is 2 minutes (from engagement to cutoff). So as long as you stay below that, you are fine. Also make sure to turn off all air-conditioning before you start the engines, this is a common mistake sim-pilots make. At high density altitude, jet engines accelerate VERY slow. This is the reason for the "flight idle" setting which is considerably higher than the 21% or so you get on the ground. It would simply take "forever" to accelerate the engines from 20% while at FL200... When the jet passes 80 kts during the takeoff roll, the autothrottle servo motor gets "cut off" from it´s electrical supply (shown by THR HOLD at 84kts). Now it can´t drive the thrust levers anymore. If the correct N1 is not achieved by that time, the pilot has to set it manually. This is normal. To avoid that, follow correct procedure: Hold brakes Advance thrust levers until both engines reach 40% N1 Click TOGA (for IXEG: Advance both hardware thrust levers full forward) Release brakes (note: If you are at a very high airport, you may consider holding your brakes until N1 passes 60% or so - this should ensure that calculated N1 will be set by autothrottle before the aircraft is passing 80 kts. You can even hold your brakes until N1 is achieved ("static takeoff") but it is not recommended as it places a lot of stress on landing gear and wheels and also increases the chance of foreign-object ingestion and adverse flow in the engine in high crosswind situations. Cheers, Jan

The real aircraft has this and we plan to implement it - in a future update of the FMS. It will not be part of the next interim update, though. If you want to "emulate" this function, you can enter the fix (in this case BTG) on the FIX page and then enter (draw) the desired inbound course as a radial from that fix. Then fly to and follow that radial (=bearing inbound) in heading mode (or enter the direct-to again when on the desired bearing). Jan

I do - it is a list in progress - and I am not ready to share it yet ;-) Cheers, Jan

That is unfortunately not true...there is still a problem with some of the lit textures, that button being one of them :-/ Jan

Sneak peak - new material for throttles:

Thanks for the feedback, skydriver! I have also not noticed any detrimental effects in 11.50. My framerate increased by about 30% (Nvidia card). Cheers, Jan

Yeah, wow, that sound just blasted my ears and almost blew out my speakers. How could I have missed that??? Seriously - yes, I hear it. Its not going to jump to spot ONE of our to do list, though. It will probably slide in just in front of that little "swip" sounds the red flags on the RMI make when popping in and out... Cheers, Jan

Unfortunately I can´t for various reasons ;-). You can probably find some on the internet, though. Note that we model the 20k version of the CFM 56, only. Cheers, Jan

That is true - I have to search my old videos again for this. My memories fade, it has been almost 8 years since I last flew a 737 :-( We are looking at moving all of our sounds to FMOD - but not for this next update. So I will add this to the wishlist for the future. Cheers, Jan

I don´t remember this "click". What do you think would cause it? Jan

Hmm, that is normally not required - I can simply use any view keys during replay, no need to reboot or so. Maybe some incompatibility with another plugin (fly with lua, etc.) Cheers, Jan

No, it is a bug of your system :-) Cheers, Jan

We´ll see ;-) Jan

Thanks for the reports, guys - unfortunately there is way too little/inaccurate information in them to really even understand what your problem is - let alone trying to guess the cause or the solution. I would suggest troubleshooting on your part (nav data, user error, proper procedures, etc.) and if that doesn´t help, come back and give me a detailed report (including pictures and/or video) describing step by step instructions to show the problem. Don´t forget to include the Log.txt and of course to remove all other plugins and third-party addons before you try to recreate it. Cheers, Jan

Cptburgos, I will never say never when it comes to X-Plane...but there really was nothing changed in the way the radios or nav-database works with 11.50. I also checked on my side with 11.50 and the navradios work fine. Cheers, Jan mmerelles: Working on it ;-)