(This page is under construction. Ye who enter here, abandon all hope!)

Reverse Engineering

Early Block I Downlist Protocol
Late Block I Downlist Protocol
Early Block II Downlist Protocol
Mid Block II Downlist Protocol
Late Block II Downlist Protocol
Display Formatted Telemetry

Downlist Versioning
Version Aliases
The "TSV" Files
The "Documentation" Files

Introduction

The original AGC (and our emulators, yaAGC and yaAGCb1) periodically emitted (emit) telemetry data in the form of "downlists" that consist of individual "downlinked" items of data. By a downlist, I mean a sequence of downlinks, each having a fixed interpretation in terms of its position in the emitted data stream. Virtual AGC has up to now provided two methods of accessing those downlists, with one of the methods being based on the other:

An API based on the files DecodeDigitalDownlink.c, ddd-*-*.tsv, and the header file agc_engine.h appearing in the Virtual AGC software tree's yaAGC/ folder. Usage of the API is discussed elsewhere.
yaTelemetry, which is itself a stand-alone C++ program based on the API. yaTelemetry is discussed elsewhere.

However up to now, these methods have implemented only the downlist transmission protocol used the flown manned Apollo missions, leaving the unmanned missions and the AGC software versions that were not flown completely untouched. The emphasis of this page is implementation of those overlooked earlier protocols. Whereas to the extent that the final protocol is discussed, it is merely for completeness.

The basic facts which must be understood to proceed with the discussion are these:

Each AGC software version partitions the telemetry information it emits into 1-6 different types of downlists, with the particular downlist being emitted at any given time depending on the current context, i.e. on which numbered program (Pnn) or major routine (Rnn) currently executing.
Over the course of the Apollo software-development effort, the protocol for transmission of the downlists evolved. For our purposes here, I've partitioned those into four categories, in roughly chronological order. This partitioning is subjective, based on how convenient I felt implementation was, and your opinion may vary.

The early Block I protocol
The late Block I protocol
The early Block II protocol
The mid (and late) Block II protocol(s)

Each downlist consists of fixed number of downlinked 15-bit "words", which varies from 40 to 200, depending on the particular protocol. For the early Block I protocol, the downlist size is only nominally fixed (40 words), because a few extra words can be downlinked asynchronously with respect to the fixed 40 words.
Each downlinked word is accompanied by a separate "word-order" bit whose value distinguishes downlinked words that have a special purpose rather than being just pure "data". Special words include ID words (see the next item) and asynchronously-emitted words (see the preceding item). The level (i.e., set vs reset) of the word-order bit that signifies a data word is not the same in all versions.
Some AGC software versions have several different types of downlists, all sharing the same protocol, but nevertheless differing in the interpretations of the downlinked data. In these cases, the first word of a downlist is always an "ID" word giving the type of the downlist. Moreover, sometimes one of the items on a downlist is what's known as a "SYNC" word, which always has the same value, and seems to have no purpose other than to exist. We won't be considering the existence or non-existence of ID and SYNC words to be part of the protocols, but merely exemplars of downlinked items that happen to belong to the downlists, though we will provide information concerning them. This will perhaps become clearer later.

Downlist References

Here's an abbreviated, roughly-chronological list of reference materials consulted in implementing AGC downlists in Virtual AGC. It's "abbreviated" in the sense that I haven't necessarily listed references that aren't relevantly different from those already listed. Conversely, in a burst of uncharacteristic wishful thinking, references I wish I had but currently don't are also sometimes listed.

