737NG Radio Altimeter/Autothrottle/Autopilot Interface
 

I've started this thread to discuss only the technical aspects of the 737NG radio altimeter, autothrottle and autopilot interaction and operation. This is due to the Turkish Crash thread and BOAC's request since that thread is quite large.

So, to start off, I wanted to provide some results of some simulation tests I performed on an actual 737-800.

Please note: I could not simulate engines running and all of the actual precise conditions (reactions) of a flight, but what I did note may be of interest to you. In no way am I saying for 100% that this is the way the aircraft is supposed to behave or will behave as I am not Boeing and only the official confirmation of how the aircraft should operate can come from Boeing. I am just noting my observations. :8

Simulation parameters:

A. Aircraft in AIR mode.
B. #1 Radio Altimeter reading -4 feet (on ground)
C. Radio Altimeter reading 1950 feet (test box input)
D. Altitude (barometric) reading 2000 feet.
E. Airspeed reading varied on where I had flaps set, but initially above alpha.
F. On LOC and G/S (APP mode)
G. Autopilot running latest Honeywell FCC OPS (-10)
H. -4 Smiths Autothrottle Computer installed

I was able to verify that the Autothrottle went to flare retard mode while the autopilot maintained the glideslope. I decreased the airspeed and the Alpha warning in the MCP speed window started to flash (A in front of speed). The airspeed amber box appeared and also flashed initially as it is supposed to on both PFD's. The autopilot still tried to maintain the glideslope.

I continued to decrease the airspeed and simulated below glideslope. When I finally got the stick shaker, the autopilot did NOT disengage; it actually still tried to maintain the glideslope. The autothrottle remained in flare retard. After at least 10 seconds the autopilot did disengage, but I do not know the reason (could be pitch trim time limit or no reaction since I still had below the glideslope emitting from the test box).

Next, I started over and failed the #1 Radio Altimeter by pulling the circuit breaker. Now, the autothrottle did NOT go into flare retard. I first believed that this confirmed my suspicion that the autothrottle switched to the #2 radio altimeter. However, when I lowered the #2 radio altimeter to -4 feet, the autothrottle remained in MCP SPEED. I believe this confirms that the autothrottle in fact only does use the #1 radio altimeter for mode changes. Note that with that #1 radio altimeter or both radio altimeters inoperative (circuit breakers pulled), the autothrottle would still engage and remain in MCP SPEED.

In the Turkish crash thread, I had posted that the AMM notes that there is an engage/disengage condition which is "no stick shaker present". This would lead a person to believe that the autopilot will disengage when the stick shaker is active. But, as noted above, CMD B remained engaged and tried to maintain glideslope for at least 10 seconds of stick shaker (in the last test I simulated above and below for the glideslope and the yoke pitched up and down accordingly to the glideslope indications).

Also, some other observations:

A. Autothrottle would not go to flare retard when G/S not captured (this confirms AMM description).

B. When loosing glideslope and localizer signals (turned tester off), F/D remained in LOC and G/S and autothrottle would remain in flare retard.

C. I did not see any nose down trim (speed trim) with the autopilot disengaged and stick shaker active.

D. Once again, TOGA saves the day! Pressing TOGA cancelled flare retard.

The one test I was not able to perform due to time and constraints was a dual channel test simulating a radio altimeter going to ground. I have previously believed that the autopilot would drop out of dual channel if the radio altitudes were not the same. However, I am not so sure of that now based on some other information I am digging into.

Good info, thanks. You might clarify parameters B and C. Did you force the #1 radalt to -4 by disconnecting the test box, or was it there the whole time?

Regardless, your test confirmed what I posted on the Turkish thread: you are better off pulling the CB than staring at erroneous data. The airplane is equipped to handle failures better than errors. In that thread I was also amazed there would be supposed professional pilots who are afraid to pull clearly labeled circuit breakers in flight.

GB

yep .. very good info ...

so a couple of questions.

