Back to main menu


La remontée étrange du module lunaire











Une vidéo de la librairie de vidéos d'Apollo 17 montre le décollage du module de remontée d'Apollo 17 supposément retournant vers le module de commande.
Tout ce que les adeptes du canular ont trouvé à dire sur cette vidéo est l'absence de plume sous le moteur, à quoi les tenants d'Apollo pensent avoir une réponse.
Pourtant il y a bien plus à dire à propos de cette vidéo, et c'est ce que ce document va expliquer.









Initialement le vaisseau spatial se déplace dans la direction dans laquelle la caméra filme.
Nous pouvons nous demander pourquoi l'opérateur a attendu aussi longtemps avant d'agir sur la caméra.
Le décalage entre ce que l'opérateur voit et ce qui se passe réellement est de 1,25 secondes.
Il y a un délai de 2,5 secondes entre une action de l'opérateur sur la caméra et le résultat correspondant qu'il voit (le temps d'envoyer la commande plus le temps pour que le résultat correspondant revienne).
Le LEM a pris plus de dix secondes pour atteindre le sommet de l'écran après le décollage, et donc l'opérateur avait tout le temps pour agir sur la caméra avant que le LEM n'atteigne le sommet de l'écran.
En attendant que le LEM atteigne le sommet de l'écran avant de réagir, il y avait un risque que le LEM sorte du champ de vue de la caméra.









Dans la première phase de la remontée, alors que le LEM va dans la direction dans laquelle la caméra filme, nous le voyons faire un mouvement de tangage assez abrupt.
En fait il ne pourrait pas tourner brutalement de cette manière, il devrait tourner très lentement, régulièrement.







Lorsque la fusée Saturne s'élève dans les airs, nous ne la voyons jamais tanguer de cette manière, elle tangue très lentement, progressivement; si elle avait tangué comme nous voyons le LEM le faire dans la vidéo de sa remontée, elle serait retombée sur terre et s'y serait écrasée.







Ce schéma simplifié illustre ce qui se produit quand une fusée est lancée.
J'ai représenté la poussée de la fusée par une flèche jaune, la gravité par une flèche rouge, et la force centrifuge grandissante par une flèche verte.
Lorsqu'une fusée est lancée pour être mise en orbite, il monte d'abord verticalement pour s'extraire de la gravité terrestre et gagner de la vitesse verticale.
Puis elle commence de tourner vers une attitude plus horizontale pour gagner de la vitesse horizontale, mais pas brutalement, très graduellement au lieu de cela.
Elle prend d'abord une attitude horizontale modérée qui lui permet de gagner de la vitesse horizontale.
Alors qu'elle gagne de la vitesse horizontale, une force centrifuge commence d'apparaître, et cette force centrifuge aide la fusée à combattre la gravité terrestre.
Alors la fusée tourne vers une attitude plus horizontale qui lui permet de gagner davantage de vitesse horizontale; l'accroissement de la vitesse horizontale génère un accroissement correspondant de la force centrifuge qui permet de contrer davantage la gravité terrestre, ce qui permet à la fusée de prendre une attitude encore plus horizontale pour gagner encore davantage de vitesse horizontale, et ainsi de suite...
A la fin du processus, la fusée termine avec une attitude complètement horizontale; sa vitesse horizontale est à présent la vitesse orbitale qui permet de créer une force centrifuge exactement égale à la gravité terrestre, ce qui signifie que la fusée n'a plus à produire une force verticale pour contrer la gravité terrestre.
La fusée peut conserver sa vitesse orbitale sans avoir à produire une force horizontale, car, dans le vide, il n'y a pas de force de résistance pour ralentir la fusée.
La fusée suit à présent naturellement son orbite sans avoir à utiliser son moteur.
Le changement d'attitude de la fusée de vertical vers horizontal est très lent, progressif, et régulier; il ne peut en aucune sorte être brutal.






Si la fusée, après sa montée verticale initiale, tournait brutalement vers une attitude horizontale, comme elle n'a pas gagné la vitesse horizontale permettant de produire une force centrifuge qui contre l'attraction terrestre, elle commencerait de retomber vers la terre.
Alors qu'elle retombe, elle gagnerait de la vitesse horizontale, mais pas assez rapidement pour avoir atteint la force centrifuge nécessaire pour contrer l'attraction terrestre avant de toucher le sol.
Le crash est inévitable.







La physique de la remontée est exactement la même pour le module lunaire.
Il doit tourner lentement et régulièrement vers une attitude horizontale pour laisser le temps à la force centrifuge de grandir suffisamment pour être capable de maintenir le module lunaire dans l'espace.






Après s'être brusquement retourné vers une attitude horizontale, le module lunaire commence à tomber dans la vidéo d'Apollo 17, ce qui est normal puisqu'il n'a pas encore atteint la vitesse horizontale permettant de créer la force centrifuge compensant l'attraction lunaire.
Mais tout d'un coup sa chute s'arrête; quelle est la force mystérieuse qui a soudainement arrêté sa chute? Cela ne peut pas être la force centrifuge, car il n'a pas encore atteint la vitesse horizontale permettant de créer la force centrifuge compensant l'attraction lunaire.










Puis, soudainement le module lunaire commence à faire un étrange mouvement sinusoïdal.
Certains fans d'Apollo ont prétendu que le mouvement sinusoïdal que le module lunaire fait à la fin de la vidéo venait des efforts de l'opérateur de la caméra pour suivre le module lunaire avec la manette de contrôle, mais cette explication ne tient pas, et je vais expliquer pourquoi.
Vous pouvez constater que l'axe horizontal du mouvement sinusoïdal n'est pas au milieu de l'image, mais en bas de celle-ci.









Il est évident que l'opérateur, s'il n'est pas complètement stupide, essaierait de centrer le module lunaire au milieu de l'image; s'il voit que le module lunaire est sous le milieu de l'image, il pousserait la manette de contrôle vers le bas, et pas vers le haut, et, inversement, s'il voit que le module lunaire est au dessus du milieu de l'image, il pousserait la manette de contrôle vers le haut, et conséquemment nous verrions quelque chose comme ceci...










...et non comme ceci.
Sur la vidéo, même lorsque le module lunaire est sous le milieu de l'image, l'opérateur le ferait descendre au lieu de le faire monter, il n'essaierait jamais de le remonter sur le milieu de l'image, ce qui est totalement illogique.
Je ne peux croire que la NASA aurait laissé un opérateur complètement stupide maneuvrer la manette de contrôle de la caméra, qui ne saurait pas que, lorsqu'il voit le module lunaire sous le milieu de l'image, il doit le faire remonter sur l'image et non le faire descendre.









En fait, si le module lunaire allait vraiment droit et n'oscillait pas, nous aurions du voir quelque chose comme ceci.
En effet, après avoir fait une maneuvre sur la manette de contrôle, l'opérateur sait qu'il ne verra pas immédiatement le résultat, et qu'il doit attendre le délai de la commande (2,5 secondes); la maneuvre suivante dépend de l'endroit où il verra le module lunaire après le délai de la commande; s'il voit le module lunaire au dessus du milieu de l'image, sa prochaine maneuvre sera un mouvement vers le bas, et si inversement il voit le module lunaire en dessous du milieu de l'image, son prochain mouvement sera un mouvement vers le haut; de plus, s'il sait normalement maneuvrer, il devrait réussir à progressivement rapprocher le module lunaire du milieu de l'image, et à faire des mouvements de plus en plus petits sur la manette de contrôle.
Le mouvement du module lunaire sur l'image devrait ressembler à une forme d'onde carrée, centrée sur l'image, et avec une amplitude décroissante...








...et non à une sinusoïde, non centrée sur l'image, et avec une amplitude croissante.
Il ne fait pas de doute que le mouvement sinusoïdal que nous voyons le module lunaire faire sur la vidéo vient du mouvement de balancement causé par le couple de désalignement corrigé par les réacteurs latéraux.









En fait il y a une confirmation que le comportement étrange du module lunaire ne vient pas des actions de Ed Fendell sur la manette de contrôle alors qu'il essaie de suivre le module lunaire sur l'écran, et qu'il a quelques difficultés à cause du délai entre la commande et le résultat qu'il voit sur l'écran.
En effet, voici ce que Fendell a dit, traduit (Lien dans la description de la vidéo):
"Maintenant, la manière dont cela marchait était celle-ci. Harley Weyer, qui travaillait pour moi, s'est assis et a calculé ce que la trajectoire serait, et où le rover lunaire serait à chaque seconde alors qu'il s'éloignait, et où vos réglages iraient. La représentation que vous avez vue a été prise sans regarder du tout le décollage. Celui-ci n'a pas été regardé, et n'avait rien à voir avec cette représentation. Alors que l'équipage décomptait, c'était une représentation d'Apollo 17 que vous avez vue, alors qu'Eugène Cernan décomptait et savait où il devait parquer le rover au bon endroit car j'allais le tuer s'il ne le faisait pas - Et Gene et moi-même étaient de bons amis, il pourra vous le dire - J'ai en fait envoyé la première commande trois secondes avant le décollage. Et chaque commande était scriptée, et tout ce que je faisais était de regarder un chronomètre, et d'envoyer des commandes, je ne regardais pas la télévision. Je n'ai vraiment pas vu le film avant que la remontée soit terminée, et qu'il soit rejoué. C'étaient juste des commandes précalculées qui étaient envoyées en fonction du temps. C'est de cette manière que cela a fonctionné."
Lien vers l'explication de Ed Fendell
Donc, non, l'explication des tenants d'Apollo ne tient pas, Fendell ne regardait pas l'écran, il appliquait simplement des actions préprogrammées à des moments définis.
Cela signifie que, si le module lunaire se comportait de cette manière sur la vidéo, c'est parce qu'il se comportait vraiment ainsi dans l'espace.









Le centre de masse du vaisseau spatial ne peut constamment rester aligné avec la ligne de poussée si le moteur n'est pas réorienté; alors que les réservoirs de propergol se vident, le centre de masse se décale, et il n'est plus aligné avec la direction dans laquelle le moteur pousse; la conséquence est que cela créerait un couple de désalignement si le moteur n'était pas réorienté de sorte que le centre de masse redevienne aligné avec la ligne de poussée.
Le moteur de l'état de descente était articulé, ce qui permettait de le faire pivoter au long de la descente de sorte que la ligne de poussée reste alignée avec le centre de masse alors que celui-ci se décale avec la baisse de niveau des réservoirs de propergol.









Mais le moteur de remontée était fixe et non articulé comme le moteur de descente, et ainsi il ne pouvait être pivoté pour garder l'alignement avec le centre de masse.
Tant que le centre de masse restait aligné avec la ligne de poussée, tout se passait bien.









Mais, après que les réservoirs de propergol avaient commencé de se vider, le centre de masse se décalait progressivement, et la conséquence était que cela créait un couple de désalignement qui faisait tourner le module lunaire dans le sens des aiguilles d'une montre et le poussait sur la droite.
Si rien n'était fait pour contrer ce couple de désalignement, le module lunaire entamerait une pirouette fatale, et finirait par s'écraser sur la lune.









Puisque le moteur de remontée ne pouvait pivoter pour refaire l'alignement avec le centre de masse, la solution était d'utiliser les réacteurs latéraux du RCS pour créer un contre couple qui s'opposerait au couple de désalignement.
Si le couple créé par les réacteurs latéraux pouvait être exactement équivalent au couple de désalignement, le module lunaire continuerait d'aller droit.
Mais la poussée des réacteurs latéraux ne pouvait être ajustée, ils fonctionnaient en "tout ou rien", et conséquemment il n'était pas possible d'ajuster leur poussée pour créer un contre couple exactement équivalent au couple de désalignement.
La conséquence est qu'ils ne pouvaient être mis à feu de manière permanente, mais périodiquement au lieu de cela, et comme ils ne pouvaient être commandés à une fréquence suffisante (la période de guidage était de 2 secondes), le résultat est qu'il n'était pas possible d'éviter un mouvement de balancement conséquent.









Cette animation explique ce qui se passait: Le couple de désalignement faisait tourner le LEM dans le sens des aiguilles d'une montre et le poussait sur la droite; puis les réacteurs latéraux étaient mis à feu et faisaient tourner le LEM dans le sens inverse et le poussaient sur la gauche; puis les réacteurs latéraux étaient coupés (sinon ils auraient continué de faire tourner le LEM dans le sens inverse et de le pousser sur la gauche), et le couple de désalignement refaisait tourner le LEM dans le sens des aiguilles d'une montre et le repoussait sur la droite, et ainsi de suite...
Plus le couple de désalignement devenait important, et plus l'amplitude du mouvement sinisoïdal augmentait, car la fréquence de commande des réacteurs latéraux ne pouvait être augmentée pour contrer le couple de désalignement plus rapidement.
Ceci pouvait fonctionner tant que le couple de désalignement ne devenait pas supérieur au contre couple créé par les réacteurs latéraux, car, si jamais il le dépassait, cela serait fatal au LEM, et il n'y aurait rien qu'il ne puisse faire pour éviter une issue fatale, à part couper le moteur principal, mais ce serait également fatal, car alors il serait incapable d'atteindre sa vitesse orbitale.









Lorsque nous voyons comment le moteur principal était placé, il apparaît que le centre de masse n'était pas aligné avec la poussée du moteur lorsque les réservoirs de propergol étaient vides; lorsqu'ils étaient pleins, l'équilibre était possible car le propergol le plus proche du moteur avait une densité supérieure à celui plus éloigné.
Mais, au fur et à mesure que les réservoirs se vidaient, le centre de masse se décalait progressivement sur la droite, et un couple de désalignement apparaissait alors.
Ce n'est absolument pas une supposition que je fais, c'est confirmé dans la documentation par les ingénieurs de la NASA.
Même Clavius en parle sur son site, et dit ceci:
"Alors que la poussée hors-axe faisait tourner le module de remontée, les réacteurs latéraux étaient mis à feu pour contrer la rotation et le remettre dans l'attitude correcte. C'est pourquoi les films de la remontée du module montrent cette oscillation périodique: Les réacteurs latéraux s'opposaient à la poussée hors-axe du moteur de remontée."









Le fait que le réservoir de l'oxydant était placé plus près du moteur de remontée s'explique par le fait que l'oxydant avait une densité plus grande que celle du carburant (1,5 fois plus grande).
Si les réservoirs avaient été placés à la même distance du moteur, la différence de densité des propergols aurait fait tourner le LEM du côté de l'oxydant.
Au début de la remontée, lorsque les réservoirs sont pleins, leur contenu est plus lourd que les contenants, et donc le couple de désalignement est encore limité.
Mais, au fur et à mesure que les réservoirs se vident, la différence entre les contenus et les contenants s'amenuise, et conséquemment le centre de masse du LEM se décale vers le réservoir de carburant, avec la conséquence que le couple de désalignement s'accroît; comme les réacteurs latéraux du RCS ne peuvent augmenter leur fréquence de correction du couple de désalignement, la conséquence est que l'amplitude de l'oscillation du LEM s'accroît progressivement.
(Le but de cette animation est de faire comprendre ce qui se passe, et non de représenter la réalité exacte).
Même s'il était possible de corriger le couple de désalignement avec les réacteurs latéraux, cela gaspillait quand même inutilement leur propergol (et cela compliquait aussi le guidage, car ils étaient aussi utilisés pour modifier la trajectoire du LEM), alors que ce propergol aurait pu être économisé si le moteur de remontée avait été articulé.









Si vous observez le mouvement sinusoïdal du LEM alors qu'il se déplace vers la gauche, vous pouvez constater que l'amplitude de la sinusoïde tend à augmenter de manière notable.
Vous pouvez voir que, lorsque le LEM est sur le point de quitter le champ de vue de la caméra, l'amplitude de la sinusoïde est déjà conséquente comparée avec la taille du module lunaire!
Et nous ne voyons que les premières secondes de la montée motorisée, laquelle va encore durer pendant plusieurs minutes.
Si l'amplitude est déjà assez importante après quelques secondes, vous pouvez aisément imaginer ce que ce sera après plusieurs minutes!
Il y a une chance non négligeable que le couple de désalignement finisse par dépasser le contre couple créé par les réacteurs latéraux, ce qui se révélerait fatal pour le LEM.
Remarquez aussi que, lorsque nous commençons à voir le mouvement sinusoïdal, il a déjà une certaine amplitude, alors que l'amplitude initiale devrait être faible.











Le rover est placé de manière à regarder vers l'arrière du LEM.
Le module lunaire alunit toujours de manière à avoir le soleil dans le dos, et à avoir son avant à l'ombre.
C'est une manière naturelle d'alunir, car le module lunaire arrive toujours par l'est (le module de commande tourne autour de la lune dans le sens des aiguilles d'une montre), mais cela permet aussi aux astronautes de sortir du LEM sans être exposés au soleil.
Donc l'avant du LEM est orienté vers l'ouest, et son arrière vers l'est.
Lorsque le rover regarde vers l'arrière du LEM, il regarde conséquemment en direction de l'ouest.
Et c'est logique car le module lunaire doit aller principalement vers l'ouest.









