Litjan

Hi, there could be several things causing this, so please check them off one by one: A very hot ambient temperature combined with high field elevation An inadvertantly set high TASS in the FMS Your joystick interfering with the virtual thrust levers during takeoff run - some people try to move their hardware throttle "along" with the advancing thrust levers - this will cause them to snap back to "manual control" when the plane passes 84kts (THR HOLD), and the throttle being now controlled by hardware throttle again. To avoid this, follow the recommended procedure: Click TOGA button, immediately advance joystick throttle to forward mechanical stop (full power!). A spikey joystick throttle that "regains" control of the virtual thrust levers by accident. If all this fails, please post a video of a takeoff where this happens and we will go from there. Cheers, Jan

Hi Andreas, yes, unlike on the Airbus, a lot of stuff hinges on the battery (like the power to the generator breakers), and switching it OFF will leave you with nothing but the hot battery bus (and ground service, if there is a GPU plugged in and the switch is toggled - this is not modeled yet). Onlike Airbus, Boeing relies on their pilots to have a brain and not turn off the battery switch until they have a VERY good reason to do so and understand the consequences ;-) The IRS units have DC backup, but not on the hot-battery bus, so they will die, too. Pressurization should be able to be regained, you need to get the cabin back into parameters first with the Standby or Manual mode, then you can re-engage automatic mode (switch to standy and back). You can re-align the IRS in attitude mode, but the position will be lost - however the GPS will work, so that is not the end of the world. The "huge speed" inthe MCP speed window is definitely a bug, some situation that you guys are getting yourself into that we haven´t tested for... I will try to recreate this myself and then we put some sort of stopgap to the maximum speed. I am a little wary of tinkering with that code too much, Tom and I want to really rip the guts out of VNAV and then sow everything back in neatly in a future update, and this will likely affect many of these quirky speed calculations... Cheers, Jan

We are still investigating this - I don´t see this on my end. Probably some interaction with some other plugin that changes art-control dataref (to achieve different colours of the sky) or such. We have had some reports, so you are not the only one - but still trying to nail down the reason. Could you attach your LOG.TXT so we can see which other plugins you have running (that may cause this)? Thanks, Jan

This is probably correct. We use the knob to "trigger" the trim moving - but not the other way round. Something to consider for an update, thanks for pointing it out! Jan

Hi Nuno, and thanks for the nice words... The PROG page is still pretty much work-in-progress and we plan to finish it in a future update. Enjoy what is there already, but we don´t claim that it is fully functional (or even half ;-)) Cheers, Jan

Hi IronCondor, please give us a little bit more information - what kind of crash do you see? Does X-Plane quit altogether? Do you get a crash to desktop? Is there an error message popping up? Please post your Log.txt that you get (find it in your X-Plane root directory) after the crash, it might give us a clue! Thank you, Jan

Thanks, I will check that out! Cheers, Jan

Make sure that your default X-Plane failures are set to off. Other than that I could only imagine a hydraulic failure (or you forgetting to turn on the pumps) to cause that. We still have to code the engine fire switch also stopping the reverser from deploying, so that can´t be it. Cheers, Jan

Hi Steve, just some quick thoughts - everything that VNAV does can also be done with the basic modes. Instead of clicking "DES NOW" you can select V/S -1000 and experience the exact same thing. VNAV is a bit more comfortable in theory, but in reality you will rarely fly an approach in the real world as programmed in the FMS, and with every shortcut or extension your predetermined VNAV descent path will crumble and you are left to improvise. Don´t change your approach speed around. The autothrottle is certified to compensate for gusts, so you will always only ever set Vref+5 and just leave it there, no matter the wind. Only when flying manually you would set a higher target speed - but it is never changed during the approach, unless the tower reports a radically different wind. I am personally not convinced that the (real) autothrottle is so great at compensating for gusts, so I would maybe add another 5 in really windy conditions just to stay away from that stick-shaker experience... The "sticky" mouse could be due to your system performing some taxing background tasks that saturates the CPU and causes certain mousepresses or releases to not register. Maybe try to run X-Plane as clean as possible to troubleshoot - especially removing all plugins not needed, just to see if it helps. The problem of "reversering" the direction is known and appearantly very hard to solve, I have made it a habit to always "grab again" when I change direction. I agree that the MCP ALT button is too sensitive, I have been pestering Nils to tune it down...to little effect, so far :-) But I haven´t given up hope! There is also the element of "familiarity", I guess if you moved those buttons for 7+ years like me, you adapt... And yeah, I invite you to plan your descents - it is actually quite satisfying when it works out and it is also required when flying VNAV - even the real system is absolutely not failsafe and you need to know when to step in and show the computer who is the pilot ;-) Cheers, Jan