The fault on RA # 1 was apparently noted on several occasions prior to the accident flight, I am not aware as to whether it was written up or not ( and I am not going back onto the other thread to find out ! )

IF it were written up, what is the engineering procedure and the operator procedure from the MEL ?

My guess is that the CB for RA#1 would be pulled and collared ?

TR

earlier RA faults and non-reporting?
 

[Retired software engineer, no piloting skills.]

It is probably worth reconsidering posting #1544 (permalink) on the original thread. In which cargun stated that:

... back as in September 2007, I read in local forums that THY 737 pilots were complaining about negative left RA readings. They were told and believed this to be harmless and explained with "yet another cell phone activated". Due to such a repetitive error, resolved with a stupid explication, crew may have ceased to report this "harmless error". That might be the reason the previous errors are there on the FDR, yet not on the airplane's maintenance log book.

From Bulfer:

With a RA inop, do not use associated Flight Control Computer for appr or landing, and do not use associated A/P for appr.
If No1RA system is inop, A/P A should not be used for appr- A/T automatic retard during landing flare is inop.
If No2RA system is inop, A/P B should not be used for appr.

(reason is No2RA controls Flare program- No1RA does not control Flare. They act totally independently- as you would want!). This should be standard knowledge. So no great discovery! I think most pilots would remove a RA display that was indicating a false figure. I would expect a display indicating -7' would be amber and would be removed by most pilots- with time available. As for 2000' on final approach? Not a time to be messing about with the CB panel!

Good info, 737AvEng!

I suppose you're an engineer, not a pilot. Were you (or any pilot nearby) able to recover for a stall at 500' with all that back trim? Yes, I know SOP implies trimming as part of the stall recovery procedure, but you have to know that. Not much time to look it up...

Interesting data.Thanks

Not a Sudden Event
 

Radio altimeter indications rarely go to 0', valid, on the approach at 2000' or whatever arbitrary altitude.

As the ground return signal diminishes on aircraft climbout, and if there is a strong enough leakage path, the indication will drop back to -8 or so, instead of indicating correct altitude, and will remain at -8 the entire flight until the ground return is strong enough again on the approach. The crossover from correct to incorrect indication can be at any altitude up to about 5,000 feet, depending on strength of leakage path, and altitude gain programming of the radalt receiver.

There should be plenty of time to pull a CB during cruise. Not knowing the downstream effects of a false indication of radio altitude will lull a crew to ignore the false indication rather than kill it. Moreover, if the radalt indication has shown on prior flights to start being correct again at 500' or 300' or whatever, on the approach, maybe the crews preferred that.

At any rate, belly corrosion needs to be addressed, and some, if not most, maintenance organizations need training on radio altimeter troubleshooting and corrective actions.

GB

The RA only indicates below 2500' AGL. Above that you have no indication and no scale. I don't know if they had a false indication above that. It would leave you minimal time to troubleshoot.

Were the pilot's arms broke? Was their vision impaired? Were they retarded?

It's very difficult to troubleshoot a problem that is not in the logbook. It's also usually frowned upon when you start taking apart serviceable airplanes in scheduled service.
If these pilots were so concerned about the previous rad alt problems, they should have documented the faults in the logbook. At that point, it would require someone to take some action that would have to be documented. Everything would be very clear then.
It's actually amazing how much troubleshooting on rad alts can be done with the aircraft on the ground.
I would personally prefer that pilots not troubleshoot faults during the approach. It's obviously a critical time which requires the pilots undivided attention. Systems like A/Ps and A/Ts only require monitoring during the approach phase. There are switches on the MCP that turn off systems that are not functioning correctly. No need to search for circuit breakers. After the aircraft lands, any faults can be written up in the logbook.

When the signal leakage path leads a radalt to believe the plane is at -8 feet, it will do that at all altitudes above the signal strength crossover altitude. Yes, it will indicate -8 feet at cruise, and all altitudes above signal crossover.

