-
NGX SP1D Autobrake Issue
I've tried all of the following, yet I'm still not able to get the autobrake to disarm on the landing rollout by stowing the speedbrakes. - Started the flight by loading a simple aircraft (C172) - Cleared all of the panel states that were saved prior to SP1D - Uninstalled the NGX and then downloaded and installed again. For those of you where this feature is working, can you confirm that you're definitely running SP1D? Many thanks.
-
NGX SP1D Autobrake Issue
Was that really necessary? I explained the reason for my error and apologised.
-
NGX SP1D Autobrake Issue
Oh no!! It kept saying that the service was unavailable due to scheduled maintenance/high domain traffic. So sorry about that!!! :-( After braking has started, any of the following pilot actions disarm the system immediately and illuminate the AUTO BRAKE DISARM light: • moving the SPEED BRAKE lever to the down detent • advancing the forward thrust lever(s), except during the first 3 seconds after touchdown for landing • applying manual brakes.
-
NGX SP1D Autobrake Issue
After installing SP1D for the NGX, it appears that stowing the Speedbrake Lever after landing no longer disconnects the autobrakes? Is this a bug? Many thanks, Martin Neep
-
737 NGX Elevator Issues
Thanks for the tip, I'll give this a go and see if it resolves the issue. Many thanks, Martin Neep
-
737 NGX Elevator Issues
I've been having issues with manual elevator control in the NGX ever since it was installed, and after extensive testing I've come to the conclusion that the issue is with the aircraft itself. I always perform a flight control check as part of the 'Before Taxi' checklist and often find that the elevator responsiveness is sluggish. With the SYS page open on the lower CDU it is clear that sometimes the elevator doesn't reach it's full range of travel and moves at a slower rate than the control inputs. This issue is intermittent, but can sometimes be remedied by moving my CH controller through it's full range of motion a few times. Every time this happens, I also switch to the CH control manager and test my yoke, it shows completely normal range of travel and responsiveness. There is also an issue whereby after the autopilot has been used, the elevator will not reach it's full range of travel (according to the SYS page on the CDU). When the yoke reaches either full back or full forward travel, the elevator will jump to the neutral position. Again, a check of CH control manager shows that this behaviour is absent. The result is that manual flying after the use of the autopilot is much more difficult than after takeoff. During the approach the aircraft is 'mushy' and not as responsive. Out of interest, loading a default FSX aircraft also clears this issue, therefore I have to assume that the problem is with the NGX itself. Has anyone else noticed this issue, or know of a remedy? Many thanks, Martin Neep
-
Geometric descent.
Sometimes a STAR will have an altitude constraint which requires an early descent and subsequent level portion. In order to fly level for a time and ignore the geometric descent calculated by the FMC, the FCOM states that a new TOD can be calculated by entering the aircraft's current altitude on the CRZ page. For some reason, I can't get this to work. Senario: Let's say the STAR has restriction of FL150 at waypoint A. and 2000ft at Waypoint B. After reaching FL150 and passing waypoint A, rather than descend at 300fpm to waypoing B, you would like to maintain FL150 and re-commence the descent for an idle profile to waypoing B. When entering 150 as a new cruise altitude on the CRZ page, the entry is accepted, but as soon as I press EXEC, it jumps back to the descent page and the descent path indicator reverts to the geometric descent. Any suggestions? Many thanks,
-
Assumed temp takeoff - V2
Wow, I had no idea that the flap schedule is used differently. What about on the approach, you wouldn't select a speed slower than the manoeuvring speed for the current flap setting, right?
-
Assumed temp takeoff - V2
So the question remains, when reaching for the MCP to set 'bug up', is it normal to see AXXX indicating low speed protection BEFORE you reselect the bug?
-
Assumed temp takeoff - V2
- Assumed temp takeoff - V2
I'm not using a 3rd party application to calculate V-Speeds. They're coming directly from the FMC based on actual weights.- EHAM - SUGOL 2A P-RNAV Transition.
Here's a route, give it a go... EGKK SID CLN L620 REDFA STAR EHAM- Assumed temp takeoff - V2
Sorry, I didn't explain it very well. It's not that my actual airspeed is low, following the FD, current IAS is approximately V2+20. The problem is that the airspeed bug, which is set to V2 prior to takeoff, falls within the low speed buffet margin, causing the A/T to display low speed protection. I'll take a screenshot later when I get home that might help to explain it better.- Assumed temp takeoff - V2
Whenever I perform an assumed temperature takeoff, and commanded N1 changes from D-TO to CLB, V2 always falls within the orange low speed buffet range and A14X flashes on the speed window to indicate that the selected speed is too low. Obviously, the speed means very little because with the pitch mode in 'TOGA' the FD is commanding V2+20. However, I have a friend who flies the real 738 and his company SOP calls for 'bug up' at thrust reduction alt (the queue for the PM to select the airspeed bug to flap up speed). He said that he's never seen the speed window indicating min speed reversion on takeoff. Where am I going wrong?- EHAM - SUGOL 2A P-RNAV Transition.
Where are you starting from? - Assumed temp takeoff - V2