(Note that this will not be a topic of interest to most readers, so you may want to jump in the lifeboat right now and get out of here!)

Table of Contents

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:

However, until about May of 2025, 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.  This page describes the reverse engineering and findings associated with implementation of those overlooked protocols from the unmanned missions and AGC software versions never flown at all. 

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

Downlist References

Here's an abbreviated, roughly-chronological (by AGC software version) 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,
Apollo 6
GSOP R-537, Section 3.4 "AGC Digital Downlink"

Flight 501 Memo #8, "Programming Changes from AS-202 to AS-501"

SOLRUM55 source code
N/A

Aurora 88 program
N/A
"Aurora 85 & 86 and Sundial Mode Bits"

"Retread 50, Aurora, Sundial B&C Data Cards"

"Aurora 88 and Sundial C Reference Cards"

Aurora 88 source code

SUNBURST 37 program
N/A
Sunburst 37 source code

DAP Aurora 12 program
N/A
"Aurora 85 & 86 and Sundial Mode Bits"

"Retread 50, Aurora, Sundial B&C Data Cards"

"Aurora 88 and Sundial C Reference Cards"

DAP Aurora 12 source code

Apollo 5
N/A
"Lunar Module Systems Handbook, Vehicle LM-1, AS-204", Rev C (changed pages only), Table 7-1 "AS-206 Downlink Format"

"Lunar Module Systems Handbook, Vehicle LM-1, AS-206", Rev B (full document), Table 13-4 "LMP Prime (LGC &/or PRA Sequenced) Command"

Sunburst 120 source code
In spite of the title, Rev C of the Lunar Module Systems Handbook appears to be for AS-206 rather than AS-204.
2TV-1
SUNDIAL D reference cards, "NOMINAL CGC DOWNLINK LIST"

"Aurora 85 & 86 and Sundial Mode Bits"

"Retread 50, Aurora, Sundial B&C Data Cards"

"Aurora 88 and Sundial C Reference Cards"

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
A full copy of the  "Programmed Guidance Equations for COLOSSUS 2", Rev 2, section "Up and Down Telemetry", it is believed, would also describe the downlists in detail.  The only revision we have for this document is for COLOSSUS 2A, but our copy contains only the changed pages since Rev 1 (Apollo 10, MANCHE45R2).  There are no changed pages in the "Up and Down Telemetry" section, implying that the descriptions of all telemetered items in the Apollo 11 CM are identical to those in Apollo 10.
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

"Programmed Guidance Equations for LUMINARY 1B" seemingly provides all of the same information as the GSOP, possibly with different wording.

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

"Programmed Guidance Equations for LUMINARY 1C" seemingly provides all of the same information as the GSOP, possibly with different wording.

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

"Programmed Guidance Equations for LUMINARY 1D" seemingly provides all of the same information as the GSOP, possibly with different wording.
Luminary 178 source code: here and here
From the list of PCRs incorporated, the PRELIMINARY documents confine their changes to Rev 9, so those GSOPs 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

"Programmed Guidance Equations for COLOSSUS 3", section "Information in Telemetered Words"

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"

"Programmed Guidance Equations for SKYLARK" seemingly provides all of the same information as the GSOP, possibly with different wording.

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 piPeripheral/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:

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 (such as ECLIPSE) that we haven't seen.  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:

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 D000 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:

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.

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:

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.  BOREALIS is not an Apollo-era program but rather a modern one based on DAP AURORA, so it has identical characteristics as DAP AURORA with respect to downlinked telemetry.

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:

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:

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:

And here are those ID words vs downlist types:

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 (though I have not tried to do so), 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:
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

Simple Testing

Any testing of an implementation of these downlists requires the ability to put the AGC into a state in which it is actually emitting the particular downlist which one desires to test.  The following table gives a list of sample DSKY commands that produce any given downlist in any given AGC software version, though in most cases, these are far from the only DSKY commands that could be used.  Of course, for those software versions that emit only a single type of downlist, DSKY commands are unneeded.  I've abbreviated the downlist names somewhat for space, and because equivalent downlists may have slightly different naming in different documentation; hopefully it will be obvious which downlists are being referenced.

AGC
Software
Version
Downlist Types
(Titles Abbreviated)
Coast Entry
AGS
Rendezvous
Powered
Orbital
Prog22
Descent
Surface
Nominal
Update
Radar
Sunburst 45
Sunburst 69









Unneeded


Corona 261
(AS-202)




TBD




TBD
Sunspot 247
(Apollo 1)
V37E00E* V37E63E*


V37E01E*




TBD
Solarium 55
(Apollo 4, 6)




TBD




TBD
Sundial E
(2TV-1)









Unneeded


Aurora 88


TBD





TBD
TBD
DAP Aurora 12


TBD





TBD
TBD
Borealis









Unneeded


Sunburst 37









Unneeded


Sunburst 120
(Apollo 5)









Unneeded


Sundance 306
(Apollo 9 LM)
V37E00E


V37E20E

V37E40E






All later CM
V37E00E
V37E27E

V37E20E V37E40E

V37E22E





All later LM
V37E00E

TBD
V37E20E

V37E40E

