u/WheelPrestigious

Imagine a routine XPDR/TCAS SYS change on the A350.

The FO switches from SURV SYS 1 to SYS 2 in accordance with the SOP, to keep the system aligned with the PF. Normally, it is just a routine action that takes a few seconds.

But if the AESU happens to be performing its periodic Mode C / Mode S transponder Loop Around test at the same time, things can become unnecessarily complicated. Add ATC or surrounding TCAS interrogations into the mix, and suddenly:

SURV XPDR 1(2) FAULT

What started as a simple SYS change is no longer quite so simple.

CBs are being monitored, the weather radar is being watched, coordination with ATC is ongoing, and now a few more questions appear: Is the XPDR actually faulty? Has TCAS been affected? Should we switch to the other SYS? Does the AESU need a reset?

There is no dramatic beginning here. It is simply a routine switch and a system test overlapping at exactly the wrong moment.

And without really doing anything unusual, we have suddenly created some extra workload for ourselves.

One important detail comes next: the first instinct — “let’s switch to the other SURV SYS” — is not the right action in this case.

I’ve been looking at an A350 HF failure scenario close to a westbound NAT HLA entry and wanted to hear how people would think about it operationally.

Let’s say the HF won’t tune properly in VOICE or DATA. You try a different HF frequency as recommended, but it still won’t transmit or receive. VHF and SATCOM/CPDLC are still available.

If this happens before the Shanwick oceanic entry point, would you be comfortable continuing into NAT HLA, or would you first treat it as an HF relief / entry eligibility issue with Shanwick?

And would your thinking change if the exact same failure happened just after oceanic entry?

Curious how you’d draw that line.

I’ve always made it a habit to preset my target heading on the FCU before pulling the knob. Recently came across the write-up for the "NOT COMMANDED TURN AT HDG/TRACK MODE ENGAGEMENT" bug, and it made total sense why that habit pays off.

If you pull without presetting, the PRIM briefly uses the old stored heading value. If your new target happens to be 180 degrees off, the system glitches—it starts a 180-degree turn, and as the memory updates a split second later, it turns into a full 360-degree orbit. Presetting first completely avoids this.

Curious about your daily technique—do you guys always preset first out of habit, or do you just pull and turn?

Hi everyone,

I’m curious if any A350 pilots have experienced this in line operations.

During an ILS approach, everything initially appears normal:

• LOC captures normally.
• However, the G/S deviation is not displayed on one or both PFDs.
• The G/S mode remains armed but never captures.
• There are no ECAM messages and no dispatch message indicating a problem.

According to Airbus documentation, this can be caused by a specific internal failure of one or both MMR units.

The operational recommendation is fairly straightforward:

• If the glideslope deviation is missing on only one PFD, disconnect the affected side’s autopilot.
• If the glideslope deviation is missing on both PFDs, discontinue the ILS approach and revert to another type of approach.

I’m not really looking for troubleshooting advice—I was wondering whether anyone has actually seen this happen in service.

• Was it discovered only after LOC capture?
• Did you continue manually for situational awareness before going around or changing the approach?
• How did maintenance eventually identify the MMR issue?

It seems like one of those rare situations where nothing appears wrong from an alerting perspective, yet the ILS is no longer behaving as expected.

I’d be interested to hear if anyone has experienced this firsthand, especially on the A350, or if you’ve encountered something similar on other Airbus types.

Hey everyone,
I’ve been diving into some technical documentation regarding a very specific FMS behavior on the A330, and it’s one of those "hidden" traps that could really ruin your day if it happens mid-flight.
Basically, there’s a known scenario where a Dual FMS Reset (leading to a total loss of the active flight plan) can occur, but it requires a very specific "perfect storm" of conditions:

1. The Temperature Rule: All 4 cruise temperatures for a waypoint must be defined at altitudes strictly above the Tropopause.
2. The Location: The waypoint must be on the cruise segment of the Active flight plan.
3. The "Random" Variable: There needs to be some specific garbage data present on a local variable stack.
   Because of that third condition, it’s not something that happens every time the first two are met, which makes it incredibly frustrating to troubleshoot.
   The technical "workaround" is simple: Don't input 4 cruise temperatures. If you keep it to 3 or fewer on the CRZ TEMP page, the reset condition is mathematically impossible to trigger.
   I’m curious—has anyone here actually experienced this firsthand, or heard of it happening in their fleet? Especially on those high-latitude polar routes where you're flying deep in the stratosphere and the Tropopause is naturally low?
   It seems like one of those things that becomes a non-issue as long as you're aware of it, but I'd love to hear some real-world operational experiences or if any of you have been briefed on this by your training departments.