Mission or Software	CM	LM	Notes
SUNRISE program	"R-467, "The Compleat Sunrise, Being a Description of Program SUNRISE (SUNRISE 33)", Section "DOWNRUPT PROCESSOR" Sunrise 45 source code	N/A
AS-202	GSOP R-477 Rev 2, Section 8.1.1 "AGC Digital Downlink" Corona 261 source code	N/A	MSC 66-FM-50 (Apollo 1, see below) in some cases describes differences from the AS-202 downlists.
Apollo 1	MSC 66-FM-50, "Command Module Guidance Computer Software Requirements, Mission AS-204" Sunspot 247 source code	N/A	An additional reference, AS-204 reference cards, "AGC DOWNLINK FORMAT", contains downlist documentation that could be interpreted as being for AS-204, but I would advise against doing so, since it's far out of date with respect to 66-FM-50, and contradictory to it as well.
Apollo 4	GSOP R-537, Section 3.4 "AGC Digital Downlink" SOLRUM55 source code	N/A
Aurora 88 program	N/A	Aurora 88 source code
SUNBURST 37 program	N/A	Sunburst 37 source code
DAP Aurora 12 program	N/A	DAP Aurora 12 source code
Apollo 5	N/A	Sunburst 120 source code
Apollo 6	GSOP R-537, Section 3.4 "AGC Digital Downlink" SOLRUM55 source code	N/A
2TV-1	SUNDIAL D reference cards, "NOMINAL CGC DOWNLINK LIST" Sundial E source code	N/A
Apollo 7	Sundisk 282 source code	N/A
Apollo 8	GSOP R-577 (COLOSSUS 1 & 1A), Section 2 "Data Links" Rev 2 Colossus 237 source code: here and here	N/A
Apollo 9	GSOP R-577 (COLOSSUS 1 & 1A), Section 2 "Data Links" Rev 2 Colossus 249 source code: here and here	GSOP R-557 (SUNDANCE 306), Section 2 "Data Links" Rev TBD Document E-2164, "Guidance, Navigation, and Control Lunar Module Functional Description and Operation Using Flight Program SUNDANCE", Section 3.4.1 "LGC Digital Downlink" Sundance 306 source code: here and here
Apollo 10	GSOP R-577 (COLOSSUS 2), Section 2 "Data Links" Rev 4 MANCHE45R2 source code: here and here	GSOP R-567 (LUMINARY), Section 2 "Data Links" Rev 3 LUM69R2 source code: here and here
Apollo 11	GSOP R-577 (COLOSSUS 2A), Section 2 "Data Links" Rev 5 Comanche 55 source code: here and here	GSOP R-567 (LUMINARY 1A), Section 2 "Data Links" Rev 4 LMY99R1 source code: here and here
Apollo 12	GSOP R-577 (COLOSSUS 2C), Section 2 "Data Links" Rev 7 Comanche 67 source code: here and here	GSOP R-567 (LUMINARY 1B), Section 2 "Data Links" Rev 6 Luminary 116 source code: here and here
Apollo 13	GSOP R-577 (COLOSSUS 2D), Section 2 "Data Links" Rev 9 MANCHE72R3 source code: here and here	GSOP R-567 (LUMINARY 1C), Section 2 "Data Links" Rev 8 LM131R1 source code: here and here
ZERLINA program	N/A	Zerlina 56 source code: here and here
LUMINARY 163 program	N/A	Luminary 163 source code: here and here
Apollo 14	GSOP R-577 (COLOSSUS 2E), Section 2 "Data Links" Rev 13 Comanche 108 source code	GSOP R-567 (LUMINARY 1D), Sections 2, 4, & 5 PRELIMINARY GSOP R-567 (LUMINARY 1D), Sections 2, 3, 4, & 5 PRELIMINARY CHANGE PAGES, Second Issue GSOP R-567 (LUMINARY 1D), Section 2 "Data Links" Rev 10 Luminary 178 source code: here and here	From the list of PCRs incorporated, the PRELIMINARY documents confine their changes to Rev 9, so they remain incomplete with respect to the final (Rev 10). As to whether any of the uncompleted PCRs affect the downlist data specifically, I don't know.
Apollo 15	GSOP R-577 (COLOSSUS 3), Section 2 "Data Links" Rev 14 Artemis 72 source code: here and here	GSOP R-567 (LUMINARY 1E), Section 2 "Data Links" Rev 12 Luminary 210 source code: here and here
Apollo 16
Apollo 17
Skylab 2	GSOP R-693 (SKYLARK 1), Section 2 "Data Links" Skylark 48 source code: here and here	N/A
Skylab 3
Skylab 4
ASTP

Early Downlist Protocols

Reverse Engineering

For those who are confident in their ability to deal with Block I and Block II assembly language, or want to consider it as a learning experience, the principal means of understanding the downlist-protocol details is the source code of the DOWN-TELEMETRY_PROGRAM.agc source code for the AGC software version of interest.

For those of us with less such confidence, the program piPeripherals/piTelemetry.py has been created to view the actual downlinks emitted by the AGC, to experiment with implementation of the protocols, or even to "unofficially" be used much as yaTelemetry is, albeit less flair and style. The syntax for doing so is this:

piTelemetry.py --port=PORTNUMBER [ --software=AGCSOFTWARE ] [ --block=N ] [ --packet=M ]

where:

--port=PORTNUMBER (default 19799) is an unused TCP port monitored by the AGC emulator
--software=AGCSOFTWARE, if present, specifies the AGC software being run by the AGC CPU emulator yaAGC or yaAGCb1, which implicitly sets the protocol used and the lists of items on the downlists; AGCSOFTWARE must match one of the following: Sunrise45, Sunrise69, Corona261, Sunspot247, Solarium055, SundialE, Aurora88, Aurora12, Borealis, Sunburst37, or Sunburst120. If not present, then raw downlinks suitable for reverse engineering an unknown protocol are displayed; in this case, the following additional command-line switches are also useful:

--block=N, where N is either 1 (Block I) or 2 (Block 2/LGC).
--packet=M (default 40) is the maximum number of downlinked items to print per line.

Here's a table of the command-line switches I've personally found to be helpful for reverse engineering the downlists of specific AGC software versions that I've run under the VirtualAGC GUI:

AGC Software Version	Usage	Reverse-Engineering Command^*
SUNRISE 45 SUNRISE 69	Block I CM G&N Acceptance	piTelemetry.py --port=19672 --packet=40 --block=1
CORONA 261 SUNSPOT 247 SOLARIUM 55	AS-202 CM Apollo 1 CM Apollo 4, 6 CM	piTelemetry.py --port=19672 --packet=100 --block=1
SUNDIAL E	2TV-1 CM Block II CM G&N Acceptance	piTelemetry.py --port=19698 --packet=100 --block=2
AURORA 88 DAP AURORA 12 BOREALIS	LM G&N Acceptance Concept development Validation of yaAGC	piTelemetry.py --port=19798 --packet=100 --block=2
SUNBURST 37 SUNBURST 120	Development Apollo 5 LM	piTelemetry.py --port=19798 --packet=200 --block=2
^*Since `--packet=40, 100,` or `200` downlinks per line might be too wide to comfortably display on your computer's screen, you might try `--packet=20` to cleanly divide each downlink into multiple lines.

