tomcjones 0 Posted January 25, 2013 Share Posted January 25, 2013 Gentlemen With all due respect there is much work to be done on the MCDU. I did a short flight from KDFW to KMSY. Preparing for descent I set the altitude to 4000 feet and presses the altitued button as close to the T/D marker as I could. The aircraft descended to an altitude of 11000 feet and stopped. A few minutes later the speed bug started coming down to 250 knots. Later, much to late, the altitude started decreasing and leveled of at 4000 feet. I passed over the airport at 4000 feet and at 250 knots. I can see that there has been some work on the managed descent problem but with not enought priority. This is a severe problem and should be worked on with highest priority. Gentlemen you all know as well as I do that there is a severe problem with managed descents and should be worked with the highest priority. With all due respect Regards Link to comment Share on other sites More sharing options...
Emi 5161 Posted January 25, 2013 Share Posted January 25, 2013 Though we can not recreate this problem we know that you are not the only customer reporting this. With the VNAV update we're working on this will hopefully be solved anyways. The fact that it stayed at 4000ft is because you said you've dialed 4000ft into the FCU and so it leveled off there. Just normal behaviour. It has highest priority already. Link to comment Share on other sites More sharing options...
tomcjones 0 Posted January 25, 2013 Author Share Posted January 25, 2013 I dialed in 4000 feet because that is the altitude at which you should pass the knite waypoint and it should not have leveled off there. The aircraft should have passed the knite waypoint at 4000 feet but keep descending. It did not. As I said it leveled off at 11000 feet with 4000 feet dialed in then later leveled off at 4000 feet. Why did it do this. When the glide slope bug appeared it was at the very botton of the display. Like I said the aircraft should not have leveled of at 11000 feet nor 4000 feet. When the glide slope bug appears on the display it should be at the center or above the center. If not the aircraft is too high on the glide path. Link to comment Share on other sites More sharing options...
kidcraig 9 Posted January 25, 2013 Share Posted January 25, 2013 There was probably a restriction at a waypoint at 11000. It leveled off because there is an issue with managed descent and the plane has major issues crossing restricted waypoints properly. It descended way too early, leveled off at 11000 and waited to cross the restricted waypoint. This is being fixed as I type, I hear. It continued down to 4000 after the restriction, then because you we're high above the glideslope, the plane did not capture it, so you stayed at 4000. This is my guess. Don't worry, it's getting worked on. Link to comment Share on other sites More sharing options...
Deputy Sheriffs jrotaetxe 242 Posted January 26, 2013 Deputy Sheriffs Share Posted January 26, 2013 Or was preparing the 10000 feet speed reduction... Without further info, seems a misinterpretation of Tomcjones (Your nick is a little bit annoying for spanish speaking people, by the way ). Would like to have the star ang the initial FL to analise better. Regards Link to comment Share on other sites More sharing options...
PaulMidd 2 Posted January 26, 2013 Share Posted January 26, 2013 (Your nick is a little bit annoying for spanish speakink people, by the way ). There is a British senior politician with the name of Ed Balls. Perhaps he's related to Tom C*jones Link to comment Share on other sites More sharing options...
Deputy Sheriffs jrotaetxe 242 Posted January 26, 2013 Deputy Sheriffs Share Posted January 26, 2013 he, he, he.... May be. They are the origin of everything... Thanks Link to comment Share on other sites More sharing options...
tomcjones 0 Posted January 26, 2013 Author Share Posted January 26, 2013 jrotaetxe,PaulMidd you two probably have no origin. Your existance is for nothing. Link to comment Share on other sites More sharing options...
Deputy Sheriffs jrotaetxe 242 Posted January 26, 2013 Deputy Sheriffs Share Posted January 26, 2013 Oh... You are welcome. Link to comment Share on other sites More sharing options...
BigJacko 5 Posted January 26, 2013 Share Posted January 26, 2013 I dialed in 4000 feet because that is the altitude at which you should pass the knite waypoint and it should not have leveled off there. You mention KNITE - but I can't find a KNITE waypoint at New Orleans (KMSY). I have found a KINTE on the AWDAD6 approach to rwy 10, though... is that what you were flying? It seems logical: KDFW CLARE3 SWB BTR AWDAD6 KMSY is a route I've just dug out of VATAWARE. If so, there's the approach chart (no idea how fresh is it, though - found it here: http://www.flyeagleaircharter.com/charts/kmsy/AWDAD_SIX_ARRIVAL.jpg ) If that is the approach you were flying, then according that the Runway 10 ILS chart, KINTE should be passed at 2000ft, not 4000ft. See here: http://www.flyeagleaircharter.com/charts/kmsy/ILS_RWY_10.jpg The aircraft should have passed the knite waypoint at 4000 feet but keep descending. It did not. Regardless of what altitude is correct for passing KINTE, if you authorised the aircraft to descend to 4000ft, and no further, than that is all it will descend to: 4000ft. It will not go below 4000ft unless one of the following is true: you dial in a lower-than 4000ft altitude setting whilst in managed mode if and only if there is no 4000ft constraint in the FlightPlan at that point,give it APPR authorisation with an already-captured glideslope (in any AP mode),set the autopilot to use an OPEN DESCENT (OP DES) by pulling the button, orare handflying it manually, without any autopilot at all. As I said it leveled off at 11000 feet with 4000 feet dialed in then later leveled off at 4000 feet. Why did it do this. If this is the AWDAD6 approach, then there is a note in the text of that chart which states that (if landing at KMSY, which you were) you should expect clearance to cross Awdad Int at 11000ft. It's my guess then, that 11000ft is set up as a go-no-lower constraint in the AWDAD6 STAR in the MCDU - and it would precisely explain why your aircraft would not descend below 11000ft, whilst in managed mode. You could (if you had wished) have PULLED the altitude knob to select OPEN DESCENT (OP DES), and played the scenario that you'd be granted a lower clearance, but it's probable in the real world that that would be unlikely to happen (after all, it says to expect 11000ft, so that's most likely what you'd get, nine times out of ten). The point is, in managed mode, the aircraft will respect the constraints of the published STAR and not break them unless you override them manually. If Awdad Int has a 11000ft descent constraint on it, the aircraft will attempt to cross that waypoint at 11000ft, if you've entered a figure at or below 11000ft. I've already answered why managed mode will not descend below the level which YOU - the captain - have dialled in and thus authorised (i.e. the 4000ft). When the glide slope bug appeared it was at the very botton of the display. Like I said the aircraft should not have leveled of at 11000 feet nor 4000 feet. When the glide slope bug appears on the display it should be at the center or above the center. If not the aircraft is too high on the glide path. In my humble opinion, and with the greatest respect, I think the glideslope bug appeared at the bottom because you were 2000ft too high, and 'by your own hand' (because you'd misread the ILS RWY 10 chart, probably - it is a little cluttered in the area around TURTL - but the 'side-profile' view lower down should always be your cross-check, and that pretty-clearly shows KINTE glideslope intercept at 2000ft.) So - I hate to say it, but I think this one is 99% pilot error. There are issues, certainly (as kidcraig pointed out) whereby the managed descent isn't particularly smooth, but it's not a show-stopper. It's just not 100% realistic. The critical point-of-failure is, imho, you not dialling in 2000ft early enough to allow the plane to descent to the glideslope capture level at KINTE - nothing more. Sorry, but hopefully this has been a helpful dialog? I hope so. Regards Link to comment Share on other sites More sharing options...
tomcjones 0 Posted January 26, 2013 Author Share Posted January 26, 2013 BigJacko thanks for the information. Instead of setting the altitude at 4000 feet I set it to 0. When the glideslope bug appeared it was approx half way between the center and bottom of the scale, pretty much like I have been getting all along. I downloaded and installed the fix08 but I could tell no difference. With all due respect I have been flying managed or automatic approaches on just about all FSX and FS9 aircraft equiped with FMC's since FS9 came into existance. Regardless of what you say I am very familar with SIDS, STARS and approach plates. Never in all my years of flightsimming have I ever had a problem with managed approaches like this aircraft has. I totally disagree with your 99% pilot error comment. Regards Link to comment Share on other sites More sharing options...
BigJacko 5 Posted January 27, 2013 Share Posted January 27, 2013 OK - you're saying you flew the KDFW CLARE3 SWB BTR AWDAD6 KMSY route again, yes? But this time with a managed-mode authorised descent to zero feet? (it's not 100% clear; my apologies if this seems pedantic, I'm just trying to establish the facts.) If so, here are some follow-up questions:What was the altitude crossing VOODO, TURTL and KINTE this time?Were you in managed speed AND managed descent/altitude mode too?If yes, what were the speeds at VOODO, TURTL and KINTE?Also, WHEN did you give the bus the zero-feet authorisation (nearest waypoint) and what altitude was it at then?What was your en-route/max cruise level/altitude prior to BTR? (this may have an impact on the following question...)Did the bus cross AWDAD - under its own managed/STAR constraint - at 11000ft? Please understand I'm not simply 'trying to prove you wrong' - I am actually quite interested to find out whether this is a genuine bug, and if so, to what extent. I already concede there are some issues with managed mode, but in general, I've found they can be mitigated to some extent by careful handling or can at least be prepared for (and sometimes counteracted and prevented) by careful study and/or alteration of the auto-generated parts of a flightplan in the MCDU, which it computes once the key waypoints are entered. I do not mean to suggest that you have no experience - so please don't infer that from what I have written. It is true though, that even the very best pilots, with thousands of hours, can misread a chart one time, or make a 'pilot-error'. It remains the case that if you were attempting to intercept the glideslope at KINTE at 4000ft, as a commanded limit given to your autopilot, then that's a straight-up pilot error. Whether the managed mode descent has issues aside from that, is something we'll still need to ascertain - but on the evidence you gave initially, pilot error was the most-likely cause of the failure to intercept the slope. Being a commanded 2000ft above the slope at the standard point-of-capture will generally result in exactly what you experienced the first time, as a rule! When I get a minute or two tomorrow, I will try and fly this hop myself, to see what I discover. There doesn't seem to me (on the face of it) a great deal of time to get down from the 11000ft at AWDAD to the 4000ft at VOODO (13.2 nm between them, that's about 1886 feet per mile. At 180kt - a reasonable approach speed ten miles out, perhaps even a bit slow - that would mean you're travelling about 3 miles a minute, so that's a descent-rate of about 5658ft per minute, which is, er, madness, unless you want a plane full of vomit.) I think the secret may lie in the ILS approach chart... there's a clue there that ATC may sometimes (or perhaps even often) give clearance for AWDAD to be passed a lot lower than 11000ft - hence the note about 2000 with ATC approval, which applies to the two legs with the white number 1s in the black circles. Perhaps the real-life situation is that (as the STAR chart says) one should EXPECT 11000 at AWDAD, and plan approach speeds at minimum in order to get down in time (or several loops around the hold, which is at AWDAD, after all), but in reality, one HOPES that ATC will clear you down to 2000ft as early as possible - even before AWDAD - if circumstances permit it, so that the 10nm track prior to KINTE can be done at 2000, in plenty of time to get ready and to intercept the glide. There's another clue in that ILS chart, too... notice how it shows the leg from AWDAD to VOODO at 7000ft? That might indicate the nominal, expected exit-level from the AWDAD hold. 11000 in, 7000 out. It's possible that's the case. Alas, I'm not in the USA, and I've never flown this STAR, so I'm not familiar with its reputation or daily handling! It is fair to say that sometimes the navigation data is at fault in at least some of these cases, rather than the managed mode. Certain waypoints are entered as constraints that are (as we can see) near-impossible to make comfortably if followed slavishly. In reality, these approaches would almost never be flown without ATC overriding the paper charts; vectors are often given which shortcut the published STARs, or drop you down lower, earlier. I've seen many Navigraph STARs which are next-to impossible over the years - some are based exactly on the 'worst-case' chart-interpretation, others (few) are just plain wrong. I think this bus is using NavDataPro data, but there's every likelihood that some of it will be 'tight', if not 'almost impossible without a run or two round the hold'. Faults in the navdata don't automatically make it the managed-mode's fault. Keep investigating. I'm sure if we do turn up anything 'definitely faulty' about the managed mode, it can only help get it improved (but we need to be equally open that it might be the navdata or even the handling sometimes). I'll let you know if I discover anything if I get a chance to run this tomorrow. Right now it's 1:47am, and I need to hit the hay, pronto! Link to comment Share on other sites More sharing options...
tomcjones 0 Posted January 27, 2013 Author Share Posted January 27, 2013 I do not have a reading on the crossing altitudes. I did use the Clare3 SID and the Awdads STAR. The flight level was FL330. I set in 0 altitude about 10 miles prior to the T/D cue. At the T/D cue I pressed the altitude knob and the aircraft started its descent. It leveled off at 11000 feet before reaching Adads. I assume that this is correct because of the note on the STAR page. The speed decreased to 250 knots prior to reaching Awdads. Passing Awdads the descent begain. I let the MCDU control the speed but the speed remained at 250 knots all the way down. At approx 20 miles from KMSY the glide slope bug came into view but it was approx halfway between the middle and the bottom of the scale. I pressed the approach button but apparently the aircraft was too high to capture the glide slope. I can see no difference with the altitude set at 0, 2000 or 4000 feet. The aircraft is too high and over shots the runway. One other bit of info. I did a flight from KDFW to KBNA. I used the Graham5 Arrival with transation at Memphis. This approach was looking really good. Prior to reaching the Graham VORTAC it leveled off at 11000 feet, again probably because the expected passing is at 11000 feet at a speed of 250 knots. After Graham the aircraft started it descent and at approx 20 miles the glideslope bug came into view and this time it was above the center mark about halfway from the top. I then pressed the approach button and to my supprise the aircraft turned right approx 45 degrees from the course line on the MFD. Eventually it started turning left toward the Lreta intersection for a landing on rwy 02C. At this point I went totally to a manual mode and made the landing on rwy 02C. I will do the flight tomorrow to KMSY and take reading on the altitudes, etc. I am very anxious to get this managed descent under control. I will help as much as possible. Link to comment Share on other sites More sharing options...
tomcjones 0 Posted January 27, 2013 Author Share Posted January 27, 2013 BigJacko first things first. Are you a memeber of the Aerosoft Team or a beta tester. If not how do we know that all the data we create will be useful or used by Aerosoft to resolve managed descent issues. I do not mind doing testing but I expect it to be of some benifit to Aerosoft. A little about myself: You are dealing with an 84 year old person. Flight Simulator is not a hobby but instead is a passion. I have every copy of Microsoft Flight Simulator software that was ever published. My basic interest in Flight Simulation is scenery design. Years ago some of my scenery was on Flightsim.com and AVSIM.com. Don't know if it is still there or not. I am a degreed engineer with 38 years of experience in Aerospace Engineering. At one time I did some beta testing on a 737NG that was published by a company in the UK. At 84 my mind is in fairly good shape but I do make mistakes in flying flight fimulator products. Link to comment Share on other sites More sharing options...
BigJacko 5 Posted January 27, 2013 Share Posted January 27, 2013 Hi Tom, No, I'm neither an Aerosoft Team member nor a beta-tester. if I was, it'd be in my signature below or my profile avatar to the left. It's entirely up to you whether you attempt to test or debug this problem, but I would've thought that the elimination of personal pilot-error as a possible cause would be of some import to you, regardless of whether Aerosoft take the matter further. I'm sure they will read this, but I can't speak for them as to whether they would act upon it, if it turned out not to be a handling issue. From a personal perspective, I'm keen to find out more because (a) I'd like to help if I can and (b ) I get something out of it too - a clearer knowledge of the limitations of the managed-mode, which of course will assist me in my flying this bus later on. If you get something out of it too, then that's a bonus also. And I suppose if anyone else reading these posts gets something out of it too, then that's a double-bonus. My background's not important (and to be fair, neither is yours - the problem is a matter of detecting the facts, not an emotional thing at all, ideally) - but for the record, I'm 49, a software developer with a decade and a half in the professional videogame industry (now retired from that, and am self-employed on projects that take my fancy or which my clients need, delete as applicable!). I've beta-tested as many products as I've developed or overseen the development of myself (50+), but none in the FS world - though I have developed scenery items (like yourself) and aircraft repaints for use privately within the VA of which I am a member. I've been a hardcore user of FS products since before they were taken over by Microsoft! That is to say, I was using it when it was still owned by SubLogic on the Commodore 64, and have every version since MS's early release (with the exception of FS2002 which I skipped). Moving on, I think have the answer to our issue. Simply put: it's drag. I ran the KDFW-KMSY route today, as promised, and let the managed-mode handle the descent (in fact the entire trip from wheels-up). Sure enough, passing KINTE happened at around 4800ft, well above the glideslope. However, during the descent I noticed that there are two points at which a speed-reduction is called-for, and thus the bus will 'flatten-out' in order to reduce forward-speed. Throttles are at idle (set by the autothrust) and it simply has no other way to slow down, other than by using nose-up pitch (relative to the vector of descent). The speed-reduction from 250kts to green-dot speed is the first such item, and the second happens almost immediately once green-dot speed is achieved, and that's the flaps 1 and flaps 2 calls, to reduce the bus to near landing speed for the localiser/glideslope grab. If you're using the co-pilot and checklist mode as I was, she'll deploy flaps just after VOODO, and you'll pass that waypoint at around 7700ft. From AWDAD to VOODO the rate of descent was about 1200ft per min, but after the speed-reductions is reduced to as low as 900fpm, then 300fpm, in order to claw back the speed. As a result, it simply cannot make the vertical profile - nor could it, in reality, without help. Descending planes is either 'reduce speed' or 'reduce height' - doing both together is generally very hard work or next-to-impossible! I went 'missed' at KMSY and struggled with the autopilot for a good long while (and thereby hangs another tale entirely, but I won't bore you with that one now), until I was able to get back to AWDAD at 11000 feet again, and reset the approach on the MCDU in order to have another go. I went around the AWDAD HOLD at 11000 a couple of times to settle things out, and then tried again, same as before. This time, however, I made one alteration. Every time a speed-reduction was called for (magenta arrow moving to green-dot or approach speed), I deployed the speed-brakes until the speed-tape was back on the magenta arrow. Net result, problem solved. When the glideslope bug appeared at around 21DME out, I was already below it (and still at about 5000ft). I arrived at KINTE at smack-on 2000ft, and had no trouble doing a CATIII autoland with dual APs, from there. So - I'm going to call this one a handling problem. The navdata is asking the managed-mode to do the impossible (quite common in my experience), and it cannot be achieved without help, in the form of speedbrake-deployment. My only criticism would be that in most other buses I've flown (virtually), there's usually an ECAM warning which says "MORE DRAG". I've confirmed this is what should appear (in principle) with a good friend of mine who is a First Officer for a company that flies orange airbuses, and has a couple of thousand hours experience on the type (he's on a train currently, and I'll confirm it in more detail later if I can). So - managed mode descent in this case is not 'wrong', I feel. Certainly it is being a bit dim by not warning us that it cannot achieve the programmed profile, and it really should be yelling something at us to get us to deploy the speedbrake in order to maintain the vertical profile. This, I think, is its only failing (in this regard). As for the original waypoint crossing level, I did notice that the complaint of it descending too early, didn't bear out today. I crossed AWDAD the first time at exactly 11000ft, in a continuous descent with no leveling off. I had the 2000ft level commanded on the FCU since top-of-descent just before BTR, by the way. I was quite impressed at how efficient the AWDAD level-passing was, really - no discernable alteration in descent-rate, or flattening of the profile before AWDAD was reached. However, as for what happened after the missed approach, that's a whole 'nuther can of worms - but to be fair, I already know that Aerosoft have stated that the Go-Around phase is not yet completely working (and then some! ). However, I was able to beat it into submission and try again, and land perfectly, so despite it not being 'by-the-book' even that bit is not wholly impossible! I'm sure it'll be improved in time. Hope this answers your initial query. Please feel free to put it to the test. Providing you have the weight-and-balance of the plane all set up and entered into the MCDU, I don't think you'll have a problem. (For ref, I was Fuel: 8.4 blocks (kg-tonnes), 100pax and 159 cargo with 1:15 trip-duration set on the 'simple' fuel-loader mode giving ZFW: 49.8 tonnes, ZFWCG: 25%, TOW: 57.895t, LW: 54.205t. I used Cost Index:12 (which is current-practice at a certain bus-using airline that I probably shouldn't name, so won't ). Thanks for the opportunity to take a nice flight in the USA that I probably wouldn't have otherwise! Best regards, Neil Link to comment Share on other sites More sharing options...
tomcjones 0 Posted January 27, 2013 Author Share Posted January 27, 2013 Neil attached are screenshots of a flight from KDFW to KBNA. I decided to do this one because of the aircraft behaviou when I pressed the approach button. This flight was flown at FL330 clear weather no wind. Screenshot 01 approaching the T/D 125 miles from KBNA. The altitude was set to 787 feet the MDA of rwy 02C at KBNA. Screenshot 02 the aircraft levels off at 11000 feet 14.6 miles from the GHM Vortac. The speed has reached 250 knots. Screenshot 03 the glideslope bug has appeared in and st this point it looks live a good approach, however the aircraft kept decreaing altitude and I pressed the APPR button. Screenshot 04 show that the aircraft has made a 90 degree right turn and has started turning back to the left. Screenshot 05 shows the aircraft still turning to the left. At this point I aborted the flight. The significant porblem on this flight was the aircraft turning right when the APPR button was pressed. Instead of setting the MDA altitude just prior to the T/D I probable should have set it at 4000 feet, the crossing altitude of the LRETA intersection. At this intersetion the aircraft would have leveled off and the glideslope would have started down and captured at the mid range on the scale. Retards Tom Link to comment Share on other sites More sharing options...
BigJacko 5 Posted January 28, 2013 Share Posted January 28, 2013 Tom - not sure about this one, and (now that Monday is almost here again) it's unlikely I'm going to be able to fly this one in any detail, at least for a while. My initial reaction would be to ask 'which APPR button do you mean?' Are you referring to the 'Activate Approach Phase' button on the MCDU, or the APPR button on the FCU (below the VS rotary)? If you're referring to initiating the approach PHASE via the MCDU, then this loss of direction is somewhat confusing, and probably worthy of further investigation. If on the other hand, you simply pressed the APPR button on the FCU (ie to capture localiser and glideslope for the ILS landing), then several things appear relevant.You're not lined up, and appear to be at or more than 45 degrees off on your intercept course to the localiser (judging by the track in to LRETA - this would be at the far reaches of a safe/feasible localiser intercept.)You've not got a live localiser at any point in those screenshots, even though the glideslope appears to be alive. Rule is, localiser capture first, then glideslope capture from below. I don't believe it's even legal for a plane to capture glide before loc.You're far enough away, to have not got any DME distance readout from the ILS. I think what's happened is that you've pressed the APPR FCU button far, far too early, and (in shot 4) the plane is simply hunting to the right for the localiser. In shot 5, it appears to have realised it's now going away from the touchdown point, rather than to it, so has turned leftwards in the hope of regaining a live (and by that I mean 'moved off the far-edges', not just 'lit up') localiser. I think if you'd left the plane running, it's possible it might have finally got a deflection on the ILS by the time it reached abeam LRETA, though it's doubtful that it would've been able to turn towards it fast enough to keep it locked. I also have a feeling that the Aerosoft bus doesn't fully respect the 'APPR grabs loc & glide in one button-press' philosophy that the real buses do - I believe you still have to use LOC to capture localiser first, then APPR to grab the glide, on the AXE. However, even the real-world single-press APPR idea only works in the 'proper order' - localiser captured first, glideslope second (and from below only). Anything outside of those parameters can cause the plane to go a-hunting or bug out. I would recommend leaving the APPR button alone until you are certain that the loc and g/s are both visible and moving, and you're with a 45 degree angle of the localiser and below the slope. 30 degrees is my personal preferred angle of intercept, but only because it's more guaranteeable in wind. Hope this helps. Regards, Neil Link to comment Share on other sites More sharing options...
tomcjones 0 Posted January 28, 2013 Author Share Posted January 28, 2013 Neil I will try the KDFW-KBNA again tomorrow. I have just finished the flight from KDFW-KMSY, again. I set the load and fuel planner for a distance of 500 miles, the same as the other flights, with passangers and cargo the same as before. What I did different this time was setting a CI to 12. I had been setting it at 50, On this flight I crossed AWDADS at precisley 11000 feet. The aircraft leveled until the speed was down to 250 knots then the descent begain again. The glideslope bug appeared below the center of the scale so I deployed the speed brake until the bug was in the center of the acale. I then set the speed brake to arm. I pressed the APPR button (under the altitude knob) and the glideslope was captured. I then did the flaps, and landing gear routine and made a very good landing. Things are looking up but I should not have had to deploy the speed brake although this is not a big issue. Link to comment Share on other sites More sharing options...
BigJacko 5 Posted January 28, 2013 Share Posted January 28, 2013 Glad you're making headway, Tom. Speaking to my Airbus-flying First Officer buddy, it is apparently *very common* to have to deploy speed-brakes in order to maintain the vertical descent profile on approaches. This is by far a 'normal procedure', so don't feel that this is strictly a 'managed mode' shortcoming. It's really a shortcoming in the navdata that the MCDU (and thence the managed-mode) is given to work with, but this again is quite normal (loosely-speaking). As I mentioned before, most SIDs and STARs when in navdata form are built with the 'worst-case scenario' provided-for, so that all possible safety and level constraints are not broken. In real-life those constraints will be routinely altered by ATC working with the current real-life situation, and the charts therefore are (as much as anything else) provision for when radio-comms breaks down and a pilot may have to fly the chart 'on his own', so to speak. The area where the AXE is failing, imho, is the lack of a 'MORE DRAG' warning on the ECAM, which physically reminds/alerts you that you need to deploy speedbrakes. Most other Airbus sims in FSX feature this (certainly the old PSS bus for FS9 did, and I believe the FSX Wilco/Feelthere bus also has this feature). There does need to be some 'clue' given to the pilot that the vertical profile is unattainable, and in plenty of time for him to be able to take action to attain it either manually or with addition of speedbrake - otherwise this kind of 'last-minute level bust' will be frighteningly common, and result (at least) in a lot of missed approaches and go-arounds (which the AXE is not very good at handling, at the moment). For my part, I have taken to using a bit of manual speedbrake every time there's a speed-reduction called-for, in cases where there's a lot of altitude to lose in a comparatively short-ish distance. Better to be at the correct speed early, and have the plane reduce the descent-rate to compensate - whilst achieving the goal, than the reverse, which is to come in too fast, sail above the vertical goals, and arrive too high and not know till too late. There is no risk that the plane will descend too low (the waypoint constraints and your authorisation of descent levels via the FCU will see to that), but being too high too late in the run will always mean hardship and an embarrassed explanation to your passengers as to why you were another 15mins/half-hour late in landing due to the go-around! (a very good friend of mine - of around the same age as you, Tom - who was a British Airways captain all his working life, and now a member of our VA, taught me that little rule!) All the best, Neil Link to comment Share on other sites More sharing options...
Anachron13 5 Posted January 28, 2013 Share Posted January 28, 2013 I'm far from being a specialist but the leveling at 11000 feet seems to be normal to me, it's due to the 250 knots under 10 000 feet constraint. I have seen this behaviour on every automated aircraft i fly (like QW RJ or PMDG MD11). Link to comment Share on other sites More sharing options...
Emi 5161 Posted January 28, 2013 Share Posted January 28, 2013 I'm far from being a specialist but the leveling at 11000 feet seems to be normal to me, it's due to the 250 knots under 10 000 feet constraint. I have seen this behaviour on every automated aircraft i fly (like QW RJ or PMDG MD11). No, it is because there's an altitude constraint at the following waypoint. The ALT CSTR mode on the FMA clearly shows that as well as the magenta circle around the GHM VOR. Link to comment Share on other sites More sharing options...
BigJacko 5 Posted January 28, 2013 Share Posted January 28, 2013 Emi - you're quite correct. Picking up on my earlier point - about the 'MORE DRAG' callout that was missing from the AXE - I've just been chatting to my real-world Airbus FO about this. I got the positions of the callout wrong... it should appear: On the PFD, below the FMA and above the artificial horizon, andOn the MCDU scratchpad. It should not appear on the ECAM, as I had surmised incorrectly. My apologies. Will this 'MORE DRAG' call be implemented, Aerosoft? Oh - and just out of interest, and to add weight to my comment that this was 'normal' practice to receive MORE DRAG callouts quite frequently, my friend received one TODAY, on his flight back from Lisbon! These callouts are as common as muck (to use a quaint British expression) and it would be a shame (not to mention make life more difficult) if they remain absent from the otherwise excellent AXE. Regards Neil Link to comment Share on other sites More sharing options...
KyleD 1027 Posted January 28, 2013 Share Posted January 28, 2013 Will this 'MORE DRAG' call be implemented, Aerosoft? Could be soon.... Link to comment Share on other sites More sharing options...
tomcjones 0 Posted January 28, 2013 Author Share Posted January 28, 2013 Neil I have checked with my pilot friend who is retired from Eastern Airline years ago. He also confirms that deploying the speedbrakes to maintain the vertical profile is a very common practice. Tom Link to comment Share on other sites More sharing options...
kidcraig 9 Posted January 28, 2013 Share Posted January 28, 2013 Not sure why but the bus seems to fly better now in version 1.4 with regards to managed descent. Maybe it has to do with some STARS not having many restrictions? Not sure, but we're looking forward to VNAV soon! Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.