V37E12E
V37E22E



*Untested, in lieu of missing AGC software.

Downlist Versioning

The scope of our present discussion consists of the 43 different AGC software versions available in our repository that can emit telemetry, plus SUNSPOT 47 (for Apollo 1) for which we've provided telemetry support for even in the absence of the AGC software itself.  Perhaps someday!

However, there are less than 44 distinct categories of unique downlist types.  For example, downlists for Comanche 44, 45, 51, 55, 67, and 72 are all identical to the downlists for AGC software Manche45R2.  So naturally, in supporting these downlists, we only provide support for Manche45R2, then maintain a list of all the AGC versions which are identical to it.

Besides the list of downlink items for any given downlist type, we also have to provide documentation files for them, displayable by yaTelemetry.  But even when two AGC software versions have the same items on their downlists, that doesn't imply that the documentation for them is the same.  So it's possible to have more documentation files than downlist types. On the other hand, for many AGC software versions we don't have the necessary Apollo-era documentation to be absolutely sure about the descriptions of downlinked, so we have to fall back on generic downlist documentation that we hope is nearly correct.     So in that sense, there can be less documentation files than unique downlist types.

Besides all of that, it's helpful for yaTelemetry or whatever software is interested to know which downlist protocols are applicable.

All of this information is maintained in a file (master copy in in yaAGC/) called ddd-version-aliases.tsv, which which software like yaTelemetry or piTelemetry.py reads at runtime to determine which rules it ought to apply.  This file must be maintained if, for example, new AGC software versions become available.  It is a tab-delimited ASCII file in which each line consists of 4 fields:
  1. The name of the AGC software, as listed in the Virtual AGC repository.  In the example above, perhaps Comanche044, Comanche072, or Manche45R2.
  2. The name of the AGC software having the same items on each downlist.  In the example above, Manche45R2.
  3. The basename associated with the documentation files.  In the case of our example, it happens to be Colossus2.
  4. The name of the applicable downlink protocol, from among these choices:  early1, late1, early2, mid2, late2.

Here's an excerpt from ddd-version-aliases.tsv that encompasses our example:

...
Comanche044 Manche45R2 Colossus2 late2
Comanche045 Manche45R2 Colossus2 late2
Manche45R2 Manche45R2 Colossus2 late2
Comanche051 Manche45R2 Colossus2 late2
Comanche055 Manche45R2 Colossus2 late2
Comanche067 Manche45R2 Colossus2 late2
Comanche072 Manche45R2 Colossus2 late2
Manche72R3 Manche45R2 Colossus2 late2
...

The "TSV" Files

There's a so-called "TSV" file for each unique downlist type, providing a description of each downlinked item on the downlist.  The appropriate TSV files are ready by yaTelemetry or whatever program wants to process the down-telemetry.

Master copies of these files appear in two places in the Virtual AGC repository.  Those for the "late2" protocol used Apollo 7 and beyond are all in the yaAGC/ directory in the repository, while those for everything prior, i.e. using the early1, late1, early2, and mid2 protocols, instead appear in the piPeripheral/ directory.  However, when Virtual AGC is built from source and installed, all of these files are conglomerated in a single location appropriate to the target system.  There is a naming convention for the files,

ddd-NNNNN-SOFTWARE.tsv

Here, SOFTWARE is the AGC software version, such as "Comanche055" or "Luminary099".  Whereas NNNNN is the so-called I.D. word of the downlist, as a 5-digit octal number.  You'll recall from the earlier discussion that most AGC software versions emit multiple types of downlists, such the "Powered List" or the "Rendezvous and Prethrust List", and that each such downlist type has a different I.D. word like 77777 or 77774.  For AGC software versions having a single downlist type, there typically is no such I.D. word, and in those cases we conventionally use 00000.

In fact, for no good reason, here's a complete list of the unique TSV files at present; all downlist definitions alias to one of these:

 ddd-00000-Sunrise45.tsv     ddd-77772-LM131R1.tsv       ddd-77774-Luminary163.tsv      ddd-77776-LUM69R2.tsv