Hi Steve, thanks for the nice words. I skipped (well, skimmed over) your paragraph on VNAV, the green circles, and altitude restrictions because it is not really implemented yet and doesn´t work like it should in the real plane. Please resort to basic airmanship when planning your descents and use basic autopilot modes for now. This is actually the way the 737 is flown in most cases. Improving VNAV is on our agenda. VNAV will not honour the flap placard (maximum) speed during the descent - it will only honour the "lowest maneuvering speed". So if you are in a segment where VNAV wants to fly 250 and you extend your flaps, bad things happen. But if you are in a segment where VNAV wants to fly 160kts and you don´t extend your flaps, you should see the 210/FLAPS and the plane will not slow down below that. Again, this may not always work right now. It works the other way during climb. VNAV will always fly either its desired speed, or current flap setting placard speed -5, this works pretty well, already. The "B" you are talking about is actually a "all segments lit" and signifies a placard speed reversion. The autothrust kicks in and reduces power to stay at 230kts exactly. It will not try to fly a "safe" speed, it is just a pretty crude reversion mode to avoid ripping off the flaps. 230 is the absolute maximum to fly with flaps 1, it is better to extend flaps to 1 when you are well away from this placard speed. I recommend 225 for very heavy weights (>53.000kgs) or 215 when below that. You are right, you need to exit VNAV to exit the speed reversion mode, so just click FL CHG, dial the MCP SPD down by 15kts to get out, then click VNAV again (if you rely on using it during the descent). I am not covering these mechanisms in my tutorials, because they are way over the head of most users and would just confuse people. In 10 years of flying the real 737 I never triggered a speed reversion, that is the goal, here. Wait until speed diminishes and you are safely below the placard speed - and watch for VNAV misbehaving, with the imperfect implementation we have it COULD accelerate again after passing a certain waypoint. On the manipulators sticking: You need to have the manipulator on your screen (iirc) to release it - if you grab it, then look away, you can´t release it. The mouse-view works the same way, if you move the cursor off the screen, it "sticks". I agree this is not ideal, but I think it´s an X-Plane limitation. Hope this helps, Jan

You are right, Tom. X-Plane uses one setting for "maximum braking" - this can be toggled by the default button V, it also doubles as the RTO mode of the autobrake AND the parking brake. From a designer´s standpoint this is cumbersome, but the effect on the brakes is actually the same for all three applications - maximum braking. Your neck would hurt less in the real plane if you used the parking brake, because the wheels would lock (no antiskid) and the braking deceleration is actually less than in RTO...which is just the same as maximum manual braking. Cheers, Jan

Hi admroz, you are right, there should be a small "OVHT" label above the window heat test switch, I will take a look, thanks for pointing that out! Tom is right, to reset the window overheat condition you need to turn each switch OFF then ON. The effect of the switch is kind off the same in both directions. Pushing it UP (ovht) will trigger the overheat condition, illuminating all lights. Pushing it down will apply "full power", which will usually also result in an overheat condition (a real one) with the above effect, at least on the ground. Note that we do not simulate the cooling effect of airflow (yet)... Hmm, gives me an idea... The manual says, however: NOTE: Do not PWR TEST when all amber OFF lights are extinguished. Whatever that means...I have never used that on the real plane, I would think that it is mainly for maintenance use. Cheers, Jan