Sounds like the THY pilots were convinced by MX that the cause of the erroneous altitude indication was EMI from laptops or something. In that case, they would cease writing it up, as reportedly happened a couple of years ago.

I would like one of you experts to point out the radalt on/off switch on the MCP.

AAL had a radalt indicator on/off switch on their DC10-10, to reduce indicator failures, but the radalt transceiver was still alive and feeding the other systems.

No, a radalt error is not easy to troubleshoot on the ground, as it will indicate perfectly with such strong ground return. There are ways, however...

GB

Unless the rad alt problem was fleetwide, I don't see how anyone could be convinced not to write it up. It only takes a minute. Let any engineer sign it off by a statement like 'the problem is cause by a laptop or something.' Now it is documented. I knowthat there are a few who may try to do that but many more will either placard the system inop or troubleshoot if time permits.
There are 3 main components in the system. 2 antennae and an R/T. Replacing an antenna will be the perfect time to check for corrosion. If these fail to cure the fault, the cables can be looked at. Most of the modern aircraft now do not have independent indicators but are displayed as part of the EFIS system.
There are no switches for the rad alt. My comments referred to the A/T and A/P. The rad alt primary function is to supply information to those systems. Pilots are not just flying by the rad alt. They fly by the A/P and A/T. When these systems do not respond correctly, they can be turned off.
Pilots need to monitor the aircraft performance as well as system operation at all times and not focus on one item. In this case it seems that they didn't focus on anything.
The A/P and A/T monitor rad alt information. They are looking for specific altitude data. As the data received was not flagged as faulty, these systems unfortunately responded in a correct manner. If the aircraft was monitored correctly, we would not be discussing this at all.

737 - apologies for missing your PM yesterday and indeed thanks for getting this going - very useful info.

Just to clarify RB's - which is confusing! As I understand it, BOTH RAs are needed for the FLARE to be active. The bar on use of A/P with FAILED RA is because of the lack of RA control smoothing at the very least and possibly also some 'other buried' F/D- A/P functions are missing too

Personally I doubt any pilot would attempt to "remove a RA display that was indicating a false figure" but in the time-honoured RAF fashion would probably hang their flying glove over it (ie ignore it:)).

I come back to the comment I made on R&N (no doubt 'usefully' modded out of existence:mad:) that we need to expand the training input on RA functions for starters so that more crews are aware of the implications of the involvement of the RA in the approach modes, and as I also said I'm sure B will be looking at some sort of comparator.

As I mentioned elsewhere ( I note 'Safety Concerns' has declined my inviation to discuss:hmm:) unless there is a non-volatile interrogatable ROM, the likelihood (NB - no criticism of LAEs here!) is that a reported 'blippette' of RA mis-read would be bite checked and 'PRF' ('Please report further')? That is another mini-campaign I have failed on, namely getting 'PRF' into a more formal Tech Log entry so it was easily visible to successive crews rather than relying on trawling back when 'time available' onto faded copy sheets in the log.

Your efforts on the A/P disconnect confirm my belief that it does not 'disconnect' at the stick shake but probably as you said,at a trim limit as I think happened to the BA 777 at LHR..

Thanks for your efforts.

It was there the whole time. I had only one radio altimeter test box, so I could not control both radio altimeters at the same time using different altitudes.

Here is the official wording straight from the Boeing 737 DDG (non-customized) for the -600/-700/-800/-900 Radio Altimeter MEL:

MAINTENANCE (M)

Do these steps (AMM 34-00-00/901):

Open and collar associated P6-1/P18-1 panel Radio Altimeter circuit breaker to deactivate the inoperative radio altimeter.

For airplanes without FCC Operational Program Software (OPS) 2212-HNP-03B-05 or later installed, re-initialize the Flight Control Computer (FCC) associated with the inoperative radio altimeter by momentarily opening and then closing the applicable P6-2/P18-1 panel FCC circuit breaker.