ddd-00000-Sunrise69.tsv ddd-77772-LUM69R2.tsv ddd-77774-Luminary178.tsv ddd-77776-Luminary099.tsv
ddd-00001-Aurora12.tsv ddd-77772-Luminary099.tsv ddd-77774-Luminary210.tsv ddd-77776-Luminary163.tsv
ddd-00001-Aurora88.tsv ddd-77772-Luminary163.tsv ddd-77774-Manche45R2.tsv ddd-77776-Luminary178.tsv
ddd-00001-Borealis.tsv ddd-77772-Luminary178.tsv ddd-77774-Skylark048.tsv ddd-77776-Luminary210.tsv
ddd-00236-Sunburst120.tsv ddd-77772-Luminary210.tsv ddd-77774-Sundance306ish.tsv ddd-77776-Manche45R2.tsv
ddd-00253-Aurora12.tsv ddd-77772-Zerlina56.tsv ddd-77774-Zerlina56.tsv ddd-77776-Skylark048.tsv
ddd-00253-Aurora88.tsv ddd-77773-Artemis072.tsv ddd-77775-Artemis072.tsv ddd-77776-Sundance306ish.tsv
ddd-00253-Borealis.tsv ddd-77773-Colossus249.tsv ddd-77775-Colossus249.tsv ddd-77776-Zerlina56.tsv
ddd-00321-Aurora12.tsv ddd-77773-LM131R1.tsv ddd-77775-LM131R1.tsv ddd-77777-Artemis072.tsv
ddd-00321-Aurora88.tsv ddd-77773-LUM69R2.tsv ddd-77775-LUM69R2.tsv ddd-77777-Colossus249.tsv
ddd-00321-Borealis.tsv ddd-77773-Luminary099.tsv ddd-77775-Luminary099.tsv ddd-77777-LM131R1.tsv
ddd-00354-Sunburst37.tsv ddd-77773-Luminary163.tsv ddd-77775-Luminary163.tsv ddd-77777-LUM69R2.tsv
ddd-01724-SundialE.tsv ddd-77773-Luminary178.tsv ddd-77775-Luminary178.tsv ddd-77777-Luminary099.tsv
ddd-62001-Corona261.tsv ddd-77773-Luminary210.tsv ddd-77775-Luminary210.tsv ddd-77777-Luminary163.tsv
ddd-62001-Solarium055.tsv ddd-77773-Manche45R2.tsv ddd-77775-Manche45R2.tsv ddd-77777-Luminary178.tsv
ddd-62001-Sunspot247.tsv ddd-77773-Zerlina56.tsv ddd-77775-Skylark048.tsv ddd-77777-Luminary210.tsv
ddd-62066-Sunspot247.tsv ddd-77774-Artemis072.tsv ddd-77775-Sundance306ish.tsv ddd-77777-Manche45R2.tsv
ddd-62067-Corona261.tsv ddd-77774-Colossus249.tsv ddd-77775-Zerlina56.tsv ddd-77777-Skylark048.tsv
ddd-62067-Solarium055.tsv ddd-77774-LM131R1.tsv ddd-77776-Artemis072.tsv ddd-77777-Sundance306ish.tsv
ddd-62153-Sunspot247.tsv ddd-77774-LUM69R2.tsv ddd-77776-Colossus249.tsv ddd-77777-Zerlina56.tsv
ddd-62240-Sunspot247.tsv ddd-77774-Luminary099.tsv ddd-77776-LM131R1.tsv

As far as the internal composition of the files is concerned, they are tab-delimited files with lines that typically have 6 fields.  But there are some exceptions:

For Apollo 7 and later, i.e. the "late2" protocol software, the AGC software is very consistent in giving all of this data in a standardized way within AGC program comments.  Gavin Eadie (thanks, Gavin!) created software to scrape this information from the AGC source code, and thus his software created all of the Apollo 7 and later TSV files by scraping the source code.  Gavin's software can be found in his GitHub repository.

For earlier software (early1, late1, early2, mid2), the AGC software is neither as systematic in its descriptions, nor consistent with the later software, so Gavin's software unfortunately could not be used with it.  I manually scraped all of them myself.  The side effect of that is that I haven't (yet?) provided most of the scaling factors or formats for the downlinked items, and the TSV files instead have used the easy, safe, but less-useful alternative of treating almost all items as single-precision, unscaled octals.

The "Documentation" Files

One usability problem with yaTelemetry's display of this downlist data is that it's only minimally informative to be told that (say) COMPNUMB is equal to 5, if you have no idea what COMPNUMB represents in the first place.  To marginally mitigate that, each type of downlist has an associated helpfile written in HTML (and thus displayable in a browser), in which a description much fuller than a mere symbolic name is provided for each downlinked item.  These files follow a naming convention like

ddd-ID-DOCUMENTATIONTYPE.html

and are grouped in directories with names like ddd-DOCUMENTATIONTYPE/.  There is a style file, documents.css, common to all of them.  As far as master copies are concerned, the late2 files are all found in yaTelemetry/documentation/, whereas the earlier (early1, late1, early2, mid2) files are found in piPeripheral/documentation/.  After installation of VirtualAGC, though, the documentation/ directories are all combined in the installation directory as a single documentation/ subdirectory.

As mentioned earlier, the official descriptions of downlinked data are in the Guidance System Operations Documents (GSOPs) for the various missions, typically in Section 2 "Data Links".  However, we have only a handful of such documents for actual missions, and they weren't even produced for intermediate versions of the AGC programs anyway, so it is often — or more accurately, almost always — impossible to truly base the documentation files on the official Apollo-era documentation.  For early1 through mid2, I've made an effort to cobble up the documentation files specific to the AGC software version, however inaccurate they may have ended up being.  With late2, however, there are simply so many AGC software versions, and so little to distinguish them in terms of Apollo-era downlist documentation, that I've instead instituted a system of fallback documentation files of an increasingly-generic nature.

Here's how the fallbacks work:

I wrote all of the HTML files myself, although cut-and-pasting as much as possible from GSOPs and other documents, so the blame for the undoubtedly-many errors is all mine.  All I can say is that it's a lot better having these files than not having them.




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

Virtual AGC is hosted
              by ibiblio.org