|
Bryan Sullivan in 1969 – from Goddard MSFN Technical Information Bulletin Volume 6, Number 11, July 20 1969. (Click the image to download a copy.)
ASTRO, the software mentioned in the 1969 article linked above, was an early version of Bryan’s diagnostic tool running on the 642B computer. The final version, SABRE, ran on the 1218. |
During the lead up to Apollo-8 mission, several data flow tests at HSK failed intermittently. In most attempts, the command inputs from Goddard Computers on our Net-4 line were completely ignored by our current command mission software. Requests by the NASA test conductors to reload and reinitialise our system software always seemed to rectify this problem which occurred regardless of whether we used our CP1 or CP2 computer.
I suggested that we split the Net-4 hardware connection so that the test data would feed both computers simultaneously. I would produce a short diagnostic software program to run concurrently in the second computer. Such a configuration (referred to as an un-approved ‘kludge’) installed in the rear of the modem racks in the Communications Centre would not be easily noticed by any of our senior staff.
I started writing the diagnostic software while Bill Waugh and Laurie Turner set to work on splitting the Net-4 hardware connection as they were authorised to work in the Comm. Centre and Ron Hicks assumed an overseeing role in the operation.
|
Laurie Turner, Bill Waugh, Ron Hicks, Bryan Sullivan and Tony Gerada each played a role in the Honeysuckle Command Data Kludge.
Images from the 1967 staff photos by Hamish Lindsay. |
After several days we were ready for the next GSFC scheduled data flow test. With the mission operations software running in CP 1 and my diagnostic program running in CP 2 the whole command data flow test ran perfectly with each of the spacecraft command details listed on the high speed printer. The diagnostic program in CP 2 also recorded the data on a separate magnetic tape in binary coded octal format for later analysis also, without attracting the attention of any senior staff.
Ron and I examined our test magnetic tape one evening and were surprised to see such a large amount of data for each spacecraft command, which consisted of eighty columns across by ten lines. As one single spacecraft real time command (RTC) consisted of a vehicle address, a system address followed by a three digit command number i.e. twenty four binary bits in total, why and what was all this additional data for?
|
Bryan Sullivan and Ron Hicks in the Computer area. |
After some late night discussions with the appropriate GSFC engineers, some evening visits to the Switching Centre in Deakin, ACT, part of the worldwide communications for all space tracking stations (NASCOM), their technical staff provided me with much information and documentation regarding this vast network.
I now knew that a particular spacecraft message or command was encapsulated by a large header and smaller trailer which were applicable only to the NASCOM portion of the network.
Back at HSK, Ron and I commenced decoding each individual RTC data block, along with its unique polynomial error protection (PEP) code. The PEP code detected errors independently of any transmission line errors as specified in the NASA SP- 87 manual.
The encapsulating header and trailer contained quite a variety of parameters such as:
modem synchronising codes, total length of transmission, parity code indicators both lateral and longitudinal, data definition codes for five, seven or eight levels, data format either binary coded octal or hexadecimal, check sums, source code, destination code, start of data code. All of this preceded the Apollo message content followed by an end of data code and an end of transmission code.
Think of this as like mailing an ordinary letter: the envelope, stamp(s), sticker(s) e.g. card only, airmail etc., the address to: and from:, a subject …….. etc etc …………
Now, back to the Apollo Command problem at HSK: Armed with a more complete knowledge of the high speed data transmission problem between GSFC, NASCOM and HSK it became obvious that it was due to a wrong destination address in the command test data i.e. the Goldstone (GDS) station instead of the HSK address code.
On several occasions between Apollos 9, 10 and 11 this frustrating problem was investigated again with the intervention of the Network Operations Management staff and without tying up a second operational 642B computer.
During the long delay after the Apollo 13 disaster, I set about converting my diagnostic software to run on our spare UNIVAC 1218 computer while Tony Gerada in the Communications Centre converted the original wiring ‘kludge’ into some spare plug and jack positions on the front panel of the modem cabinets. The new software along with some operating enhancements soon became a handy diagnostic tool.
|
Bryan Sullivan in the 1218 area. Scan: Bryan Sullivan.
|
|
The Communication Section.
Here Dick Stubbs, left foreground and Charlie Collins, right foreground, are sending teletype messages, while Tony Gerada is sitting at the operations console in the centre. Fred Hill [Comms Tech] is monitoring the switching and patch panel behind.
Photo and notes: Hamish Lindsay. |
Prior to a trip I made to the US for a training course at the NASA Network Test and Training Facility, the HSK station director, Tom Reid, asked me to demonstrate this process to NASA engineers but under no circumstances release a copy of our software to them. He said there was a more formal process for this and gave me the name of the NASA person to contact.
The demonstration at the Goddard Space Flight Centre was a success and witnessed by software engineers including some from UNIVAC Systems Div.
My software eventually became incorporated into the HSK Simulation System and was used to add a degree of realism for the staff on the station operations console. It provided command sequences in line with events as detailed in the timeline of the Mission Flight Plan document. For the Apollo 14 and 15 missions it was operated within the Simulation Room, generating strings of spacecraft commands, where the HSK operators were unable to tell the difference as to whether they were emanating from mission control at Houston or from behind the tinted glass windows of the our simulation room.
|
The Honeysuckle Creek Simulation Room.
At left is the window looking through to the USB Area.
Polaroid photo: Ian Grant. Scan: Colin Mackellar. |
What was thought to be a simple hardware problem turned out to be a very challenging exercise. The ultimate solution was a long investigation and the development of software and operating procedures to augment the HSK Simulation System. It proved to be a great training advantage during the Apollo 15, 16 and 17 missions. It was incorporated into the horizon countdown (H-30 minutes) to acquisition of signal (AOS). It was also incorporated into the Software Catalogue for the Apollo Network (SCAN) document.
Even though system diagnostic procedures of this scale may still involve a ‘kludge’ in the idiom of the technician, now days it is more broadly referred as ‘hacking’, which is the subject of a book titled The Cuckoo’s Egg by Clifford Stoll. The author tells a true story of his relentless investigation and pursuit of a ‘break in’ to the university’s computer system ….
________