Another helpful thing to be able to do while reverse engineering these protocols is to run the AGC emulator in debugging mode, so that the AGC software's execution can be paused and easily trackable values inserted into the AGC memory locations being downlinked. Otherwise, it all too often can happen that the AGC's erasable memory is mostly zeroes, and that's not too informative when your entire downlist is 0, since you find yourself asking, Was it parsed correctly by the receiving software or not? Whereas if you forced a certain memory location to have a value of (say) 12345 and 12345 shows up where you expect it in the downlist, then you've got something!

Early Block I Downlist Protocol

This protocol applies only to the AGC program SUNRISE. SUNRISE is the earliest surviving Block I AGC program we've seen, though it's known that there are earlier ones still that we haven't. SUNRISE is available to us in two versions (SUNRISE 45 and 69), though the two versions are identical in terms of telemetry. These programs were not flown, but were used in acceptance testing for the Block I Command Module G&N systems. Here's relevant info from document R-467, from the standpoint of Virtual AGC's "virtual wiring" framework:

Emits a 15-bit word every 40 ms. The AGC does this by placing the word into the CPU's OUT4 register (address octal 14) and then writing to the CPU register OUT1 (address octal 11). The only bit of OUT1 that's relevant to this discussion is the word-order bit (mask 00400).
Entries are emitted in reverse order from their appearance in the downlist definitions of DOWN-TELEMETRY_PROGRAM.agc.
The emitted words are of four types:

Relay words. These relate to AGC manipulations of the "relay banks" and are emitted asynchronously (with respect to the timing and ordering of the downlists) whenever they occur. I think that the relay banks referred are those of the DSKY, and are what would be referred to as DSPTAB, ..., DSPTAB +10 in the downlists of later AGC software (though not asynchronous in that later software).
Input Character words. These are keycodes received by the AGC from the DSKY keypad or from the uplink from the ground, or else are "marks" from astronauts taking star sightings. These too are emitted asynchronously with respect to the downlists.
Downlist-data words. A downlist-ID word is distinguished from all of the other emitted types of words by the word-order bit (see OUT1 above) being 1. From the Sunrise source code, I see that there is a single downlist, containing 32 data entries.
Downlist-ID words. A downlist ID word is emitted after each chunk of 4 downlist-data words. The ID word contains the index of the data word emitted immediately prior.

In the absence of relay words or input-character words, a complete downlist (32 data words + 8 ID words) is emitted every 1.6 seconds.

Here's a summary of the formats of the 4 different word types, representing OUT4 in binary as ABC DEF GHI JKL MNO:

Word Type	Word-Order Bit (OUT1)	OUT4
Relay Words	0	`ABC D` ≠ `000 0` is a relay-word address, `EF GHI JKL MNO` contains the relay settings.
Input-Character Words	0	`ABC DE` = `000 01`, `F GH` are unused, `I` = MARK button, `J` = `0` for keyboard or `1` for uplink, `KL MNO` = character code for the DSKY keyboard or uplinked character.
Downlist-Data Words	1	Entire word is data
Downlist-ID Words	0	`ABC DE` = `000 00`, `F GHI JKL MNO` is the index into the downlist of the immediately-preceding data word.

So for concreteness: The downlist data items as specified by DOWN-TELEMETRY_PROGRAM.agc in the Sunrise source code (at label DNLST1) consist of:

TIME1 TIME2 IN0 IN2 IN3 ... TNUV+3 TNUV+4 TNUV+5 GYROD+5 GYROD+3

Absent any relay or input-character data, the downlist would actually be emitted as follows:

data GYROD+3
data GYROD+5
data TNUV+5
data TNUV+4
ID 34 octal
data TNUV+3
...
data IN3
ID 04 octal
data IN2
data IN0
data TIME2
data TIME1
ID 00 octal

If SUNRISE is run from the VirtualAGC GUI, a suitable command for displaying the telemetry is:

piPeripheral/piTelemetry.py --protocol=sunrise --port=19672

Here's a sample, in which I ran SUNRISE 45 and punched the DSKY keys V37E00E:

...
Downlist
TIME1: 01270        TIME2: 00000        IN0: 00000          IN2: 00000          IN3: 00000          OUT1: 00400         RRECT: 00000        RRECT+1: 00000      
RRECT+2: 00000      RRECT+3: 00000      RRECT+4: 00000      RRECT+5: 00000      TDELTAV: 00000      TDELTAV+1: 00000    TDELTAV+2: 00000    TDELTAV+3: 00000    
TDELTAV+4: 00000    TDELTAV+5: 00000    VRECT: 00000        VRECT+1: 00000      VRECT+2: 00000      VRECT+3: 00000      VRECT+4: 00000      VRECT+5: 00000      
TNUV: 00000         TNUV+1: 00000       TNUV+2: 00000       TNUV+3: 00000       TNUV+4: 00000       TNUV+5: 00000       GYROD+5: 00000      GYROD+3: 00000      
Downlist
TIME1: 01530        TIME2: 00000        IN0: 00000          IN2: 00000          IN3: 00000          OUT1: 00400         RRECT: 00000        RRECT+1: 00000      
RRECT+2: 00000      RRECT+3: 00000      RRECT+4: 00000      RRECT+5: 00000      TDELTAV: 00000      TDELTAV+1: 00000    TDELTAV+2: 00000    TDELTAV+3: 00000    
TDELTAV+4: 00000    TDELTAV+5: 00000    VRECT: 00000        VRECT+1: 00000      VRECT+2: 00000      VRECT+3: 00000      VRECT+4: 00000      VRECT+5: 00000      
TNUV: 00000         TNUV+1: 00000       TNUV+2: 00000       TNUV+3: 00000       TNUV+4: 00000       TNUV+5: 00000       GYROD+5: 00000      GYROD+3: 00000      
Key VERB
Downlist
TIME1: 01774        TIME2: 00000        IN0: 00000          IN2: 00000          IN3: 00000          OUT1: 00400         RRECT: 00000        RRECT+1: 00000      
RRECT+2: 00000      RRECT+3: 00000      RRECT+4: 00000      RRECT+5: 00000      TDELTAV: 00000      TDELTAV+1: 00000    TDELTAV+2: 00000    TDELTAV+3: 00000    
TDELTAV+4: 00000    TDELTAV+5: 00000    VRECT: 00000        VRECT+1: 00000      VRECT+2: 00000      VRECT+3: 00000      VRECT+4: 00000      VRECT+5: 00000      
TNUV: 00000         TNUV+1: 00000       TNUV+2: 00000       TNUV+3: 00000       TNUV+4: 00000       TNUV+5: 00000       GYROD+5: 00000      GYROD+3: 00000      
Key 3
Relay NOFLASH VD1=3 VD2=(blank)
Key 7
Relay NOFLASH VD1=3 VD2=7
Downlist
TIME1: 02254        TIME2: 00000        IN0: 00000          IN2: 00000          IN3: 00000          OUT1: 00400         RRECT: 00000        RRECT+1: 00000      
RRECT+2: 00000      RRECT+3: 00000      RRECT+4: 00000      RRECT+5: 00000      TDELTAV: 00000      TDELTAV+1: 00000    TDELTAV+2: 00000    TDELTAV+3: 00000    
TDELTAV+4: 00000    TDELTAV+5: 00000    VRECT: 00000        VRECT+1: 00000      VRECT+2: 00000      VRECT+3: 00000      VRECT+4: 00000      VRECT+5: 00000      
TNUV: 00000         TNUV+1: 00000       TNUV+2: 00000       TNUV+3: 00000       TNUV+4: 00000       TNUV+5: 00000       GYROD+5: 00000      GYROD+3: 00000      
Key ENTER
Relay FLASH VD1=3 VD2=7
Relay  ND1=(blank) ND2=(blank)
Downlist
TIME1: 02530        TIME2: 00000        IN0: 00000          IN2: 00000          IN3: 00000          OUT1: 00400         RRECT: 00000        RRECT+1: 00000      
RRECT+2: 00000      RRECT+3: 00000      RRECT+4: 00000      RRECT+5: 00000      TDELTAV: 00000      TDELTAV+1: 00000    TDELTAV+2: 00000    TDELTAV+3: 00000    
TDELTAV+4: 00000    TDELTAV+5: 00000    VRECT: 00000        VRECT+1: 00000      VRECT+2: 00000      VRECT+3: 00000      VRECT+4: 00000      VRECT+5: 00000      
TNUV: 00000         TNUV+1: 00000       TNUV+2: 00000       TNUV+3: 00000       TNUV+4: 00000       TNUV+5: 00000       GYROD+5: 00000      GYROD+3: 00000      
Key 0
Relay  ND1=0 ND2=(blank)
Key 0
Relay  ND1=0 ND2=0
Downlist
TIME1: 03010        TIME2: 00000        IN0: 00000          IN2: 00000          IN3: 00000          OUT1: 00400         RRECT: 00000        RRECT+1: 00000      
RRECT+2: 00000      RRECT+3: 00000      RRECT+4: 00000      RRECT+5: 00000      TDELTAV: 00000      TDELTAV+1: 00000    TDELTAV+2: 00000    TDELTAV+3: 00000    
TDELTAV+4: 00000    TDELTAV+5: 00000    VRECT: 00000        VRECT+1: 00000      VRECT+2: 00000      VRECT+3: 00000      VRECT+4: 00000      VRECT+5: 00000      
TNUV: 00000         TNUV+1: 00000       TNUV+2: 00000       TNUV+3: 00000       TNUV+4: 00000       TNUV+5: 00000       GYROD+5: 00000      GYROD+3: 00000      
Key ENTER
Relay  ND1=(blank) ND2=(blank)
Relay  MD1=0 MD2=0
Relay NOFLASH VD1=3 VD2=7
Downlist
TIME1: 03270        TIME2: 00000        IN0: 00000          IN2: 00000          IN3: 00000          OUT1: 00400         RRECT: 00000        RRECT+1: 00000      
RRECT+2: 00000      RRECT+3: 00000      RRECT+4: 00000      RRECT+5: 00000      TDELTAV: 00000      TDELTAV+1: 00000    TDELTAV+2: 00000    TDELTAV+3: 00000    
TDELTAV+4: 00000    TDELTAV+5: 00000    VRECT: 00000        VRECT+1: 00000      VRECT+2: 00000      VRECT+3: 00000      VRECT+4: 00000      VRECT+5: 00000      
TNUV: 00000         TNUV+1: 00000       TNUV+2: 00000       TNUV+3: 00000       TNUV+4: 00000       TNUV+5: 00000       GYROD+5: 00000      GYROD+3: 00000      
Downlist
TIME1: 03530        TIME2: 00000        IN0: 00000          IN2: 00000          IN3: 00000          OUT1: 00400         RRECT: 00000        RRECT+1: 00000      
RRECT+2: 00000      RRECT+3: 00000      RRECT+4: 00000      RRECT+5: 00000      TDELTAV: 00000      TDELTAV+1: 00000    TDELTAV+2: 00000    TDELTAV+3: 00000    
TDELTAV+4: 00000    TDELTAV+5: 00000    VRECT: 00000        VRECT+1: 00000      VRECT+2: 00000      VRECT+3: 00000      VRECT+4: 00000      VRECT+5: 00000      
TNUV: 00000         TNUV+1: 00000       TNUV+2: 00000       TNUV+3: 00000       TNUV+4: 00000       TNUV+5: 00000       GYROD+5: 00000      GYROD+3: 00000      
...

