Aamir

The aircraft will, at a specified distance from the destination runway threshold - no longer engage managed descent, but instead assume a step descent to a lower level - hence the new CRZ FL message. This is an actual function of the aircraft, whether or not it is being triggered erroneously, you will need to send a support ticket in for so someone can take a look.

The rudder on the A320 is REALLY powerful so you still have effectiveness at VMCG (minimum ground effectiveness) - the purpose of this is to be able to counteract the asymetric thrust if an engine were to fail at lower speeds but high thrust output (i.e before V1, at TOGA) - the rudder is so powerful that the aircraft itself will limit allowable rudder inputs above 180knts in flight so you don't rip the tail clean off. This reduction is from 30 degrees of deflection down to around about 8 degrees if I remember correctly. Now, to give you an idea of the input you need to place to achieve this rudder limit of 8 degrees, it's about 1 inch of rudder pedal travel.. The point to all the above - the rudder is powerful, and sensitive. Treat with care and an abundance of respect. And please configure your sensitivities - we've tried to capture this facet of the airplane but it requires cooperation on your side to calibrate your hardware appropriately to this "sensitivity", by reducing your hardware sensitivity if it's uncomfortable. Feel free to use the rudder damping options to further help.

For whatever it's worth - I spent the Sunday morning going through our ticketing system since a couple of you have come up with this issue here. I found pretty much every single one of these interactions (there were quite a few!) were marked resolved as a result of 2 things: 1) Windshifts, we discussed above. 2) This is important - MSFS will happily set bindings for things and reset them here and there on updates etc. It is extremely important to check that you do NOT have a double binding anywhere - the most common example is on the numpad which a lot of people configure to use with their views. MSFS can, for example, set one of those buttons as "aileron trim left" or "elevator trim up", both of which will kick out the AP no matter what we do. The last changes we made several months ago was to set the "disconnect" threshold arbitrarily high, for people bumping their sticks etc. I believe we set it at 60% or such, of stick travel, before the AP disconnects. The issue with this MSFS binding is the moment you hit it, even for 0.1s - you will have FULL 100% input for the period of time the key is depressed. This will instantly shoot past the 60% threshold and kick your AP right off. In reality there is a locking solenoid on the stick, the force of which you need to overcome before AP kicks off, hence our solution. Don't just look at your stick controls either. Rudder can do it too. This is the most common basic cause of it, if not windshifts. I have so far not come across any unresolved instances of this besides those two issues - happy to investigate further but please make sure you are not falling afoul of these sorts of MSFS hijinks. As I said before too, happy to continue looking into a more robust but less realistic optional system, but there are some knock on considerations with the various ECAM inputs and outputs when automatic AP disconnect is inhibited, and the aircraft is expecting it to drop. Hope this helps, gotta run for the rest of my Sunday - but I will continue looking when back into the office Monday. Thanks!

I can look at adding a slightly unrealistic "AP lock" for when the windshifts cause the AP to kick out. I, and we, ultimately can't really do much about MSFS unsmoothed weather updates knocking out AP besides add this option for people. Probably worth adding as we do get quite a few customers, such as Bob above, stating it's a problem with Fenix as opposed to just the aircraft following it's Airbus design specs on when to kick out the AP and what for. The disconnect logic on our side is, and has been, relatively unchanged for several months now.

I mentioned this to you in our discord - I've not seen any reports of an authothrottle disconnect that weren't resolved by a good look at your 2024 bindings - we've had several reports and all have come back and it was binding interference. Same for AP disconnects and setting your views up on your numpad, for example.

Hey - to be clear, she is not an active staff member, and hasn't been for more than a year. We've left the staff tags on her as a nod of respect to her work early on with our EFB.

If you are on a 3XXX series card from nvidia, there is an FS2024 bug that can tick on frame gen - this will absolutely nuke your performance. Seen some people report this.

GSX is causing crashing right now if you have any jetway exclusions. Make sure to disable all of them - for whatever reason disable is on the right, not the left, so double check this. Apply and try to reload, GSX should stop crashing your sim.

Well, you're essentially describing a fly by wire aircraft. Inherently when the stick is returned to center it should not roll further at all - if it does so, it loses precision and is generally considered a relatively failed design. In a crosswind, etc, you absolutely do not want the airplane trying to smooth your inputs, not when you're trying to decrab and align, etc, just for "feel of inertial" - The difference here is that the Airbus stick is a heavily damped unit in reality. Your return to center from your desktop joystick to a real Airbus sidestick is probably "lighter" by a factor of 10, if not more. However, we cannot slow down your return to center artificially, nor rate limit it - as we cannot decipher whether it is a return to center, or left through right. The rate limits of the roll channel at 15 degrees/s are respected regardless of course, but you can get to it, and out of it, very quickly with a lighter joystick - so what is the solution? Well, a good calibration would go a long way to begin with - going to the sensitivity menu and starting to adjust things like reactivity to your liking - and similarly with the actual input curves, we have basic recommendations as a starting point on our knowledge base - but they are simply a starting point - you need to adjust to your liking and add and remove weight as you see fit by modulating the curve. It will also add "inertia" in the sense your return to center will take longer, so there is an emulation of damping if you're able to mix reactivity and sensitivty curves. It would be specific to your hardware and your own taste - something we unfortunately accomodate (the hardware that is - there are 10s of thousands of combinations here..) - all we can do on our side is to make absolutely sure the fly by wire does what it is expected to do per it's design - as any filtering we add with naturally turn things out of sync on other joysticks. Things like SDS etc are present in options to also help with this. Re flare - yes, that is exactly again the system working as intended and as designed. Your flare "weighting" is dynamic, the nose down input is "dynamic", and based on the actual mathematics that utilise your pitch angle through 50ft as a significant input - more pitch means, in laymans terms, you're gonna feel like you need to apply more backstick, and with less pitch, you feel like you need to apply less. As it would be in a conventional aircraft in a sense, but here we and Airbus are adding the impetus. If you are destabilised in this area you're going to have an issue unless you're familiar enough with the aircraft that you are in sync with it's attitude coming in and how much backstick to expect to need based on where you were at, at 50ft. Generally, it works out in reality because the pitch attitude at 50ft is not going to be far from the expected design norms where in sim.. well, as you approach at the wrong angle, it's gonna bite if you're not used to it. https://fenixsim.com/blog/entries/2024-11-05_its_shark_week/ And yes, we continue to work on it. It has been promised, it will be delivered.

Final numbers arrive on paper, then they arrive via ACARS - the ACARS might turn up a little late, so can be during the taxi out. The ADC is an automated system - so it is relatively dispassionate on when it turns up. With that being said though, it seems reasonably non invasive, no aural alert, a small notice on the ECAM about a message, and that's pretty much it.

If you need to lift MZFW a long way, that's what the ACTs are for - so perhaps not necessarily max range missions, but extending it's operational range with a big payload. A hefty chunk of AA 321s are packin dual ACTs - at least every single one we've opted to paint - and JetBlue run them too - this way they can run JFK-SFO, BOS-LAX, type trips without compromising on payload. Just my understanding on it anyway - the airlines and their decisions escape my own logic sometimes.

Yep - things like final loadsheet arriving on the taxi-out, etc is quite common also.

Huh? This may be the case at your operator but the Airbus operator we referenced for this absolutely get ADC every single leg - they aren't from crew scheduling.

Pretty much the same question for you - what specs are you running?

Weird, you already have the fix - it rolled out a couple of updates ago and we've got really positive feedback from quite a few people that it resolved their oscillation issues. If you're still having oscillation issues, I'm not entirely sure where to go from here. Could you share your computer specs with me please?