(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!)
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:
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 |
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 |
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, 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. |
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 |
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 |
|
CORONA 261 SUNSPOT 247 SOLARIUM 55 |
AS-202 CM Apollo 1 CM Apollo 4, 6 CM |
|
SUNDIAL E |
2TV-1 CM Block II CM G&N Acceptance |
|
AURORA 88 DAP AURORA 12 BOREALIS |
LM G&N Acceptance Concept development Validation of yaAGC |
|
SUNBURST 37 SUNBURST 120 |
Development Apollo 5 LM |
|
*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. |
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. |
DNLST1
) consist of:Absent any relay or input-character data, the downlist would actually be emitted as follows:TIME1 TIME2 IN0 IN2 IN3 ... TNUV+3 TNUV+4 TNUV+5 GYROD+5 GYROD+3
GYROD+3
GYROD+5
TNUV+5
TNUV+4
34
octalTNUV+3
IN3
04
octalIN2
IN0
TIME2
TIME1
00
octalIf SUNRISE is run from the VirtualAGC GUI, a suitable command for
displaying the telemetry is:
Here's a sample, in which I ran SUNRISE 45 and punched the DSKY keys V37E00E:piPeripheral/piTelemetry.py --protocol=sunrise --port=19672
...Notice the Key and Relay downlinked items, which occur asynchronously with respect to the downlists.
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
...
This protocol applies to the AGC programs CORONA, SUNSPOT, and
SOLARIUM.
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.
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.
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.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.
AGSLIST IS NOT REQUIRED FOR AS206 [i.e.,
Apollo 5] BUT IS INSERTED IN SUNBURST TO
RESERVE
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.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:
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.
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. |
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 |
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. |
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
...
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:
DSPTAB
")
in the AGC software, or else the names of variables plus
numeric offsets (such as "DSPTAB +5
"), but not
always.B
n
where n
is a decimal integer (negative,
0, or positive), in which case it's interpreted as 2n.
In either case, the downlinked quantity will be divided by the
scaling factor before being displayed.FMT_OCT
for a 15-bit octal number.FMT_2OCT
for a 30-bit octal number. In
this case, two successive downlinked items are combined,
with the more-significant word coming first.FMT_DEC
for a 15-bit decimal number.FMT_2DEC
for a 30-bit decimal number.
In this case, two successive downlinked items are combined,
with the more-significant word coming first.FMT_SP
for a single-precision (15-bit)
floating-point number.FMT_DP
for a double-precision (30-bit)
floating-point number. In this case, two successive
downlinked items are combined, with the more-significant
word coming first.FMT_USP
for an unsigned 15-bit fraction,
printed as a single-precision floating-point number.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.
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:
ddd-
ID
-
AGSSOFTWARE
.html
,
does not exist, then you fall back to ddd-
ID
-unavailable-CM.html
or ddd-
ID
-unavailable-LM.html
instead, depending on whether AGCSOFTWARE
is for the CMC or for the LGC. ddd-
ID
-unavailable-CM.html
(or ddd-
ID
-unavailable-LM.html
)
does not exist, then you fall back to ddd-unavailable-CM.html
(or ddd-unavailable-LM.html
).ddd-unavailable-CM.html
(or ddd-unavailable-LM.html
)
does not exist — but of course, they do exist! — then
you fall back to ddd-unavailable.html
.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.