;file /galileo/euv/gll_euv_cruise_ops.doc Nov 16, 1988 Bill, The following material gives most of the details regarding the microprocessor program for Galileo EUV cruise science. It turns out that these additional software fits into the area remaining from the standard encounter load so that both are on-board at once. Which is used is controlled in one bit of the command word. Your comments are most appreciated. Recall that I mentioned at an earlier date that EUV 'memory readout' is now considered a mission default. We expect to have two DSN passes available per week. We are currently discussing each DSN pass as a 'set' which might contain two concurent memory dumps with another pair at the end of the DSN pass. We consider this a good method to estimate counting rates on three intervals: very short, intermidiate (8 hours) and long (several days). We calculate a bright star could roll over the counter in eight hours so these dump intervals will help us resolve the data set. I hope I've given you enough background to adequately consider this information. Please call if you need any further details. Karen Simmons (303) 492-8363 cc: Ajello, Waggoner From: PISCES::ONEIL 1-NOV-1988 19:16 To: ORION::SIMMONS Subj: A Summary of Cruise Operations A baseline program has been written for the EUV spectrometer to demonstrate a technique for handling the data collected by the EUV instrument during an "all sky map" while in the cruise portion of the Galileo mission. Because of the lack of firm definition of the science requirements, and some uncertainty regarding spacecraft telemetry operations during cruise, the program is primarily intended to generalize the approach to data collection and to provide an indication of what can be expected during this mode of operation. The remainder of this document summarizes the major features of the program. The cruise program occupies approximately 200 bytes of instrument memory and is co-resident with the existing EUV program which will be operational during the orbital portion of the mission. Although the two programs share many of the existing routines, they are independent and mutually exclusive. To switch from one program to the other requires a hardware reset and, therefore, a new set of uplinked commands. To initiate an all sky map operation (assuming that the program has been loaded into instrument memory and a start command issued), the usual command set is uplinked, i.e. MODE/HV, start angle, number of scans per sector, and number of sectors. The distinguishing feature of the cruise command set is that the most significant bit of the number of scans per sector byte is set high. This is detected by the software which responds by activating the cruise program. Prior to uplinking the command set, a Fixed Pattern Noise table should be loaded into instrument memory. This table will have a different form than that associated with orbital operations. The table will contain a sequential numerical entry in hexadecimal, beginning with zero, for all pixels of interest. The remaining entries will be FF. For example, assume that the pixel numbers of interest, in decimal, are 12 through 23. The table will have the following appearance: F000 FF FF FF FF FF FF FF FF FF FF FF FF 00 01 02 03 F010 04 05 06 07 07 09 0A 0B FF FF FF FF FF FF FF FF F020 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF . . . F070 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF In the cruise mode, data memory is reconfigured to provide 768, 16-bit storage registers. The program counts the number of active pixels specified by the Fixed Pattern Noise table and configures the storage registers in the following way: | | Sector # | | |_______ Pixel # Obviously, the greater the number of active pixels that are specified, the fewer number of sectors into which the "sky" can be divided. In addition, it will be desirable to replace some of the registers with housekeeping information, the details of which remain to be determined. The data storage area includes the memory locations between 0900 and 0EFF inclusive. The spacecraft will be expected to read these locations and telemeter the data back to earth. The received data will have the format: sector0, lowest numbered pixel; sector 0, next highest numbered pixel;...sector 0, highest numbered pixel; sector 1, lowest numbered pixel; etc. The sixteen bit words will be received least sig- nificant byte first. Following the last register will be a series of bytes containing the housekeeping information. In the present imple- mentation, the last two bytes, 0EFE & 0EFF, are don't cares. They are used as a scratchpad by the software. Table 1 presents the possible pixel-versus-sector trades-offs and shows the resulting amount of housekeeping available for each choice. The entries in the deg./sector column take into account the methodology of sector definition (20.8 millisec./scan, integral number of scans per sector) and assume a spin rate of exactly 3 RPM. Data taking sessions having a duration greater than 360 degrees were not considered in this analysis since there appears to be no particular reason for them. Table 1 Trade-offs Among Sectors/Pixels/HK Bytes # of sectors deg./sect total deg. # of pixels # of HK bytes 127 2.62 332.8 6 12 126 2.62 330.2 6 24 125 2.62 327.6 6 36 124 2.62 325.0 6 48 123 2.62 322.4 6 60 122 2.62 319.7 6 72 121 2.62 317.1 6 84 120 3.00 359.4 6 96 119 3.00 356.4 6 108 118 3.00 353.4 6 120 117 3.00 350.4 6 132 116 3.00 347.4 6 144 115 3.00 344.4 6 156 114 3.00 341.5 6 168 113 3.00 338.5 6 180 112 3.00 335.5 6 192 111 3.00 332.5 6 204 110 3.00 329.5 6 216 109 3.00 326.5 7 10 108 3.00 323.5 7 24 107 3.00 320.5 7 38 106 3.37 357.2 7 52 105 3.37 353.8 7 66 104 3.37 350.4 7 80 103 3.37 347.1 7 94 102 3.37 343.7 7 108 101 3.37 340.3 7 122 100 3.37 337.0 7 136 99 3.37 333.6 7 150 98 3.37 330.2 7 164 97 3.37 326.9 7 178 96 3.74 359.4 8 0 95 3.74 355.7 8 16 94 3.74 351.9 8 32 93 3.74 348.2 8 48 92 3.74 344.4 8 64 91 3.74 340.7 8 80 90 3.74 337.0 8 96 89 3.74 333.2 8 112 88 3.74 329.5 8 128 87 4.12 358.3 8 144 86 4.12 354.2 8 160 85 4.12 350.1 9 6 84 4.12 345.9 9 24 83 4.12 341.8 9 42 82 4.12 337.7 9 60 81 4.12 333.6 9 78 80 4.49 359.4 9 96 79 4.49 354.9 9 114 78 4.49 350.4 9 132 77 4.49 345.9 9 150 76 4.49 341.5 10 16 75 4.49 337.0 10 36 74 4.49 332.5 10 56 73 4.87 355.3 10 76 72 4.87 350.4 10 96 71 4.87 345.6 10 116 70 4.87 340.7 10 136 69 4.87 335.8 11 18 68 5.24 356.4 11 40 67 5.24 351.2 11 62 66 5.24 345.9 11 84 65 5.24 340.7 11 106 64 5.62 359.4 12 0 63 5.62 353.8 12 24 62 5.62 348.2 12 48 61 5.62 342.6 12 72 60 5.99 359.4 12 96 59 5.99 353.4 13 2 58 5.99 347.4 13 28 57 5.99 341.5 13 54 56 6.36 356.4 13 80 55 6.36 350.1 13 106 54 6.36 343.7 14 24 53 6.74 357.2 14 52 52 6.74 350.4 14 80 51 6.74 343.7 15 6 50 7.11 355.7 15 36 49 7.11 348.6 15 66 48 7.49 359.4 16 0 47 7.49 351.9 16 32 46 7.49 344.4 16 64 45 7.86 353.8 17 6 44 7.86 345.9 17 40 43 8.24 354.2 17 74 42 8.24 345.9 18 24 41 8.61 353.1 18 60 40 8.99 359.4 19 16 39 8.99 350.4 19 54 38 9.36 355.7 20 16 37 9.36 346.3 20 56 36 9.73 350.4 21 24 35 10.11 353.8 21 66 34 10.48 356.4 22 40 33 10.86 358.3 23 18 32 11.23 359.4 24 0 31 11.61 359.8 24 48 30 11.98 359.4 25 36 29 12.36 358.3 26 28 28 12.73 356.4 27 24 27 13.10 353.8 28 24 26 13.48 350.4 29 28 25 14.23 355.7 30 36 24 14.98 359.4 32 0 23 15.35 353.1 33 18 22 16.10 354.2 34 40 21 16.85 353.8 36 24 20 17.97 359.4 38 16 19 18.72 355.7 40 16 18 19.84 357.2 42 24 17 20.97 356.4 45 6 16 22.46 359.4 48 0 15 23.96 359.4 51 6 14 25.46 356.4 54 24 13 27.33 355.3 59 2 12 29.95 359.4 64 0 11 32.57 358.3 69 18 10 35.94 359.4 76 16 9 39.69 357.2 85 6 8 44.93 359.4 96 0 7 51.29 359.0 109 10 6 59.90 359.4 128 0 From: PISCES::ONEIL 14-NOV-1988 15:23 To: ORION::SIMMONS Subj: Addendum to Cruise Ops Karen: We're having some problems with our AT in the lab, so I wasn't able to get a printout of the simulated 1536 byte cruise buffer. However, this note may suffice to define our current cruise housekeeping dump. The last "line" of the buffer (i.e. addresses 0EF0-0EFF) has the appearance: 0EF0 xx 10 85 10 C0 12 34 56 27 05 DA 70 10 96 xx xx The "xx" are don't cares; the rest, in order, are: 10 the uplinked byte corresponding to the start angle 85 Mode/HV - pulse count mode, HV = 05 10 number of scans/sector - 16 decimal C0 number of sectors - 40 hex, MSB high (for cruise) 12 \ 34 RIM count at start of data taking session 56 / 27 MOD91 counter at start 05 RTI interval at start DA\ delta theta times 8 70/ i.e. change in theta in one RTI interval (66 2/3 msec.) 10\ value of theta at the start of data taking 96/ as computed by the software (theta at RTI0 + delta theta) Naturally the address 0EF0 will not appear in the telemetry stream. At present these data will appear at the end of the dump. If it is decided to dump the Fixed Pattern Noise table, it will follow the two "don't care" bytes. Hope this clears things up a bit. Fred