richboy2307

Your suggestion is noted, thanks!

Hi @Bazz So it shouldn't ignore your constraints in a managed descent (DES). It would however ignore them in an Open Descent (OP DES). Normally you would see on the bottom right of your PFD, the target ALT, same as set on your FCU in blue colour. If it is limited by any constraint, it would show up in Purple with the ALT of that constraint. So when you are noticing this issue, could you please provide a screenshot of your PFD,ND, FCU and also the MCDU (FPLN Page)? Could you share the full route that you tried? Also a screenshot of your INIT A/B pages or list the values used. I have just tried with a couple of randomly generated dispatches via simbrief and not exactly seeing your calcs. Here's an example: From this, I can see for YBCG RNAV-W RWY 14, the following computed path: Do note that VAPMU is programmed in this procedure as 2500ft or above alt constraint by the navdatabase itself, and we cannot control that. So given this restriction, it has computed the path (within margin of error) whilst still abiding by the constraints. I am not able to reproduce the erroneous path currently, but would love to try with the data you are using to see if we can reproduce the problem, and thereby improve on it. Thanks!

For our aircraft (e.g. A300/A350) we probably could theoretically, but obviously no for Microsoft products like the A310/320neo. Thanks!

Hi @Kevin B There is an update currently under testing that includes performance and stability fixes. Please try with that once available and let us know about your performance then. Thanks!

Hi @DanDan87 / @Airbuskid87 Can you check if you have Aircraft Light assists set to OFF? (Options > Assistance Options > Aircraft Systems) Do note, after setting it to OFF, you will need to restart the flight for changes to take effect.

Hi @Shanks16 Thanks for the data. We do have performance metrics internally as well, which we gather from tests across different tiers of systems as part of the optimization process but never hurts to have have more data for analysis. Shared with the team. Also would appreciate if you could run the same test on the upcoming A300 update once it is available. There are some performance and stability improvements coming in that, so would be curious to see the difference on your system compared to the current data. Thanks!

Hi @LeeH No, we do not have any more liveries planned for the moment. Thanks!

Hi @Thompson Thanks for the suggestions. 1) Navigraph Charts - As this is a Microsoft Product, that decision ultimately rests with them. As much as you or we would love to, in the end such integrations with 3rd-party, non-default services have to be wanted and approved by them in their product. 2) In-Game ATC integration - your suggestion is noted and shared with the team. Thanks!

Hi @MitchellAA300 We just checked on our end and are not able to reproduce such issues with lighting. The lights will generally disappear at certain zoom levels (as this is part of LOD optimization for performance reasons), but they remain on in external views at the right zoom level. Also stairs are only available on cargo variants. Are you not able to see them via the EFB on the cargo aircraft?

I'm afraid you're on your own with that as that is copyrighted and protected material that we cannot share whole. However, google is your friend 😉

Thanks, reported.

Hi @kekki Please English only on these forums. And no you shouldn't need to restart the plane after every flight. What is the issue you are facing?

Hi @BrownCow069, Good catch. The 'Actual N1%' needle (green arrow) is correct, and at max reverse ~45% N1 is expected. However what appears to be wrong here is the 'Thrust Lever Angle (TLA) Position / N1% Command' needle (red arrow), so will log that as a bug. Thanks!

Thanks for confirming my statement. It "updates" with some "ILS data" every time you select a procedure. The 'phase of flight' determines whether that "ILS data" should be read from Departure Airport or Arrival Airport files. But if you continue further to read the third paragraph, you'd notice: In other words, when you select a procedure, the MCDU is calling on a default MSFS function that pulls the "ILS data" from an airport. The "ILS data" it pulls, is as defined by: the scenery itself (default or add-on) OR some other scenery files (as added by Navigraph or other navdata addons).* *The priority of the load order between both of the above is also not something the a320neo can control. There is no independent nav-database that the airplane is calling upon (e.g. in addons such as Fenix or PMDG which you can update via Navigraph Hub). So the "fix" to this issue is to ensure the scenery data and additional navdata is not in conflict, and appropriately taking precedence. Hope that helps you to better understand the issue. Thanks!

Ah, sorry I misunderstood your request. But that should be an easy fix. Bug logged, thanks!