Notice the Key and Relay downlinked items, which occur asynchronously with respect to the downlists.

Late Block I Protocol

This protocol applies to the AGC programs CORONA, SUNSPOT, and SOLARIUM.

The AGC emits a 15-bit downlinked word by placing it into the CPU's OUT4 register (address octal 14) and then writing to the CPU register OUT1 (address octal 11). The only bit of OUT1 that's relevant to this discussion is the word-order bit (mask 00400).
Downlists consist of 100 15-bit words.
Entries are emitted in reverse order from their appearance in the downlist definitions of DOWN-TELEMETRY_PROGRAM.agc.
The word-order bit is normally set to 0. Certain words having a special purpose have a word-order bit of 1. (The original documentation refers to these as "data" and "ID" words respectively, but that nomenclature does not reflect their usage, so please ignore that ancient usage for the purpose of this discussion.)
The first word in the downlist has a word-order bit of 1 and has a value in the octal range 40000-74777 except 7400N. This pattern uniquely indicates the beginning of a downlist.
Additionally, words having the octal values 7400N may have a word-order bit of 1 and if so, are referred to as "marker" words. The usage of these words is tricky, so I apologize for the complexity of the description. Every downlist has precisely 6 marker words, three of which are logically in positions 49, 50, 51, 97, 98, and 99, assuming that the downlist's words are indexed from 1 to 100. I say "nominally" because there's a difference in the transmitted order of the marker words vs the logical order. Marker words may be emitted out-of-order with respect the logical ordering, in that they may be transmitted earlier than their logical order implies. The first three marker words may be transmitted prior to position 49, and the second three marker words may be transmitted prior to position 97 (but after position 51). Therefore, the receiving algorithm must shuffle the order of the received words to move the move the marker words into their expected positions.

Although I've said that ID and SYNC words in the downlists are not a part of the protocol in my estimation, but merely exemplars of downlinked words contained in the downlists, now is as good a place as any to describe what I've found about them, and about the downlist titles as well. The first two words of the downlist are an ID word and a SYNC word. The value of the SYNC word is always octal 00437. Because there is an ID word, each AGC software version using this protocol can have multiple downlist types. And here they are, to the best of my understanding:

AS-202 (Corona261):

Powered List: ID=62067
Update List: ID=62001

Apollo 1 (Sunspot247):

Update List: ID=62001
Powered and Boost List: ID=62066
Coast and Align List: ID=62153
Entry List: ID=62240

Apollo 4, 6 (Solarium055):

Powered List: ID=62067
Update List: ID=62001

However, some of the ID words and titles listed above are based on inferences on my part.

As far as the ID is concerned, it appears to me that it is constructed by the assembler when the source-code of DOWN-TELEMETRY_PROGRAM.agc is assembled, by applying the ADRES pseudo-op (which linearizes the address space) to the starting address of the downlist definition. (Or more precisely, to the first segment of the downlist that's specific to the downlist type, rather than being a segment that's common to all of the downlist types of that AGC version.) In Solarium 55, for example, the relevant code in DOWN-TELEMETRY_PROGRAM.agc is:

...
006177,000204:    2566           06067        LDNLST1            ADRES    501LSTA1                      	(linearized address of first downlist)
006178,000205:    2567           06001        LDNLST2            ADRES    501LSTA2                      	(linearized address of second downlist)
...
006229,000256: 10,6001           01117        501LSTA2           ADRES    COMPNUMB                      	(starting point of second downlist)
...
006286,000313: 10,6067           01457        501LSTA1           ADRES    TFF        +1                 	(starting point of first downlist)
...

At some point during the actual process of emitting the downlist, LDNLST1 or LDNLST2 gets loaded into the variable DNLSTADR, which is further processed by discarding all but the lowest 11 bits, and then adding 60000, thus turning 06067 or 06001 as above into 62067 or 62001:

