Transcriber’s notes
The first page if this document contains some unreadable areas where inference from context has been used to replace the missing words.
See listDEC 22 196666-FM1-189FM/Deputy Chief, Mission Planning and Analysis DivisionWe’ve bit the bullet on GRR
The fact that the 206 LM is the only LM to be powered up when launched presents a requirement for some unique manner for the G&N to detect or at least be informed that liftoff has occurred. In the absence of a hardwire liftoff signal, it had been intended to transmit a guidance reference release (GRR) discrete by means of an RF link to the guidance system at a pre-determined time prior to liftoff. Most recently this value was at T-30 seconds in the countdown. Once this signal was sent there was no way to stop the platform from being released and the computer transmitting commands on its preset sequence. This has caused a great deal of concern everywhere, – at MIT, at the Cape, and here at MSC since Saturn countdown history includes some rather weird holds. Our problem was that any interruption in the countdown occurring after GRR was trans- mitted would force a recycle of about 2 hours to get the G&N squared away again and could very likely result in scrubbing that launch attempt. MIT has proposed a fix for this by a change in the spacecraft computer pro- gram which we have decided to implement. It is the purpose of this memo- randum to inform you of this rather significant programming chance.
In place of a hardwire or RF signal of liftoff, we intend to detect the change in acceleration that occurs at liftoff by the guidance system itself. Since the platform is activated long before this time, it is merely necessary to provide a small, relatively simple program for mon- itoring the ΔV which, when a pre-established threshold has been exceeded, could provide a discrete to be treated precisely ns the GRR signal. Ob- viously this is not any gigantic breakthrough except in the sense we have decided to do it. Although the concept seems well founded, I'm sure there will be some continuing discussions as to the threshold to be selected.
MIT is currently proposing 1.1 g's. (Recall the LM G&N is experiencing 1 g prior to engine ignition). In order to permit discussion to rage on on this subject, the threshold will be located in erasable storage. Another choice to be made but which no doubt influences the documentation of the program is what system should be established as prime operationally. MIT would prefer using the ΔV monitor as backup with the signal sent within the last several seconds prior to liftoff. This is because the liftoff may not be detected for as much as 9 seconds which would result in small spacecraft state vector errors. I am sure those responsible for the control of the flight will insist that the G&N ΔV monitor be prime and the GRR discrete via RF would be sent only as a backup in the event some G&N fail- ure has been detected immediately after liftoff.
It is probably worth pointing out that MIT is anxious to make this change and are confident that it is something they can really do without running into trouble. They feel the impact on program delivery is negligible and in fact point out that their effort required for this programming change and its verification will probably be less than that required for the de- velopment of workaround procedures involved in the recycle countdown. If we run into some sort of insurmountable problem not foreseen at this time, it should be a relatively simple matter to retreat to the system we had before this change, at least insofar as the spacecraft computer program is concerned. The basic programming to handle the GRR signal is not being changed. Accordingly, if we revert to the procedure of sending GRR at T-30 seconds it will only be necessary to change the value of this time in the erasable load.
Well, that's about it. I hope everyone will be happy about this. I know I am, if it only cuts down on the number of telephone calls on this hor- rible subject.