Le module lunaire, de manière à joindre le module de commande, doit, comme le module de commande, tourner autour de la lune horizontalement dans le sens des aiguilles d'une montre; il doit donc partir vers l'ouest.
Comme le site d'alunissage d'Apollo 17 était un peu au nord, le module lunaire devait aller un peu vers le sud de manière à se rapprocher de l'équateur de la lune, mais pas manière non brutale, en suivant une longue trajectoire courbe.









Mais ce n'est pas du tout ce que nous le voyons faire; initialement le module lunaire va dans la direction dans laquelle la caméra filme, vers l'ouest.









Puis le module lunaire fait un brutal quart de tour, ce qui signifie qu'il se déplace à présent plein sud.









Donc, ceci est la trajectoire que nous voyons le module lunaire prendre sur la vidéo.
Le module lunaire ne prend pas du tout une trajectoire horizontale pour joindre l'orbite du module de commande, mais une trajectoire verticale à la place.









Cela signifie que, lorsque le module lunaire croisera l'orbite du module de commande, il la croisera perpendiculairement, et il n'ira pas dans la direction dans laquelle le module de commande va.
Et, à la vitesse à laquelle le module lunaire croise cette orbite (environ 6000 km/h), il est totalement incapable de tourner d'un quart de tour pour aller dans la même direction que le module de commande.
Et, si vous demandez si, au lieu de faire ce brutal changement de direction impossible, le module lunaire ne pourrait faire un très large virage pour joindre l'orbite du module de commande, je répondrai que cela coûterait bien plus de propergol du RCS pour faire ce virage, même s'il est très large, que si le module lunaire avait fait les choses normalement, i.e. prendre un orbite horizontal dès le début (et, dans la documentation technique, il n'est pas question de faire une telle maneuvre).
Et de plus le RCS gaspille déjà beaucoup de propergol pour contrer le couple de désalignement!









Surtout que le RCS aura besoin d'avoir encore du propergol pour faire la maneuvre finale pour s'arrimer au module de commande.
De toute façon, avec tout le propergol qu'il aura gaspillé, il n'atteindra même pas l'orbite du module de commande.









Sur la vidéo de la remontée d'Apollo 17, on peut voir que l'amplitude du mouvement sinusoïdal du module lunaire est déjà importante, et augmente de manière consistante; or cette vidéo ne dure qu'une demie minute, et la remontée motorisée dure plus de sept minutes (selon la documentation de la NASA).
Il est donc plus que probable que le module lunaire rencontrera un destin fatal, et finira pas s'écraser sur la lune.
Vous voyez, il y a bien plus que le problème de l'absence de plume dans cette remontée.









Maintenant, lorsque nous comparons la vidéo prise par la caméra du rover avec celle prise par la caméra DAC à l'intérieur du module lunaire, au moment où le module lunaire montre un mouvement sinusoïdal sur la vidéo de la caméra du rover, nous n'en voyons pas sur la vidéo prise par la caméra DAC.
Les tenants d'Apollo le prennent comme une preuve que ce mouvement sinusoïdal ne vient pas du module lunaire lui-même, mais de l'effort de l'opérateur de la caméra pour centrer le LEM sur l'écran, quoique ce soit complètement illogique, et montrerait une incompétence rare de la part de l'opérateur.









Mais, sur la première phase de la remontée, nous voyons le sol lunaire bouger de manière importante sur la vidéo de la caméra DAC, comme si le LEM faisait un important mouvement de tangage, alors que, pendant ce temps, le LEM ne tangue que de manière modérée sur la vidéo de la caméra du rover; et, lorsque nous voyons le LEM faire un important mouvement de tangage sur la vidéo de la caméra du rover à la fin de la phase initiale, le sol lunaire bouge bien moins que précédemment sur la vidéo de la caméra DAC, comme si le mouvement de tangage était réduit à ce moment.
En d'autres termes, le LEM tangue fortement sur la vidéo de la caméra DAC quand il tangue modérément sur la vidéo de la caméra du rover, et, inversement, il tangue modérément sur la vidéo de la caméra DAC quand il tangue fortement sur la vidéo de la caméra du rover.
Il y a une contradiction totale entre les deux vidéos, elles ne sont pas synchronisées l'une avec l'autre.
Au moins l'une des deux est fausse, et devinez quoi? Elles sont toutes deux fausses!









Plus tard nous voyons un mouvement irregulier dans la vidéo prise depuis le module lunaire, et ce mouvement irrégulier vien du mouvement de balancement du module lunaire, et il va également en s'accroissant.
Ce mouvement de balancement arrive plus tard dans la vidéo prise depuis le module lunaire que dans celle prise depuis le rover lunaire; une fois de plus ces deux vidéos ne sont pas synchronisées l'une avec l'autre.









Maintenant, pour en revenir à l'absence de plume du moteur, les tenants d'Apollo pensent en détenir la raison.
Michael Shermer donne cette explication pour le fait quelle ne soit pas visible:
"the main reason is that the LM’s engine used hypergolic propellants that burn very cleanly"
soit:
"La raison principale est que le moteur du LEM utilisait des propergols qui brûlent de manière très propre.
Oh vraiment?









Alors, pourquoi peut-on voir la plume des réacteurs latéraux sur une séquence du film de la caméra du module de commande, alors qu'ils utilisent le même propergol que le moteur de remontée?









Si nous pouvons voir la plume des réacteurs latéraux, il n'y a pas de raison que nous ne puissions pas aussi voir la plume du moteur de remontée!









Il y a encore quelques faits étranges, quoique pas autant incriminants que les précédents.
Nous voyons quelques étincelles colorées assez éloignées du module lunaire, comme ces deux que j'ai cerclées sur cette image extraite de la vidéo.









Ou bien ces deux sur une autre image extraite de la vidéo.
Quoique ce soient des faits mineurs comparés avec les précédents, ils soulèvent quand même des questions.









Apollo 17 n'est pas bien sûr la seule mission dans laquelle il y a des anomalies dans la remontée du module lunaire, puisqu'elles sont toutes fausses.
Dans cette vidéo, je vais montrer des problèmes dans la remontée du module lunaire dans Apollo 16 et Apollo 15, quoiqu'il y ait beaucoup moins à dire que dans Apollo 17, et cette vidéo sera donc plus courte.









Ceci est ce que la caméra du rover voit peu après que le module lunaire ait décollé de la lune dans Apollo 16.
Nous voyons le module lunaire descendre lentement et régulièrement, puis, lorsqu'il est près du bas de l'image, il remonte soudainement, car l'opérateur de la caméra a baissé la caméra du rover pour continuer à suivre le module lunaire dans sa descente.
Dans sa descente???









Après que le module lunaire ait décollé, il va grimper dans le ciel lunaire pour atteindre un orbite autour de la lune, dans une première phase, appelée "montée motorisée", dans laquelle il utilisera intensément son moteur.
Après avoit atteint l'orbite de départ, il entamera une seconde phase pour atteindre l'orbite du module de commande, dans laquelle, la plupart du temps, il n'utilisera pas son moteur, seulement occasionnellement.
Si la caméra du rover veut suivre le module lunaire, elle devra être régulièrement levée, de sorte à ne pas le perdre de son champ de vue.
A chaque fois que le module lunaire arrive près du haut de l'image, l'opérateur de la caméra lève la caméra, ce qui a pour effet de ramener le LEM près du bas de l'image, de sorte que la caméra puisse continuer à suivre le module lunaire qui va continuer de monter.









Mais ce n'est pas du tout ce que nous voyons sur la vidéo.
Ce que nous voyons est que le module lunaire descend lentement, régulièrement, et, lorsqu'il arrive près du bas de l'image, l'opérateur de la caméra agit sur la caméra pour l'abaisser, de sorte que le module lunaire remonte, près du haut de l'image, de sorte que la caméra du rover puisse continuer à suivre le LEM dans sa descente.
Cela signifie que le module lunaire, alors qu'on devrait le voir monter, on le voit descendre à la place!









Maintenant, si j'inverse la vidéo de la remontée du module lunaire d'Apollo 16, nous voyons alors quelque chose de plus normal: Nous voyons le module lunaire monter lentement, régulièrement, et, lorsqu'il arrive près du haut de l'image, le module lunaire redescend rapidement près du bas de l'image, car l'opérateur a levé la caméra.









Il semble plus difficile de dire quelque chose à propos de la remontée du module lunaire filmé par la caméra du rover dans Apollo 15, car l'opérateur n'a pas pu manipuler la caméra à cause d'un problème technique.
Toutefois, il est encore possible de vérifier sa direction initiale.









Le moteur du module de remontée ne pouvait pas pivoter, il était fixé, et il poussait donc nécessairement suivant la direction de l'axe du LEM.
Le LEM était initialement equilibré (ce n'est que plus tard, après que les réservoirs de propergol avaient commencé de se vider, qu'un déséquilibre commençait à apparaître), de sorte que nous devrions le voir commencer à partir dans la direction initiale de l'axe du LEM; j'ai donc dessiné une ligne qui est parallèle à la base du LEM (un peu en biais, car le LEM était un peu penché lorsqu'il a aluni), ainsi qu'une ligne perpendiculaire à cette dernière, qui représente la direction initiale de l'axe du LEM; nous devrions voir le LEM suivre cette direction; je l'ai dessinée sur toutes les images de la remontée sur lesquelles nous pouvons voir le module lunaire.









Maintenant, avec la direction initiale dessinée sur toutes les images de la vidéo sur lesquelles nous voyons le LEM, nous voyons que le LEM ne suit pas exactement cette direction, mais en diverge à la place.
Maintenant, certains pourraient dire que le LEM divergerait de la direction normale parce qu'il aurait utilisé ses réacteurs latéraux pour changer sa direction; mais, si les réacteurs latéraux avaient été utilisés, cela aurait plutôt été pour corriger l'orientation initiale, pour la rendre plus verticale, et non moins verticale.
Je n'en ai pas été surpris lorsque je l'ai constaté, car je savais que c'était le seul indice qu'ils pouvaient donner, comme nous ne pouvons plus voir le LEM une fois qu'il a quitté l'image.









Avant la mission Apollo 15, dans les missions Apollo 11, 12, et 14, la remontée du module lunaire était seulement suivie par la caméra DAC à l'intérieur du module lunaire.
Ce que nous voyons sur ces vidéos ressemble à ce que nous voyons sur la vidéo de la caméra DAC d'Apollo 17, et montre le même type de problème, c'est à dire, au lieu d'une ascension régulière, une ascension irrégulière, dans laquelle il y a des arrêts soudains à des intervalles réguliers, ce qui est impossible, et pas du tout physique.









Toutes les remontées du module lunaires sont fausses pour la bonne raison que le module lunaire ne s'est jamais posé sur la lune.









Nous allons maintenant voir le meilleur.
Les réacteurs du RCS qui doivent être mis à feu pour appliquer le couple désiré s'opposant au contre de désalignement sont ceux que j'ai cerclés sur ce schéma et sont désignés comme A3U, B4U, A2D, et B1D, selon la terminologie du RCS.
Ils doivent tous être mis à feu en même temps pour éviter un déséquilibre.









Nous allons maintenant voir comment les réacteurs latéraux du RCS étaient commandés, et pour ce faire nous allons analyser l'interface de commande des réacteurs latéraux, montré à la page 2-1-133 du manuel technique du module lunaire (qui décrit tous les interfaces du module lunaire).









Les dispositifs que j'ai encadrés sont des relais électromécaniques; un relai électromécanique est composé d'une bobine, que j'ai cerclée de vert, et d'un interrupteur dont l'état est changé en excitant la bobine, et que j'ai cerclé d'orange.









Voici comment fonctionne le relais électromécanique:
- Lorsque la bobine n'est pas excitée, le point central de l'interrupteur est connecté au contact du haut.
- Lorsque la bobine est excitée, elle attire l'interrupteur vers le bas, et le point central de l'interrupteur devient connecté au contact du bas à switch down, and the central point of the switch becomes connected to the lower contact instead.









Si le contact du bas du relais électromécanique est connecté à la masse, l'effet est que la sortie du relais électromécanique est connectée à la masse lorsque la bobine est excitée.









Le circuit que j'ai cerclé de rouge est un ampli OP avec deux sorties; ces deux sorties sont complémentaires: Lorsque l'une est à 1, l'autre est à 0, et inversement.
Le circuit que j'ai cerclé d'orange est une porte OU avec des entrées inversées.









Dans la symbologie d'Apollo, les portes ET et OU sont représentées par le même symbole, mais avec un point noir à l'intérieur de la porte OU pour la différencier de la porte ET.









Une porte OU est un circuit qui a plusieurs entrées (au moins deux), et dont les sorties sont à 1 si au moins l'une des entrées est à 1, et 0 seulement si toutes les entrées sont à 0.









Lorsqu'il y a un petit cercle devant les entrées, ce petit cercle signifie que les entrées sont inversées avant d'être appliquées à la porte OU (i.e. un 0 devient un 1, et vice versa).
La porte OU sort alors un 0 quand toutes les entrées sont à 1, et un 1 sinon (i.e. si au moins une entrée est à 0).
Lorsqu'il n'y a qu'une entrée dans ce circuit, la sortie du circuit est l'entrée inversée.









Sachant tout ceci, nous pouvons analyser cette circuiterie.
Nous allons analyser la connexion au relais électromécanique de la commande des réacteurs horizontaux.
Le circuit 1 reçoit deux paires de signaux provenant des amplis op d'entrée; dans chaque paire les signaux sont complémentaires, et donc deux des entrées de ce circuit sont à 0; la sortie du circuit 1 est donc à 1 d'après ce que j'ai expliqué.
Cette sortie est inversée par le circuit suivant, ce qui signifie que la sortie du circuit 2 est toujours à 0; cette sortie est inversée avant de rentrer dans un circuit OU, ce qui signifie que la sortie du circuit 3 est toujours à 1.









Comme la sortie du circuit 3 est toujours à 1, elle excitera toujours la bobine du relais électromécanique auquel elle est connectée après amplification, et donc, comme le contact du bas de ce relais électromécanique est relié à la masse, la sortie du relais sera toujours reliée à la masse, quelque soient les entrées de la circuiterie de ce relais électromécanique.










Et pour les relais électromécaniques de la commande des réacteurs verticaux, cela fonctionne de manière analogue.
Les circuits que j'ai cerclés produisent deux sorties à partir des entrées de commande (que j'indique avec des flèches doubles) qui sont complémentaires, ce qui signifie que, lorsque l'une est positive, l'autre est négative, et vice versa.
Pour la même raison que précédemment expliqué, les sorties des circuits 1, 2 et 3 sont toujours à 1.
Le circuit 4 reçoit deux entrées toujours à 1, mais sont inversées avant d'en faire un OU, ce qui signifie que l'on fait un OU de deux 0, ce qui donne un 0; la sortie du circuit 4 est donc toujours à 0.
Pour la même raison, la sortie du circuit 5 est aussi toujours à 0.
La sortie du circuit 4 est inversée avant d'en faire un OU avec deux autres entrées; le 0 inversé devient un 1 à nouveau, et la sortie du circuit 6 est donc toujours à 1; elle alimente un ampli op qui activera toujours le relais électromécanique auquel elle est reliée.
Pour la même raison, le fait que la sortie du circuit 5 est toujours à 0 a pour conséquence que la sortie du circuit 7 auquel elle est connectée est toujours à 1; elle alimente un ampli OP qui activera toujours le relais électromécanique auquel elle est reliée.









Donc les relais électromécaniques sont tous connectés de sorte que leurs sorties sont toujours mises à la masse quelques soient les entrées de leur circuiterie.
Conséquemment les commandes des réacteurs latéraux qui sont connectées à ces relais électromécaniques pourraient tout aussi bien avoir été directement connectées à la masse puisque les sorties des relais électromécaniques sont toujours reliées à la masse.









Maintenant, si nous regardons les connexions aux relais électromécaniques, que nous savons toutes reliées à la masse, nous pouvons constater que la paire de réacteurs B4U et A4D sont commandées seulement par les sorties des relais élecromécaniques, ce qui signifie toutes les commandes de ces réacteurs sont à la masse, et donc ces deux réacteurs ne seront JAMAIS activés.









A présent nous pouvons constater que la commande de roulis (qui est normalement la commande qui permet d'appliquer le contre couple) est connectée à l'entrée + de la commande de la paire de réacteurs A3U et B3D, et à l'entrée - de la commande de la paire de réacteurs B2U et A2D; cela signifie que le roulis activera ou bien les réacteurs A3U et B3D lorsque positif, et les réacteurs B2U et A2D lorsque négatif, mais jamais les quatre en même temps.









Maintenant, c'est là que cela devient vraiment savoureux: Les réacteurs A3U et B3D, qui sont activés en cas de roulis positif, sont deux réacteurs verticaux qui sont directement opposés l'un à l'autre; cela signifie qu'ils vont mutuellement annuler leurs effets respectifs, et la conséquence est que le roulis positif...NE FAIT RIEN!









Et les réacteurs B2U et A2D, qui sont activés en cas de roulis négatif, sont deux réacteurs verticaux qui sont aussi directement opposés l'un à l'autre; cela signifie qu'ils vont mutuellement annuler leurs effets respectifs, et la conséquence est que le roulis négatif...NE FAIT RIEN!









Et nous pouvons constater que la commande de tangage rentre sur l'entrée + de la commande de la paire de réacteurs B2U et A2D, et sur l'entrée - de la commande de la paire de réacteurs A1U et B1D; cela signifie que le tangage activera ou bien les réacteurs B2U et A2D lorsque positif, et les réacteurs A1U et B1D lorsque négatif.









Et nous retrouvons le même gag que pour le roulis; les réacteurs B2U et A2D, qui sont activés en cas de tangage positif, sont deux réacteurs verticaux directement opposés l'un à l'autre; cela signifie qu'ils vont mutuellement annuler leurs effets respectifs, et la conséquence est que le tangage positif...NE FAIT RIEN!









Et les réacteurs A1U et B1D, qui sont activés en cas de tangage négatif, sont deux réacteurs verticaux directement opposés l'un à l'autre; cela signifie qu'ils vont mutuellement annuler leurs effets respectifs, et la conséquence est que le tangage négatif...NE FAIT RIEN!









Si chaque commande active deux réacteur latéraux directement opposés l'un à l'autre, il est évident qu'elle ne va pas avoir d'effet sur l'attitude du module lunaire.







Je pense donc que vous avez compris maintenant: L'interface de commande des réacteurs latéraux est une absurdité totale qui ne fait absolument rien, et ne permet pas de commander les réacteurs latéraux du RCS pour changer l'attitude du module lunaire.
Le module lunaire est tout simplement non maneuvrable avec cet interface.









Ce n'est qu'une qu'une bonne blague imaginée par les ingénieurs de la NASA!
Mais ils ont même poussé la plaisanterie plus loin comme nous allons le voir.









L'AGC met à jour les angles (et accélérations) en incrémentant ou décrémentant des compteurs suivant le sens de variation des angles (avec des instructions "cachées", ce qui est une hérésie, comme je l'ai déjà fait remarquer, car l'incrémentation ou décrémentation de ces compteurs devrait se faire matériellement), la navigation calcule des angles et position en fonction de la trajectoire qui doit être suivie; un angle mesuré est comparé avec l'angle désiré correspondant; la différence est comparée avec un seuil; si la différence est au-dessus du seuil, les réacteurs qui font augmenter cet angle sont activés si la différence est positive (i.e. l'angle désiré est plus grand que l'angle mesuré), et inversement les réacteurs qui font diminuer cet angle sont activés si la différence est négative; si la différence est sous le seuil, aucun réacteur faisant changer cet angle n'est activé.









Maintenant, ce qu'ils font est un peu différent.
Ils calculent la différence entre ces deux valeurs de l'angle dans un compteur, et ils convertissent cet angle en une valeur analogique avec un convertisseur digital vers analogique; la valeur analogique convertie module un signal haute fréquence, et la phase de ce signal est mise suivant le signe de la différence.
Puis ce signal modulé est démodulé, et le signal démodulé est comparé avec une référence; si le signal démodulé est au-dessus de la référence, les réacteurs qui font augmenter cet angle sont activés si le signal modulé est phasé, et inversement les réacteurs qui font diminuer cet angle sont activés si le signal modulé est déphasé; si le signal démodulé est sous la référence, aucun réacteur faisant changer cet angle n'est activé.









Mais c'est complétement absurde!
Lorsque des commandes soivent être transmises depuis un boitier de commande vers un drone, comme il n'y a pas de connexion filaire entre le boitier et le drone, la seule manière de transmettre les commandes du boitier de commande vers le drone est de moduler une porteuse haute fréquence avec les commandes, de sorte que ces commandes puissent traverser à travers l'air jusqu'au drone; dans la circuiterie électronique du drone, la porteuse haute fréquence est démodulée, et les commandes du boitier en sont extraites et appliquées au drone.









Mais, dans le cas du contrôle du RCS, les commandes sont envoyées à travers des fils, et pas dans l'air, et c'est donc une complication complètement inutile, qui complique la circuiterie et gaspille inutilement de la puissance.










En d'autres termes, cette complication complètement inutile n'est rien d'autre qu'une nouvelle plaisanterie de la part des ingénieurs de la NASA, pour un interface qui de toute manière ne fonctionne pas, et ne permet pas aux RCS de contrôler l'attitude du module lunaire.









Donc, nous avons un couple de désalignement, provenant du décalage du centre de gravité, qui ne peut pas être corrigé en pivotant le moteur de remontée puisqu'il est fixe; ce couple de désalignement ne peut être contré par les réacteurs latéraux du RCS puisque nous avons vu qu'il ne fonctionne pas.









La conséquence est que le module lunaire va tourner comme une girouette, indéfiniment, sans que cette rotation ne puisse être empêchée.









Le résultat est prévisible: Le module lunaire va s'écraser sur le sol lunaire peu après son décollage.
Oh les pauvres astronautes qui vont trouver un sort fatal!









Mais ne craignez rien pour les astronautes, ils s'en sortiront car ils peuvent sortir du module lunaire quand ils réalisent qu'il est hors de contrôle, et sauter en parachute pour sauver leurs vies...









...Comme Armstrong l'a fait lors d'un vol d'entrainement sur le module d'entrainement, pour sauver sa vie alors que le module avait un problème irrécupérable.









Vous me direz que, si le RCS ne pouvait être contrôlé, il a aussi du y avoir un problème dans la descente du module lunaire.
Certes, mais, dans la descente, les astronautes peuvent aussi sauter en parachute pour sauver leurs vies.









Vous allez vous dire: Comment les pauvres astronautes vont-ils réussir à survivre avec leur réserve limitée d'oxygène?
Est-ce que sauter en parachute n'est pas seulement retarder un peu leur mort?









Ne vous inquiétez pas pour eux, il y a de superbes bases lunaires sur la lune qui ont été construites lar les sélénites (habitants de la lune).
Elles ont tout le confort désiré, une réserve illimitée d'oxygène.









Et, sur la lune, les astronautes trouveront tout ce dont ils ont besoin pour leur survie, des hotdogs, des donuts du coca-cola!









Et ce que la NASA ne vous a pas montré dans ses vidéos officielles est qu'il y a une faune abondante sur la lune.
Quoique vous ne puissiez pas voir d'animaux sur les vidéos officielles de la NASA que la NASA vous permet de voir, ils existent sur des vidéos que la NASA n'a pas rendues publiques.
la NASA m'a autorisé à fouiller dans les vidéos privées qui n'ont jamais été montrées au public, et j'y ai trouvé cette perle d'un sanglier courant dans la plaine lunaire.









Il y a même des casinos pour se divertir!









Et les activités que vous pouvez trouver sur la lune n'ont rien à envier à celles que vous pouvez trouver sur terre.
Par exemple il y a des piscines lunaires sur la lune.









Et il y a aussi des stations de ski sur la lune qui permettent aux skieurs de tous niveaux de descendre les montagnes lunaires.
Comme sur terre il y a des pentes de différentes niveaux, des pistes vertes, bleues, rouges, noires...









Et les astronautes peuvent déguster leur bière, confortablement installés sur des chaises longues, tout en regardant la terre tourner lentement.









Et vous savez quoi? Si un astéroïde frappe la terre, il peuvent admirer en toute sécurité le grand spectacle, les veinards!









Je me suis intéressé au programme de la remontée de l'AGC qui peut être trouvé sur le NET.









Le programme de la routine de guidage calcule des équations utilisant les informations fournies par l'IMU (en fait l'IMU ne donne pas directement des angles et des vitesses à l'AGC, mais des impulsions que l'AGC doit compter pour les mettre à jour), et l'altitude donnée par le radar, pour obtenir de nouvelles commandes pour le moteur principal et le RCS.









L'AGC utilise la mémoire fixe (la mémoire à cordes de tores) pour faire tourner ses programmes, et la mémoire effaçable pour y stocker les données temporaires utilisées par ces programmes, mais, de manière à communiquer avec l'environnement externe (et en particulier avec les commandes du moteur principal et du RCS), il utilise des ports d'entrée/sortie (ports I/O), il ne peut le faire directement à travers la mémoire.









De manière à écrire sur un port I/O, l'AGC a une instruction dédiée appelée "WRITE"; le programme place dans l'accumulateur la valeur à écrire sur un port I/O, et appelle ensuite l'instruction WRITE, lui donnant en argument l'adresse du port I/O sur lequel écrire la valeur placée dans l'accumulateur.
Cela veut dire que, dans le programme de la routine de guidage, nous devrions trouver plusieurs appels à cette instruction pour envoyer des commandes au moteur principal et au RCS.









Et pourtant, dans tout le programme de la routine de remontée, nous ne la trouvons pas une seule fois, même pas une!









La routine "THROTTLE" permet de contrôler la poussée du moteur principal.
Elle est seulement appelée par le programme de descente, pas par le programme de remontée.









Mais, même dans cette routine, nous ne pouvons pas non plus trouver l'instruction "WRITE" qui permettrait d'envoyer la commande calculée au moteur principal.
Elle fait des calculs vains qui ne servent à rien.









Donc, quoi que fasse la routine de guidage, elle n'essaie pas de contrôler ni le moteur principal ni le RCS, quoiqu'elle soit supposée le faire.









Pourtant, si nous examinons le code de la routine de guidage, elle semble faire plein de calculs, mais ces calculs ne suivent pas un schéma logique, et ils ne sont pas utilisés pour contrôler le moteur principal ou le RCS, leur résultat n'est utilisé pour rien du tout, c'est un travail complètement inutile.
Et cela va même plus loin que le travail de cette routine étant inutile, comme nous allons le voir.









Le programme utilise principalement des macro-instructions qui sont décrites dans la documentation de l'interpréteur.
Certaines macro-instructions utilisent deux arguments (appelés X et Y), qui suivent sur les deux lignes suivantes, et d'autres utilisent un seul argument (appelé X) qui suit sur la ligne suivante.









Voici un exemple de macro-instruction avec deux arguments, la première qui est rencontrée dans la routine de remontée.
La macro-instruction "BON" teste l'aiguilleur spécifié par le premier argument (FLRCS) et se branche à l'étiquette spécifiée par le second argument (ASCENT) si cet aiguilleur est positionné.









Et voici un exemple de macro-instruction avec un seul argument.
La macro-instruction "DSU" soutrait au double accumulateur (appelé MPAC) la valeur spécifiée par l'argument (YDOT), et place le résultat dans le double accumulateur.









Maintenant, sur de nombreuses lignes du programme, nous trouvons deux macro-instructions sur la même ligne, ce qui n'est pas autorisé, car chaque macro-instruction devrait être suivie d'un ou deux arguments, et ceci aurait du être rejeté par le compilateur.









Le compilateur est le logiciel qui analyse le programme utilisateur, détecte les erreurs de syntaxe ou de logique, les signale, et, lorsqu'il ne trouve pas d'erreur, génère le code machine qui est compréhensible par l'ordinateur.
Le compilateur aurait du rejeter la majorité des instructions de la routine de remontée.









Le programme utilise aussi des variables incorrectement spécifiées, le nom d'une variable ne peut contenir un des opérateurs '+', '-'; '*', ou '/', car cela crée une confusion avec ces opérateurs.









Cette macro-instruction bleutée (STCALL) place le double accumulateur dans TGO, et fait ensuite un appel à l'étiquette ASCTERM2.









Cela signifie que le programme reprend depuis l'étiquette ASCTERM2.
A cette étiquette, l'instruction "EXIT" est utilisée pour sortir de l'interpréteur (appelé avec "TC INTPRET", que nous trouvons à plusieurs occasions dans le programme), mais nous ne sommes pas couramment dans l'interpréteur, et donc cette instruction ne devrait pas être utilisée ici.
Cette instruction est suivie par l'instruction "TCF ENDOFJOB" (aller à ENDOFJOB) qui termine la routine, ce qui signifie qu'il n'y aura pas de retour à l'appelant.









La macro-instruction "BPL" se branche à l'adresse spécifiée par l'argument qui suit si le double accumulateur (MPAC) est supérieur ou égal à zéro; manifestement la ligne qui suit contient cet argument, car RATES est une étiquette que nous trouvons dans le programme; et la macro-instruction "SET" permet de positionner un aiguilleur qui est spécifié sur la ligne suivante; cet aiguilleur est en fait spécifié sur la ligne qui suit l'argument de "BPL" (FLPC).
Cette manière de croiser les macro-instructions et leurs arguments est une fantaisie complète, et non une manière normale de procéder; elle ne peut être acceptée par le compilateur.









Les macro-instructions "DMP" et "PPDL" ont chacune un argument; elles ne devraient pas avoir été spécifiées sur la même ligne, et il n'y a pas d'argument après la ligne qui les contient, car la ligne suivante contient une macro-instruction et non un argument.









L'accumulateur est calculé avec les deux instructions "CA FLAGWRD9" et "MASK FLRCSBIT"; l'accumulateur est ensuite testé avec l'instruction "CCS A", et, si le résultat de ce calcul est positif, l'instruction suivante est exécutée, "TCF ASCTERM3", laquelle saute à ASCTERM3.
Les deux mêmes instructions "CA FLAGWRD9" et "MASK FLRCSBIT" sont exécutées à nouveau, donnant exactement le même résultat que précédemment; il est donc complètement inutile de faire deux fois le même test, c'est redondant; et, cette fois, l'instruction qui suit "CCS A" ne peut être exécutée, comme le résultat du calcul ne peut être positif, sinon il y aurait eu un branchement à ASCTERM3 lors du test précédent.
Nous avons ici manifestement un gaspillage d'instructions, en répétant inutilement deux fois le même test.









Lorsqu'une subroutine n'est pas dans la même banque de mémoire que la banque dans laquelle le programme courant tourne, elle ne peut être directement appelée, mais elle doit être appelée avec une instruction spéciale "TC BANKCALL", suivie par une déclaration "CADR" ayant en argument le nom de la subroutine à appeler dans cette autre banque de mémoire.
Ici c'est la subroutine "GODSPR" qui est appelée, et cette subroutine est dans le programme de l'affichage, qui est dans une autre banque de mémoire que la routine de remontée, ce qui explique la manière dont elle est appelée.









GODSPR retourne à l'adresse qui suit l'appel, sauf si le verbe/noun qui est utilisé correspond à un affichage clignotant; dans ce cas, il retourne à l'adresse qui est quatre lignes après l'appel.









Cela signifie que, si GODSPR était appelé avec un verbe/noun clignotant, le retour serait fait à l'étiquette "ASCTERM4"; depuis là, il y aurait un retour à l'étiquette "ASCTERM1", exécutant à nouveau les mêmes instructions, et nous aurions une boucle infinie, ce qui signifie que la routine de guidage ne se terminerait jamais.









En réalité, le programme GODSPR est appelé avec un verbe 06 et un noun 63 (CAF V06N63), et, si nous regardons dans la documentation, nous voyons que cette combinaison de verbe/noun correspond à un affichage non clignotant.









Le retour correspondra donc a à un affichage non clignotant, ce qui signifie que cela se terminera avec un branchement à ENDOFJOB, terminant la routine de guidage.
Cela signifie peut-être que le programme ne bouclera pas indéfiniment (contrairement au cas d'un affichage clignotant), mais cela signifie aussi qu'il n'y aura jamais un branchement à ASCTERM4, et, conséquemment, que les instructions que j'ai barrées avec une croix ne seront jamais exécutées, et sont donc un gaspillage inutile de mémoire.









Plus loin dans le programme, nous voyons un appel à la procédure "GOFLASH", qui est aussi dans le programme d'affichage de l'AGC, qui doit donc aussi être appelée à travers BANKCALL.









Dans les commentaires associés à GOFLASH, nous voyons que l'astronaute peut terminer un affichage clignotant de trois manières différentes.
- S'il le termine avec le verbe 34, le retour sera fait à la première instruction qui suit l'appel à GOFLASH.
- S'il le termine avec le verbe 33, le retour sera fait à la seconde instruction qui suit l'appel à GOFLASH.
- Et, s'il le termine avec le verbe 32, le retour sera fait à la troisième instruction qui suit l'appel à GOFLASH.









Si l'astronaute termine l'affichage clignotant avec le verbe 32, le retour sera fait à l'instruction "TCF -5" (reculer de 5 instructions), ce qui fait que la procédure GOFLASH va être à nouveau appelée.









Nous avons un autre exemple un peu plus loin, dans lequel, si l'astronaute termine l'affichage clignotant avec le verbe 32, le programme rebouclera en arrière, et un nouvel appel à GOFLASH sera fait.
Cela signifie que, si l'astronaute termine systématiquement l'affichage clignotant avec le verbe 32, il peut faire indéfiniment boucler la routine de guidage.
Vous pourriez dire que l'astronaute devrait être bien stupide pour bloquer la routine de guidage de cette manière, et qu'il devrait terminer l'affichage clignotant avec un autre verbe, de sorte qu'il ne bloque pas la routine de guidage.









Mais, même ainsi, cela lui prendra du temps pour taper le verbe pour terminer l'affichage clignotant, certainement plus de deux secondes, et une nouvelle routine de guidage est lancée toutes les deux secondes, ce qui signifie que la routine de guidage courante doit prendre moins de deux secondes pour tourner.
Dans Apollo 11, les routines de guidage se sont accumulées à cause des impulsions rapides de l'interface radar, retardant leur exécution...









...et ici, cela va être encore pire, avec le temps que prend l'astronaute pour taper le verbe terminant l'affichage clignotant, les routines de guidage retardées vont s'accumuler encore plus vite, provoquant une surcharge de l'ordinateur.









Et, lorsque cette surcharge de l'ordinateur survient, le résultat est la fameuse alarme 1202.









Et, lorsque l'alarme 1202 se produit, la procédure BAILOUT est appelée pour terminer le processus de la surcharge, et nous avons vu dans une vidéo précédente que cette procédure bloquait l'AGC, et empêchait son redémarrage.









Mais, de toute façon, pourquoi est-ce que les ingénieurs se seraient souciés d'écrire un programme de guidage normal pour un ordinateur...









...dont la mémoire ne fonctionnait même pas correctement!









Et, si les ingénieurs ont appelé cette mémoire "LOL", ce n'est pas parce que cela signifiait "Little Old Lady", comme on nous l'a fait croire, mais parce que cela signifiait ce que cela signifie généralement, c'est à dire "Laughing Out Loud" (riant bien fort).









Et, même si l'AGC avait vraiment fonctionné, et que la routine de guidage avait vraiment eu du sens, cela n'aurait été d'aucune aide, avec un interface de commande du RCS montrant que chaque commande verticale activait deux réacteurs verticaux directement opposés l'un à l'autre sur la même grappe...









...Annulant ainsi leurs effets respectifs, ce qui empêchait toute rotation de tangage ou de roulis.









Les ingénieurs n'ont vraiment épargné aucun effort pour s'assurer que le seul endroit où le module lunaire se poserait jamais serait le plateau de la fausse lune (dans l'aire 51), descendu avec une grue.

Site hosted by Angelfire.com: Build your free website today!