NOTE: Rockwell Collins FCC Operational Program Software (OPS) part numbers are considered to be equivalent to Honeywell FCC OPS part number 2212-HNP-03B-05 and later.

Refer to MMEL Item 32-17. An invalid radio altimeter signal will generate a dispatchable PSEU fault.


OPERATIONS (O)

NOTE: For airplanes with -1, -2, or -3 SMYD, an invalid signal from radio altimeter number 1 will result in failure of both stick shakers to self test.

1. Ensure that weather minimums or operating procedures are not dependent upon its use.

2. With radio altimeter(s) inoperative, do not use the associated autopilot or autothrottle for approach and landing.

3. For airplanes with FCC Operational Program Software (OPS) 2212-HNP-03B-05 or later installed, if the remaining radio altimeter fails:

NOTE: Rockwell Collins FCC Operational Program Software (OPS) part numbers are considered to be equivalent to Honeywell FCC OPS part number 2212-HNP-03B-05 and later.4. For airplanes without FCC Operational Program Software (OPS) 2212-HNP-03B-05 or later installed, dispatch with an inoperative radio altimeter:

NOTE: Rockwell Collins FCC Operational Program Software (OPS) part numbers are considered to be equivalent to Honeywell FCC OPS part number 2212-HNP-03B-05 and later.There definitely needs to be clarification on this subject. When entering dual channel operation, the first FCC to be engaged becomes the master. If it is the right, I am assuming that the right radio altitude will be used for flare. If it is the left, then I would assume the left radio altitude is used. I can not say with 100% confidence that an erroneous radio altitude will cause the autopilot to drop out of dual channel.

Boeing's philosophy from the best of my knowledge has always been to compare external systems only when there are 3 or more installed. In certain systems on the 737NG, if the left radio altitude fails, the system will switch to using the right. However, it appears that the autothrottle is not one of those systems (even though it is receiving right radio altitude).

ASFKAP

Quote:
Let any engineer sign it off by a statement like 'the problem is cause by a laptop or something.
No engineer in their right mind would sign off a defective Rad Alt like this without something written in black and white (like a Boeing service letter or Airbus TFU etc) telling him that a faulty Rad Alt might be caused by this)

Let me clarify what I wrote. I was suggesting the crew write the problem in the logbook. This way, an engineer has to commit to put something in writing. He is going to think twice about writing nonsense.

This has not been my experience. Perhaps this is an aircraft type/manufacturer thing? I haven't changed a Rad Alt box for 20 years, but have had lots of bonding problems with antennae.
Some aircraft rely on bonding through the screws (and countersunk holes on the antenna). The mating surface of the antenna and the fuselage don't always provide a good bonding surface, especially if the corrosion inhibitor is forming a barrier.
We started to find some of the countersunk, metal surfaced holes on the antenna painted over with white paint (not sure if this is ex-manufacturer or ex-workshop). This was creating lots of problems with bonding.

Rgds.
NSEU

Bobcat4...
In case you haven't already guessed, the tests were run using a real aircraft (on the ground) ;) This was not in a simulator

NSEU

Wow! I thought it was in the sim. :)

Well, that would make my question very silly... :ouch:

Pulling CBs in flight
 

Graybeard,

Your advice about pulling CBs in flight to remove erroneous displays would seem to be counter to much of the current operating wisdom.

737AvEng provides some insight into the dangers of pulling CBs when not required by the QRH - you are embarking on a voyage of discovery about what systems are dependent upon the radalt signal and what systems share the CB as a power source. The DDG gives a big hint - there are specific AMM procedures to be followed to allow despatch with a disabled RadAlt which, even if you knew what they were and understood what they achieved, on most occasions cannot be achieved in flight because you cannot access the equipment bays. The associated Ops procedures are meaningless if the maintenance procedures have not been completed.

While your nom de plume indicates that you have been around for a while, your advice lacks the necessary gap between old and bold - there are a few of us in our career twilight who have learnt that CBs are no longer simple on/off switches....

Stay Alive