¿Cuáles fueron los problemas en el módulo lunar del Apolo 11?

Estas fueron las alarmas del programa "1202" y "1201", que eran señales de advertencia de que la computadora del módulo lunar se estaba sobrecargando.

Durante el descenso del Apolo 11 a la luna, la tripulación dejó el radar de encuentro del LM, que se utilizó para encontrar el camino de regreso al módulo de comando, encendido en el modo "SLEW", por lo que estaría listo si tuvieran que abortar el aterrizaje. .

Esto significaba que la computadora de guía estaba procesando los datos del radar de encuentro al mismo tiempo que intentaba ejecutar el programa de guía de aterrizaje. Esto casi sobrecargó la capacidad de procesamiento de la computadora.

Cuando Aldrin le pidió a la computadora que calculara y mostrara una cierta cifra llamada delta-H, esto fue suficiente carga de procesamiento adicional para llevar a la computadora al límite; comenzó a descartar tareas de baja prioridad como actualizar la pantalla, pero el software fue diseñado para mantener en ejecución las tareas de alta prioridad, como dirigir el módulo de aterrizaje. Cuando abandonaba la tarea de baja prioridad, activaba la alarma principal y mostraba un código de error, 1202. Aldrin y Armstrong no estaban familiarizados con este código, por lo que le pidieron una explicación al control de la misión:

102:38:30 Armstrong: (A Houston) Es un 1202.

102:38:32 Aldrin: 1202. (Pausa)

102:38:42 Armstrong (a bordo): (A Buzz) ¿Qué es? Incorporemos (los datos del radar de aterrizaje). (A Houston) Danos una lectura de la alarma del programa 1202.

Afortunadamente, solo unos días antes del lanzamiento del Apolo 11, el equipo que trabajaba en la computadora reunió una lista de todas las posibles alarmas del programa y los pasos a seguir si ocurrían. Las notas de 1202 decían que si sucedía intermitentemente no había necesidad de abortar. Los controladores consultaron la lista, dieron el visto bueno a CAPCOM Charlie Duke, quien se la transmitió a Eagle:

102:38:53 Duque: Roger. Te tenemos... (Con algo de urgencia en su voz) Activamos esa alarma.

Poco tiempo después, la alarma se disparó de nuevo. Aldrin hizo la conexión de que la alarma ocurrió cuando estaba tratando de monitorear delta-H; el control de la misión le dijo a la tripulación que podían monitorear delta-H desde tierra.

Un poco más tarde, la computadora comenzó a dar alarmas 1201, un síntoma muy ligeramente diferente del mismo problema básico, y nuevamente se pusieron en marcha:

102:42:19 Aldrin: Programa Alarma. (Pausa) 1201

102:42:24 Armstrong: 1201. (Pausa) (a bordo) Bien, 2000 a las 50.

102:42:25 Duque: Roger. 1201 alarma. (Pausa) Vamos. El mismo tipo. Estamos ir.

Las alarmas distraían mucho, lo que obligó a Armstrong a dirigir su atención dentro de la cabina, ya que necesitaba concentrarse en encontrar un buen lugar de aterrizaje, lo que puede haber contribuido al largo tiempo de descenso y al alto consumo de combustible del aterrizaje.

que paso :

Con solo siete minutos y medio restantes antes de que aterrizaran en la luna, Armstrong y Aldrin informaron una alarma de programa. "Es un 1202".

La alarma 1202 indicó que la computadora de guía estaba siendo sobrecargada con tareas. Tenía problemas para completar su trabajo en el tiempo de ciclo disponible.

"Revisamos la lista en esa alarma y, sí, claro, si no vuelve a ocurrir con demasiada frecuencia, estamos bien", informó Garman.

Danos una lectura sobre la alarma del programa 1202", dijo Armstrong por radio, con un poco más de urgencia en su voz.

"Vamos a eso, Vuelo", le aconsejó Bales a Kranz. Antes de que el director de vuelo pudiera responder, el capcom Charlie Duke transmitió la noticia a la tripulación: "Estamos 'Ir' en esa alarma".

Sin embargo, las alarmas no habían terminado. Menos de un minuto después, hubo otra alarma 1202, seguida de tres más, una alarma 1201 y dos alarmas 1202, en menos de 40 segundos.

"Cuando volvió a ocurrir [era] una alarma diferente pero era del mismo tipo", relató Garman. "Recuerdo haber gritado claramente, en este momento gritando, ya sabes, en el bucle aquí:" ¡Mismo tipo! "Y [Bale] grita" ¡Mismo tipo! "Podía escuchar mi voz haciendo eco. Luego [Duke] dice:" Mismo tipo !"

la causa :

Entonces, lo que sucedió durante el Apolo 11, según recuerdo, fue que se programaron trabajos repetidos para procesar los datos del radar de encuentro (que, por supuesto, no estaban realmente allí) debido a una mala configuración de los interruptores del radar. Por lo tanto, los conjuntos básicos se llenaron y se generó una alarma 1202. El 1201 que apareció más tarde en el rellano se debió a que la solicitud de programación que provocó el desbordamiento real era una que había solicitado un área de VAC.

Lo que sucedió a continuación en cualquier caso fue lo que usted describió como: 'La computadora ha sido programada para reconocer estos datos como de importancia secundaria y los ignorará mientras realiza cálculos más importantes'.

