alt Hacker NewsThis is such an interesting peek into the engineering of these sort of systems with very constrained resources at the time. Like any random file you open contains little pragmatic design decisions like this
https://github.com/chrislgarry/Apollo-11/blob/master/Comanch...
# THE POSITION OF THE MOON IS STORED IN THE COMPUTER IN THE FORM OF # A NINTH DEGREE POLYNOMIAL APPROXIMATION WHICH IS VALID OVER A 15 # DAY INTERVAL BEGINNING SHORTLY BEFORE LAUNCH. THEREFORE THE TIME # INPUT BY THE USER SHOULD FALL WITHIN THIS 15 DAY INTERVAL.
Better be back home in 15 days! ;)
Replies
The LM landing algorithm was also based on a polynomial, with "time-to-go" as the variable. Problems would occur if that variable went negative.
Given the constant launch delays how could they justify hard coding a 15 day window like this?
And I'm scared to hardcode some negligible config value that will never change
The Apollo program set a requirement for a fourteen day mission from the beginning. None of the missions lasted that long; the longest was Apollo 17 at 12 and a half days.
The Space Shuttle flight software used an interpolating polynomial for the solar ephemeris, with coefficients that were valid 10+ years (I've forgotten the exact number). The solar position was an input to the atmosphere model used to compute on-orbit drag, which itself was itself an interpolating function for data generated by a model with higher fidelity. I could go on. The pattern of using interpolation formulas to save memory and CPU cycles was (is) a common one.
People would be surprised by the amount of data required for on-board guidance and navigation software. Some of it is non-mission specific, but much of it must be generated for each mission. During the Shuttle era, these parameters were called I-Loads (for Initialization, of course) and were a separate memory load from the flight software itself.