Hi @Hungrypilot We currently have it tuned per IRL data for the A306. The BRAKE FANs exist for this reason, and are important equipment on this plane (unless you got time to wait for your brakes to cool). Generally, the slower you are, the less energy there is to lose using brakes, and the less heat will be generated as a result. In short, more flap, more reverser, less brake. Turn on brake fans as soon as you vacate. Do note that even with them ON, the brakes will continue to heat up as they try to dissipate the energy stored in them, and eventually they will reach equilibrium and the fans will start taking effect. Thanks!

Hi @PotatoSalad Ensure you are on the latest version of the the iniManager (2.3.7). On launch of the iniManager, it should automatically download the latest version of the 'scenery_config.json' file that rectifies the issue. In case you are still not able to see the options, please re-install the scenery. Thanks!

Hi @JoeDel To intercept an ILS, you need to: Fly on an intercept heading/course towards the LOC, and Capture and establish on the LOC before you can capture the GS Capture the GS at an altitude below the GS If you are already above the GS, the AP may still capture the LOC, but will not initiate a descent to capture the GS. The airplane will also not follow the GS until you are established on the LOC first. From your screenshot, I can see LAND is selected on the FCU, and G/S & LOC are properly armed (in blue) as the next modes for the autopilot to capture. However, from the ILS raw data, I can see that the LOC is to your right, and the GS is already below you. From the current position, you'd need to fly further to the right to intercept the LOC, and initiate a descent to a lower altitude (e.g. 1500ft) using VS mode (at -1000 fpm or as necessary) to get below the GS to intercept it. There are plenty of video tutorials available on youtube regarding this, but here is a Computer Based Training (CBT) for a standard ILS approach: https://youtu.be/bS_tLfKDak4?t=587 Hope it helps, thanks!

Hi @samj Other than conflicting/noisy control inputs, other things that can upset the autopilot include excessive turbulence or abrupt wind/weather changes (e.g. when the sim does a weather update). One way to ensure that this isn't what is happening here is to try a flight with the 'Clear Weather' preset, and see if you still notice the issue. The other thing is to also check that AI Assists (e.g. Auto Yoke and Auto Trim) are disabled. Those can also cause issues with the Autopilot. Thanks!

Seen your report on discord and noted, thanks!

Can y'all confirm you've enabled the correct radios from the ACP? See:

Hi @Nighthwk Thanks this is known and will be sorted in next update.

Hi @Airbuskid87 As reported by @DanDan87 on discord, this issue appears to be related to anti-aliasing settings. Perhaps try to change your settings and see if the issue is resolved. Thanks!

Hi @KirkJohn The ND does not display the top of descent arrow when HDG (or TRACK) mode is engaged. So you have to be in Managed (NAV) mode following your flight plan. There could also be additional reasons such as not having reached your CRZ alt, as well as having already passed it. Could you please share the route you were flying (e.g. EGGW/25 N0371F180 OLNE2B OLNEY T420 TNT N57 DENBY DCT LBA DCT EGNM/32) as seen on simbrief in the 'Route' section of the dispatch? Thanks!

Hi @geckuz Thanks for your post. Unfortunately this is not correct, and a misconception derived from an old version of FCOM. Such a limitation was only applicable to very early variants of the A320ceo. The A320neo meanwhile is a different beast altogether when it comes to Flexible Thrust takeoffs when compared to any variant of the A320ceo. The A320neo engines generally have more FLEX by comparison. Here is a real world example of an A320neo where the FLEX N1% target (~79%) is lower than the CLB one (~83%). https://youtu.be/cv41hm4JEB8?t=157 And also for A321ceo where the FLEX N1% target (~85%) is lower than the CLB one (~87%). https://youtu.be/LGeegwNsKwU?si=Iir3j35AKEqxTQxt&t=1120 We are looking into improvements for calculations at high altitudes in a future update, but generally, performance calculations are a complex subject with a lot of variables at play. The takeoff speeds are optimised for maximum flex for the given restriction, meaning on a dry runway 50ft elevation at the end of it, and 35ft for a wet one. The EFB's computed performance is aiming to FLEX as much as possible while giving as much climb gradient for the 2nd segment which is often why you see 2nd segment limited message, and it will try to use up as much runway as it can if it means it can flex the engines more. Thanks!