Educational familiarization only. This TechOpsBase resource is an original learning transformation grounded in a privately supplied B737 MAX ATA 34 source. It does not reproduce manufacturer task steps, limits, figures or controlled maintenance instructions. Current approved data and aircraft effectivity control real work.
What this resource teaches
Organize radio navigation and hazard-awareness systems by what they sense and how other systems use the result.
Radio altimeters measure height above terrain at low range
The chapter includes low-range radio-altimeter operational/system/BITE tests. Radio altitude is a sensor output used by several aircraft functions, so a failure can create downstream status messages outside ATA 34.
Weather radar is a separate sensing system
Weather-radar receiver/transmitter, processor and control-panel components form their own chain: transmit/receive energy ? process returns ? display weather information.
ILS/MMR provides radio-navigation guidance
The navigation chapter contains instrument-landing/multi-mode receiver content. Radio-navigation data becomes another source used by crew displays and autoflight.
Sensor validity versus display validity
If radio-altitude or weather data is incorrect, first ask whether the source/sensor chain is wrong or whether correct data is being mis-presented downstream.
Safety boundary
Radar/RF, antenna and test-set procedures can expose personnel/equipment to hazards. TechOpsBase keeps this page at architecture level; approved test procedures control actual work.
Put this topic into the wider system
ATA 34 is deeply integrated
The source directly ties ATA 34 testing to ATA 22 DFCS, ATA 31 MDS, ATC/ADS-B, TCAS, radio altitude and FMCS. Treat these as a network of data producers and consumers rather than isolated avionics boxes.
One source can feed many consumers
Air-data/inertial/navigation outputs are shared by displays, autoflight, surveillance and flight management. When several consumers disagree with reality in the same way, common upstream data should be considered before separate downstream failures.
Deeper system reasoning
Alignment is about creating a trustworthy inertial reference
The source provides FMC-CDU, ISDU and GPS-assisted automatic alignment methods. The educational point is not the switch sequence; it is that the inertial system needs a valid present-position reference and a sufficiently stable aircraft to establish navigation mode. Geographic latitude changes alignment behavior, and excessive aircraft movement can restart the process. Invalid initialization can therefore look like a computer problem even when the underlying issue is setup/data quality.
Technician evidence matrix
Record the specific data item that is wrong, left/right source comparison, ADIRS/alignment/source validity, GPS/radio availability and which consumers show the same symptom.
Before using a maintenance message as a conclusion, note what independent evidence agrees with it and what evidence does not. If an alternate source, channel or display changes the symptom, record that explicitly because it can separate a common path from a source-specific path. Preserve configuration and event conditions in the handover so the next technician does not have to rebuild the diagnostic context from memory.
Evidence-first study method
For any system complaint, separate source/input, control logic, physical response, sensing/indication and consumer/result. When two layers disagree, that disagreement is useful evidence. Do not turn that evidence into a maintenance action until the applicable approved fault-isolation or maintenance data is open.
Approved-data boundary
Educational system explanation only. Do not use this page to perform maintenance, operate aircraft systems, isolate components or determine dispatch status. Current approved maintenance data, aircraft effectivity and operator procedures control real aircraft work.
