This 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! ;)

▲

CaptainRefsmat 5 minutes ago | parent | next [-]

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.

▲

sehugg 4 hours ago | parent | prev | next [-]

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.

▲

lloydatkinson 2 hours ago | parent | prev | next [-]

Given the constant launch delays how could they justify hard coding a 15 day window like this?

	▲	teraflop an hour ago \| parent \| next [-]
		The coefficients are stored in writable memory as input data. Only the structure and degree of the polynomial are hard-coded in the program. So if the launch is delayed you just change the data. Of course, the justification is that compute and memory were at an extreme premium on the spacecraft. Accurately predicting the position of the moon at arbitrary times requires more complicated calculations. You can dramatically optimize the calculation by fitting a polynomial approximation which is valid for the length of the mission. And there's no reason to waste resources fitting that polynomial in space when it could be done on the ground, using much more powerful machines. The AGC is what tends to get the press. It's easy to forget that the Apollo program relied on a cutting-edge distributed hardware and software stack, most of which was in Mission Control at the Real Time Computing Center.
	▲	bragr an hour ago \| parent \| prev [-]
		It wasn't hardcoded. The exact mission parameters (mission clock, moon position, orbital parameters, etc) were uploaded by mission control the morning of the launch. From that point, they had 15 days. The longest Appolo mission was 12.5 days.

▲

sthuck 3 hours ago | parent | prev [-]

And I'm scared to hardcode some negligible config value that will never change