Not if the autobrake is working in RTO mode, as it will apply maximum braking for you. If you should disengage the autobrake accidentially (it could happen during wild steering with the pedals, or just due to startle) you need to apply full manual braking, of course. Just watch the "AUTOBRAKE DISARM" light during the RTO. Cheers, Jan

Pull thrust leves to idle. Then pull up speedbrake lever and then activate reverse thrust.Thats it. Jan

Yes, it is - I hope we will be able to include it with the next fix. Cheers, Jan

Interesting - and you could potentially save some time and land really early at your destination! I will try to reproduce and then fix it... Thanks for the report, Jan

The scavange pumps will only trigger if you turn the center fuel pumps from ON to OFF. I am not sure if the center pumps need to actually run to trigger the scavange pumps, or if you merely have to move the switch. I am also not home right now, so I can´t look it up, but I doubt that the scavenge pumps are powered through the batteries, so once your generators drop off line (like in the scenario above), they would not run, either. Cheers, Jan

Nice writeup and shots, Tom! I am glad to see that us extending the maximum database range for the plane is paying off! Cheers, Jan

I would put my money on VRAM exhaustion in combination with Orthophotos. Cheers, Jan

If you leveled off at 3000 due to the MCP altitude window commanding so while in a VNAV climb, the N1 limit indicator would change to CRZ and the autothrottle would use up to maximum cruise N1 to accelerate to VNAV climb speed. You would, however, most likely be already at this speed (since you where in the climb before) and therefore the autothrottle would not need to apply "full power" to accelerate. Cheers, Jan

The N1 limit indicator does not show the "phase" at all, it only shows the N1 limit. So whenever the plane is at the altitude you commanded through the MCP (in your case 35400) and in level flight, the limit will go to CRZ - this means that the maximum power that the autothrust can apply is cruise power. Again, this does not mean that you are in your cruise phase. Another example. You take off, and your initial level-off altitude is 3000 feet (so you set 3000 on the MCP), even though your intended cruise flightlevel is 350 (and that is set in the FMS). You will see the N1 limit go to CRZ again when the plane levels off at 3.000, even though you are not at your "cruising altitude". Cheers, Jan

Mistyped that - its BEG (Belgrade) and I was talking real flights... Ortho´s Level 10000 . Cheers, Jan

Thanks for the feedback, have a great flight to Palma (I am looking at BEO-FRA-LHR-FRA today)! Let me know how the rest of your problems pan out! Cheers, Jan

Hi Ian, this is a new one... the problems you encounter engaging the autopilot are related to your yoke being off center for sure. We read the joysticks position straight from X-Plane, so I dont think the problem is with our plane - and since you checked your neutral position, the only idea I have is checking for X-Plane random "failures" (make sure you have them off and all systems working). There are things like trim runaway, iirc. For the start-up state problems I would look to either the settings you select in the X-Plane menu, you can elect to start with "engines off" there, and that would interfere with our settings. The buzz you hear is the IRS warning horn, alerting you that the IRS units are running on battery and IRS R will shut down in 5 minutes or less... If that does not help, maybe check for incompatibilities with other plugins, things like fly-with-lua and other scripts can interfere if set up not correctly. If you can recreate the gizmo-pop up error when changing the speed limit I would love to hear the exact steps to do that so we can fix it! There are still some lingering gizmo crashes related to the FMS and we want to stomp as many as possible. Fixing them is not hard - finding them is! Hope this helps, Jan

Yes, mfor sums it up pretty well. The autobrakes are "really worried" about braking when the pilot actually attempts to accelerate (again) - so it will immediately quit breaking if thrust is applied (even a bit) or the brakes are pumped manually. Even a "spiky" hardware thrust lever (or one that does not go ALL the way to zero) will interfere with it working. Cheers, Jan