006027,000054:    2417           40672                           CS       DNLSTADR                      	# CHANGES IN DNLSTADR NOT HONORED UNTIL
006028,000055:    2420           40000                           COM                                    	# THIS PHASE.
006029,000056:    2421           50671                           TS       LDATALST                      	#
006030,000057:    2422           74302                           MASK     LOW11                         	#
006031,000058:    2423           64170                           AD       60K                           	# AT FOD'S REQUEST.

As far as the titles of the downlists are concerned, Sunspot titles (and IDs) are easy to find since they're documented. For Corona and Solarium, documentation and AGC source code seem to agree that ID 62001 is the the Update List. Unfortunately, I've found no smoking gun in either documentation or source code about a reasonable title for ID 62067, though there is agreement that the associated downlist is emitted all of the time except during updates, and program comments sometimes mention the "nominal" list. In spite of that, I've settled on Powered List as the name, in analogy with Sunspot and with the CM downlists in the late Block II protocol.

Early Block II Protocol

This protocol applies to the AGC programs SUNDIAL, AURORA, DAP AURORA, BOREALIS, and early versions of SUNBURST.

Each downlist has 100 15-bit words, except that SUNBURST has 200. (Note that it is not necessary to know how many words the downlist has, because the start/end of a downlist is always detectable regardless.)
Entries are emitted in reverse order from their appearance in the downlist definitions of DOWN-TELEMETRY_PROGRAM.agc.
Data is always emitted in pairs of 15-bit words, in the following invariable sequence:

The first word is placed in CPU register 34₈.
The word-order bit (mask 00100 of register 13₈) is normally set to 1 and is left at that value, but it is explicitly set to 0 if the word just emitted is the start of a downlist.
The second word (i.e., the word immediately following the first word in memory) is placed in register 35₈.
The word-order bit is restored to 1 if necessary.

This works much the same (in the abstract) as for the late Block I protocol described in the preceding section. But there are some differences in detail, so let me just list those differences:

The GENADR pseudo-op is used to generate the addresses of the downlist definitions, rather than the ADRES pseudo-op used in Block I, and the only subsequent arithmetical manipulation is that only the least-significant 10 bits are retained. For example, in Sundial E, the downlist definition starts at NOMDNLST, and GENADR NOMDNLST generates the value 01724, which is already just a 10-bit number ... so that's the ID of the downlist.
The AGC source code makes it much more difficult for us to extract the definitions of the downlists hard-coded into the software, because those definitions in DOWN-TELEMETRY_PROGRAM.agc only list the first word of each pair of downlinked words. In principle it's therefore necessary, for each pair of words, to consult ERASABLE_ASSIGNMENTS.agc (or other material) to figure out what the missing downlinks are. Whereas DOWN-TELEMETRY_PROGRAM.agc source-code files for the late Block I protocol simply listed every word in the downlist. Fortunately, the program comments do explain what the even-numbered words are, so in practice it's seldom necessary to consult the erasable assignments.

Although I've said that ID and SYNC words in the downlists are not a part of the protocol in my estimation, but merely exemplars of downlinked words contained in the downlists, now is as good a place as any to describe what I've found about them, and about the downlist titles as well. The first two words of the downlist are an ID word and a SYNC word. The value of the SYNC word is always octal 00437. Since there is an ID word, each AGC software version using this protocol can have multiple downlist types.

Here are the specifics by AGC version, as I understand them:

Sundial E:

Nominal List: ID=01724

Aurora 88:

Nominal List: ID=00321
Radar List: ID=00253
AGS Initialization List: ID=00001

DAP Aurora 12: Same as Aurora 88. (I.e., the downlist types, titles, and IDs match. But the downlinked items on the downlists differ somewhat.)
Borealis: Same as Aurora 88. (I.e., the downlist types, titles, IDs, and the downlinked items on the downlists match identically.)
Sunburst 37

Nominal List: ID=00354
AGS List: ID=00001. However ... while the Sunburst 37 source code does include this downlist, the comments say that "AGSLIST IS NOT REQUIRED FOR AS206 [i.e., Apollo 5] BUT IS INSERTED IN SUNBURST TORESERVE SPACE FOR IT IN 207/8 AND FUTURE MISSIONS". By the time of Sunburst 120, the AGS List was missing entirely from the source code. At any rate, since there's no way for Sunburst 37 to actually emit the AGS List, it's not implemented in piTelemetry.py.

Mid Block II Downlist Protocol

This protocol applies only to later versions of the AGC program SUNBURST, as far as I know. By the standards I've claimed apply, this is not really a different protocol than the late Block II protocol described in the next section, but it does differ in certain superficial parameters that I thought were definitive when I originally wrote yaTelemetry, and therefore SUNBURST will not work with yaTelemetry as it is at present. The differences are as follows:

Each downlist has 100 words rather than 200 words.
The values of the ID words differ. The rules for the values of the ID words is the same as for the early Block II protocol.
The value of the SYNC word is 00437 rather than 77340.

And here are those ID words vs downlist types:

Sunburst 120 (Apollo 5):

Nominal List: ID=00236

To be clear, every AGC version using the late Block II downlist protocol should work with the mid Block II protocol as implemented in piTelemetry.py, since piTelemetry.py entirely ignores the parameters which differ from the late Block II protocol.

