martinboehme

The deadzone in the MCDU is for the thrust lever detents. The deadzone in the MSFS control sensitivities is for aileron, elevator, and rudder.

What was your weight and ISA deviation? I'm going off the tables here: https://www.air-septimanie.com/pdf/technical/A320/en/A320PERFORMANCE.pdf Based on those, at FL 320 and ISA, a Mach. 78 cruise gives a fuel flow of 5,100 pounds per hour (both engines) at 120,000 lbs. That's relatively light - but maybe you were doing a short sector and weren't fully loaded? Getting the fuel consumption right was a big focus of the external engine model, so I would expect they have done extensive validation on this.

Sorry to hear that. In any case, the flight model should be set to "Modern" -- this is the setting that the PMDG was designed for, anything else will give unexpected behavior.

I believe so. The Getting Started guide in the knowledge base lists updating Navigraph navdata as one of the steps to perform before starting up the sim.

I'm seeing various lvars that do look like they're exactly what you would need to drive a FCU display (i.e. what FenixQuartz was required for so far). These appear to come in pairs that tell you whether a given parameter is managed and selected, and what the selected parameter is. I_FCU_SPEED_MANAGED N_FCU_SPEED I_FCU_HEADING_MANAGED N_FCU_HEADING (In TRK/FPA mode, N_FCU_HEADING is the selected track.) I_FCU_ALTITUDE_MANAGED N_FCU_ALTITUDE N_FCU_VS (In TRK/FPA mode, N_FCU_VS is the flight path angle times 1000 -- so an FPA of +2.5, for example, would correspond to 2500.) This is the only parameter for which I can't find a corresponding "MANAGED" variable. Maybe this is because there is no concept of "managed vertical speed" -- but one would still need to know whether to display dashes in the vertical speed window, and I'm not sure how one would determine this. Maybe I just haven't found the right variable, maybe this is an oversight by the developers. In any case, this is looking pretty good for being able to drive displays on a hardware FCU without FenixQuartz. Edit: It looks as if the I_FCU variables already existed prior to B2, as there are existing entries for them on HubHop. The N_FCU variables appear to be new; I just added them to HubHop.

Lots of people here are focusing on the flight controls, but I can't see how these would cause the gross differences in behavior that you're observing compared to what other people are reporting. I do think though that there could be something in your sim settings that could be affecting the PMDG's behavior in the flare. Just a stab in the dark: Can you confirm that your flight model (in Settings / General Options / Flight Model) is set to "Modern", not "Legacy"?

I found this tidbit in the changelog: This sounds to me as if at least some of the hardware support (in accordance with their new agreement with ProSim) has already made it into B2. Can anyone confirm this? Doing a flight right now that I want to complete first, but after that I'll go searching around in the lvars. If this means FenixQuartz is no longer needed... that would be great! Edit: Just found this in the Knowledge Base: https://kb.fenixsim.com/example-of-how-to-use-lvars Does anyone know if this is new or if it already existed before B2? It doesn't talk about outputs to the sim (e.g. the FCU displays) -- but in any case, I'll be doing some digging later on.

IIUC, the app won't prompt you (yet) - you need to download from the website: See the quote in the first post:

That would be McDonnell Douglas. 😉 (DC-10)

Typical. Was about to depart on a farewell flight with the B1, now my fuel burn will be inaccurate. When will they get their act together! 😉

My understanding is this won't be in B2, as the discussions with ProSim happened only very recently and there wasn't time to get it into B2.

Yes. If anything, airfields are easier to pick out in the sim than in real life. One thing that can help when going into an unfamiliar airfield is not to try and enter the pattern directly but to first overfly the field well above pattern altitude. That will give you an idea of how the airfield fits into the surrounding scenery and help establish your bearings.

You'd use LOC if you've been instructed to join the localizer but not cleared for the ILS approach (probably the most common case these days) or when flying a localizer back course or localizer-only approach (though these are increasingly rare given the prevalence of RNP approaches). Edit: What @Fiorentoni said!

You decide how you want to sim - there is no right or wrong. The only thing I would say is that if you're on PilotEdge or VATSIM, you should be able to follow instructions competently so you don't spoil things for the controllers and other pilots. If you want to ease into it by using a GPS, I don't see anything wrong with that, as long as you can do what you're expected to do. Obviously, in the real world, VFR pilots are expected to be able to navigate without GPS, but this isn't the real world. That said, learning pilotage and dead reckoning is fun, and it's not harder than what you've been doing - just different and a skill set that you haven't exercised much, so of course you're not as good at it yet. Dive in, learn, and enjoy the process!

Most airlines encourage pilots to hand-fly if the situation (workload, weather) allows. Pilots need to be able to hand-fly, and if you don't practice, the skill atrophies. Of course the airplane doesn't balloon if the autopilot is holding altitude, but that's not what the OP was asking - they wanted to know whether and to what degree the FBW corrects for the balloon effect when hand-flying. My understanding is that, despite the FBW, the A320 does balloon on flap selection if the pilot doesn't correct for it. See this discussion on PPRuNe: https://www.pprune.org/archive/index.php/t-253852.html

That's my understanding too.

Speech recognition and speech synthesis uses AI. The underlying ATC engine is coded.

Have you listened to the offline voice samples (examples)? Yes, the premium voice include more "human" hesitations and a greater variety of accents, but the offline voices sound perfectly acceptable to me, on par with other non-cloud-based ATC addons.

It doesn't cost transmission time if you're using offline voices though?

Oh, it wasn't in vain. Lots of people got off on the chance to butt each other's heads in, which is, after all, the whole point of this forum. At least you'd think that some days.

The big advantage, speaking from what I've seen in X-Plane, is that you don't have to download and install airports individually - it's all just there and updated regularly.

Agree - it's unfortunate that they don't allow this. I hope they open up this capability at some point. In X-Plane, it's amazing how much of the character of an airport some gateway contributors are able to recreate with just default objects. I was an active contributor for a while, and it's a satisfying challenge too - working out creative ways to get as close as possible to the look of the airport with just the default objects.

You can search ASRS for "dual FMGC failure" - I find 21 reports. (You don't need the IRSs to fail additionally - without the FMGC, how would you perform RNAV navigation?)

You can navigate though - you just can't have the autopilot automatically follow the radial. Lots of systems failures cause an increase in workload, and as things go, this one isn't terrible. I'll readily admit, I had exactly the same reaction you did when I flew an Airbus in the aim for the first time and learned it can't track VORs. It seemed so weird - you're telling me it can't do this basic thing? Realistically, though, it's not often an issue in practice.

What does the fact that they're based in Germany have to do with whether they are reputable or not? If it doesn't have anything to do with it, why mention it?