mfor

Do you use the TOGA button for takeoff? - the moment I press it I get the FD needles.

Yes

You've de-rated the engines that's why it's saying R-<Whatever>

Make sure all waypoints have a reasonable altitude setting on the legs page - at least that was the solution when I had the problem.

Well you probably pushed the TOGA button and thus putting the flight computer into TOGA mode, activating several ap modes as shown at the top of the EADI. As far as I know it will activate HEADING HOLD mode engage TO thrust (later reduced to N1) provide FD pitch cue to maintain MCP speed+15 provide FD lateral cue to maintain heading (or LNAV once engaged) When you drop out of TOGA mode by activating AP CMD your MCP speed dial will be set to you current speed and you'll be put into LVL CHANGE mode (or ALT HOLD if you've already reached the MCP altitude) along with either HDG HOLD or LNAV if you had engaged that. So you don't really need to activate any AP modes if you're happy with the defaults and activate LNAV and VNAV whenever you think is suitable. I usually arm LNAV shortly after takeoff, engage the AP after reaching 1500, and once above 3000 I speed up via the MCP speed bug while cleaning up the aircraft before engaging VNAV. FWIIW: If you perform a manual takeoff (i.e. not use the toga button) pushing the AP CMD button will indeed put you into CWS mode as you expected.

Well if you look at the top of the EADI display, you can see that the AP is in ALT HLD mode (green, top) and G/S capture is armed (white, below), so it is waiting for the plane to cross the glideslope. So maybe you were already above the glideslope when you armed APP and never crossed it thus the AP never captured it. IOW you need to cross the glideslope with APP armed for the AP to enter G/S mode and land. In that case the G/S will move to the top in a green font and the AP will disregard any altitude setting in the MCP. If you did cross the glideslope, then disregard this post.

Thank you @Litjan - missed the thrust mode annunciation fail. And boy are you fast in fixing these things All this bus failure talk had me thinking: is it really common for a bus to fail - I understand things like a TR failure, but the AC bus itself failing? Or I guess maybe a more appropriate and more interesting question would be: What kind of failures did you encounter in your 737-300 career?

Well he said: "However, during this flight, everytime I crossed a waypoint, the VNAV would turn on, and try to take control. " This sounds more like an addon that automatically engages VNAV when crossing a waypoint - unless he overspeeds on every turn. So I'd recommend disabling everything except for ixeg (and gizmo) and see if it is still happening.

But in that case shouldn't it not be showing voltage either? I think it's weird that it shows AC voltage but not the frequency. Also see https://www.youtube.com/watch?v=xSBwy21WOVc&t=128 where it show both on AUTO. Depends on the voltmeter of course but they usually draw in mA range, which should be negligible over a few days, plus it would only apply if you ledft the meter on BAT. Also see: https://www.youtube.com/watch?v=xSBwy21WOVc&t=50 Stuff that is visibly failing with AC Electronic 1 failure speed trim fail light comes on yaw damper light comes on cap altimeter fail fo box off terrain inop light on gpws inop light on OAT display fail Mach Warning No1 (when tested) Autothrottle seems to be working. Stuff listed in the schematics dependent on No1 El, 115V AC: Aileron force limiter Autothrottle, GPWS Autopilot stab. trim Alt/Rad.Alt Cap. Stuff listed as dependent on No1 El. DC No1 DAA - FMC No1 Mach Warning FCC- A Flight mode annun. Mach trim sys A Mode control panel Yaw damper With DC Electronics 1 failure I seem only to lose AP A and Nav2 (FCC/DAA?) Might be more - haven't tested extensively. So it seems some stuff from the DC bus is failing when you disable the AC bus. Of course those schematics might be wrong and/or systems depend on more stuff than what is listed there. Thanks in advance for any insight you can provide.

While you are at it, some more electrical questions/issues STBY PWR shows no AC frequency with STANDBY POWER switch on AUTO but works when on BAT. However voltage shows in both cases - bug? feature? DC meter does not show BAT voltage with BAT switch off - not sure if it is supposed to though. Failing AC Electronic 1 seems to fail (some) DC Electronic 1 circuits as well, while DC Elec 1 fails less than it should - at least according to the 737 technical site, so I'm not too sure about that, see post below for schematic. Regards