Late Block II Downlist Protocol

In the earlier protocols, all downlists were defined in the file DOWN-TELEMETRY_PROGRAM.agc. Whereas in the late Block II protocol, definitions of the downlists were moved to the file DOWNLINK_LISTS.agc, and the DOWN-TELEMETRY_PROGRAM.agc is merely the algorithm.

Each downlist has 200 15-bit words. Data is always emitted in pairs of 15-bit words, i.e., in doublewords, in the following invariable sequence:

The word-order bit (mask 00100 of register 13₈) is normally 1 and left as-is, but at the start of a downlist is set to 0 by explicitly outputting it.
The first word placed in CPU register 34₈.
The second word (i.e., the word immediately following the first word in memory) is placed in register 35₈.
The word-order bit is restored to 1 if necessary.

In earlier protocols, items were downlinked in reverse order of their appearance in DOWN-TELEMETRY_PROGRAM.agc. This seems to no longer be the case, and items are downlinked in the same order as their appearance in DOWNLINK_LISTS.agc. There is an exception, though, in that if a section of a downlist is designated as a "snapshot sublist", the final item in the definition is emitted first, followed by the other items from the beginning of the definition working downward.

Although I've said that ID and SYNC words in the downlists are not a part of the protocol in my estimation, but merely exemplars of downlinked words contained in the downlists, now is as good a place as any to describe what I've found about them, and about the downlist titles as well. The first two words of the downlist are an ID word and a SYNC word. The value of the SYNC word is always octal 77340.

Aside: Notice the slightly-amusing factoid that the 77340 contains 437 (from the late Block I and early Block II protocol SYNC word 00437) in reverse order. Whether that's significant or a coincidence, I don't know. It seems to me that 73400 would have been a better choice aesthetically than 77340, but what do I know?

Since there is an ID word, each AGC software version using this protocol can have multiple downlist types. Regarding the ID words and titles of the downlists, these are simply fixed for all AGC software versions using this protocol, and are not algorithmically generated:

	Downlist Title
ID	Command Module	Lunar Module
77777	Coast and Align	Coast and Align
77776	Entry and Update List	AGS Initialization and Update List
77775	Rendezvous and Prethrust List	Rendezvous and Prethrust List
77774	Powered List	Orbital Maneuvers List^*
77773	Program 22 List	Descent and Ascent List^†
77772		Lunar Surface Align List^†
^*An exception is the Apollo 9 Lunar Module SUNDANCE software, in which the downlist title for ID 77774 is "Powered List". ^†Not emitted by the Apollo 9 Lunar Module SUNDANCE software.

Displaying Formatted Telemetry

Here's how to use piTelemetry.py to display telemetry as parsed according to the protocols described above. It's pretty straightforward, as long as you know appropriate port numbers with which to connect to yaAGC or yaAGCb1, namely 19672 for Block I, 19698 for Block II, or 19798 for LGC if yaAGC/yaAGCb1 are using the same port ranges that the VirtualAGC GUI assigns to them.

