Alpha Floor

I don't know if this has been reported (haven't seen it), but something I experience often is that VNAV will not engage on departure because the altitude restrictions of the SID are not correct, or just blank with dashes. I don't know if the issue here lies with the AIRAC database, or the IXEG VNAV logic. To fix it I go through LEGS and hit the DELETE key, then right LSK on the "offending" restrictions. Once all are clear, the FMC populates the passing altitudes or flight levels and I can finally engage VNAV.

Offtopic, but oddly enough for some reason there is a huge difference with the JustFlight Piper Turbo Arrow here. It happens when after flying the IXEG 733, I load the PA28R and upon rotation I find out the aircraft is basically uncontrollable because I forgot to uncheck the experimental flight model...

Exactly right, that's what I meant!

What I do is create my own views based on the native X-Plane commands, that way I don't have to re-do the views after updating.

Ah yes! I tried it out when taxiing back to the holding point, and indeed, it kept going off. I just decided to ignore the horn the second time and carry on. If this happened in real life, Jan, a TOWS horn that goes off for no apparent reason. After aborting a take-off and troubleshooting, what would you do? I guess you'd contact your companies maintenance and let them know? Maybe they would ask you to pull and push the corresponding CB to reset the system? Eventually you would just take-off and ignore the horn or would the flight be cancelled? This was out of base on a return flight. I guess the decision to cancel the flight is also dependent on whether you're in or out of the company base.

Hey Jan, thanks for your quick comment! I think it must be something with the Gizmo plugin, I will reboot it between flights as you said! For information: I have the speedbrake assigned to a rotating knob in my Saitek X-52 Pro. The knob was rotated all the way up but as you said, some noise in the signal may be sending a slight non-zero value... And kind thanks for the compliment. If unsure, better to reject the take-off at a low speed than continue with the uncertainty of what is going on... only to find out on rotation...

Gentlemen, Another issue caught today while live streaming. This time it caused me a rejected take-off. TOWS kept going off. The usual suspects are: - Flaps set for take-off - Stab trim in green band - Speedbrakes fully down - Parking brake released But it still kept going off. Anything I am missing here? https://youtu.be/MNCTzcAPfQI?t=14503 Jump to 4:01:43 I had a normal take-off earlier at 1:05:00 with no alarms, for the record.

Hello, Any chance 8.33 radio spacing will be included anytime soon? Really starting to miss it when flying on IVAO as on my last couple of flights it seems like every single frequency is on 8.33 and I can't select them through the radio panel in the aircraft and have to use the x-Ivap software.

That's a good solution. Just let the users decide whether they want the feature or not.

I used it for a bit until I realised that it's best to be consistent with the view system one uses. It's either the custom aircraft views or the native X-Plane views, but no mixing! This is because I have my hat switch set to "glance left/right" on the side buttons, but to "Captain" and "IFR" views on the up/down buttons. I had to remap de Captain and IFR views to native X-Plane views for the transition between the glances and the views to work properly. Lengthy explanation but my conclusion is: get rid of it.

It appears someone had this already and the workaround is to add one pixel to the screen resolution? Is this still the "fix"? http://forums.x-pilot.com/forums/topic/13653-ixeg-menu-not-hiding/?do=findComment&comment=127678 Edit: This didn't do it for me. Setting X-Plane to run in WINDOWED MODE does work, the menus work again. But I don't want to use XP in windowed mode for obvious reasons...

Hello, As of yesterday the IXEG 733 was working fine. Today I connected a new monitor to X-Plane and all works well so far. The only issue I have found is the IXEG 737 Main Menu will NOT show when moving the mouse to the left. Issue 1 - MAIN MENU NOT SHOWING If it matters, my setup is the following: Lenovo laptop on the left, its screen being the "main" screen on Windows Display settings. Second monitor to the right of the laptop; this is the monitor where I run X-Plane 11 in full screen mode. I can slide the mouse to the left from the X-Plane window over to the desktop on the Laptop screen. However the IXEG Main Menu does not popup. Issue 2 - MAIN MENU NOT HIDING I tried to reorder the position of the screens on Windows Display. If I move the second monitor (which is physically right of the laptop), to the left (opposite of where it should be), then the issue reverses. The Main Menu shows but it WILL NOT hide. Also to move the mouse from one screen to another the motion is opposite which is extremely confusing/inconvenient. Any help/ideas? Thanks! Jaime

As we all know and Jan very well explains in the video tutorials, the A/T can be disengaged using two methods: 1) Pushing the "A/T disengage" button located on the side of the throttle levers twice (second time to cancel the alarm). This disengages the A/T and also disarms it. 2) Deselect the active thrust mode, for example, by pushing the SPD button on the MCP if it's lit up. This will "uncouple" the A/T but leave it armed. Technically it is still "engaged" in ARM mode. Some airlines prefer method 2 as the idea is that it leaves the A/T armed in case of a go-around. Other airlines however don't encourage it or outright prohibit this method. It's interesting how different operators view things in different ways. I have looked into Boeing's FCTM to see what they say, and it seems that they don't recommend method 2 either because, quote, "the autothrottle ARM mode is normally not recommended because its function can be confusing". It's interesting that Boeing themselves admit that their own system is confusing, and also that they don't really give an elaborate reasoning as to why it is so confusing. Now, here are some important points of the A/T ARM mode: 1) It provides minimum speed protection in the event the airplane slows to minimum maneuver speed. 2) Gust protection is NOT provided. 3) If the A/T is left in ARM mode during a descent to an MCP altitude (for example, the MDA of a non-precision approach), the system will wake up and engage in SPD mode to level off at the MCP altitude. This can be unintended behaviour if we are flying manually and have gained visual contact with the terrain. Of course one would argue "well why did you not set the MCP altitude to the MAA (missed approach altitude) in the first place?", which is a fair question that can be discussed separately. This is something to bear in mind though. So in my view, I personally prefer to fly either fully manually (both A/P and A/T completely disengaged) or fully automatically (both A/P and A/T engaged and active, not just armed). In case of a go-around if I hit TO/GA the go-around mode will activate in the FMA but I will have to manually advance the thrust levers to set go-around thrust. Fine by me. Your opinions, gentlemen? (and ladies if any, let's be inclusive...)

Is there a list of what will be changed with v1.3 so far? I'm particularly interested in FMC functions (HOLD, custom waypoints etc.) and VNAV logic.

Jan that's a very interesting point. I had a little "accident" regarding an armed A/T in manual flight and will open another thread to discuss it. But I think this is pretty much down to airline SOP as I've been told by other 737 pilots that it's their SOP to "disarm" (not just "deselect") the A/T when in manual flight.