Well, copying files based on OS and X-plane version plus a Gizmo dependency check alone doesn't really sound like "weeks" complicated, but it is what it is, I guess.

The joys of DRM / copy protection...

Thank you, JIT compilation certainly explains why Defender jumps in and gets saturated when modifying the lua code frequently.

Well "recalculating values" should not trigger any action of the AV program, nor should running scripts. AVs are usually are only interested in verifying reads/writes of certain file types and some program actions that usually involve memory acrobatics and other rare stuff. So the question remains what triggers the AV activity and why is it not happening during the initial calculations. Note: I'm not worried at all and have added the exclusion since I've first encountered the problem. However it irritates the programmer in me: I can't see a good reason why this process would need to do something that triggers the AV and thus it makes me feel there should be a way to do this without upsetting the AV. So fixing this or at least explaining why this is happening (and can't/won't be fixed) would at least satisfy my curiosity in the latter case and in the former case avoid the problem in the first place.

Muchimi has got a point though. Not really sure why changing the route in flight would require such heavy AV activity - is the cause of this known? If not, it might be worth looking into this and fixing the problem, as it isn't really reassuring to tell customers "exempt out program from AV or it won't run properly" unless it is somewhat comprehensible.

Did a few more tests without wind and no turbulences. At first I thought they were inconclusive, because I got drops to 6000 with both settings and sometimes both would behave well (~4000-ish). However during one test with a drop I noticed a slight stutter during the nose dive, which, I presume, was the result of either x-plane or an addon performing some loading action due to the view changing (my prime suspect is Skymaxx). Such a leap in the time continuum could easily throw off any PID controller. So I disabled (almost) all plugins and relocated the testing area out to open see. So far I haven't seen any unruly drop in the vertical speed there. Haven't tried with turbulences yet and the number of test has been rather small - running out of fuel However I currently think that drop is due to fluctuations in the physics, either in form of the frame rate (stutter or slow downs) or maybe wind speeds due to turbulences - not sure yet about the latter. Edit: It seems turbulences (set to 1) can cause this as well - although it seemed to be a little less extreme (would barely touch 6000) PS: Didn't know you can ditch planes in X-Plane - good thing the operations manual includes a ditching section. Drag seems a little low though. PPS: Hope the life vests are included with IXEG's model. PPPS: Send boats... or nudes... or both...

I think I did a flight without turbulence and it was more or less the same, will try with MCP speed set to knots.

With some tweaks you can use it in XP-11 already (the flight model is a bit off though) and to my knowledge there will be a free patch to make it XP-11 compatible.

See attached a video (15MB) - if you need better resolution/sound, let me know. lvlch.mp4

Same thing here: Selecting LVL CH at FL330 made the vertical speed drop to 6000+ fpm for about 2000ft before slowly recovering towards 2500 at FL290. Speed went up from .74 to .785+ (294)@~FL300 - still a bit below the red band though, so I didn't think much of it. This was with a ZFW of 48.3 tons plus 5.1t fuel left and a 42 knots headwind on XP-10.

For the barometric minimum descend altitude it's just a bug on the altimeter, so no callouts - if you use the the radar DH you get the "minimums" callout.

Any news on that one? Still seems to be the case in V1.1 for me - should we re-post it in the bug forum?

Known issue with 1.1 due to the XP-11 fixes. http://forums.x-pilot.com/forums/topic/13200-pushback-truck-only-pushing-straight/

The altitudes are referred to as flight levels (FL170) above the transition altitude and as feet (17000) below - for example on the LEGS page. I don't think it impacts calculations (like VNAV) - I may be wrong though.

It's under the custom commands for this aircraft (click the button next to the text line in the keys tab to open those) in XP-10 ixeg/733/autopilot/AP_disengage ixeg/733/autopilot/AP_A_cmd_toggle ixeg/733/autopilot/AP_B_cmd_toggle