AGC Software Version	Usage	Reverse-Engineering Command^*
SUNRISE 45	Block I CM G&N Acceptance	`piTelemetry.py --port=19672 --software=Sunrise45`
SUNRISE 69	Block I CM G&N Acceptance	`piTelemetry.py --port=19672 --software=Sunrise69`
CORONA 261	AS-202 CM	`piTelemetry.py --port=19672 --software=Corona261`
SUNSPOT 247	Apollo 1 CM	(We don't have a copy of this software ... yet?)
SOLARIUM 55	Apollo 4, 6 CM	`piTelemetry.py --port=19672 --software=Solarium055`
SUNDIAL E	2TV-1 CM, Block II CM G&N Acceptance	`piTelemetry.py --port=19698 --software=SundialE`
AURORA 88	LM G&N Acceptance	`piTelemetry.py --port=19798 --software=Aurora88`
DAP AURORA 12	DAP concept development	`piTelemetry.py --port=19798 --software=Aurora12`
BOREALIS	Validation of yaAGC	`piTelemetry.py --port=19798 --software=Borealis`
SUNBURST 37	Development	`piTelemetry.py --port=19798 --software=Sunburst37`
SUNBURST 120	Apollo 5 LM	`piTelemetry.py --port=19798 --software=Sunburst120`

Downlist Versioning

Unique Downlink Formats	Additional AGC Software Versions Using the Same Downlink-List Format
Sunrise45	Sunrise69
Corona261
Solarium055
Sunspot247
SundialE
Colossus249	Colossus237
Manche45R2	Comanche044, Comanche045, Comanche051, Comanche055, Comanche067, Comanche072, Manche72R3
Artemis072	Artemis071
Skylark048
Borealis
Aurora88
Aurora12
Sunburst37
Sunburst120
Sundance306ish	SundanceXXX
LUM69R2	Luminary069
Luminary099	Luminary096, Luminary097, Luminary098, LMY99R0, LUM99R2
LM131R1	Luminary116, Luminary130, Luminary131
Luminary163	Luminary173
Luminary178
Luminary210
Zerlina56

Version Aliases

TBD

The "TSV" Files

TBD

The "Documentation" Files

TBD

Legacy material ... blow it away completely after writing the stuff above!

It's rocket science, what did you expect? But all is not lost: It's not terribly difficult, just terribly intricate. So just keep reading.

First, the telemetry data that was downlinked varied somewhat from mission to mission. These differences were small and gradual from one later Apollo mission to the next, but could be quite large between early versions of the AGC software. Among the AGC software versions we've managed to obtain here at Virtual AGC, and Apollo 1 for which we haven't (yet?), here's a table of the unique downlink behaviors we've identified. Fortunately, you don't really need to know these details since yaTelemetry knows it and selects the proper formats for you. But hey, if I didn't list all of this stuff in excruciating detail, how would you know you're getting your money's worth?

So one thing you need to keep in mind when interpreting the telemetry data is the answer to the question, What mission is this from? Of course, if you were running the simulation yourself, it goes without saying that you would know what AGC software version you were using. For the screenshot above, I can tell you that I was running an Apollo 13 Lunar Module — or very close to it, anyway —, and that the AGC software was what's known as LM131R1.

Second, different downlink lists were emitted during different phases of the mission. Like most or all of the flown missions, in Apollo 13 there were 5 different phases (and thus 5 corresponding types of downlink lists) for the CM, and 6 for the LM. We can identify the flight phases with the AGC Pnn programs running during those phases. These downlink lists were identified both by title — "Coast and Align" in our sample screenshot — and by a 5-digit octal ID number — 77777 in our sample. For example, the most-common thing you'll see upon starting an AGC simulation is the "Coast and Align List" (ID 77777), which is emitted during idling (program P00).

While there are some missions for which we haven't yet obtained the appropriate section of the associated GSOP documents, we have done so for the Apollo 13 Lunar Module. Unfortunately, we do not presently have the GSOP for the Apollo 13 Command Module, and hence can only provide similar information via possibly-suspect inference.

Command Module:

Powered List (ID ): P11 Earth Orbit Injection (EOI) Monitor, P40 SPS Thrust, P41 RCS Thrust, P47 Thrust Monitor, P61 Entry Preparation Program
Coast and Align List (ID 77777): P00 CMC Idling, P01 Prelaunch Initialization, P02 Gyro Compassing, P03 Optical Verification of Azimuth, P06 CMC Power Down, P07 System Test, P51 IMU Orientation Determination, P52 IMU Realignment Program, P53 Backup IMU Orientation Determination, and P54 Backup IMU Realignment
Rendezvous and Prethrust List (ID ): P17 CSM TPI Search, P20 Rendezvous Navigation, P21 Ground Track Determination, P23 Cislunar Navigation, P30 External ΔV Maneuver Guidance, P31 Lambert Aim Point Maneuver Guidance, P34 Transfer Phase Initiation (TPI) Guidance, P35 Transfer Phase Midcourse (TPM) Guidance, P37 Return to Earth Maneuver Guidance, P38 Stable Orbit Rendezvous Guidance, P39 Stable Orbit Midcourse Guidance, P74 LM Transfer Phase Initiation (TPI) Targeting, P75 LM Transfer Phase Midcourse (TPM) Targeting, P76 Target ΔV, P77 LM TPI Search Program, P78 LM Stable Orbit Rendezvous, P79 LM Stable Orbit Midcourse Targeting
Entry and Update List (ID ): P27 CMC Update, P62 CM/SM Separation and Pre-entry Maneuver, P63 Entry Initialization, P64 Post 0.05 G Entry Mode, P65 Up Control Entry Mode, P66 Ballistic Entry Mode, P67 Final Entry Mode
Program 22 List (ID ): P22 Orbital Navigation

Lunar Module:

Orbital Maneuvers List (ID ): P40 DPS Thrust, P41 RCS Thrust, P42 APS Thrust, and P47 Thrust Monitor
Coast and Align List (ID 77777): P00 LGC Idling, P06 LGC Power Down, P51 IMU Orientation Determination, and P52 IMU Realignment
Rendezvous and Prethrust List (ID ): P20 Rendezvous Navigation, P21 Ground Track Determination, P25 Preferred Tracking Attitude, P30 External ΔV Maneuver Guidance, P32 Coelliptic Sequence Initiation (CSI), P33 Constant Differential Altitude (CDH), P34 Transfer Phase Initiation (TPI), P35 Transfer Phase Midcourse (TPM), P72 CSM CSI Targeting, P73 CSM CDH Targeting, P74 CSM TPI Targeting, P75 TPM Targeting, and P76 Target DELTA V
Descent and Ascent List (ID ): P12 Powered Ascent Guidance, P63 Braking Phase Guidance, P64 Approach Phase Guidance, P66 Rate of Descent (ROD) Landing Phase Guidance, P68 Confirm Lunar Landing, P70 DPS Abort Guidance, and P71 APS Abort Guidance
Lunar Surface Align List (ID ): P22 Lunar Surface Navigation and P57 Lunar Surface Alignment
AGS Initialization and Update List (ID ): P27 LGC Update and R47 AGS Initialization. Note the R!

Which is all very well and good, but what about the mysterious data that yaTelemetry is showing within the downlink lists themselves? For example, in the sample screenshot earlier, we see TBD

This page is available under the Creative Commons No Rights Reserved License
Last modified by Ronald Burkey on 2025-04-18.

Table of Contents