En el Apolo 11, cada vez que aparecía una alarma 1201 o 1202, la computadora se reiniciaba, reiniciaba las cosas importantes, como dirigir el motor de descenso y hacer funcionar el DSKY para que la tripulación supiera lo que estaba pasando, pero no reiniciaba todas las alarmas programadas erróneamente. trabajos de radar de encuentro.

Causa principal:

¿Entonces qué pasó? Alambres cruzados. Durante el diseño de la computadora de guía en el laboratorio de instrumentación del MIT, Buzz Aldrin quería que la computadora pudiera manejar simultáneamente los datos de radar de la superficie lunar y los módulos de comando y servicio del Apolo en órbita lunar, en caso de que el Apolo 11 tuviera que abortar el alunizaje. y encuentro con el CSM. A pesar de las discusiones, la capacidad adicional nunca se incorporó al sistema, para sorpresa de Aldrin el 20 de julio. (Las simulaciones nunca habían probado completamente la función y no pudieron revelar su ausencia).

Respuesta complementaria ( estas respuestas lo cubren bien, pero hay algunas otras cosas de interés):

Para cualquier persona interesada en los detalles de este tema, el libro Sunburst and Luminary de Don Eyles tiene, creo, el tratamiento definitivo. ¡Eyles fue el programador del software de guía de descenso LEM!

Eyles explica que el problema se encontró en el suelo dos veces, de forma independiente.

La primera vez fue por Grumman realizando pruebas en Bethpage en LM-3 en mayo de 1968.

El informe diagnosticó correctamente el problema, pero luego, en lugar de proponer una solución, lo descartó con la impresionante racionalización de que el interruptor del radar de encuentro solo estaría en SLEW o AUTO si el PGNCS hubiera fallado, sin tener en cuenta el hecho de que este interruptor sin protección había fallado. el potencial de hacer que el PGNCS falle, como casi lo hizo en el Apolo 11.

( S&L , página 168)

La segunda vez fue de George Silver, un empleado del MIT destinado en KSC.

George Silver identificó el problema de la interfaz del radar de encuentro en Cabo Cañaveral uno o dos meses después de que Grumman lo descubriera en Bethpage. Escribió el problema... e ideó una solución que requería un pequeño cambio de hardware... Solo podemos culpar a Silver por no hacer un mal olor mayor. Es posible que no haya obtenido la aprobación para su solución, pero un grupo más grande habría sabido sobre el problema...

( S&L , página 169)

La tripulación tenía el radar configurado según la lista de verificación, pero la lista de verificación se había actualizado muy poco antes del vuelo y, por lo tanto, no se había ejercitado mucho en el entrenamiento.

La línea de base alrededor de 1965 era tener RR activado, modo LGC y rastrear el CSM durante el descenso. En algún momento... el plan se convirtió en RR apagado, modo en LGC... en junio de 1969... el plan se convirtió en RR encendido con modo en AUTO o SLEW.

( S&L , página 167)

Explicación del interruptor de modo de radar:

El interruptor de modo tenía tres posiciones: LGC, AUTO y SLEW.

1. LGC (LEM Guidance Computer): los resolutores de ángulo de antena utilizaron como señal de referencia una señal de 800 Hz del PGNCS y, por lo tanto, los datos tenían sentido para la computadora de guía.
2. GIRO - Modo de giro manual. La señal de referencia de 800 Hz provino del hardware LEM
3. SEGUIMIENTO AUTOMÁTICO: la antena rastrea un objetivo adquirido. La señal de referencia de 800 Hz provino del hardware LEM

(Imagen del Manual de operaciones de Apolo - Módulo lunar - LM10 y posteriores - Volumen 1 )

Si el interruptor no estaba en LGC y el radar estaba encendido, el LGC podría tener problemas para procesar los datos según la relación de fase entre las dos señales de 800 Hz, y esta relación era completamente aleatoria, determinada por el momento en que se encendió el LGC. La solución de hardware propuesta por Silver habría sincronizado las dos señales, eliminando el problema.

(Condensado de S&L páginas 159-160)

Abordar la parte de la pregunta "problemas con algún botón". Lo que sigue es una cita de una fuente de noticias .

“En general, se informa que cuando Armstrong devolvió el módulo lunar después de la caminata lunar, su mochila rompió un interruptor de circuito”, dijo la fuente, un empleado de North American Aviation que es uno de los últimos en ver a los astronautas del Apolo antes de que se encierren. en su nave espacial.

"Cuando eso sucedió, eliminó el programa de disparo de secuencia de ascenso normal".

Afortunadamente, Aldrin usó un bolígrafo en la parte rota del interruptor para que funcionara.

"Pero si no hubiera podido, eso habría arrojado toda la bola de cera a la secuencia de guía de aborto", continuó la historia.

“Y a menos que él pudiera haberlo activado, no hay respaldo para eso, habrían tenido problemas reales. La única esperanza habría sido los 16 pequeños chorros en el sistema de control de reacción. Y dudo que eso pudiera haberlos llevado de regreso al módulo de comando.

Con respecto al problema del "botón" que señalaba con mayor precisión en otro comentario :

Según el Apollo 11 Journal , alrededor de la marca de las 102:03:35 y antes, parece estar relacionado con el interruptor CWEA ( Conjunto electrónico de precaución y advertencia )