/* file: /ansa4/gll_archive/gen_templates/uvs_history.doc */ /* Jan 19, 2006 - kes */ PDS_VERSION_ID = PDS3 OBJECT = NOTEBOOK NOTEBOOK_ID = "GO-J-UVS-2-EDR-V1.0" OBJECT = NOTEBOOK_PART_1 NOTEBOOK_NAME = "Galileo Orbiter UVS instrument Experimenter's Notebook, part 1 of 2" PRODUCER_FULL_NAME = "Karen E. Simmons, LASP University of Colorado, Boulder, CO" NOTEBOOK_PART_1_DESC = " This file represents the Experiments' Notebook of anomaly reports for the Galileo UVS instrument. The Galileo UVS instrument consists of the UltraViolet Spectrometer (UVS) and the Extreme UltraViolet (EUV) Spectrometer. Except for the initial two emails below, the EUV anomalies are separated from those for the UVS hardware and the EUV notes appear at the end of this file. A second part of the Experimenter's Notebook is the file of all UVS and EUV instrument commands: CMD_ARCHIVE.LIS . Generally these reports come from email within the team or team/Project reports, etc. Each entry is separated by a full line of '-'s. The date shown is either the date the email was received or when a file of the email was created. -------------------------------------------------------------------------------- file: gll_uvs_temp_vs_mem.doc;2 8-Jan-1993 Keith Below is a table of UVS Power commands vs TC temperature (as reported in the daily email from Acevedo.) Note that there is one Power On at -5.9 degrees besides the -10.1 deg Power On where we had the problem. ============================================================== RIM Clock SCE time of event UVS cmd TC Temp Cmd Flag DN deg C _______________________________________________________________ U 117368:34:0 89-361/19:11:49.866 34A,1; ?156 4.59 S 0144637:00:0 90-012/22:45:29.000+ 34AR; 157 5.29 R 159961:39:0 90-026/16:58:06.666# 34A; 163 9.51 S 762790:59: 91-084/23:45+ 34AR; 153 2.49 R 91-121/17:00:00.000# 34A; 156 4.59 S 91-123/05:22:10.000+ 34AR; 156 4.59 R 925054:87:0 91-198/22:12:08.000 34A; 141 -5.92 S 91-201/02:30:00.000+ 34AR; 152 1.78 R 966729:78:0 91-228/04:30:03.600 34A; 157 5.29 R 1137155:31:0 91-347/20:29:02.800+ 34AR,1; 151 1.08 R 1141613:05:0 91-350/23:36:17.333+ 34A,1; 148 -1.02 R 1212547:63:0 92-035/18:59:02.466+ 34AR,1; 151 1.08 R 1218310:83:0 92-039/20:06:17.600+ 34A,1; 148 -1.02 R 1250955:88:0 92-062/18:14:02.933 34AR,1; ?152 1.78 R 1254429:60:0 92-065/04:46:20.133 34A,1; 157 1.78 R 1310845:51:0 92-104/19:29:02.533 34AR,1; 143 -0.32 R 1314853:29:0 92-107/15:01:19.733 34A,1; 153 2.49 U 1430300:33:0 92-188/16:31:02.400 34AR,1; 143 -4.5 U 1436130:80:0 92-192/18:46:20.200 34A,1; 154 3.19 U 1570225:53:0 92-286/22:30:52.533 34AR,1; 135 -10.1 U 1573213:50:0 92-289/00:52:02.466 34A,1; 136 -9.4 R 1604596: 92-311/01:43:10 + 34AR; 144 -3.8 R 1622600 92-323/17:07 + 34A; 151 1.08 U 1679698:42:0 92-363/19:20:03.000 34AR,1; 136 -9.41 -------------------------------------------------------------------------------- file: UVS part of anomaly_events.lis;13 5-Nov-1993 STATISTICS of UVS and EUV ANOMALIES RELATIVE to the OCTOBER 11,93 EUV LOAD ANOMALY Nov 4,93 - K.E. Simmons UVS UVS Anomalies............................... 1 * Nov 5,92: Bit hits seen in memory verifies Action: * Power Off, Power On, memory load, 3 verifies - successful * Recommended remove verifies - done 5 successful loads since UVS On-off Cycles (as of Nov 4,93).......... 17 (+ On now) Cold Start Cycle (no memory verify)..... 1 Power cycles with memory verifies....... 11 Cycles since memory verifies were removed on FEB 10,93; all successful........ 5 ========================================================================= Extracted from the UVS/EUV CMD_ARCHIVE.LIS file Nov 4,93 - K.E. Simmons 89-361/17:54:58.533 EUV On,Mem Load,1 verify, 4-day checkout Dec 27,89 89-361/19:11:49.866 UVS On,Mem Load,1 verify, 4-day checkout Dec 27,89 89-364/22:35:09.000 EUV Emergency Power Off,'PARTICLE' ANOMALY Dec 30,89 90-006/19:45:00.000 EUV On,Load mem,9 verifies Jan 6,90 90-012/22:45:29.000+ EUV Power Off, s/c Fault Protection Jan 12,90 90-012/22:45:29.000+ UVS Power Off, s/c Fault Protection Jan 12,90 90-026/16:58:06.666# UVS On, mem load, lib seq:UVSON Jan 26,90 90-026/18:15:00.000# EUV On, mem load,lib seq:EUVON,3 verifies Jan 26,90 90-040/07:43:56.333 EUV Power Off (for HIC) Feb 09,90 90-041/05:08:04.266 EUV On, mem load, one verify Feb 10,90 90-041/06:29:56.266 EUV Power Off for HIC Feb 10,90 90-041/08:44:04.266 EUV On, Mem load, one verify Feb 10,90 90-342/22:05:13.466 EUV Power Off (for HIC) Dec 28,90 91-003/17:00:02.666 EUV On, Mem load, three verifies Jan 3,91 91-084/23:45+ EUV Power Off, s/c Fault Protection Mar 25,91 91-084/23:45+ UVS Power Off, s/c Fault Protection Mar 25,91 91-121/17:00:00.000# UVS On, MEM LOAD,3 verifies,lib seq:UVSON May 1,91 91-121/00:00:00.000# EUV On, MEM LOAD,3 verifies May 1,91 91-123/05:22:10.000+ UVS Power Off,s/c-HGA Fault Protection May 1,91 91-123/05:22:10.000+ EUV Power Off,s/c-HGA Fault Protection May 1,91 91-198/22:12:08.000 UVS On, mem load, 3 verifies Jul 17,91 91-201/02:30:00.000+ UVS Power Off, s/c Fault Protection Jul 19,91 91-228/04:30:03.600 UVS On, mem load,3 verifies Aug 16,91 91-238/01:22:02.400+ EUV On, mem load,3 verifies Aug 26,91 91-340/22:52:01.200+ EUV Power Off, Cold Turn #3 pre-cooling Dec 6,91 91-347/20:29:02.800+ UVS Power Off, Cold Turn #3 pre-cooling Dec 13,91 91-350/23:36:17.333+ UVS On, mem load,2 verifies at 10bps Dec 16,91 91-351/00:40:02.666+ EUV On, mem load,2 verifies at 10bps Dec 17,91 92-028/22:52:01.533+ EUV Power Off, Cold Turn #4 Jan 28,92 92-035/18:59:02.466+ UVS Power Off Cold Turn #4 Mar 4,92 92-039/20:06:17.600+ UVS On, mem load,2 verifies at 10bps Feb 8,92 92-039/21:09:02.933 EUV On, mem load,2 verifies at 10bps Feb 8,92 92-055/20:02:01.333 EUV Power Off, Cold Turn 6 Feb 24,92 92-062/18:14:02.933 UVS Power Off, Cold Turn 6 Mar 2,92 92-065/04:46:20.133 UVS On, mem load,2 verifies at 10bps Mar 5,92 92-065/05:42:10.133 EUV On, mem load,2 verifies at 10bps Mar 5,92 92-097/23:22:01.600 EUV Power Off, Cold Turn 6? Apr 7,92 92-104/19:29:02.533 UVS Power Off, Cold Turn 6? Apr 14,92 92-107/15:01:19.733 UVS On, mem load, 2 verifies at 10bps Apr 16,92 92-107/15:57:09.733 EUV On, mem load, 2 verifies at 10bps Apr 16,92 92-188/16:31:02.400 UVS Power Off, WT/CT 6A Jul 7,92 92-192/18:46:20.200 UVS On, mem load,2 verifies Jul 10,92 92-286/22:30:52.533 UVS Power Off, DDA Pulsing #4 Oct 12,92 92-289/00:52:02.466 UVS On, mem load,3 verifies Oct 15,92 92-302/00:29:01.466 EUV Power Off, for HIC Oct 28,92 92-311/01:43:10 + UVS Power Off,'bit hits in verify' ANOMALY Nov 5, 92 92-323/17:07 + UVS On, mem load,3 verifies Nov 18,92 92-343/21:09:24.733 EUV On, mem load,3 verifies Dec 8, 92 92-363/19:20:03.000 UVS Power Off, for DDA #5 Dec 29,92 93-022/19:29:59.528+ UVS On, used CS for Grating Exercise Jan 22,93 93-022/20:29:59.526+ UVS Power Off, more DDA#5 Jan 22,93 93-041/19:20 + UVS On, mem load, NO verifies Feb 10,93 93-159/16:06:01.133 EUV Power off, for HIC h/k Jun 8,93 93-159/19:10:59.133 EUV On, mem load, 3 verifies June 8,93 93-161/16 + EUV Power Off, s/c Safing Commands Jun 10,93 93-161/16 + UVS Power Off, s/c Safing Commands Jun 10,93 93-179/19:56:03.266 UVS On,mem load, NO verifies Jun 28,93 93-179/20:30:59.266 EUV On, mem load,3 verifies Jun 28,93 93-191/20:16:58 + UVS Power Off, s/c safing Jul 11,93 93-191/20:16:58 + EUV Power Off, s/c safing Jul 11,93 93-201/21:10:03.066 UVS On, mem load,NO verifies,SCION lib seq Jul 20,93 93-201/21:44:59.066 EUV On, mem load,3 verifies,SCION lib seq Jul 20,93 93-223/22 + EUV Power Off, SBA s/c safing Aug 11,93 93-223/22 + UVS Power Off, SBA s/c safing Aug 11,93 93-232/15:03:03.333 UVS On,mem load,NO verifies, SCION libseq Aug 20,93 93-232/15:37:59.333 EUV On,mem load,3 verifies, SCION libseq Aug 20,93 93-267/17:00:00 + UVS Power Off, SBA s/c safing, in allspin Sep 24,93 93-267/17:00:00 + EUV Power Off, SBA s/c safing, in allspin Sep 24,93 93-276/03 + UVS On,mem load,NO verifies Oct 02,93 93-286/20 to 288?? + EUV On,mem load,3 verifies Oct 13-5,93 93-289/01:10 + EUV Power Off, 'load/verify' ANOMALY Oct 15,93 Flags: + = Approx SCE time # = Transmit time UT ? = questimate -------------------------------------------------------------------------------- UVS Anomalies -------------------------------------------------------------------------------- file: uvs_nov0392.doc;3 Nov 3,93 -KES DDA#4 turned off the UVS instrument (as I recall, for power and temperature margins) so when it was over the UVS was Powered back On. Three memory verifies were executed as a result of the Power On: the first verify indicated everything was OK, the second two were not checked ...until later! When LRS data became available on November 4,92 I noticed that the instrument did not seem to be doing what it was supposed to be: G channel, HV-off. The data signature was bizarre and I reported an error. It turned out that the 2nd memory verify indicate a memory location had been corrupted, apparently due to the verify. We performed a BCE/Eng model test here and Charlie asked for the instrument to be Powered Off. This action was in preparation to Power it on again to recover proper operation before E2. The Project, however, forced a major review and finally allowed the PI to turn on his instrument. The UVS worked properly following this turn on. The event times are roughly as follows: see the Experimenter's Notebook and file DISKH:[GLLSEQ.HISTORY]CMD_ARCHIVE.LIS for exact details. Oct 13 92-286/22:30 Power Off Oct 16 92-289/00:52 Power On, uP load and verifies Nov 4 92-308/ LRS became available, data were studied Nov 5 92-309/23:31 Three full memory verifies Nov 6 92-311/01:37 UVS Powered Off (with another full dump) Nov 19 92-323/17:07 UVS Powered back On WITH 3 memory verifies The post-E2/DDA-5 UVS turn on was then the first UVS Power On to be executed without memory verifies. -------------------------------------------------------------------------------- file: UVS_NOV0392.TXT;1 9-Nov-92 UVS RECOVERY PLAN use current UVS PowerOn Library seq all three micro verify YES "JOY" MROs OK? Proceed with E2 plan NO 1st OK, remaining YES Implies MROs bad? corrupt memory: use Plan A NO All MROs are 'false' at YES Implies bad same bit/byte micro mem loc: use Plan B NO Some good, some bad, no repeats YES ??? ---page Current UVS PowerOn Library Sequence UVS Supp. Heater Off - 34HSR (sent twice) time 0 Power On - 34A t0 + 8s begin memory DMLs (each at 0.666s separation) t0 + 5m 30.6s 1st Memory Verify - 6MROH t0 + 7m 32.0s 2nd Memory Verify - 6MROH t0 + 9m 33.3s 3rd Memory Verify - 6MROH ** t0 +11m 34.6s Micro Start - 34ST Configure command - usually a "safe" state: 34UVS,7,Scan,Norm,Norm,Norm,Same,0, Off,Off,On,Off,Off,Noovr,1,2C,01,00,00. (= G-G, full scan, HV Off) ** May want to decide to wait for memory compare verification before proceeding ---page PLAN A Recover from Memory Corruption Apparently Caused by MROs * Reload the UVS PowerOn library sequence WITHOUT the memory verifies MROs check against a) "cockpit error" of loading the wrong version of the micro program (as seen in ground test) b) provide "warm, fuzzy" reassurance that memory is loaded correctly ---page PLAN B Recover from Implied Sensitive Bit/byte in UVS memory * Reprogram around bad location * Two bytes currently available in program therefore easy to NO OPT bad byte * Use Cold Start Mode to obtain a) Mission Critical Earth 2 X-Cal Observation b) Any other Priority 2 and lower observations that the project can support * Cold Start is a hardware driven automatic mode using F & G full scans with HV On * To implement needs: a) NO-OPTs or removal to cancel 34UVS micro commands in current sequence s b) Power On at appropriate time, Power Off at end of observation -------------------------------------------------------------------------------- file: uvs_jun1996.doc;1 25-Jun-1996 Two days after HV-on data began to arrive from the J0CD sequence, the science group began to report a 'ghost' or 'artifact' in the UVS RTS data. There was considerable evidence that the problem was the grating logic was skipping one 'fringe' because of the cold temperature of the J0CD period. This had been observed in the ground calibration. We had not run the UVS at this temperature previously. Commands were sent on Friday, June 21st (one IAPR at 5:15 pm PDT and one DAC for Saturday 14:20 UTC execution.) These raised the temperature and the frequency of errors reported in the UVS fiducial starting wavelength decreased. They apparently have not completely disappeared, although full analysis of the S.Wavelength is slow due to the irregular rollover of the fiducial status words at different DN levels during different integration periods. KES -------------------------------------------------------------------------------- file: p2_sw_error.lis;1 11-May-1998 From: VIRALF::STEWART 20-SEP-1996 22:34:18.53 To: BPER::SIMMONS CC: PISCES::HORD,PISCES::SIMMONS,PISCES::WHITE Subj: RE: N/G miniscan data Karen - Jeremy & I talked to Neil & he located an error in the UVS software. His code recognizes 9 bits in the grating position field fo a miniscan, but for the N-ch 4070A we needed position 725 which requires 10 bits. Therefore we went to position 725 mod 512 = 213, or 3443A (coincidentally there appears to be a line there, so we did see something). Then it tried to step off -355 steps to get to the g-ch 1259A emission, but of course went too far & we saw nothing. We will need to transmit a patch to the instrument s/w (a single byte). If We will need to transmit a patch to the instrument s/w (a single byte). I have left messages for Joe & Stuart, & Neil was calling Keith, to give them a heads- up on this - we should talk it over Monday & decide what to do officially. If we agree to send the patch, and if we can't get it up before G2C, then we should work up alternative commands for G2C & try to get them up. I will work out what the commands should be over the weekend. - Ian -------------------------------------------------------------------------------- file: uvs_v6p2.hex;1 29-May-1998 (note - the following is the UVS version 6.2 software load that corrects the error described above and addressed in several ISAs [Instant Surprise Anomaly] below.) 0000,71,60,F8,09,A6,F8,00,B6,D6,B1,BB,BC,F8,31,A1,F8, C0,A2,F8,A2,A4,F8,8C,A5,F8,70,A7,F8,F6,AD,F8,ED; 0020,AE,F8,F8,AF,F8,01,B2,B4,B5,B7,BD,BE,BF,70,66,30, 2F,36,36,C4,C4,D7,F8,3A,A6,D6,35,56,19,89,52,83; 0040,E2,F3,3A,4F,99,52,93,F3,3A,4F,A9,B9,D4,30,56,9A, 52,E2,67,22,1B,D5,3F,5E,F8,31,A1,E6,30,2D,0D,FB; 0060,59,32,A8,9C,32,58,EE,0E,FB,01,5E,FA,01,FE,FE,AA, 1E,8C,F3,32,7D,F9,1F,5E,8C,F2,5E,64,2E,1E,0E,FA; 0080,04,32,87,8A,FB,04,AA,4E,FA,03,BB,0E,AB,8A,52,E2, 67,22,F8,ED,AE,F8,01,B8,F8,E9,A8,0E,FA,01,CE,18; 00A0,18,48,B3,08,A3,C0,01,22,E2,F8,04,BA,52,67,22,F8, 01,B8,F8,E9,A8,F8,01,B9,4F,A9,49,58,B3,18,09,58; 00C0,A3,18,EF,0F,FA,08,CE,65,2F,0F,FA,F7,BC,5F,FA,F4, 5E,EE,63,66,2E,1F,4F,AC,FE,3B,E0,8C,FA,9F,30,E8; 00E0,FE,3B,E7,8C,FA,5F,38,8C,5E,64,4F,AB,0F,FA,03,BB, 4F,FA,FC,F6,F6,F9,C0,A9,49,58,18,09,58,4F,5E,1E; 0100,0F,5E,F8,ED,AE,F8,F9,AF,0F,2F,FE,33,1E,F8,02,B3, F8,10,A3,83,58,28,28,58,18,93,58,28,28,58,F8,00; 0120,B9,A9,F8,01,B1,F8,47,A1,E6,70,66,3C,2B,D5,E6,71, 26,F8,00,B1,8B,32,43,FB,FF,3A,40,52,67,22,1B,38; 0140,2B,7B,7A,C0,00,58,70,7A,22,78,22,73,36,4F,D7,35, 6B,19,89,52,83,F3,3A,66,99,52,93,F3,3A,66,A9,B9; 0160,9A,FB,04,BA,30,6B,9A,C6,2B,38,1B,12,42,30,46,D1, 4D,FB,5A,3A,88,0D,FB,09,3A,84,0E,F9,08,52,63,EE; 0180,63,22,2E,E2,0D,FC,01,5D,2D,30,6F,D6,8B,3A,95,9B, FA,03,BB,32,8B,7B,7A,F8,14,A8,28,88,3A,9A,2B,30; 01A0,8C,D6,9C,32,A1,9A,FB,04,BA,30,A1,C4,C4,C4,C4,C4, C4,C4,C4,C4,C4,C4,C4,C4,C4,C4,00,00,00,00,00,00; 01C0,00,00,01,00,02,00,03,00,04,00,06,00,08,00,0B,00, 0C,00,10,00,16,00,18,00,21,00,2C,00,30,00,42,00; 01E0,58,00,84,00,B0,01,08,02,10,00,00,00,00,00,00,00, 00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,62; -------------------------------------------------------------------------------- file: uvs_oct1996.txt;11 13-May-1998 From: GLLSVC::STEPHENS 'STUART K. STEPHENS' 8-OCT-1996 17:09:07.05 To: JPLUVS::JAJELLO,@JPL.DIS CC: ZODIAC::STEWART,PISCES::HORD,PISCES::BARTH,PISCES::SIMMONS,PISCES::PRYOR Subj: status of v6.2 UVS uplink at JPL Tu 10/8/96 10:00 am Hi Joe, I met with Ray Weaver, Bob Barry, and other OET folks yesterday at 3:30 pm, and we came up with the following plan: 1. I'll deliver a SEQGEN file on the UNIG, containing what Keith created before (UVS OFF, UVS ON, v6.2 FSW load) plus a DISCRD/PACKET UVFLUSH pair to give us 5 RIMs of data. Some additional info: a) They requested we put the cold-start commands (34UVS/34CS) and the OFF commands (2 34ARs) into one IAP, so that the command uplink would be more reliable (less succeptible to human error) and more easily verified. b) They'd like me to make the epoch for UVO (UVS OFF) be 296/22:00 SCET (October 22nd, after the RTS Survey has ended). Since they want 2-way light-time plus a little bit for verifying the UVS OFF, the UVS epoch (UVS ON and v6.2 FSW load) will be 297/1:00. These are subject to change. c) The UVS OFF uplink will take less than 5 RIMs, then there will be the 3-hour wait. They will give a GO/NO-GO for the remaining uplink based on *either* (i) verification, using a CDS MRO, that the CDS command count has incremented (almost assured), *or* (ii) evidence of a power change in engineering readings (it's not clear they'll see it). They actually plan on doing CDS MROs (as IAPRs) before and after our UVS OFF IAP. Then comes the uplink of UVS ON, v6.2 FSW load, and UVFLUSH will take 23 RIMs, followed by another 3 hours or so for verification of the UVFLUSH info. [At the end of this e-mail I'm enclosing the SEQGEN file that I'll give to Dennis Bluhm of OET later this morning. He'll be generating the commands.] 2. What is our preferred backup approach, if we see (from the UVFLUSH info) that v6.2 has not loaded properly? They want one of two answers: a) If there's time within the same DOY 296-297 command pass (which there apparently is), uplink the whole thing right away, from UVS OFF to the UVFLUSH. This requires an immediate decision (late in the evening). b) Immediately uplink the UVS OFF, but wait until the next command pass (DOY 299, October 25, 2 days before torus observations start) to uplink the remainder. This allows additional time for thinking through the problem, and a change in plan if necessary. Project will prefer (b). [I've e-mailed this question to Ian, Charlie, and Karen S. separately, to get an immediate answer.] 3. I think Bob Barry et al. are aware of our past memory re-disturb (?) problem with UVS MROs, so he knows we may be reluctant to use them to verify instrument status. Can you confirm that this is still the case? 4. The schedule is: Today 3:30 pm PDT Engineering (OET) staff review of our FSW uplink -- I'll present a very brief description of the problem, the v6.2 fix, a claim that testing has verified that this is what we want, and something noting that we are redelivering (on a diskette) the new FSW to Project Th 10/10 3:30 pm Project Command Conference for Generation, at which a similar presentation will be needed Th 10/17 3:30 pm Command Conference for Uplink (this could get slipped until just before uplink if OET needs the time) Tu 10/22 2:00 pm Approximate uplink time (+ possibility of backup) F 10/25 Next command window for uplink (I'm not sure what time) Su 10/27 11:30 am UVS/EUV torus observations begin (SCET) 5. Here's the command file I've prepared: From: GLLSVC::STEPHENS 'STUART K. STEPHENS' 9-OCT-1996 22:57:26.13 To: PISCES::GEBBEN CC: PISCES::SIMMONS Subj: UVS realtime v6.2 FSW uplink file W 10/9/96 3:55 pm Hi Jeremy, Would you hand-check the following (realtime, so it contains IAPs) file for us? Keith and I will do the same here. Let us know if it looks okay by tomorrow afternoon. Thanks, Jeremy! Stuart $$GLL ORBIT PROFILE *ORPRO GLL*STUART.ORPRO/UVS62FSW1008 *LEVEL SEB *PREP UVS-MWG/S.STEPHENS 37737 *RUNID SKS *PROGRAM SEQGEN 96-208/15:34:17.000 *CREATION 96-282/11:16:05.601 *BEGIN 96-296/00:00:00.000 *EPOCH UVO,96-296/22:00:00.000 *EPOCH UVS,96-297/01:00:00.000 *CUTOFF 96-300/00:00:00.000 *TITLE RT IAPS TO LOAD PHASE2 UVS 6.2 FSW (10/8/96) *SCLK GDMT*CLK-LTF.SCLKSCETCOEF *LITIME GDMT*CLK-LTF.LITETIMEFILE *ORPRO GLL*STUART.ORPRO/UVS62FSW1008 *ORPRO GLL*KEITH.ORPRO/UVS62FSW $$EOH IMMGS,IAP,31AA,BOTH,UVO+CDS 00:00:0; CMDI,34UVS,31AA4A,PRI,UVO+CDS 00:04:0,07,SCAN,NORM,NORM,NORM,SAME,0,ON,OFF,ON, ON,OFF,NOOVR,1,00,9C,01,2C; CMDI,34CS,31AA5A,PRI,UVO+CDS 02:00:0; CMDI,34AR,31AA3A,PRI,UVO+CDS 04:00:0,1; CMDI,34AR,31AA3B,SEC,UVO+CDS 04:12:0,2; IMMGE,IAP,31AA11A,BOTH,UVO+CDS 04:13:0; IMMGS,IAP,31BA,BOTH,UVS+CDS 00:00:0; CMDI,34A,31BA3A,PRI,UVS+CDS 00:04:0,1; CMDI,34A,31BA3B,SEC,UVS+CDS 00:16:0,2; IMMGE,IAP,31BA11A,BOTH,UVS+CDS 00:17:0; IMMGS,IAP,31BB,PRI,UVS+CDS 02:17:0; CMDI,34DML,31BB4A,PRI,UVS+CDS 02:21:0,0000,71,60,F8,09,A6,F8,00,B6,D6,B1,BB,BC, F8,31,A1,F8,C0,A2,F8,A2,A4,F8,8C,A5,F8,70,A7,F8,F6,AD,F8,ED; CMDI,34DML,31BB4B,PRI,UVS+CDS 02:22:0,0020,AE,F8,F8,AF,F8,01,B2,B4,B5,B7,BD,BE, BF,70,66,30,2F,36,36,C4,C4,D7,F8,3A,A6,D6,35,56,19,89,52,83; CMDI,34DML,31BB4C,PRI,UVS+CDS 02:23:0,0040,E2,F3,3A,4F,99,52,93,F3,3A,4F,A9,B9, D4,30,56,9A,52,E2,67,22,1B,D5,3F,5E,F8,31,A1,E6,30,2D,0D,FB; IMMGE,IAP,31BB11A,PRI,UVS+CDS 02:24:0; IMMGS,IAP,31BC,PRI,UVS+CDS 04:24:0; CMDI,34DML,31BC4D,PRI,UVS+CDS 04:28:0,0060,59,32,A8,9C,32,58,EE,0E,FB,01,5E,FA, 01,FE,FE,AA,1E,8C,F3,32,7D,F9,1F,5E,8C,F2,5E,64,2E,1E,0E,FA; CMDI,34DML,31BC4E,PRI,UVS+CDS 04:29:0,0080,04,32,87,8A,FB,04,AA,4E,FA,03,BB,0E, AB,8A,52,E2,67,22,F8,ED,AE,F8,01,B8,F8,E9,A8,0E,FA,01,CE,18; CMDI,34DML,31BC4F,PRI,UVS+CDS 04:30:0,00A0,18,48,B3,08,A3,C0,01,22,E2,F8,04,BA, 52,67,22,F8,01,B8,F8,E9,A8,F8,01,B9,4F,A9,49,58,B3,18,09,58; IMMGE,IAP,31BC11A,PRI,UVS+CDS 04:31:0; IMMGS,IAP,31BD,PRI,UVS+CDS 06:31:0; CMDI,34DML,31BD4G,PRI,UVS+CDS 06:35:0,00C0,A3,18,EF,0F,FA,08,CE,65,2F,0F,FA,F7, BC,5F,FA,F4,5E,EE,63,66,2E,1F,4F,AC,FE,3B,E0,8C,FA,9F,30,E8; CMDI,34DML,31BD4H,PRI,UVS+CDS 06:36:0,00E0,FE,3B,E7,8C,FA,5F,38,8C,5E,64,4F,AB, 0F,FA,03,BB,4F,FA,FC,F6,F6,F9,C0,A9,49,58,18,09,58,4F,5E,1E; CMDI,34DML,31BD4I,PRI,UVS+CDS 06:37:0,0100,0F,5E,F8,ED,AE,F8,F9,AF,0F,2F,FE,33, 1E,F8,02,B3,F8,10,A3,83,58,28,28,58,18,93,58,28,28,58,F8,00; IMMGE,IAP,31BD11A,PRI,UVS+CDS 06:38:0; IMMGS,IAP,31BE,PRI,UVS+CDS 08:38:0; CMDI,34DML,31BE4J,PRI,UVS+CDS 08:42:0,0120,B9,A9,F8,01,B1,F8,47,A1,E6,70,66,3C, 2B,D5,E6,71,26,F8,00,B1,8B,32,43,FB,FF,3A,40,52,67,22,1B,38; CMDI,34DML,31BE4K,PRI,UVS+CDS 08:43:0,0140,2B,7B,7A,C0,00,58,70,7A,22,78,22,73, 36,4F,D7,35,6B,19,89,52,83,F3,3A,66,99,52,93,F3,3A,66,A9,B9; CMDI,34DML,31BE4L,PRI,UVS+CDS 08:44:0,0160,9A,FB,04,BA,30,6B,9A,C6,2B,38,1B,12, 42,30,46,D1,4D,FB,5A,3A,88,0D,FB,09,3A,84,0E,F9,08,52,63,EE; IMMGE,IAP,31BE11A,PRI,UVS+CDS 08:45:0; IMMGS,IAP,31BF,PRI,UVS+CDS 10:45:0; CMDI,34DML,31BF4M,PRI,UVS+CDS 10:49:0,0180,63,22,2E,E2,0D,FC,01,5D,2D,30,6F,D6, 8B,3A,95,9B,FA,03,BB,32,8B,7B,7A,F8,14,A8,28,88,3A,9A,2B,30; CMDI,34DML,31BF4N,PRI,UVS+CDS 10:50:0,01A0,8C,D6,9C,32,A1,9A,FB,04,BA,30,A1,C4, C4,C4,C4,C4,C4,C4,C4,C4,C4,C4,C4,C4,C4,C4,00,00,00,00,00,00; CMDI,34DML,31BF4O,PRI,UVS+CDS 10:51:0,01C0,00,00,01,00,02,00,03,00,04,00,06,00, 08,00,0B,00,0C,00,10,00,16,00,18,00,21,00,2C,00,30,00,42,00; IMMGE,IAP,31BF11A,PRI,UVS+CDS 10:52:0; IMMGS,IAP,31BG,PRI,UVS+CDS 12:52:0; CMDI,34DML,31BG4P,PRI,UVS+CDS 12:56:0,01E0,58,00,84,00,B0,01,08,02,10,00,00,00, 00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,62; CMDI,34ST,31BG5A,PRI,UVS+CDS 13:00:0; CMDI,34UVS,31BG4Q,PRI,UVS+CDS 14:00:0,C1,FIXED,NORM,NORM,NORM,SAME,0,OFF,OFF, ON,OFF,OFF,NOOVR,1,2C,05,00,00; IMMGE,IAP,31BG11A,PRI,UVS+CDS 14:01:0; IMMGS,IAP,31BH,BOTH,UVS+CDS 16:01:0; CMDI,6UVRT,31BH6A,BOTH,UVS+CDS 16:05:0,DISCRD,UVS; CMDI,6UVRT,31BH6B,BOTH,UVS+CDS 21:05:0,PACKET,UVS; IMMGE,IAP,31BH11A,BOTH,UVS+CDS 21:06:0; -------------------------------------------------------------------------------- file: uvs_jun1996.isa;1 27-Jan-1997 From: BPER::SIMMONS 'KAREN SIMMONS AT LASP/COLORADO' 10-JAN-1997 23:51:34.64 To: GLLSVC::STEPHENS CC: HORD,STEWART,PRYOR,GEBBEN,WHITE,@JPLUVS Subj: temperature issues and the close-out of ISA Hi Stuart, Wow, I'd completely forgotten about that one! Let me check my 'file pile' and see if I can spot the ISA. In the mean time, here's one thought that comes to mind about maybe needing to say just a bit more: if PPR is now discovering that their instrument will step WHEN IT IS COLD then we might need to document more carefully the success we've had WHEN WE ARE WARM. There may arise problems in later orbits at deciding warm vs cold. Do we have any UVS data during the time they did their test, maybe just some RTS or something to see what our temp was? Was that a sequenced patch they did their test in, can we find out when it was done? Just some thoughts off the top while I look for the ISA. Karen ===================================================================== From: GLLSVC::STEPHENS 'STUART K. STEPHENS' 10-JAN-1997 22:01:01.07 To: PISCES::SIMMONS CC: SMTP%'keith.naviaux@jpl.nasa.gov' Subj: close-out of 1996 UVS Supplemental Heater ISA Report F 1/10/97 2 pm Hi Karen, We are being asked to close out our ISAs (Incident/Surprise/Anomaly Reports), and one of the ones that I think we can do that with is the grating-stepping anomaly in the middle of last year that was related to periods when the UVS Sup- plemental Heater was off. This is ISA #10337. Keith did the write-up when it was initiated, and if you don't have a copy handy I'll send you one, but here is my proposed Action which should close it out: ******** Since DOY 96-175 -- i.e., during the G1 encounter and into subsequent orbits including the recent E4 encounter -- the UVS grating has been operating correct- ly when the UVS Supplemental Heater has been on. In G1 cruise, commands to turn on the heater in the real-time after sequenced off commands were issued to keep the heater on. In subsequent orbits, the previously sequenced off com- mands were removed so that the heater would remain on without the necessity of real-time commanding. A 9/3/96 Project decision memo (IOM #JKE-96-005), UVS Supplemental Heater Usage, documents the decision to keep the heater on. This will comply with Flight Rule FR34A8, UVS Supplemental Heater Operation. ******** Let me know if you have any changes, or if you want me to include any more information. Karen Buxbaum indicates that this should be sufficient, and addi- tional documentation isn't needed unless folks ask for it. Thanks, Stuart ******************************************************************************** From: GLLSVC::KNAVIAUX 'Keith @ JPL/Pasadena,CA' 13-AUG-1996 08:52:58.64 To: PISCES::STEWART,PISCES::HORD,PISCES::SIMMONS,PISCES::PRYOR CC: PISCES::RUTZG,@[KNAVIAUX.DIS]JPLUVS.DIS Subj: UVS Supplemental Heater Status Hello All, Greg just called with a question that made me realize I hadn't sent out a status of the UVS Supplemental Heater approach for the rest of the mission in quite some time. The OET is preparing RT commands to turn on the Supplemental Heater a few minutes after each of the sequenced heater off commands. Therefore, RT commands will be sent at 5 times during the G1C sequence to turn the heater back on. I have faxed a copy of the times for the RT commands to Greg. The OET/SEQ teams have removed all UVS Supplemental Heater commands from the G2 sequences (encounter and cruise). The approach we'll be taking is to RT command the heater on in G1C (as discussed above) and then leave it on for the remainder of the mission. Therefore, all supplemental heater commands will be pulled out of the future sequences. However, there is still some discussion going on for later orbits. Right now there is a concern that there may not be enough power margin to leave the heater on during the later orbits. The OET will be investigating this further and will be checking into options of turning off other loads as necessary. I have continued to stress to the OET/project that our only requirement is to have the heater on 2 days prior to our cruise torus observations or our encounter MWG, AWG, and SWG observations. For the early orbits it is much easier for them to simply leave the heater on throughout the orbit - it is TBD if they will need to cycle it in the later orbits. I have sent a copy of a memo discussing the OET's approach and detailed analysis of the power margin w/ respect to the UVS heater to Karen through ground mail. Please let me know if you have any questions. Keith..... (818) 393-7740 -------------------------------------------------------------------------------- file: uvs_apr1997.txt;1 9-Apr-1997 From: GLLSVC::STEPHENS 'STUART K. STEPHENS' 9-APR-1997 01:49:31.40 To: ZODIAC::STEWART CC: PISCES::SIMMONS,PISCES::PRYOR,JPLUVS::JAJELLO Subj: thoughts on UVS grating mis-stepping, and faxed info Tu 4/8/97 6 pm Hi Ian, Following our conversation about the UVS Lyman-alpha ghosts, I'll look into the following questions, although without raising any concerns yet with Project: -- whether a real-time command can be sent in G7B to change MAGNEB CMDRS's from 34UVS commands that are 16-steppers to ones that are 88-steppers -- such 16- step commands occur when we don't have to worry about PWS-quiet; in G7B they start on DOY 112, which is April 22, two weeks from today, and continue until DOY 123, just before G8A starts -- but I don't know for sure if we can send up a real-time CMDRS PA or a 34UVS command to overwrite (or occur just after) a sequenced CMDRS sub-command -- whether Project is also amenable to an in-flight low-temperature test on such a miniscan (much as PPR did when they had their filter wheel anomaly) -- i.e., making UVS as cold as possible by turning off the UVS Supplemental Heater and then seeing if we get consistent shifted spectra that are still useful -- how Project would treat such an issue -- i.e., as a health-and-safety concern or as a data concern only -- this would affect how we would approach Project this time around -- my initial reading of the Supplemental Heater ISA docu- mentation is that we considered the use of the heater a health concern for UVS I've left messages with Keith and Kent (Kent will be back from vacation and in the office tomorrow morning). As you may know, Joe gets back on the 14th or 15th. Remember, G8A changes (for S&CG) are due THIS WEEK (G8B next week). Thinking about the real-time commanding, I would think we can send up a 34UVS command that would take affect after existing MAGNEB commands in G7B. One thing that will make this easier is the fact that the CMDRS PA that issues the HV ON command at the beginning of the MAGNEB stands alone, and then I have a separate CMDRS PA near the end of the observation to issue the 34UVS that turns HV OFF. (If the same stored-sequence CMDRS issued both commands, then it occurs to me we might not be able to do anything in real-time between the two commands.) Also, a 34UVS command is considered non-interactive (except for the PWS-quiet issue I believe), so the real-time command approval process is simplified. The 34HSR and 34HS for turning the UVS Supplemental Heater off and on are different in that they are interactive, affecting power consumption and margin, and we'd need as much lead time as possible. I seem to remember 2 weeks for work authorization before uplink as a minimum when we did the v6.2 UVS FSW fix, and that's what we have now before the first 16-step commands in G7B MAGNEBs (we have 1-steppers for PWS-quiet until then, on 1304 and 1320 Angstroms). Offhand, and without yet speaking with Keith or Kent, I think Project con- sidered our J0CD/G1A problem (grating mis-stepping and Lyman-alpha ghosts) to be an instrument health issue. I'm faxing you some relevant documentation, including the ISA that Keith wrote at the time (I closed it a couple of months ago), and a copy of the official Project decision memo covering the use of the UVS Supplemental Heater. The memo (from Jim Erickson) states, 'To maintain the health of the UVS, the UVS Supplemental Heater shall remain on throughout the mission,' which suggests they considered it a health-and-safety issue (to keep the heater ON that is -- I don't know if they'd react differently to us asking to turn it OFF!). For what it's worth, the ISA, under 'Mission Opera- tions Impact Assessment,' has Significant checked off, rather than Minor (but not Major). Anyway, check out the faxed into, copies of which you all probably have some- where (or Karen has laying around in her brain somewhere!), and I'll try reach- ing you tomorrow after talking with K and K and perhaps other folks. Stuart -------------------------------------------------------------------------------- file: uvs_apr1997.log;1 15-apr-1997 From: GLLSVC::STEPHENS 'STUART K. STEPHENS' 15-APR-1997 19:04:11.56 To: ZODIAC::STEWART,PISCES::PRYOR,PISCES::SIMMONS,PISCES::HORD CC: KTOBISKA,JAIELLO,JPLUVS::JAJELLO Subj: UVS grating anomaly: addressing Project's concerns Tu 4/15/97 11:30 am Hi Ian, Concerning real-time tests to fix our UVS grating problem: (1) Karen and Wayne confirm that the command we were proposing does indeed involve a toggle bit. That is, putting CHANGE as the parameter in the 34UVS command means 'CHANGE from whatever grating mechanism you were using to the OTHER one.' It DOES NOT mean 'use the 2nd grating mechanism.' Eilene Theilig, the SEQ Team Chief, looked up the EV-4 Flight Sequence from our post-launch instrument checkout, which has a bunch of commands with SAME as the 34UVS para- meter and two back-to-back commands with CHANGE as the parameter. This also is consistent with (although by itself isn't proof of) it being a toggle bit. Jim Erickson explained to me this morning that the Project has always had a 'though shall have no toggle switches' rule, and that although it's water under the bridge now, it's something we should have reported or had waived at the time we built it in. As it is, we will need to convince them -- more than you and I already have -- that we fully understand the operation of the bit in the command, and the way it affects the UVS hardware. E.g., can we go from the 1st grating mechanism to the 2nd and back, repeatedly, with 99.9999% confidence that we won't get stuck in the 2nd which might turn out to be worse than the 1st? My feeling is that they take these issues very seriously, and that we\ need to convince them we know what we're doing. To the extent that you and Wayne and Karen can provide clear, concise addi- tional information about the grating mechanism operation, that will be very helpful. I realize I have the Functional Requirements documentation here, and there is description in there that probably explains these things. But, if you have diagrams (besides 6-foot blueprint pages!), etc., that we don't have, then it would be appropriate to send it. Also, if the engineers can put together a written description that would be useful to us in communicating to the Project, that will also be helpful. (2) As I discussed with you yesterday (and since then, with Karen and Wayne), we will also need to address the following questions with specific answers: -- When have we used the other grating mechanism before, with what commanding? -- What is the frequency of anomalous behavior since J0CD? In full-scans vs. mini-scans? In G7A in particular, but also characterize the period between J0CD and G7A (e.g., was there a monotonic rise in this mis-behavior, or was it so sporadic that it can't be characterized?). -- What will the results of our proposed real-time testing lead us to do in future sequences? Are we simply gathering information on our anomalous behavior in a controlled way, as you explained to me yesterday, or are we also now thinking that we can affect G8A (e.g., by simply changing the grating mechanism with the toggle switch and then leaving it there for our SAME commands in the G8A sequence to act on)? Why is this testing better than doing nothing, or waiting until G8B to test? We should address the fact that the test results will necessarily be somewhat inconclusive (i.e., they can only give us a probability that one proposed fix might work). -- (and I'm adding this question....) What, specifically, are the results of our tests on the Engineering Unit in the last week? (3) Bill O'Neill would like Charlie Hord to sign off on our proposed real- time commands when the time comes (in the next couple of days). We will need need to schedule a command conference in the next two days for generation of commands. That means I will be working with the Orbiter Engineering Team folks to put a set of appropriate commands together (with the knowledge now that we are working with a toggle bit), today and tomorrow. I will need points (1) and (2) above addressed before I go to project again, though! Sorry if I'm so pointed in my requests, but I think you will agree that we need to get a clear story together for Project in order to inspire their con- fidence in our plan. Thanks, Stuart -------------------------------------------------------------------------------- file: uvs_three_95_96.isa;7 9-Jan-1998 From: GLLSVC::STEPHENS 'STUART K. STEPHENS' 22-JAN-1997 19:08:49.48 To: PISCES::SIMMONS CC: Subj: 3 most recent ISAs, and suggestions for closing (4 printed pages) W 1/22/97 11 am Hi Karen, Well, Karen B is back in town, so I better get these ISAs done before she starts breathing down my neck! These are the ones she'd like us to address, with the notations she made in her e-mail to Kent and me (I no longer have a copy of the ccMail): 8451 UVS from 1996 Phase 2 s/w problem -- close out now or after patch 10337 UVS from 1996 Grating not stepping -- she thinks this can be closed 4527 EUV from 1995 Stays open? 4492G EUV from 1993 Stays open? Her impression was that only the recent UVS ones can be easily closed, but I think the EUV from 1995 can be closed too. Here is what I understand the status to be of the 3 most recent ISAs: 8451 (UVS 1996 Phase 2 s/w problem) ----------------------------------- I've written the following in the action section of the ISA form, after checking with Ian about the wording (he had no changes). Karen Buxbaum was happy enough to sign off on it, without any attached documentation (she seems to want to minimize that). Let me know if you think anything different should be done. 'A re-load of the UVS FSW, containing the modification of 1 hex byte (plus a change in 1 byte for the s/w version number) was successfully transmitted in real-time to the spacecraft on 96-296 to 96-297 (October 22-23). The re-load was verified by downlink of UVS housekeeping data that indicated normal opera- tion of the instrument. Actual verification of the success of the 1-byte change in UVS v6.2 FSW was obtained with downlink of G2C and C3A UVS-MWG Io torus data (DOY 301-308) that utilized commands affected by the 1 byte of FSW. The fact that we now are able to step the spectrometer grating to initial posi- tions greater than 512 (as well as to implement position changes of greater than 512 steps) confirms that the v6.2 software fix was successful. There is a res- idual problem in the v6.2 FSW that seems to be related to insufficient time for the grating drive to move to large grating steps. It is not causally related to the implementation of the v6.2 FSW re-load. The UVS PI Team is investigating this residual problem, but in the meantime is able to recover most of the sci- ence from data affected by the residual problem. We can also work around it, and are not immediately pressing for a further fix to the UVS FSW.' 10337 (UVS 1996 grating stepping problem) ----------------------------------------- In the initiation section of the ISA, Keith wrote (6/25/96): 'On DOY 96-172, the UVS PI team reported the UVS instrument was not stepping the diffraction grating properly. Real-time science data returned from the J0CD Io Torus observations indicated the instrument was periodically missing 10.66 steps (equivalent to 1 fringe cycle of the shaft encoder) at the start of the instru- ment RIM cycle-initiation. This caused the instrument starting wavelength to be offset by 16 Angstroms during 30-50% of each observation (Att. 1 & 2). Fur- ther investigation indicated the most-likely cause is a known instrument grating response at low temperatures. Identical results have been observed in the early 1980's during thermal vacuum tests of the UVS instrument at -30 degrees C (Att. 3). On DOY 96-173, real-time commands were sent to turn on the UVS Supplemental Heater causing the external UVS temerature to increase from -3.1 to +9.5 degrees C. As the instrument warmed, the correct starting wavelength occurred over a larger portion of the UVS observations. As of DOY 96-175, the instrument grat- ing has been operating correctly for 100% of the observations.' As I indicated to you in my 1/10/97 e-mail, I proposed the following action: 'Since DOY 96-175 -- i.e., during the G1 encounter and into subsequent orbits including the recent E4 encounter -- the UVS grating has been operating correct- ly when the UVS Supplemental Heater has been on. In G1 cruise, commands to turn on the heater in real-time (following sequenced off commands) were issued to keep the heater on. In subsequent orbits, the previously sequenced off com- mands were removed so that the heater would remain on without the necessity of real-time commanding. A 9/3/96 Project decision memo (IOM #JKE-96-005), UVS Supplemental Heater Usage, documents the decision to keep the heater on. This will comply with Flight Rule FR34A8, UVS Supplemental Heater Operation.' You replied that we should check to see how we did during the recent PPR ano- maly resolution exercise that freed their filter wheel, since they may want to be cold again at some point in the future. They performed their test between 96-355/20:28 and 357/02:15 (it was sequenced in E4A). I understand from Leslie and from looking through the sequence myself that they just turned PPR heaters off to get it down to about -30 C, and that the UVS Supp Htr was kept on. I will query to find out our engineering temperatures during that time. Do you also want more documentation of success we've had at higher temperatures? A recent piece of information from this morning's SSO meeting: Terry report- ed that they recently recovered (or reprocessed) half an hour of G1 data from just before their filter wheel stuck in position 21 or whatever it was, and it indicates that the FW also stuck briefly at position 24. This naturally gives them pause, since they plan on cycling through the FW once more in the nominal mission and position 24 is coming up soon. When I spoke with Leslie before the meeting, she indicated that they hoped not to have to go to cold temperatures to unstick again until the GEM mission, but of course it was the thing they would probably try first if they did get stuck again in the next few orbits. The new piece of information probably only reinforces that probability. Is this (PPR's likely desire to occasionally go to -30 C) the only thing that we should check, or is what I've written sufficient? (It seems to me that the initiation section that Keith wrote also covered most of what they should want to see for an action write-up.) 4527 (EUV 1995 microprocessor memory corruption problem) -------------------------------------------------------- The ISA was initiated by Joe on 10/3/95, and refers to some viewgraph hard- copies entitled, 'EUV Instrument Turn-On for JAA.' On 10/6/95, you wrote an e-mail which Keith forwarded to me when he left and which seemed to close out the ISA -- I've attached it below. Offhand, Karen B thinks something like this will do the trick. Let me know if that is your position too (although I realize that seemed to be your intention at the time). It's not immediately clear to me how the 10/15/93 EUV ISA relates to this, and whether it can be closed too. From: GLLSVC::KNAVIAUX 'Keith @ JPL/Pasadena,CA' 11-NOV-1996 09:02:21.50 To: JAIELLO,KTOBISKA,STEPHENS CC: Subj: FWD: 10/2/95 EUV ISA closure from KS From: BPER::SIMMONS 'KAREN SIMMONS AT LASP/COLORADO' 6-OCT-1995 13:57:39.19 To: GLLSVC::KTOBISKA CC: @JPLUVS Subj: Oct 2,95 ISA closure paper; Keith give to Gershman, Marr, etc at that meeting diskh:[simmons]EUV_OCT0295.DOC October 3, 1995 ANOMALY DESCRIPTION: The EUV science MRO on 1995-275//21:10 was delivered by email and showed a predominately zero data matrix. The status words in the (Phase 1) MRO, just before the copy of the FPN, indicated the 24EUV command had been received properly but the the time status values were not updating. Further analysis indicated that the 24SP command, issued during the EJ10 Power On in preparation for Torus observations in JAA, must have corrupted one or two bytes of program memory and that although the uP was still running, it was now running in some unknown polling loop which did not cause it to stop or to corrupt itself further. Although the PIs wishes were to simply re-start with a POR, the Project requested a memory verify set. This was agreed to as long as the MROs were part of the re-start sequence and did not include an analysis feedback loop. The IAPs were prepared for transmission on Friday, Oct 6, 1995. Prior to the Command Conference, Jim Marr requested information about what values were in the microprocessor locations after a 24SP corruption. This is what prompted the Project to request us to perform memory verifies. The data from the (May 1995) Testbed case, the LASP summer 24SP testing and all the flight cases are shown below. ANALYSIS: The EUV instrument has suffered four flight anomalies, including this October 1995 case. Three of those four are now attributed to the 24SP memory corruption situation. (The December 1989 is still not understood.) The details of the memory corruptions are addressed elsewhere, however it involves the 1802 microprocessor transition from a Run state to Load state. During this transition, which is not documented in the 1802 User Manual, it is possible to continue micro operations while it is not properly conditioned to to so and thus cause micro memory to be corrupted. This can occur with the design of the EUV CDS Bus interface. The memory corruption is therefore caused by the 24SP command and can be eliminated by not issuing this command. 24SP commands have been removed from the remaining Phase 1 and all Phase 2 sequences. The software changes for Phase 2 no longer require the microprocessor to be stopped in order to load the Fixed Pattern Noise Table. The command remains in the Power Off Library sequence where it is needed to stop the microprocessor before powering down the instrument. Since the memory is lost on Power Off, this is not a problem. submitted by Karen E. Simmons UVS/EUV Instrument Manager =========================================================================== LASP TESTING on BCE: (Summer of 1995) 24SP commands were randomly issued while the microprocessor was running. Of 70 cases when 24SP commands were issued, the following one-byte corruptions were observed. Address original value corrupted value ----------------------------------------------------------- 0000 71 C6 0000 71 00 0019 00 FF 010F 45 00 01B5 4C C6 01B6 55 00 Also, further testing of the 24SP command corruption with a test program on the BCE, indicated it was possible to corrupt numerous locations in memory. The key to the number of corrupted locations and to the value placed into the corrupted location seemed to be dependent on the contents of the CDS command data words present on the line when the SP command was recognized by the microprocessor. We considered that since time and sector broadcasts (which contain a C6 identification value) were the most frequent bus traffic, the C6 value seen in the corrupted locations could very well be these time broadcast ID values. TEST BED EVENT, May 1995: This two-byte corruption was seen in a memory verify following a 24SP command prior to Power off. This corruption did not effect the Test Bed results. Address original value corrupted value ----------------------------------------------------------- 020D,020E 02,06 B5,01 FLIGHT CASES: November 1990 - during a transition from Cruise Mode to Encounter Mode, a 24SP command was issued so a new Fixed Pattern Noise Table could be loaded. Address original value corrupted value ----------------------------------------------------------- 03B1 C3 C6 Oct 11, 1993 - during an EUV Power On after spacecraft safing, the library sequence which loads the Fixed Pattern Noise Table contains a 24SP command. Address original value corrupted value ----------------------------------------------------------- 000F A2 C6 Sept 30, 1995 - during an EUV Power On sequence in EJ10 to configure the instrument to begin taking Jupiter approach Torus data, the Fixed Pattern Noise Table library sequence issued a 24SP command. The corrupted locations are in the section of the MROs that were lost (due to a Madrid loss-of-lock.) The ACE was able to confirm that he saw the s/c power due to the Power Off/Power On commands in the IAP sequence. Address original value corrupted value ----------------------------------------------------------- ==== End of report. -------------------------------------------------------------------------------- file: uvs_oct1996.isa;1 27-Jan-1997 From: GLLSVC::STEPHENS 'STUART K. STEPHENS' 10-JAN-1997 21:26:13.71 To: ZODIAC::STEWART CC: PUP::JAJELLO,PISCES::PRYOR,PISCES::SIMMONS Subj: close-out of Anomaly Report for v6.1-to-v6.2 FSW re-load problem F 11/10/97 1:20 pm Hi Ian, I'm being asked to close out the Incident/Surprise/Anomaly Report (ISA #8451) that we filed in October for the v6.1 software problem. This requires a brief analysis/correction/verification that v6.2 did what we anticipated it would do. How about the following? (It should be about the length that you see below.) ******** A re-load of the UVS FSW, containing the modification of 1 hex byte (plus a change in 1 byte for the s/w version number) was successfully transmitted in real-time to the spacecraft on 96-296 to 96-297 (October 22-23). The re-load was verified by downlink of UVS housekeeping data that indicated normal opera- tion of the instrument. Actual verification of the success of the 1-byte change in UVS v6.2 FSW was obtained with downlink of G2C and C3A UVS-MWG Io torus data (DOY 301-308) that utilized commands affected by the 1 byte of FSW. The fact that we now are able to step the spectrometer grating to initial posi- tions greater than 512 (as well as to implement position changes of greater than 512 steps) confirms that the v6.2 software fix was successful. There is a res- idual problem in the v6.2 FSW that seems to be related to insufficient time for the grating drive to move to large grating steps. It is not causally related to the implementation of the v6.2 FSW re-load. The UVS PI Team is investigating this residual problem, but in the meantime is able to recover most of the sci- ence from data affected by the residual problem. We can also work around it, and are not immediately pressing for a further fix to the UVS FSW. (Please see attached documentation.) ******** Let me know if you want any changes. Thanks, Stuart -------------------------------------------------------------------------------- file: uvs_970420.log;2 17-Apr-1997 From: GLLSVC::STEPHENS 'STUART K. STEPHENS' 16-APR-1997 19:03:46.15 To: PISCES::SIMMONS CC: PISCES::SWEET,PISCES::GEBBEN Subj: queried glsdt1 for recent E1790 temperatures W 4/16/97 12 noon Hi Karen, I've been able to get onto sdtss10 and glsdt1, and to query the engineering temperatures (E-1790). Doing so for DOY 97 to DOY 107 gives the following file: Directory GLLSVC$USER2:[STEPHENS.BOX] E1790_DOY97_TO_107.PS;1 7 16-APR-1997 11:56:28.21 (RWED,RWED,RWED,RWED) Not a lot of readings, though, for some reason. They are all around 10 Celsius. If you have trouble getting onto glsdt1, try sdtss10 first, and then change your password -- that is what the system administrator here suggested. Talk to you later! Stuart -------------------------------------------------------------------------------- file: uvs_970420.log;1 17-Apr-1997 From:IN%'Stuart.Stephens@jpl.nasa.gov' 'Stuart Stephens' 16-APR-1997 17:54:45.25 To: IN%'stewart@lynx.colorado.edu', IN%'Alex.C.Moncada@jpl.nasa.gov' 'Alex C Moncada', IN%'Raymond.P.Weaver@jpl.nasa.gov' 'Raymond P Weaver', IN%'W.K.Tobiska@jpl.nasa.gov' 'W Kent Tobiska' CC: IN%'simmons@pisces.colorado.edu', IN%'pryor@pisces.colorado.edu', IN%'John.J.Aiello@jpl.nasa.gov' 'John J Aiello', IN%'Joseph.M.Ajello@ jpl.nasa.gov' 'Joseph M Ajello' Subj: RT cmds for UVS grating anomaly response Return-path: Return-path: Stuart.Stephens@jpl.nasa.gov Received: from eis-msg-101.jpl.nasa.gov by pisces.colorado.edu (PMDF V4.2-13 #12962) id <01IHS5VZETGW8WX8VE@pisces.colorado.edu>; Wed, 16 Apr 1997 17:54:17 GMT For uplink during the sequenced UVS observation, G8HUMAGNEB04, on DOY 110 (the morning of Sunday, April 20): IAP, at the indicated relative times (i.e., to be commanded on the indicated minor frames): CMD,6UVRT,...,BOTH,0:75:0,DISCRD,UVS; CMD,34UVS,...,PRI,0:87:0,DF,FIXED,NORM,NORM,NORM,SAME,0, OFF,OFF,ON,ON,OFF,NOOVR,1,2C,7D,00,2C; CMD,6UVRT,...,BOTH,179:75:0,PACKET,UVS; CMD,34UVS,...,PRI,180:87:0,DF,FIXED,NORM,NORM,NORM,CHANGE,0, OFF,OFF,ON,ON,OFF,NOOVR,1,2C,7D,00,2C; CMD,6UVRT,...,BOTH,359:75:0,PACKET,UVS; CMD,34UVS,...,PRI,360:87:0,C1,FIXED,NORM,NORM,NORM,CHANGE,0, OFF,OFF,ON,ON,OFF,NOOVR,1,9C,05,00,0A; Absolute-time IAP (if there's time in the uplink window), at the indicated SCLK: CMD,6UVRT,...,BOTH,3921631:75:0,PACKET,UVS; -------------------------------------------------------------------------------- file: may1998_saf.txt;7 4-Jan-1999 From:IN%'ktobiska@mail1.jpl.nasa.gov' 'W. Kent Tobiska' 1-JUN-1998 15:19:49.02 Subj: E15A - new anomaly; instruments are off Date: Mon, 01 Jun 1998 08:25:13 -0700 From: 'W. Kent Tobiska' Subject: E15A - new anomaly; instruments are off To: Amanda Hendrix , Charles Barth , Charlie Hord , 'Ian A.F. Stewart' , Joe Ajello , Karen Simmons , Kent Tobiska , Lisa Crowell , Pat Shriver , Scott Zipke , Wayne Pryor On last Thursday, there was an AACS anomaly which safed the spacecraft as a result of two realtime AACS commands being uplinked too close together. The UVS team developed a new library sequence for the flight software version 6.2 as part of the instrument turn-on sequence on Friday, May 29. That turn-on occurred as expected - Karen and I verified on Saturday morning that our instrument turn-on was nominal. UNFORTUNATELY, A SECOND ANOMALY HAS OCCURRED ON GALILEO. We found out this morning (Monday) as we came to our offices (via a notice posted on the door) that a second anomaly, related to AACS, has occurred during the E15A sequence during an Io observation. The instruments are off (again) and we will find out at a 9:00 am (JPL-time) meeting what the current status is, details, etc. I will keep you updated. -Kent -------------------------------------------------------------------------------- file: uvs_may1998.txt;1 8-Apr-1998 From:IN%'ktobiska@mail1.jpl.nasa.gov' 'W. Kent Tobiska' 29-MAY-1998 18:07:00.94 Subj: 5/22/98 Galileo Friday Report Date: Fri, 29 May 1998 10:41:32 -0700 From: Jim Erickson < Subject: 5/22/98 Galileo Friday Report Galileo Friday Report 5/29/98 The Galileo spacecraft is presently in safing, due to an error in the construction of the Europa-15 approach maneuver sequence. On May 28 the spacecraft executed the majority of the maneuver, before the sequence error caused the spacecraft to abort the on-board sequence and safe itself. The flight team is presently reconfiguring the spacecraft to allow the uplink of the encounter sequence on the evening of May 29. The navigation team has reviewed the trajectory resulting from the aborted maneuver, and the uncorrected errors will have a minimum impact on the flyby. It is expected that the encounter activities beginning on May 30 will be unaffected by the safing event. The other major activity over the past week was the continued playback of the Europa-14 recorded data. The playback process was halted by the maneuver anomaly, with 97% of the planned data returned. This will be the first encounter to use the full gyro capability since the initial gyro anomaly during the Europa-12 encounter back on December 16, 1997. The attitude control system is now believed to be fully functional, and restored to normal, pre-anomaly, capability. James K. Erickson Deputy Galileo Project Manager =================================================================== From:BPER::SIMMONS 'KAREN SIMMONS AT LASP/COLORADO' 30-MAY-1998 17:02:24.96 To: @GLL_SCI,SWEET Subj: UVS Power On looks OK All, Here are the engineering values from the flush following the UVS Power On mini-sequence. Besides being cold, the numbers all look good. I think it is safe to say that the instrument is on and all is OK for the start of E15a later today (Sat). Karen The data file is GLLUVS2:[GLL_RAW.UVS_P2]e15p_urt_poweron.dat if you want to take a look. =================================================================== Record Number 0 Start time: 4497392 End time: 4497397 First Fiducial: 8925 8925 8925 8925 8925 8925 8925 First Fiducial Starting Wavelength: 57.485714 Low Voltage (+10v): 191.11429 Low Voltage (+5v): 135.05714 High Voltage F-Channel: 31.085714 High Voltage N-Channel: 29.314285 High Voltage G-Channel: 29.771429 Limb sensor: 26.628571 Logic temperature: 141.34285 Detector temperature: 152.71428 fiducial rim time: 5 time stamp rim time: 5 The fiducial rim matches the time stamp rim. Second Fiducial: 8925 8925 8925 8925 8925 8925 8925 Second Fiducial Starting Wavelength: 57.000000 Low Voltage (+10v): 191.08571 Low Voltage (+5v): 135.08571 High Voltage F-Channel: 31.171429 High Voltage N-Channel: 29.600000 High Voltage G-Channel: 29.799999 Limb Sensor: 26.571428 Logic Temperature: 141.34285 Detector Temperature: 152.82857 fiducial rim time: 5 time stamp rim: 5 The fiducial rim matches the time stamp rim. -------------------------------------------------------------------------------- file: uvs_may1998_fsw.lib;5 29-May-1998 note: Wayne verified that the V6.2 load is what is in the BCE on this date (ie, the copy of 'v6p2' on Neil White's directory has probably been edited into the v6p3 already.) -kes, May 29,98 =================================================================== From: IN%'KTOBISKA@gllsvc.jpl.nasa.gov' 29-MAY-1998 20:36:42.34 To: IN%'SIMMONS@pisces.colorado.edu' CC: IN%'KTOBISKA@gllsvc.jpl.nasa.gov' Subj: ORPRO.UVSON-P2-V62 (OFFICIAL VERSION #2) $$GLL ORBIT PROFILE *ORPRO GLL*STUART.ORPRO/UVS62FSW1008 *LEVEL SEB *PREP UVS-SWG/K. TOBISKA 37742 *RUNID WKT *PROGRAM SEQGEN 96-208/15:34:17.000 *CREATION 96-282/11:16:05.601 *BEGIN 98-219/00:00:00.000 *EPOCH UVS,98-219/01:00:00.000 *CUTOFF 98-220/00:00:00.000 *TITLE OFFICIAL LOAD PHASE2 UVS 6.2 FSW (5/29/98) *SCLK GDMT*CLK-LTF.SCLKSCETCOEF *LITIME GDMT*CLK-LTF.LITETIMEFILE *ORPRO GLL*STUART.ORPRO/UVS62FSW1008 *ORPRO GLL*KEITH.ORPRO/UVS62FSW $$EOH PA2,COMMENT,384ZH,PRI,UVS+CDS 00:00:0,RSST,UVS-SWG/LIBRARY SEQUENCE, LSNUUVSON_02-,UVS V6.2 POWER ON,UVS V6.2 POWER ON,UVS+CDS 25:00:0; PA2,UTILITY,20ZH,BOTH,UVS+CDS 00:00:0,+CDS 25:00:0,+00:04:02.666,RSST, UVS-SWG/LIBRARY SEQUENCE,LSNUUVSON_02-,UVS V6.2 POWER ON; CMD,34A,20ZH3A,PRI,UVS+CDS 00:04:0,1; CMD,34A,20ZH3B,SEC,UVS+CDS 00:16:0,2; CMD,34DML,20ZH4A,PRI,UVS+CDS 02:21:0,0000,71,60,F8,09,A6,F8,00,B6,D6,B1,BB,BC, F8,31,A1,F8,C0,A2,F8,A2,A4,F8,8C,A5,F8,70,A7,F8,F6,AD,F8,ED; CMD,34DML,20ZH4B,PRI,UVS+CDS 02:22:0,0020,AE,F8,F8,AF,F8,01,B2,B4,B5,B7,BD,BE, BF,70,66,30,2F,36,36,C4,C4,D7,F8,3A,A6,D6,35,56,19,89,52,83; CMD,34DML,20ZH4C,PRI,UVS+CDS 02:23:0,0040,E2,F3,3A,4F,99,52,93,F3,3A,4F,A9,B9, D4,30,56,9A,52,E2,67,22,1B,D5,3F,5E,F8,31,A1,E6,30,2D,0D,FB; CMD,34DML,20ZH4D,PRI,UVS+CDS 04:28:0,0060,59,32,A8,9C,32,58,EE,0E,FB,01,5E,FA, 01,FE,FE,AA,1E,8C,F3,32,7D,F9,1F,5E,8C,F2,5E,64,2E,1E,0E,FA; CMD,34DML,20ZH4E,PRI,UVS+CDS 04:29:0,0080,04,32,87,8A,FB,04,AA,4E,FA,03,BB,0E, AB,8A,52,E2,67,22,F8,ED,AE,F8,01,B8,F8,E9,A8,0E,FA,01,CE,18; CMD,34DML,20ZH4F,PRI,UVS+CDS 04:30:0,00A0,18,48,B3,08,A3,C0,01,22,E2,F8,04,BA, 52,67,22,F8,01,B8,F8,E9,A8,F8,01,B9,4F,A9,49,58,B3,18,09,58; CMD,34DML,20ZH4G,PRI,UVS+CDS 06:35:0,00C0,A3,18,EF,0F,FA,08,CE,65,2F,0F,FA,F7, BC,5F,FA,F4,5E,EE,63,66,2E,1F,4F,AC,FE,3B,E0,8C,FA,9F,30,E8; CMD,34DML,20ZH4H,PRI,UVS+CDS 06:36:0,00E0,FE,3B,E7,8C,FA,5F,38,8C,5E,64,4F,AB, 0F,FA,03,BB,4F,FA,FC,F6,F6,F9,C0,A9,49,58,18,09,58,4F,5E,1E; CMD,34DML,20ZH4I,PRI,UVS+CDS 06:37:0,0100,0F,5E,F8,ED,AE,F8,F9,AF,0F,2F,FE,33, 1E,F8,02,B3,F8,10,A3,83,58,28,28,58,18,93,58,28,28,58,F8,00; CMD,34DML,20ZH4J,PRI,UVS+CDS 08:42:0,0120,B9,A9,F8,01,B1,F8,47,A1,E6,70,66,3C, 2B,D5,E6,71,26,F8,00,B1,8B,32,43,FB,FF,3A,40,52,67,22,1B,38; CMD,34DML,20ZH4K,PRI,UVS+CDS 08:43:0,0140,2B,7B,7A,C0,00,58,70,7A,22,78,22,73, 36,4F,D7,35,6B,19,89,52,83,F3,3A,66,99,52,93,F3,3A,66,A9,B9; CMD,34DML,20ZH4L,PRI,UVS+CDS 08:44:0,0160,9A,FB,04,BA,30,6B,9A,C6,2B,38,1B,12, 42,30,46,D1,4D,FB,5A,3A,88,0D,FB,09,3A,84,0E,F9,08,52,63,EE; CMD,34DML,20ZH4M,PRI,UVS+CDS 10:49:0,0180,63,22,2E,E2,0D,FC,01,5D,2D,30,6F,D6, 8B,3A,95,9B,FA,03,BB,32,8B,7B,7A,F8,14,A8,28,88,3A,9A,2B,30; CMD,34DML,20ZH4N,PRI,UVS+CDS 10:50:0,01A0,8C,D6,9C,32,A1,9A,FB,04,BA,30,A1,C4, C4,C4,C4,C4,C4,C4,C4,C4,C4,C4,C4,C4,C4,C4,00,00,00,00,00,00; CMD,34DML,20ZH4O,PRI,UVS+CDS 10:51:0,01C0,00,00,01,00,02,00,03,00,04,00,06,00, 08,00,0B,00,0C,00,10,00,16,00,18,00,21,00,2C,00,30,00,42,00; CMD,34DML,20ZH4P,PRI,UVS+CDS 12:56:0,01E0,58,00,84,00,B0,01,08,02,10,00,00,00, 00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,62; CMD,34ST,20ZH5A,PRI,UVS+CDS 13:00:0; CMD,34UVS,20ZH4Q,PRI,UVS+CDS 14:00:0,C1,FIXED,NORM,NORM,NORM,SAME,0,OFF,OFF, ON,OFF,OFF,NOOVR,1,2C,05,00,00; CMD,6UVRT,20ZH6A,BOTH,UVS+CDS 16:05:0,DISCRD,UVS; CMD,6UVRT,20ZH6B,BOTH,UVS+CDS 21:05:0,PACKET,UVS; -------------------------------------------------------------------------------- file: uvs_jul1998.txt;1 5-Apr-1999 Jul-1998 During E16, a slip ring problem caused a bus reset which triggered spacecraft safing. -------------------------------------------------------------------------------- file: nov2198_safe.doc;4 24-Nov-1998 E18 safing - most encounter data lost ========================================================================= From:IN%'kent.tobiska@jpl.nasa.gov' 'W. Kent Tobiska' 23-NOV-1998 16:08:17.55 Subj: 11/22/98 Galileo Anomaly Report #2 To: Amanda Hendrix , Bob West , Charles Barth , 'Ian A.F. Stewart' , Joe Ajello , Karen Simmons , Arthur Lane , Wayne Pryor As you may have heard, we lost the E18 encounter due to a couple of spacecraft safings. Activities today (Monday) are aimed at recovering the states (including UVS on and EUV off) to match the beginning of E18B (cruise) sequence. I believe we got the Europa atmosphere observation before the anomaly - Karen and Amanda, could you check? It would be 18EUATMOS_01 with 5 flushes on the following RIMs: 349CB 4747072 349CC 4747167 349CD 4747197 349CE 4747227 349CF 4747259 Do the data look ok? -Kent >>>> Galileo Anomaly Report #2 11/22/98 - 11:30 am PST The Galileo spacecraft is still in safing, with no health or safety concerns. Recovery planning is in process, with an expected return to normal operations at approximately 5:00 pm PST on November 23. Memory readouts from the Command and Data System (CDS) have verified that the spacecraft safing was induced by a simultaneous despun bus reset on each of the semi-redundant CDS halves. After the spacecraft is back to normal operations, a plan will be developed to best utilize the available playback time in the Europa 18 cruise sequence. This plan will include elements of playing back the limited data taken at Europa 18, additional recovery of Europa 17 data, and real-time cruise science. >>>> Galileo Anomaly Report #1 11/22/98 - 4:00 am PST The Galileo spacecraft has experienced an anomaly just prior to it's Europa 18 encounter. It is presently in safing, and is stable. Analysis is proceeding, but appears to show that the spacecraft has experienced another despun bus reset, similar to the reset at Europa 16. The preliminary analysis shows the reset occurred at 9:34 pm PST on November 21, approximately 2 hours prior to Jupiter closest approach, and 6 hours prior to Europa closest approach. The reset appears to have happened on both strings simultaneously (within one minor frame, two thirds of a second). After analysis confirms the sequence of events leading to the safing, a recovery plan will be developed and executed. James K. Erickson Galileo Project Manager Jet Propulsion Laboratory James.K.Erickson@jpl.nasa.gov ************************** From:IN%'kent.tobiska@jpl.nasa.gov' 'W. Kent Tobiska' 23-NOV-1998 18:02:01.48 To: IN%'SIMMONS@pisces.colorado.edu' 'KAREN SIMMONS AT LASP/COLORADO' CC: IN%'kent.tobiska@jpl.nasa.gov' Subj: RE: 11/22/98 Galileo Anomaly Report #2 Hi Karen, I will send out Erickson's anomaly messages as I get them. As for instruments, UVS was to be powered on the the recovery sequence with EUV remaining off until E19. We will get a flush from the UVS turn on at (which should be at 10:37 PST this morning - oh!... in about 1/2 hour!). 04750181:08:0 34UVS 20ZH4Q 98-327/18:37:09.133 (SCET UTC) Step: C1 Mode: FIXED F OV: NORM N OV: NORM G OV: NORM GrCn: SAME #Pos: 0 Fsel: OFF Nsel: OFF Gsel: ON HV : OFF Stim: OFF Limb: NOOVR Intg: 1 Init: 2C Pos2: 05 Pos3: 00 Pos4: 00 04750183:13:0 6UVRT 20ZH6A DISCRD UVS 04750188:13:0 6UVRT 20ZH6B PACKET UVS Talk to you later... -Kent ------------------------------------------------------------------- #2 23-NOV-1998 22:50:06.14 NEWMAIL >Subject: galileos status report > >For your information. > >-Jim E- > >To: James.Erickson@jpl.nasa.gov, Robert.W.Sible-Jr@jpl.nasa.gov, >> Torrence.V.Johnson@jpl.nasa.gov, David.P.Schranck@jpl.nasa.gov, >> Leslie.L.Lowes@jpl.nasa.gov >>From: Jane Platt >>Subject: galileos status report >> >>below and attached....the Galileo status report that went out this afternoon. >> >>MEDIA RELATIONS OFFICE >>JET PROPULSION LABORATORY >>CALIFORNIA INSTITUTE OF TECHNOLOGY >>NATIONAL AERONAUTICS AND SPACE ADMINISTRATION >>PASADENA, CALIF. 91109 TELEPHONE (818) 354-5011 >>http://www.jpl.nasa.gov >> >>Contact: Jane Platt >> >>GALILEO EUROPA MISSION STATUS >>November 23, 1998 >> >>Galileo project engineers expect the spacecraft to return to normal >>operations today at about 5 p.m. Pacific Standard Time, following a weekend >>in which the spacecraft entered safing mode twice. The first of these >>events prevented Galileo from gathering data on Europa as it flew by the >>icy moon early Sunday, November 22. >> >>Galileo engineers believe the safing events, which act as a built-in >>protection system, were triggered by resets of the portion of the craft's >>control and data subsystems that control the non-spinning part of the >>spacecraft. These subsystems handle Galileo's communications and >>transmission of data to Earth. >> >>Galileo's health and safety are not in jeopardy. The anomalies occurred >>Saturday, November 21, at 9:34 pm PST, and Sunday, November 22, at 5:30 >>p.m. The first safing happened about six hours before Galileo was >>scheduled to fly by Europa, and two hours before its closest approach to >>Jupiter's intense radiation. >> >>Before entering safing mode, Galileo performed ultraviolet spectrometer >>observations, and its near infrared mapping spectrometer performed an >>observation of Jupiter's white oval storm system. It also obtained some >>radio science measurements of Europa even while in safing mode. >> >>These anomalies are somewhat similar to a reset that occurred during a >>previous Europa flyby last June. However, in the latest anomalies, the >>semi-redundant halves of the control and data subsystems reset >>simultaneously, while in June they reset one after the other. >> >>The Galileo team has been sending commands to the spacecraft to restore its >>operations. In fact, the Sunday night safing occurred just before the >>craft recovered from the Saturday safing. Once Galileo is functioning >>normally again, the project team will develop a plan to have the spacecraft >>transmit to Earth the data it gathered. >> >> This weekend's Europa flyby was the 10th performed by the Galileo >>spacecraft; another Europa encounter is planned for January 31, 1999. The >>spacecraft has spent the past three years orbiting Jupiter and its moons, >>including Europa, and has provided scientists with a wealth of information >>and pictures. Its primary mission ended in December 1997, and the >>spacecraft is currently in the midst of a two-year extension, known as >>Galileo Europa Mission. >> >># # # # # ============================================================= #4 24-NOV-1998 00:13:04.20 NEWMAIL From: BPER::SIMMONS 'KAREN SIMMONS AT LASP/COLORADO' To: STEWART CC: @SIM:GLL_SCI Subj: UVS instrument back on Ian, The UVS instrument has been re-loaded following the two s/c safings we had over the weekend. The Power is ON and the HV is OFF, as it should be. I pulled the real-time packets that result from the re-load and they look OK (the starting wavelength is wrong but the counts are all zero so I'm sure we're safe. I'll have some more numbers in the morning. Karen note later: The Power On packets had the RIM times 4750184 - 0189 so the actual power on time can be determined from the library sequence. That was loaded on Nov 23, 1998. KES -------------------------------------------------------------------------------- file: sc_jan311999.doc;3 8-Feb-1999 file: diskh:[simmons.gll_anomalies]sc_jan311999.doc Feb 1,99 - kes The spacecraft safed during E19A, at a time just after UVS obtained the Europa Surface, Atmosphere and Surface 2 RT packets. The safing was apparently due to a timing error regarding the hi-phase Sciturn commanding the z-axis back to the sun-point. The feeling is that not enough time was allocated to the turn back and conflicting commands caused the safing. Safing time is believed to have been approx 99-032/05:41 SCET. Since the safing occured during the turn back to sun the s/c is in an undetermined z-axis pointing. No telem is therefore available because the s/c is off point. They are commanding MROs from the 43 and 63 passes to determine pointing/recovery. The safing occured after the E19A' breakpoint so the prime seq. was not used. The attitude and configuration will be recovered so that the E19B Load will execute properly: UVS and EUV are Power On, EUV will be HV ON and UVS will be HV Off. UVS should have gotten all RTS back before the safing. There is some missing packets however and these might have been caught in a station transfer or for some reason are delayed in arriving. There was a Buffer Dump To Tape in the turn so some of our RTS packets might have ended up on the tape and should be recoverable during PB. Unlikely but possible. To add insult to injury, the JPL query server went down during all this. JPL personnel moved all server activity to another machine but the new machine did not have outside-JPL access. Monday morning Lisa/Kent executed a querry for us and returned some data to a file which we then ftp'd. Feb 8,99 News from the weekend is that the s/c was commanded to return to earth-point via two sciturns and it is now 0.5 deg off earth. -------------------------------------------------------------------------------- file: sc_may1999.txt;2 17-May-1999 file: [sim:.gll_anomalies]SC_MAY1999.TXT May17,1999 - kes Additional info to the bus reset message below: a realtime command was sent to reset to Inertial at 99-125//02:30 UTC ERT JPL which would have effected the change about 3:18:35 SCT and have taken 26m3s to execute. ========================================================================= From: IN%'jerickso@mail1.jpl.nasa.gov' 'Jim Erickson' 4-MAY-1999 15:25:45.13 Subj: Bus Reset Protection Works in Flight Date: Tue, 04 May 1999 08:22:31 -0700 From: Jim Erickson Subject: Bus Reset Protection Works in Flight To: gem_project@donatello.jpl.nasa.gov, gll-inv@donatello.jpl.nasa.gov To the GEM Flight Team- As most of you have heard, we have had an opportunity to use the new Bus Reset Protection Software in flight operations. On Monday, 5/3/99, between 123/17:57 and 18:51 (SCET), telemetry indicates that the spacecraft had survived a bus reset and that the bus reset patch had executed as expected- meaning the sequence was NOT cancelled and we did NOT go through safing. Subsequently, at around 124/02:00 (SCET) the spacecraft experienced a second reset. Again, the protection worked as planned. The group that developed, tested, and uplinked this new software deserves our thanks. This new software has already proven itself, and in the words of my wife, has earned the 'Emmy seal of approval'. We will all have a chance now to devote our time and efforts to planning, sequencing, and operating the mission, instead of anomaly recovery. There may well be more anomalies to overcome, but this is yet another proof of my belief that we have the best flight team in the world, running the best spacecraft flying. Thank you all, whether you're part of the software team, or kept the rest of the project going while the team developed the patch. We all have a part to play to make the Flight Team and the GEM successful. * * * * * * * * * * * * * * * * James K. Erickson Galileo Project Manager Jet Propulsion Laboratory James.K.Erickson@jpl.nasa.gov -------------------------------------------------------------------------------- file: uvs_jun1999_grating.txt;2 14-Jun-1999 file: diskh:[simmons.gll_anomalies]UVS_JUN1999_GRATING.TXT;1 June 14,1999 - kes The Starting Wavelength reported in the UVS housekeeping data continues to indicate that the grating drive is not achieving its commanded position, even more frequently than earlier in the mission. Without knowing the cause of the drive problem, several suggestions were made about trying to remedy the problem. One was to run the grating more, as in the long cruise periods,to exercise it more; recall we stoppped this when PWS had EMagnetic interference problems and now that that part of their detector no longer funcions we are free to return to more movenment. The commands in this file change the 'one-step fixed' commands between observations and during the inter-orbit cruise periods back to 'full-scan' commands. In the meantime, tests are going forward on the engineering model to test the uP software removal of the grating fly-back. This would be accomplished by realtime commanding a two-byte patch. No results on that yet. ======================================================================= From: IN%'kent.tobiska@jpl.nasa.gov' 'W. Kent Tobiska' 1-JUN-1999 23:11:45.94 Subj: 34UVS commands in C21A that need changed Date: Tue, 01 Jun 1999 16:13:35 -0700 From: 'W. Kent Tobiska' Subject: 34UVS commands in C21A that need changed To: david.acevedo@jpl.nasa.gov, cpolansk@mail1.jpl.nasa.gov, eilene.theilig@jpl.nasa.gov Cc: kent.tobiska@jpl.nasa.gov, 'Ian A.F. Stewart' , Karen Simmons , Lisa Crowell Hi David, Carol, and Eilene, After discussions with Carol and David this afternoon, here are the agreements that we came up with for each orbit. The valid command for all sequences is now: 07,SCAN,NORM,NORM,NORM,SAME,0,ON,OFF,OFF,OFF,OFF,NOOVR,1,00,9C,00,00 C20B: Carol and David will send up the changed parameters for the 34UVS commands in sequence C20B by realtime command. The command can excute 10-15 RIMS after the nominal 'C1 FIXED...' grating exercise command in the C20B sequence so timing is not critical. 04999498:87:0 CM 34UVS 157BA156A123B4A PRI 05019437:87:0 CM 34UVS 157BB156A123B4A PRI 05039376:87:0 CM 34UVS 157BC156A123B4A PRI 05059315:87:0 CM 34UVS 157BD156A123B4A PRI C21A: The commands in C21A, specified by RIM and PSID, that need parameters changed (to be done by David Acevedo): 05061477:87:0 CM 34UVS 157CC156A123B4A PRI 05061499:87:0 CM 34UVS 157CD156A123B4A PRI 05061528:87:0 CM 34UVS 157CA156A123B4A PRI 05061560:87:0 CM 34UVS 157CB156A123B4A PRI 05062238:87:0 CM 34UVS 157CE156A123D4A PRI 05062387:87:0 CM 34UVS 157CF156A123B4A PRI 05062744:87:0 CM 34UVS 157CG156A123D4A PRI 05063132:87:0 CM 34UVS 157CH156A123B4A PRI 05063197:87:0 CM 34UVS 157CH156A123D4A PRI 05084241:87:0 CM 34UVS 157BA156A123B4A PRI 05104180:87:0 CM 34UVS 157BB156A123B4A PRI C21B: Carol will hand edit the grating exercise commands at the times: 05084241:87:0 CM 34UVS 157BA156A123B4A PRI 05104180:87:0 CM 34UVS 157BB156A123B4A PRI C22A: Kent and Lisa will change the commands in the sequence with the new green sheet delivered to Alicia. C22B: Carol will hand edit the grating exercise commands at the times: 05142982:87:0 CM 34UVS 157BA156A123B4A PRI 05162921:87:0 CM 34UVS 157BB156A123B4A PRI C23A: Kent and Lisa will deliver new commands in the sequence. The 34DML commands will not be inserted until C23A, pending testing on the UVS engineering unit. C23B: Carol will edit the library sequence to the new command. Thanks, Kent -------------------------------------------------------------------------------- file: c22a_pb_loss.doc;2 18-Aug-1999 From:IN%'kent.tobiska@jpl.nasa.gov' 'W. Kent Tobiska' 18-AUG-1999 19:48:19.80 To: IN%'SIMMONS@pisces.colorado.edu' 'KAREN SIMMONS AT LASP/COLORADO' CC: Subj: RE: c22a anomaly? >Kent, > One of the ground status reports mentioned a 'c22a anomaly': >From: IN%'skthompson@jpl.nasa.gov' 'Stanley K Thompson' 14-AUG-1999 13:41:50. >R/T COMMANDING STATUS >99Q207 'C22B - File#1' Radiated and verified. >99Q208 'C22B - File#2' Radiated and verified. >99M213 'Select Map 0/3 for memload verify' Radiated and verified >99E214 'C22A Anomaly investigation MROs' Radiated and verified. > > >got any idea of what this is about? Wayne did a 1st cut at the data and >reports that the data don't look any good. The wavelengths are all wrong as >well. I wonder if we're 'too hot'? Either that or some pointing problems. >Let us know what you hear. > >Thanks, Karen The Galileo spacecraft is operating normally, after completing the passage through the high radiation environment of the Jupiter close approach region. The spacecraft experienced three faults, and on board fault protection and the new bus reset protection software handled all of them correctly. The spacecraft is continuing to perform the planned observations and has completed approximately 33% of the total recording planned for the encounter. At 6:07 a.m. PDT on 8/12, the radiation environment near our Jupiter close approach appears to have caused a despun bus reset. The bus reset protection software succeeded in keeping the encounter going, but the tape recorder truncated the recording of an observation. On board algorithms in the CDS continued the recording sequence, but had to skip recording several other observations to get back on track. This error resulted in the truncation of 10% of a fields and particles recording, the loss of two Near Infrared Mapping Spectrometer observations, and the loss of another fields and particles observation. At 8:21 a.m. PDT on 8/12, the radiation environment appears to have also caused a backup spin source to experience a hardware error. The spin detector is monitored by on board fault protection, which disabled the spin detector and data compression of the Plasma Wave instrument. Data compression will not be re-enabled until 5:00 p.m., due to ground transmitter problems. The bus reset protection software again proved it's value, as another bus reset occurred at about 10:29 a.m. PDT on 8/12. The software handled it as planned, and the sequence continued unaffected. -------------------------------------------------------------------------------- file: c22a_rad_level.doc;1 24-Aug-1999 From: IN%'kent.tobiska@jpl.nasa.gov' 'W. Kent Tobiska' 24-AUG-1999 17:41:22.44 To: IN%'stewart@pisces.colorado.edu' 'Ian A.F. Stewart', IN%'pryor@pisces.colorado.edu' 'Wayne Pryor', IN%'hendrix@pisces.colorado.edu' 'Amanda Hendrix' CC: IN%'kent.tobiska@jpl.nasa.gov', IN%'lisa.c.crowell@jpl.nasa.gov' 'Lisa Crowell' Subj: C22 radiation Date: Tue, 24 Aug 1999 10:43:29 -0700 From: 'W. Kent Tobiska' Subject: C22 radiation To: 'Ian A.F. Stewart' , Wayne Pryor , Amanda Hendrix , Karen Simmons: ; Cc: kent.tobiska@jpl.nasa.gov, Lisa Crowell In the SPOT meeting today, SSI reported that the C22 radiation environment outbound was significantly higher than their exposure model. In their exponentially decreasing model, at 8 Rj, the radiation was double the expected counts, and at 14 Rj the radiation was 5 times the expected amounts. This may be one explanations as to why our spectra seemed really strange in C22. -Kent -------------------------------------------------------------------------------- file: c22a_uvs_temps.doc;1 3-sep-1999 From: IN%'kent.tobiska@jpl.nasa.gov' 'W. Kent Tobiska' 2-SEP-1999 21:27:37.17 To: IN%'stewart@pisces.colorado.edu' 'Ian A.F. Stewart', IN%'pryor@pisces.colorado.edu' 'Wayne Pryor', IN%'hendrix@pisces.colorado.edu' 'Amanda Hendrix' CC: Subj: UVS Temperatures Following C22 Encounter Date: Thu, 02 Sep 1999 14:30:00 -0700 From: 'W. Kent Tobiska' Subject: UVS Temperatures Following C22 Encounter To: Karen Simmons: ;, 'Ian A.F. Stewart' , Wayne Pryor , Amanda Hendrix >Date: Thu, 02 Sep 1999 13:59:54 -0700 >To: W.K.Tobiska@jpl.nasa.gov >From: 'C. D. Porter' >Subject: UVS Temperatures Following C22 Encounter >Cc: e.e.theilig@jpl.nasa.gov, > Nagin Cox , > Carol.A.Polanskey@jpl.nasa.gov > > >Kent, > >Following the C22 encounter the UVS temperature did not return to the level >that it was experiencing prior to the encounter. Even at this late dat >(some 18 days since encounter) it has remained in a somewhat warmer state >than it typically operates during the cruise phase of an orbit. The UVS >(E-1790) is currently at 11.6=B0C (166 DN) whereas during cruise phase it h= as >been at a steady state temperature of 8.1=B0C (161 DN). > >An investigation of the other temperature measurements associated with the >Scan Platform (SP) showed that they wee experiencing warmer temperatures >also. On Day Of Year 99-237 the SP temperature (E-0008) was 2 to 3 DN (1.4 >to 2.1=B0C) warmer than usual for the SP power configuration. The Gyro >temperatures (E-1472 and E-1474) were 2 DN warmer but Accelerometer #1 >temperature (E-1481) did not indicate a warmer than usual temperature. It >was at its normal temperature. > >The PPR temperatures Detector (E-1715) and the Electronics (E-1716) were up >2 DN (1.4=B0C) above their usual expected level. > >The SSI temperatures (E-1880, E-1881, E-1882, E-1883, E-1884 and E-1885) >were on the average 2 DN (1.4=B0C) warmer. > >>From a Thermal/Power perspective I do not know any reason why these >elevated temperature conditions exist. > > >Dan Porter > -------------------------------------------------------------------------------- file: c22_anomaly.txt;1 14-Sep-1999 Here's the raw data from the C22B grating exercise file: C22B_URT_GRATNG02.DAT;1 File header values (Times, etc): 99 252 14 51 27 846 99 252 11 1 48 927 5162742 99 252 14 2 48 254 5162921 8 0 0 0 0 0 0 0 25625600 122 -1 -1 11000 -1 -1 -1 -1 -1 -1 -1 (The large number 25625600 is the Data Presence Indicators bytes, indicating some missing data.) So, UTC ERT is 99-252//14:51:27.846, etc. The UVS fiducial contains 18 values. (See Attachment below.) First fiducial of spectral pair (raw values) 57371 57371 57371 57371 57371 57371 57371 0 113 15036 42535 37219 38206 36108 36017 9366 24294 33660 2nd fiducial of spectral pair (raw values) 57371 57371 57371 57371 57371 57371 57371 0 113 15036 42457 37237 38183 36104 35901 9386 24144 33509 ===================================================================== ANALYSIS RTS duration is 5162921-5162742=179 Rims; agrees with sequence as to time and duration. Each RTS buffer contains a pair of spectra, each Rim yields 14 UVS spectra therefore each summed spectra in the RTS pair represents a total of 7 x (#Rims summed). From the seven Sync words we can verify the amount of time summed: The values returned are 57371 which is (255 x 7 x 179) rolled around the 2^16 counter four times: (255 x 7 x 179)=319515-(2^16 x 4)=57371 Fiducial values 8 and 9 are digital status bytes that report the last command the instrument accepted. STATUS WORD 1 is 113, which, rolled around the 2^16 counter three times is the value 157 (base 10) or 10011101 (base 2). Using the attached map we see the F detector is On, no HV are On, and a 6msec integration. STATUS WORD 2 is 15036, which did not roll over the counter, is a base-10 value 12 or 00001100 (base 2) telling us the microprocessor is in Scan Mode, Microprocessor On, and with the HV Off. The two status words indicate the instrument did not see the sequenced Grating mini-scan which uses the G-channel, HV-On mini-scan mode. We note that these values represent the 'last values latched into these registers'. If the microprocessor interrupts are not recognized, or the instrument is in Cold Start Mode, then the values do not update. ATTACHMENT UVS fiducial values should show up in packet#0 and packet #4 of each buffer dump. Each value is 2 bytes long and should be divided by (#RIMS)*7 to get the value per spectra. # definition expected value for IFL ------------------------------------------------------- 0-6 7 Sync words = FF hex 7 Starting Wavelength (~48 hex /3d hex) gg full scans ^ flyback on mf 0 8 UVS status byte # 1 3d hex bit(0=most significant bit) 0 F detector 0=off 1 N detector 0=off 2 G detector 1=on 3 F HV 1=off 4 N HV 1=off 5 G HV 1=off 6,7 Int. time 01=6msec 9 UVS status byte # 2 0c hex bit 0 mode 0=scan,1=fixed 1,2 wavelength 00 3 motor grating 0=same 4 micro 1=micro processor on 5 HV 1=hv off 6 stim lamp 0=off 7 limb sens. 0=off 10 Low Voltage (+10V) ~191 DN (range=184 - 210) 11 Low Voltage ( +5V) ~135 DN (range=123 - 139 12 High Voltage F-Channel ~25 DN =hv off,~127 DN=hv on,~78 = transition 13 High Voltage N-Channel ~25 DN =hv off,~127 DN=hv on,~78 = transition 14 High Voltage G-Channel ~25 DN =hv off,~127 DN=hv on,~78 = transition 15 Logic Temperature ?? 16 Detector Temperature ?? 17 Limb Sensor ~26 DN = nominal -------------------------------------------------------------------------------- file: c22b_por.txt1;1 14-sep-1999 From: IN%'kent.tobiska@jpl.nasa.gov' 'W. Kent Tobiska' 14-SEP-1999 16:48:45.65 To: IN%'pryor@pisces.colorado.edu' 'Wayne Pryor', IN%'stewart@pisces.colorado.edu' 'Ian A.F. Stewart', IN%'hendrix@pisces.colorado.edu' 'Amanda Hendrix' CC: IN%'kent.tobiska@jpl.nasa.gov', IN%'lisa.c.crowell@jpl.nasa.gov' 'Lisa Crowell' Subj: Final UVS POR background Date: Tue, 14 Sep 1999 09:51:50 -0700 From: 'W. Kent Tobiska' Subject: Final UVS POR background To: Karen Simmons: ;, Wayne Pryor , 'Ian A.F. Stewart' , Amanda Hendrix Cc: kent.tobiska@jpl.nasa.gov, Lisa Crowell UVS POR commanding Tuesday Sept 14, 1999 UVS INSTRUMENT STATUS: 4 playback data segments from 9-8-99/9-9-99 showed 21/22 spectra with unexpected starting wavelength position of '0' (one spectra had a position of '1'). These were data collected during the C22 encounter, feature track period. 1 grating exercise flush on 9-9-99/9-10-99 showed that an 88 step 34UVS command had not executed in the instrument on those days (5 days ago). The data of 'last command executed' are included in the header/fiducial information of the flush packet (F/F HV off command). CONCLUSION: UVS is in anomalous operational state. HV is off. Instrument is safe but science data probably not obtainable in C23. POSSIBLE SCENARIOS TO ARRIVE AT THIS STATE: UVS microprocessor is in an anomalous state - 'bit flip, looping?' UVS grating drive electronics are in an anomalous state - 'unresolved fringes (radiation degradation)?' (e.g., LED dimming with age; LED dimming due to radiation; fringe comparison logic/diode detector and LED degraded by radiation; aging of electronics) OPTIONS: MRO the UVS memory to check the microprocessor state (will not fix the problem and MRO can cause memory location upset in UVS RAM TC244 chip). Not acceptable. Power off, then power on and reload memory of UVS, restart microprocessor (will fix microprocessor and may help grating electronics; concern of commanding during possible spacecraft anomaly and higher radiation periods during perijove and ability to get the commands into the instrument). Acceptable. Leave as is and do work after encounter (will likely lose C23 science). Not acceptable. W. Kent Tobiska -------------------------------------------------------------------------------- file: c23_por.txt;1 17-sep-1999 16-SEP-1999 23:12:15.14 NEWMAIL From: IN%'kent.tobiska@jpl.nasa.gov' 'W. Kent Tobiska' To: IN%'jerickso@mail1.jpl.nasa.gov' 'Jim Erickson' CC: IN%'kent.tobiska@jpl.nasa.gov', IN%'lisa.c.crowell@jpl.nasa.gov' 'Lisa Crowell', IN%'stewart@pisces.colorado.edu' 'Ian A.F. Stewart', IN%'pryor@pisces.colorado.edu' 'Wayne Pryor', IN%'hendrix@pisces.colorado.edu' 'Amanda Hendrix' Subj: RE: UVS anomaly report Date: Thu, 16 Sep 1999 16:14:47 -0700 From: 'W. Kent Tobiska' Subject: RE: UVS anomaly report In-reply-to: To: Jim Erickson Cc: kent.tobiska@jpl.nasa.gov, Lisa Crowell , 'Ian A.F. Stewart' , Wayne Pryor , Amanda Hendrix , Karen Simmons: ; In a report on data from the Callisto 22 cruise period, the Ultraviolet Spectrometer (UVS) team reported that their instrument was behaving anomalously. It appeared that at least one command was not executed by the instrument during cruise. A preliminary recovery command set was sent to the instrument late on 9/14. These commands served the purpose of turning the instrument off, turning it back on, reloading it's flight software, and then allowing the microprocessor to resume instrument control. Data following the commands confirm the instrument's microprocessor was successfully restarted for the Callisto 23 encounter and that, during the encounter, the grating moved. There is still a question as to whether the grating is moving as commanded. Further analysis of the Callisto 23 science data is continuing. However, high noise levels are making science data analysis difficult. W. Kent Tobiska -------------------------------------------------------------------------------- file: c23_press.txt;1 17-sep-1999 From:IN%'kent.tobiska@jpl.nasa.gov' 'W. Kent Tobiska' 17-SEP-1999 19:32:14.52 To: IN%'stewart@pisces.colorado.edu' 'Ian A.F. Stewart', IN%'pryor@pisces.colorado.edu' 'Wayne Pryor', IN%'hendrix@pisces.colorado.edu' 'Amanda Hendrix' CC: Subj: new status report - FYI - press release Date: Fri, 17 Sep 1999 12:34:55 -0700 From: 'W. Kent Tobiska' Subject: new status report - FYI - press release To: 'Ian A.F. Stewart' , Karen Simmons: ;, Wayne Pryor , Amanda Hendrix >Date: Fri, 17 Sep 1999 11:16:30 -0700 >To: gem_project@donatello.jpl.nasa.gov >From: Jim Erickson >Subject: new status report > >For your information. > >-Jim E- > > >>Date: Fri, 17 Sep 1999 10:58:21 -0700 >>To: james.erickson@jpl.nasa.gov, >> Robert.W.Sible-Jr@jpl.nasa.gov, >> Torrence.V.Johnson@jpl.nasa.gov, >> Leslie.L.Lowes@jpl.nasa.gov, >> jayne.dutra@jpl.nasa.gov, >> clawshe@sdsio.jpl.nasa.gov >>From: Jane Platt >>Subject: new status report >> >>This is going out this morning. Jayne and Cecelia, feel free to post it on >>the Galileo home page anytime. >>Jane >> >>MEDIA RELATIONS OFFICE >>JET PROPULSION LABORATORY >>CALIFORNIA INSTITUTE OF TECHNOLOGY >>NATIONAL AERONAUTICS AND SPACE ADMINISTRATION >>PASADENA, CALIF. 91109. TELEPHONE (818) 354-5011 >>http://www.jpl.nasa.gov >> >>GALILEO EUROPA MISSION STATUS >>September 17, 1999 >> >> Onward to Io! That's the rallying cry now that NASA's Galileo >>spacecraft >>has successfully completed its fourth and final flyby of Jupiter's >>pockmarked moon, Callisto. The Callisto encounters were designed to lower >>Galileo's orbit to bring it closer to the fiery moon Io, the most volcanic >>body in the solar system. Galileo will fly by Io in October and then again >>in November. >> >>The spacecraft dipped down to 1,052 kilometers (654 miles) above Callisto's >>surface Thursday, September 16 at 11:02 a.m. Pacific Daylight Time. The >>spacecraft is operating normally, has completed all planned recording, and >>is now playing back science information gathered during the flyby by the >>instruments that study magnetic fields and particles. That information was >>stored on Galileo's onboard tape recorder. >> >> In an expected repeat of an occurrence from previous orbits, a minor >>glitch popped up at 3:39 p.m. PDT on Wednesday, with a computer reset of >>the non-spinning portion of the spacecraft. Onboard software handled the >>problem correctly, and recording of data continued without interruption. >> >> Currently, Galileo engineers are trying to determine why the >>spacecraft's >>ultraviolet spectrometer instrument began malfunctioning during the >>previous flyby of Callisto in August. They sent a preliminary set of >>commands to the instrument designed to re-start its microprocessor, which >>apparently had stopped working. Preliminary results seem to confirm that >>the microprocessor was restarted successfully for this week's encounter. >>Engineers will conduct further analysis of the data gathered during this >>flyby to help assure that the ultraviolet instrument is operating normally. >> The instrument studies Jupiter's atmosphere and aurora, the surfaces and >>atmospheres of its moons, and the doughnut-shaped cloud of charged plasma >>particles in the orbit of the volcanic moon Io. >> >> Galileo has been orbiting Jupiter and its moons since December >>1995. The >>spacecraft is approaching the grand finale of its two-year extended Galileo >>Europa Mission, a follow-on to the primary mission that ended in December >>1997. JPL, a division of the California Institute of Technology, Pasadena, >>CA, manages the Galileo mission for NASA's Office of Space Science, >>Washington, D.C. >> >> ##### >>9/17/99 JP >> >> > > >* * * * * * * * * * * * * * * * >James K. Erickson >Galileo Project Manager >Jet Propulsion Laboratory >James.K.Erickson@jpl.nasa.gov > ************************** W. Kent Tobiska -------------------------------------------------------------------------------- file: c23a_poweroff.txt;1 21-Sep-1999 From: "W. Kent Tobiska" Subject: UVS off To: "Ian A.F. Stewart" , Karen Simmons: ;, Wayne Pryor , Amanda Hendrix , Jim Adams , Pat Schriver , Joe Ajello Cc: kent.tobiska@jpl.nasa.gov, Lisa Crowell Subj: UVS off Date: Tue, 14 Sep 1999 20:00:01 -0700 Hi, I just got a confirmation from the ACE at 7:30 pm JPL time that the UVS off commands in the IAP were successfully received by the spacecraft. He was within 2 minutes of sending the UVS on IAPs when I talked to him. Confirmation of those ON commands should be around 11 pm tonite JPL time. By early morning, we should have back on the ground the UVFLUSH associated with the instrument ON commands. Karen and Pat will be looking at it and will give Lisa a call when they find out the status of the instrument. I am off-Lab tomorrow in a meeting (in Long Beach) but will check by phone regularly with Lisa - she will be the point of contact tomorrow. Jim Erickson is also interested in the results and she will pass those on to him. The spacecraft also experience a possible bus reset around 7 pm JPL time tonite at about 8 Rj. However, the bus reset patch has worked successfully the last two orbits and is expected to work this time as well. I will keep you updated. Kent -------------------------------------------------------------------------------- file: c23b_testing.txt;1 24-Sep-1999 From:IN%'rlineawe@mail1.jpl.nasa.gov' 'Robert C Lineaweaver' 24-SEP-1999 14:09:01.99 To: IN%'gem_project@donatello.jpl.nasa.gov', IN%'shriver@pisces.colorado.edu', IN%'simmons@pisces.colorado.edu', IN%'greg-pickett@uiowa.edu', IN%'kent-ackerson@uiowa.edu', IN%'sartain@IowaSP.Physics.UIowa.EDU', IN%'wsk@space.physics.uiowa.edu' CC: Subj: MCT DAILY SUMMARY: 23-24 September, 1999 Date: Fri, 24 Sep 1999 07:09:02 -0700 From: Robert C Lineaweaver Subject: MCT DAILY SUMMARY: 23-24 September, 1999 To: gem_project@donatello.jpl.nasa.gov, shriver@pisces.colorado.edu, simmons@pisces.colorado.edu, greg-pickett@uiowa.edu, kent-ackerson@uiowa.edu, sartain@IowaSP.Physics.UIowa.EDU, wsk@space.physics.uiowa.edu MCT DAILY SUMMARY Start: 9-23-99 6:00 A.M. DOY 266/1300 End: 9-24-99 6:00 A.M. DOY 267/1300 (*Note* All times in UTC unless otherwise specified) S/C SEQUENCED ACTIVITY STATUS DMS Playback Continues Per SOE R/T COMMANDING STATUS 99S253 'UVS Cold Start / Grating test part 1A' Radiated & Verified 99S254 'UVS Cold Start / Grating test part 1B' Postponed, see DR #G05324 99S255 'UVS Cold Start / Grating test part 2A' Postponed, see DR #G05324 99S256 'UVS Cold Start / Grating test part 2B' Postponed, see DR #G05324 R/T TRANSFER FRAMES CONFIRMATION=09 DSS 14, Pass #3637: No DSN support scheduled. DSS 43, Pass #3637: Missed 2 frames, recoverable from PPT, see Misc. DSS 63, Pass #3637: All expected frames received in real time. DSS 14, Pass #3638: Missed 57 frames. See DR #G05324. Pass still in progress. POST PASS TRANSMISSION (DOES NOT CONFIRM RECEIPT OF MISSING R/T TRANSFER FRAMES) DSS 43, Pass #3637: Received and verified. DSS 63, Pass #3637: Received and verified. DRS/ISAS/ARS 1) DR #G05322, DSS 14 (pass #3638): The HP TXR Drive on was 10 minutes late due to a Complex Power Grid Configuration Problem. 2) DR #G05324, DSS 14 (pass #3638): Sub-Reflector Controller (SRC) problems from BOT (05:05)-11:09utc. We missed 56 transfer frames, #29379-#29434 (05:13-08:21), plus 1 additional frame, #29453 (09:26), at the early mode change from 2-way to 1-way. Commands 99S254, 99S255, and 99S256 were postponed due to the inability to verify S/C acceptance of commands in telemetry. 3) AR #103720, DSOT: During the DSS 14 pass #3638, Data Control experienced a TIS Core Dump Segmentation Fault. Consequently, the DSS 14 data was not run to the TDS. This data is in house, and can be replayed to the TDS post pass. MISCELLANEOUS DSS 43, Pass #3637: Missed frames #29108-#29109(17:13-17:17) at the BRC from 160 bps to 120 bps, recoverable from FCD2, PPT. DMS Tape Position At Last Update (ERT=3D267/12:27:56)=20 Forward, Track 1, TINC=3D3236 Playback Table Slot=3D1, Segment=3D2 CMDLOSS Timer=3D12478 PLS TEMPS (as of 267/12:27:42 ERT) CHANNEL EU DN E-1750 5.5 157 E-1751 23.8 182 E-1752 8.8 164 E-1753 5.1 157 UVS TEMP (as of 267/11:09:02 ERT) CHANNEL EU DN E-1790 5.3 157 ------------------------------ Bob Lineaweaver Galileo ACE du Jour (818) 393-5806 [3-5806] -------------------------------------------------------------------------------- file: c23_backupgrat.txt;1 1-Oct-1999 From: IN%'lcrowell@mail1.jpl.nasa.gov' 'lisa.c.crowell@jpl.nasa.gov' 1-OCT-1999 22:11:56.52 To: IN%'kent.tobiska@jpl.nasa.gov', IN%'simmons@pisces.colorado.edu', IN%'stewart@pisces.colorado.edu', IN%'pryor@pisces.colorado.edu', IN%'hendrix@pisces.colorado.edu' CC: Subj: UVS IAPs for testing backup grating Date: Fri, 01 Oct 1999 13:50:16 -0700 From: 'lisa.c.crowell@jpl.nasa.gov' Subject: UVS IAPs for testing backup grating To: kent.tobiska@jpl.nasa.gov, simmons@pisces.colorado.edu, stewart@pisces.colorado.edu, pryor@pisces.colorado.edu, hendrix@pisces.colorado.edu Hi All, Here are the radiation times for the 4 sets of IAPs part 1a 99-277/20:25:00 part 1b 99-277/23:25:00 part 2a 99-278/02:55:00 part 2b 99-278/07:00:00 One question that came up today was what ripple effects this might have. For example are there any 'canned' (library type sequences) that would have to be changed if we wanted to permanently use the back up grating. That is to say what standard activities do we have that turn the power off, so when we power on and re-load we would need to change the toggle parameter to 'CHANGE for the first 34UVS following the reload. The only thing I can think of is the state change table (what we use in the event of an anomaly). I am not sure what some of the library sequences do. Any insight would be helpful. Thanks. Enjoy your weekend, Lisa -------------------------------------------------------------------------------- file: uvs_oct1999_grat.txt;1 25-oct-2000 From: IN%'STEWART@pisces.colorado.edu' 19-OCT-1999 19:24:50.42 To: IN%'stewart@lasp.colorado.edu', IN%'barth@lasp.colorado.edu', IN%'hord@lasp.colorado.edu', IN%'mcclintock@lasp.colorado.edu', IN%'pryor@lasp.colorado.edu', IN%'hendrix@lasp.colorado.edu', IN%'simmons@lasp.colorado.edu', IN%'white@lasp.colorado.edu', IN CC: Subj: UVS meeting/telecon Date: Tue, 19 Oct 1999 19:23:43 +0000 (GMT) From: STEWART@pisces.colorado.edu Subject: UVS meeting/telecon To: stewart@lasp.colorado.edu, barth@lasp.colorado.edu, hord@lasp.colorado.edu, mcclintock@lasp.colorado.edu, pryor@lasp.colorado.edu, hendrix@lasp.colorado.edu, simmons@lasp.colorado.edu, white@lasp.colorado.edu, adams@lasp.colorado.edu, jajello@mail1.jpl.nasa.gov, ktobiska@mail1.jpl.nasa.gov, lcrowell@mail1.jpl.nasa.gov To : GLL UVS team From : Ian Stewart Date : 19 Oct 99 Re : UVS meeting/telecon We need to assess our present position, and discuss the following items: 1) The present UVS failure mode: - what is the grating drive system doing - can all the problems be attributed to the grating drive, or are there microprocessor problems as well 2) Diagnostics - what tests can we run with the spare or flight units to provide further diagnostic information - do any of these tests require reprogramming the microprocessor 3) Remedial action: - can the grating drive and/or microprocessor problems be circumvented by re-programming the microprocessor (Note that the synchronized cold-start mode, or something similar, would be scientifically very productive.) Here are possible times today & Thursday (Neil W. is unavailable Wednesday): Tuesday : 3:00 pm Thursday : 11:00 am 2:00 pm Please let me know asap which of these times works for you. At a minimum I would like to have Neil, Jim W, Wayne P, Amanda H, and Kent T involved (Karen S won't be in until next week). -------------------------------------------------------------------------------- file: I24_new_sw_v7p0.load;1 3-Nov-1999 From:IN%'kent.tobiska@jpl.nasa.gov' 'W. Kent Tobiska' 3-NOV-1999 22:23:27.93 To: IN%'stewart@pisces.colorado.edu' 'Ian A.F. Stewart' CC: IN%'kent.tobiska@jpl.nasa.gov' Subj: FSW 7.0 test sequence Date: Wed, 03 Nov 1999 14:27:00 -0800 From: 'W. Kent Tobiska' Subject: FSW 7.0 test sequence To: 'Ian A.F. Stewart' , Karen Simmons: ; Cc: kent.tobiska@jpl.nasa.gov $$GLL 24BUVSFSW7TS *24BUVSFSW7TSGLL*KENT.24BUVSFSW7TS/PA2 *LEVEL PA2 *PREP UVS-AWG/K. TOBISKA 3-7742 *RUNID WKT *PROGRAM SEQGEN 98-303/16:29:32.000 *CREATION 99-231/09:27:26.647 *BEGIN 99-312/00:00:00.000 *EPOCH UVS,99-312/11:00:00.000 *CUTOFF 99-313/00:00:00.000 *TITLE I24B UVS FSW 7.0 TEST (11/03/99) *SCLK PSDT*SCLK.SCLK/I24-1 *LITIME GDMT*CLK-LTF.LITETIMEFILE $$EOH PA2,COMMENT,384AA,PRI,UVS+CDS 00:00:0,RSST,UVS-SWG/TEST SEQUENCE, 24BUVSFSW7TS,UVS FSW V7.0 TEST,UVS FSW V7.0 TEST,UVS+CDS 455:00:0; PA2,UTILITY,20ZA,BOTH,UVS+CDS 00:00:0,+CDS 115:00:0,+00:04:02.666,RSST, UVS-SWG/TEST SEQUENCE,24BUVSFSW7TS,UVS FSW V7.0 TEST; PA2,UVFLUSH,349CA,BOTH,UVS+CDS 000:69:0,CDS 2:00:0,+00:01:07.066,RSST, UVS-SWG/K. TOBISKA 3-7742,24BUVSFSW7TS,START UVS INTEGRATION,DISCRD,UVS; PA2,CMDRS,157MA,PRI,UVS+CDS 01:00:0,+CDS 241:00:0,,RSST, UVS-MWG/TOBISKA/CROWELL,24BUVSFSW7TS,UVS_FSW07_TST,0,0,4,(157MA156A); SUBPA2,RSINTL_LST,157MA156A,PRI,UVS+CDS 01:00:0,(),(),(),(),(),(),(),(),(), (),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(), (),(),(157MA156A123A),(157MA156A123B),(157MA156A123C),(157MA156A123D); SUBGEB,UVS_SUBSYS,157MA156A123A,PRI,UVS+CDS 01:00:0,1,UVS,(157MA156A123A4A); SUBCMD,34UVS,157MA156A123A4A,PRI,UVS+CDS 01:00:0,07,SCAN,NORM,NORM,NORM, SAME,0,ON,OFF,ON,ON,OFF,NOOVR,1,00,9C,01,2C; SUBGEB,UVS_SUBSYS,157MA156A123B,PRI,UVS+CDS 01:00:0,120,UVG, (157MA156A123B4A); SUBCMD,34UVS,157MA156A123B4A,PRI,UVS+CDS 01:00:0,07,SCAN,NORM,NORM,NORM, SAME,0,OFF,OFF,ON,ON,OFF,NOOVR,1,00,00,00,00; SUBGEB,UVS_SUBSYS,157MA156A123C,PRI,UVS+CDS 01:00:0,180,UVG, (157MA156A123C4A); SUBCMD,34UVS,157MA156A123C4A,PRI,UVS+CDS 01:00:0,07,SCAN,NORM,NORM,NORM, CHANGE,0,OFF,OFF,ON,ON,OFF,NOOVR,1,00,00,00,00; SUBGEB,UVS_SUBSYS,157MA156A123D,PRI,UVS+CDS 01:00:0,240,UVF, (157MA156A123D4A); SUBCMD,34UVS,157MA156A123D4A,PRI,UVS+CDS 01:00:0,07,SCAN,NORM,NORM,NORM, SAME,0,ON,OFF,OFF,OFF,OFF,NOOVR,1,00,00,00,00; CMD,34CS,20ZA5A,PRI,UVS+CDS 001:00:0; PA2,UVFLUSH,349CB,BOTH,UVS+CDS 003:69:0,CDS 2:00:0,+00:01:07.066,RSST, UVS-SWG/K. TOBISKA 3-7742,24BUVSFSW7TS,PACKET 1 CS mP SYNC,PACKET,UVS; PA2,COMMENT,384AB,PRI,UVS+CDS 004:00:0,RSST,UVS-SWG/TEST SEQUENCE, 24BUVSFSW7TS,UVS FSW V7.0 TEST,MRO #1 UVS MEMORY,UVS+CDS 106:00:0; CMD,6MROH,20ZA6A,BOTH,UVS+CDS 004:00:0,34,0000,15,A2; CMD,34AR,20ZA3A,PRI,UVS+CDS 112:00:0,1; CMD,34AR,20ZA3B,SEC,UVS+CDS 112:12:0,2; CMD,34HS,20ZA3C,PRI,UVS+CDS 114:00:0,1; CMD,34HS,20ZA3D,SEC,UVS+CDS 114:12:0,2; PA2,UTILITY,20ZB,BOTH,UVS+CDS 116:00:0,+CDS 03:00:0,+00:04:02.666,RSST, UVS-SWG/TEST SEQUENCE,24BUVSFSW7TS,UVS FSW V7.0 TEST; CMD,34A,20ZB3A,PRI,UVS+CDS 116:04:0,1; CMD,34A,20ZB3B,SEC,UVS+CDS 116:16:0,2; CMD,34DML,20ZB4A,PRI,UVS+CDS 118:00:0,0000,71,20,F8,09,A6,F8,00,B6,D6,B1,BC,BB,F8,6D, A1,F8,01,B2,F8,FF,A2,F8,70,73,92,FB,01,3A,22,82,FB,17; CMD,34DML,20ZB4B,PRI,UVS+CDS 118:03:0,0020,32,27,F8,00,73,30,18,B7,F8,EF,A2,F8,E0,A7, F8,E7,A9,F8,F6,AD,F8,F0,AE,F8,F9,AF,F8,01,B2,B9,BD,BE; CMD,34DML,20ZB4C,PRI,UVS+CDS 118:06:0,0040,BF,E6,70,66,3C,44,E9,F8,01,B8,F8,F4,A8,48, 73,48,73,48,73,48,73,89,FB,17,3A,65,99,FB,01,3A,65,F8; CMD,34DML,20ZB4D,PRI,UVS+CDS 118:09:0,0060,01,B9,F8,E7,A9,34,65,30,41,E2,12,42,70,22, 78,22,73,36,74,D7,35,7F,9C,32,7F,9A,52,67,22,7B,7A,3F; CMD,34DML,20ZB4E,PRI,UVS+CDS 118:12:0,0080,83,30,69,0D,FB,5A,32,A0,9C,32,69,9A,FB,04, BA,EE,1E,8C,F3,32,9D,F9,1F,5E,8C,F2,5E,64,2E,2E,30,69; CMD,34DML,20ZB4F,PRI,UVS+CDS 118:15:0,00A0,F8,04,BA,0F,32,81,EF,63,2F,9B,C6,66,2F,0F, FA,08,32,B7,65,2F,F8,00,C8,F8,FF,BB,0F,FA,F7,BC,5F,FA; CMD,34DML,20ZB4G,PRI,UVS+CDS 118:18:0,00C0,F4,5E,EE,63,1F,0F,AC,FE,3B,CF,8C,FA,9F,30, D7,FE,3B,D6,8C,FA,5F,38,8C,5E,64,2E,2E,2F,30,81,E2,D1; CMD,34DML,20ZB4H,PRI,UVS+CDS 118:21:0,00E0,4D,FB,5A,3A,F3,0D,FB,09,3A,F3,0E,F9,08,52, 63,EE,63,22,2E,0D,FC,01,5D,FB,0A,CA,01,14,5D,2D,0D,FC; CMD,34DML,20ZB4I,PRI,UVS+CDS 118:24:0,0100,01,5D,FB,5B,CA,00,DE,ED,73,F8,01,F4,73,F8, 00,74,5D,1D,1D,38,2D,C0,00,DE,00,00,00,00,00,00,00,00; CMD,34ST,20ZB5A,PRI,UVS+CDS 118:70:0; PA2,UTILITY,20ZC,BOTH,UVS+CDS 119:00:0,+CDS 125:00:0,+00:04:02.666,RSST, UVS-SWG/TEST SEQUENCE,24BUVSFSW7TS,UVS FSW V7.0 TEST; CMD,6MCOPY,20ZC6A,BOTH,UVS+CDS 119:15:0,B1A1A,5018,UVS,0118,01FF; PA2,UVFLUSH,349CC,BOTH,UVS+CDS 119:69:0,CDS 2:00:0,+00:01:07.066,RSST, UVS-SWG/K. TOBISKA 3-7742,24BUVSFSW7TS,START UVS INTEGRATION,DISCRD,UVS; CMD,6MCOPY,20ZC6B,BOTH,UVS+CDS 121:15:0,B1A1A,5118,UVS,0118,01FF; PA2,UVFLUSH,349CD,BOTH,UVS+CDS 149:69:0,CDS 2:00:0,+00:01:07.066,RSST, UVS-SWG/K. TOBISKA 3-7742,24BUVSFSW7TS,PACKET 2,PACKET,UVS; PA2,UVFLUSH,349CE,BOTH,UVS+CDS 179:69:0,CDS 2:00:0,+00:01:07.066,RSST, UVS-SWG/K. TOBISKA 3-7742,24BUVSFSW7TS,PACKET 3,PACKET,UVS; CMD,6MCOPY,20ZC6C,BOTH,UVS+CDS 181:15:0,B1A1A,5218,UVS,0118,01FF; PA2,UVFLUSH,349CF,BOTH,UVS+CDS 209:69:0,CDS 2:00:0,+00:01:07.066,RSST, UVS-SWG/K. TOBISKA 3-7742,24BUVSFSW7TS,PACKET 4,PACKET,UVS; PA2,UVFLUSH,349CG,BOTH,UVS+CDS 239:69:0,CDS 2:00:0,+00:01:07.066,RSST, UVS-SWG/K. TOBISKA 3-7742,24BUVSFSW7TS,PACKET 5,PACKET,UVS; CMD,6MCOPY,20ZC6D,BOTH,UVS+CDS 241:15:0,B1A1A,5318,UVS,0118,01FF; PA2,UVFLUSH,349CG,BOTH,UVS+CDS 242:69:0,CDS 2:00:0,+00:01:07.066,RSST, UVS-SWG/K. TOBISKA 3-7742,24BUVSFSW7TS,PACKET 6,PACKET,UVS; PA2,COMMENT,384AC,PRI,UVS+CDS 244:00:0,RSST,UVS-SWG/TEST SEQUENCE, 24BUVSFSW7TS,UVS FSW V7.0 TEST,MRO #2 CDS MEMORY,UVS+CDS 211:00:0; PA2,UTILITY,20ZD,BOTH,UVS+CDS 244:00:0,+CDS 211:00:0,+00:04:02.666,RSST, UVS-SWG/TEST SEQUENCE,24BUVSFSW7TS,UVS FSW V7.0 TEST; CMD,6MROH,20ZD6A,BOTH,UVS+CDS 244:00:0,17,5000,31,B2; kent -------------------------------------------------------------------------------- file: uvs_nov99_dead.txt;1 16-Nov-1999 Date: Tue, 16 Nov 1999 00:53:43 +0000 (GMT) From: STEWART@pisces.colorado.edu Subject: UVS status To: jerickso@mail1.jpl.nasa.gov Cc: stewart@lasp.colorado.edu, barth@lasp.colorado.edu, hord@lasp.colorado.edu, mcclintock@lasp.colorado.edu, pryor@lasp.colorado.edu, hendrix@lasp.colorado.edu, simmons@lasp.colorado.edu, white@lasp.colorado.edu, adams@lasp.colorado.edu, jajello@mail1.jpl.nasa.gov, ktobiska@mail1.jpl.nasa.gov, lcrowell@mail1.jpl.nasa.gov To : Jim Erickson, GLL Project Manager cc : UVS team From : Ian Stewart, PI, UVS/EUV Date : 15Nov99 Re : UVS status The UVS 'one-byte' test, whose purpose was to inhibit step commands from the microprocessor to the grating control logic, was executed over the weekend, and we have examined the MROs today. The instrument behavior appears to be essentially unchanged from its behavior under the unmodified FSW 7.0. That is, autonomous grating flybacks continued to occur approximately once per RTI. The grating remains uncontrolled in the absence of step commands. As I indicated in my previous message, we have no further ideas about how control over grating behavior might be re-established. Three questions to be addressed in the light of this situation are: (1) what to do about I25; (2) what to do about the I25 safing recovery sequence; and (3) what to do in the longer term. 1) I25: The current I25 load calls for UVS to observe Europa before perijove, with the high voltage being turned of at about 7.7 Rj, and to observe Io after perijove, with the high voltage being turned on at about 9.4 Rj. We see no appreciable risk to UVS in carrying out these observations. We have no expectation that they will yield any science; if the Project for any reason would prefer the UVS be powered off during I25, we have no objection. n 2) I25 recovery. We will deliver UVS FSW 7.1 within a day or two. It will be the same as 7.0 except for the one-byte change that inhibits step commands from the microprocessor. The I25 recovery sequence should upload version 7.1 to UVS. 3) Post-I25: We do not wish to rule out the possibility that the UVS will recover some ability to control its grating, perhaps through an annealing of the presumed radiation damage to its grating control components. Therefore, we wish to test the instrument periodically. Current flight rules call for the UVS to be operated no less frequently that once per two weeks, and seems a suitable interval for regular testing. We will work up a new test sequence in the next few days. We feel that an annealing process will on the whole be aided by having the instrument powered off. This will therefore be the preferred UVS state between the biweekly tests. The tests will power the instrument on, exercise it using the default grating, do an MRO, exercise the backup grating, and do another MRO. Then the instrument will be allowed to warm up for 12 hours, after which these grating exercises will be repeated. Finally, the UVS will be powered off. I'll be happy to discuss any questions or suggestions you may have about the above, at any time convenient to you. I would like to thank you and your office, both for myself and on behalf of the UVS team, for the consistently helpful and supportive approach you have taken to UVS' problems. We can only wish that the damage had not been so disabling or that more remedies had been available to us. -------------------------------------------------------------------------------- file: uvs_nov99_off.txt_1 18-Nov-1999 From: VIRALF::STEWART 18-NOV-1999 17:20:34.97 To: @TMP.DIS CC: Subj: UVS during I25 To : Duane Bindschadler cc : Jim Erickson, Kent Tobiska, Karen Simmons, Ian Stewart From : Ian Stewart, PI, UVS Date : 18 Nov 99 Re : UVS during I25 The consensus is that UVS would be better off if it is powered off during I25. Therefore, please do this if it is still possible - thanks. -------------------------------------------------------------------------------- file: uvs_1199.log;1 23-Nov-1999 Date: Tue, 23 Nov 1999 09:43:38 -0700 From: 'W. Kent Tobiska' Subject: UVS powered off To: 'Ian A.F. Stewart' , Wayne Pryor , Amanda Hendrix Cc: kent.tobiska@jpl.nasa.gov Hi all, The UVS was powered off last night as requested. The command conference had minimal discussion about the UVS although there was general head nodding by the project management when I indicated that we would like to take a peek at the instrument during I25 cruise before apjove to see if annealing has any effect. -Kent MCT DAILY SUMMARY Start: 11-22-99 6:00 A.M. DOY 326/1400 End: 11-23-99 6:00 A.M. DOY 327/1400 (*Note* All times in UTC unless otherwise specified) R/T COMMANDING STATUS 99S353A 'UVS power off for I25' Radiated and verified. -------------------------------------------------------------------------------- file: uvs_99237_off.doc;1 3-Dec-1999 From: IN%'kent.tobiska@jpl.nasa.gov' 'W. Kent Tobiska' 2-DEC-1999 23:59:34.11 To: IN%'simmons@lasp.colorado.edu' CC: IN%'kent.tobiska@jpl.nasa.gov' Subj: RE: for the record Date: Thu, 02 Dec 1999 16:01:18 -0800 From: 'W. Kent Tobiska' Subject: RE: for the record To: simmons@lasp.colorado.edu Cc: kent.tobiska@jpl.nasa.gov >>Date: Wed, 24 Nov 1999 07:41:10 -0800 >>To: 'W. Kent Tobiska' >>From: 'James McClure Jr.' >>Subject: >> >>Kent, >> >>The UVS power off for I25 IAP was radiated at 327/03:12:13 TRM >>Beginning S/C execution time: >> SCET = 327/03:46:34 >> SCLK = 05269124:71 >> >>At 12:39 PM 11/23/99 -0800, you wrote: >>>Hi Jim, >>> >>>Do you have the power off transmit time and confirm times for Karen (see >>>below)? The file was >>>99S353A 'UVS power off for I25' Radiated and verified. >>> >>>Thanks, >>> >>>Kent >>> >>>>Status: U >>>>Resent-Date: Tue, 23 Nov 1999 12:32:08 -0800 >>>>Resent-From: KTOBISKA@gllsvc.jpl.nasa.gov >>>>Resent-To: ktobiska@mail1.jpl.nasa.gov >>>>Date: Tue, 23 Nov 1999 20:30:01 -0500 >>>>From: simmons@pup.colorado.edu (KAREN SIMMONS AT LASP/COLORADO) >>>>To: KTOBISKA@GLLSVC.JPL.NASA.GOV >>>>Subject: for the record >>>> >>>>Hi kent, >>>> Could you get me a Power Off transmitt/confirm time for the UVS? >>>> >>>>Thanks, Karen W. Kent Tobiska -------------------------------------------------------------------------------- file: uvs_E26_test.txt;2 25-Jan-2000 Date: Tue, 25 Jan 2000 14:26:03 -0800 From: 'W. Kent Tobiska' Subject: I27A UVS observations X-Sender: ktobiska@pop.jpl.nasa.gov To: Jerod.L.Gross@jpl.nasa.gov Cc: kent.tobiska@jpl.nasa.gov, 'Ian A.F. Stewart' , Wayne Pryor , Amanda Hendrix Karen Simmons: ; Hi Jerod, The UVS team will remove from the sequence 3 UVS observations (27IUATMOS_01, 27IUECLIP01, 27TUNANSA_01) and all the pointer commands associated with them. While there is probably not a BTG nor CDS byte issue, we felt it would be cleaner to take the observations out since, after the anneal test, we see no fundamental change in the anomalous operation of UVS and, hence, will not observe in I27A. Thanks, Kent -------------------------------------------------------------------------------- file: uvs_e26_test.log;1 28-Jan-2000 Date: Fri, 28 Jan 2000 10:06:09 -0800 From: 'W. Kent Tobiska' Subject: Status of UVS (anneal test) To: James.K.Erickson@jpl.nasa.gov Cc: kent.tobiska@jpl.nasa.gov, 'Ian A.F. Stewart' , Wayne Pryor , Amanda Hendrix , simmons@lasp.colorado.edu INTERIM ANNEAL TEST SUMMARY TEST STATUS: The UVS anneal test of Monday January 24 showed no significant change in the operation of the grating drive. Data from flushes and from an MRO both demonstrated that the grating is positioned near or at its fiducial and that there is slight movement of the grating every 1-2 RTI. Occassionally, the grating pauses, then resumes, its 'quivering' motion. The detectors F and G are still operating properly and counts are accumulated. The microprocessor is still working properly also with the exception of being unable to command the grating. Please see the detailed test results below. REVIEW OF HYPOTHESIS FOR FAILURE: The working hypothesis for the reason behind this anomaly remains the same, i.e., that long-term radiation damage appears to have affected the sensitivity of the electronic/optical paths for the grating encoder mechanism. An anneal process that removes power from the grating encoder electronics, which we had hoped would mend potentially disturbed electrical paths in this hypothesis, has still not occurred. An overview of the grating encoder failure is still being developed by the team. FUTURE PLANS: The UVS is powered off going into I27 and has been verified to be in that state from the anneal test last flush, power profile, temperature profile, and command counter on the spacecraft. All UVS commands have been removed from the I27 encounter sequence, along with associated targets and flushes. The team has no plans to command the instrument on prior to or during that encounter. As an option, UVS grating exercise commands and an anneal test have been included in the I27 cruise sequence. The grating exercise commands will not be acted upon since the instrument is powered off. However, we plan to power on, via sequence, and off the instrument during a similar but longer lasting anneal test. The main difference with the I27 test compared to E26 is that we are allowing a longer period of time for the instrument to warm up since earlier operation suggested that the instrument performed better with warmer temperatures. There is also some word-of-mouth information that annealing processes like warmer or even hotter temperatures. The UVS team is reviewing instrument plans for G28 and G29 but has not yet decided on a plan of action. DETAILED ANNEAL TEST RESULTS: RIM SCE Time Commands Activity/Status/Result 5357995:89 00-024/13:25:10 6TMSED,NORM,AL5; 5358090:06 00-024/15:00:18 MISC,,,UVS FSW V7.1 TEST 5358090:10 00-024/15:00:20 34A,1; Power On UVS Verified: Etemp 160 -> 171 'Default Grating' 5358092:06 00-024/15:02:19 34DML,0000,71,20,F8,09, start V7.1 memory load 5358092:76 00-024/15:03:06 34ST; start uP -> Cold Start 'F/G Full, HV-On' 5358093:21 00-024/15:03:30 6MCOPY,,5018,UVS,0118,01FF; UVS memory to CDS #1 full 6MCOPY (=256 bytes) 'Cold Start - Turn On/Cold' -> 0.8 RTI/flyback 5358094:75 00-024/15:05:06 6UVRT,DISCRD,UVS; clear CDS packet mem 5358094:87 00-024/15:05:14 34UVS,07,S,N,N,N,SAME,0,OFF,OFF,ON,ON... 'G/G, HV-On, Cold' 5358095:21 00-024/15:05:31 6MCOPY,,5118,UVS,0118,01FF; UVS memory to CDS #2 **have 198 bytes 'G/G HV-On, Cold' -> 0.8 RTI/flyback 5358213:75 00-024/17:05:26 6UVRT,PACKET,UVS; Send RTS Packet #1: **got last 1/8 packets 'G/G HV-On, Cold' no fiducials, nominal G cnts 5358213:87 00-024/17:05:34 34UVS,07,S,N,N,N,SAME,0,ON,OFF,ON,ON... 'F/G HV-On, +2Hr Cold' 5358214:21 00-024/17:05:50 6MCOPY,,5218,UVS,0118,01FF; UVS memory to CDS #3 **have 160 bytes 'F/G HV-On, +2Hr Cold' -> 1.1 RTI/flyback 5358273:75 00-024/18:06:06 6UVRT,PACKET,UVS; Send RTS Packet #2: nominal F/G cnts 'F/G HV-On, +3Hr Cold' Starting Wave = 0 5358273:87 00-024/18:06:14 34UVS,07,S,N,N,N,CHANGE,0,OFF,OFF,ON,ON... 'Backup Grat, G/G On, Cold' 5358333:75 00-024/19:06:46 6UVRT,PACKET,UVS; Send RTS Packet #3: nominal G/G cnts 'G/G HV-On, +4Hr Cold' Starting Wave = 0 5358333:87 00-024/19:06:54 34UVS,07,S,N,N,N,SAME,0,ON,OFF,OFF,OFF... 'Backup Grat, F/F HV-OFF, Cold' 5358335:75 00-024/19:08:47 6UVRT,PACKET,UVS; Send RTS Packet #4: verifies HV-Off 'Verify HV-Off, F/F' Starting Wave = 0 5358653:61 00-025/00:30:10 6MCOPY,,5318,UVS,0118,01FF; UVS memory to CDS #4 **have 70 bytes 'Backup Grat, F/F HV-OFF, Warmer' -> not suffient data 5358867:46 00-025/04:06:22 34AR,1; UVS Power Off 5358869:46 00-025/04:08:24 34HS,1; UVS Sup.Heater On ** indicates missing data; 9 frames of downlink permanently lost During the V7.0 test on 1999/312 the following MRO results were recorded: flush 1 = 0.8 RTI/flyback flush 2 = 1.2 ' ' flush 3 = 1.0 ' ' flush 4 = 1.0 ' ' Kent -------------------------------------------------------------------------------- file: uvs_mar2000.txt;1 6-Mar-2000 Date: Sat, 04 Mar 2000 19:53:34 +0000 (GMT) From: STEWART@pisces.colorado.edu Subject: It's official - UVS out of G28 encounter To: stewart@lasp.colorado.edu, barth@lasp.colorado.edu, hord@lasp.colorado.edu, mcclintock@lasp.colorado.edu, pryor@lasp.colorado.edu, hendrix@lasp.colorado.edu, simmons@lasp.colorado.edu, white@lasp.colorado.edu, adams@lasp.colorado.edu, jajello@mail1.jpl.nasa.gov, ktobiska@mail1.jpl.nasa.gov, lcrowell@mail1.jpl.nasa.gov HI TEAM - I had a call from Jim Erickson, & it is now official: UVS resources during future encounters (G28, G29, ...) will be distributed to other instruments. The cruise grating tests will continue. If UVS should recover at some point in thefuture, Jim will entertain any request we might make for encounter resources. - Ian -------------------------------------------------------------------------------- file: uvs_oct2400_test.txt;3 25-Oct-2000 Date: Tue, 24 Oct 2000 15:54:24 -0700 From: 'W. Kent Tobiska' Subject: Re: Latest Gll UVS test MROs To: KAREN SIMMONS AT LASP/COLORADO Hi Karen, I agree. I also gave a copy to Wayne at the DPS meeting and I think he generally concurs at the first look. -Kent on 10/24/00 3:14 PM, KAREN SIMMONS AT LASP/COLORADO at SIMMONS@pisces.colorado.edu wrote: > Kent, > I've got the MROs you faxed and have given them the 1/2 hour > once over. I'm passing a copy to Neil in a few minutes. It looks to me > like the instrument was a bit better in the first MRO but it is still not > finding its way to proper stepping. We'll talk tomorrow (Wed) morning. > > Karen ************************************************************************** Date: Tue, 24 Oct 2000 16:41:00 -0600 From: Neil White Subject: Re: Latest Gll UVS test MROs To: KAREN SIMMONS AT LASP/COLORADO Karen, My 1/2 (or less) look confirms your look. I see the grating drive flying back nearly every minor frame. This may be better than before (I cannot remember), but it is still way to often to get any useful science. Ta, ta, daaaa Ta, ta, DAAAA Ta, ta, da, Ta, ta, da, Ta, ta, daaaa Ta, ta, daaa, da, da, daaaa Ta, ta, Daaaaaaaaaa... Neil -------------------------------------------------------------------------------- file: uvs_failure.txt;1 21-Nov-2001 Date: Thu, 15 Nov 2001 23:02:42 +0000 (GMT) From: KAREN SIMMONS AT LASP/COLORADO Subject: Galileo grating photodiode To: fieseler@mail1.jpl.nasa.gov Cc: simmons@pisces.colorado.edu Date: Thu, 15 Nov 2001 16:01:00 -0700 From: Jim Westfall Subject: Re: can you identify the Galileo UVS photodiode as the culprit? To: KAREN SIMMONS AT LASP/COLORADO Karen - We can't be certain that the photodiode is the part that ultimately failed. In fact, if the design had more feedback, as we later implemented on UARS, the instrument might still be running. I think the simple answer is that we exceeded the radiation design limits for the mission and some parts wore out. I would expect that. Due to the tone in the note you copied to me, 'could prevent someone else from using it', I am presently unwilling to provide information about specific part numbers since it could be used for the wrong reasons. Any information I provide, in response to a request like this, will have to be accompanied by some pretty serious qualifiers. I would hate to jeopardize a companies reputation when their part met our expectations. It would be best if you had these folks get in touch with me directly. Jim KAREN SIMMONS AT LASP/COLORADO wrote: > Subject: photodiode > Date: Wed, 14 Nov 2001 14:51:49 -0800 > From: Paul Fieseler > To: SIMMONS@pisces.colorado.edu > > Hi Karen, > > Do you know how I can get the generic part number of the failed photodiode > in the UVS? I'd like to compare this to other failures and, in the unlikely > event that the photodiode is still manufactured, get this information to > the parts folks here at JPL. It could prevent someone else from using it. > Thanks. > > -Paul -------------------------------------------------------------------------------- file: final_uvs_letter.doc;6 28-Nov-2000 file: DISKH:[SIMMONS.GLL_ANOMALIES]FINAL_UVS_LETTER.DOC Nov 28, 2000 - kes The following documents the UVS tests completed in recent orbits to determine the health of the Galileo UVS instrument's grating drive. We first noticed inconsistent UVS data in the later GEM orbits. Particularly after the Jupiter flyby in orbit E19, we began to investigate improper instrument behavior. After the very close Jupiter encounter in C22, all UVS data was considered incorrect. We have performed a series of tests, both on the ground and on the spacecraft since the initial incidents. Our final conclusion is that the photo diode in the grating drive assembly has suffered degradation to a point that the electronics can no longer register the position of the grating assembly. The grating drive now oscillates around low grating step numbers where there are no line emissions. The failure of the photo diode is felt to be a result of the increased radiation exposure, especially experienced in the closer Jupiter flybys of the GEM orbits. The Backup Grating electronics, tested in orbit E24B, apparently suffered from the same radiation exposure. Tests were performed in the following orbit loads: C23A, I24B, E26A, I27B and G28D. A summary of the tests and their results follow. C23A A set of three separate tests were performed using UVS microprocessor software V6.2, the standard GEM software. Test 1: 99-267/03:00:00. A simple command test to verify that the UVS was receiving commands properly. Both engineering and science data indicated this to be valid. Test 2: 99-269/22:02:37. A comprehensive test of several diagnostic commanding options, there were eight real-time packets commanded (with the first being lost at the ground station). First, we tested Cold Start mode thinking the problem might be in the UVS microprocessor software. We also tested various grating position commands to see if the problem was localized in wavelength: at a Starting Wavelength (SW) at grating position 0 and at the standard 300 for G/G-channel. We also tested the standard F/G-channel operating in Cold Start mode. The engineering and science housekeeping indicated the instrument was responding properly to the commands but the grating drive was not operating as commanded. Test 3: The entire test 2 was repeated after a period of instrument warming (three days). The results were the same: incorrect grating operation. I24B Test 1: 99-312/10:17:41 A simple command test to verify that the UVS was receiving commands properly. Both engineering and science data indicated this to be valid. This verified the instrument had not changed since the last test; it was executed in software V6.2 . Test 2: 99-312/10:25:53 A new UVS software load was uplinked (V7.0) with significant changes, including no grating flyback activity (except on the first command), records the time when a 'scan start level' is seen, and always runs the grating in an up/down full scan mode starting at SW 0. The test included microprocessor mode as well as Cold Start mode with various detectors. The second half was a repeat of the first part after a 'change grating' command was issued. This test included commands to copy the UVS memory to CDS memory at four times during the test and then to transfer the MROs to the ground. The engineering, housekeeping, MROs and science data all indicated continued incorrect grating operation. E26A Test 1: 00-024/15:02:19 The I24B test having been our best guess to fix the grating, this test included a simple update to the UVS software (V7.1) to record every grating reset recognized by the microprocessor as a result of the grating electronics activity (interrupts) into a circular buffer in the microprocessor memory. The memory was then read to CDS during the four command periods. The commands tested cold and warm instrument temperature periods with the Default and Backup grating electronics using F/G, G/G and F/F-channel commands. Again, no correct grating operation was observed. I27B Test 1: 00-075/18:02:17 This test was an identical repeat of the test in E26A. The results were the same. G28D Test 1: 00-297/12:02:08 The team hoped that a period of power off would allow the optical diode to recover some output level - enough to allow the grating electronics to recognize the signal above the pre-set cutoff. The test was run after a long power-off period (222 days). Although there was a very slight reduction in the number of non-commanded flybacks, the results were basically the same - no correct grating operation. Ironically the photomultipliers are still alive and healthy, but we now consider the UVS instrument to be non-functional. It was an excellent scientific experiment and we thank all those who helped us make it so. -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- EUV Anomalies -------------------------------------------------------------------------------- file [euv_comet_anom.txt]-> [euv_051190.txt] Our preliminary analysis of the EUV surprise incidence of May 11, 1990 indicates two errors at Colorado contributed to the microprocessor halt: a) insufficient verification of the attempted software operation change and b) incorrect photon count simulation in the engineering model simulator. The EUV microprocessor software engineer has verified that given the photon count levels we were experiencing during the cruise period, the attempted software change involving the new Fixed Pattern Noise Table (FPNT) would not have worked (see Attachment 1.) Our attempt to use the FPNT was based on the hardware engineers recollection of the software operation and on simulator testing of the new FPNT. We have also learned that the encounter-level simulated counts used in the EPROM of the engineering model are probably too high for the equivalent cruise period and thus would not have trapped the software fault. We are preparing a Surprise Incidence analysis which includes information on the detection of the surprise, the procedures and data used to verify that no software or hardware damage has been done and discussion of the suspected causes. Preliminary Diagnosis of EUV Surprise Incidence of May 11, 1990 What Bruce said Clayne wants: Items to discuss: 1) How could we tell that something went wrong? What caused it? 2) What part of code was effected? 3) How are we proceeding safely? Signed by CWH and Faxed. Outline: HOW COULD WE TELL THAT SOMETHING WENT WRONG? 1) Low count levels 2) Engineering monitor values not updating, but not zero 3) Error diagnostic in MRO 4) RIM time in MRO WHAT CAUSED IT? 1) Still unknown 2) Considering: a) Timing problem - is there a criticality for when the FPN DMLs need to be acted on? b) Loading FPN before/after the EUV command? WHAT PART OF CODE WAS EFFECTED? 1a) Cruise data MROs also contain the EUV command config, the FPN, several housekeeping bytes and two 'scratch pad' bytes which would contain the diagnostic. 1) "No-interrupt" Infinite loop in Cruise portion which checks for address out of range; only portion of Cruise s/w that issues a diagnostic code into the 'scratch pad' 2) Engineering monitor value supports this "no-interrupt" 3) Full memory readout and ground "100% good" ground compare supports this HOW ARE WE PROCEEDING SAFELY? 1) Pre-launch software documentation describes the method of exiting from the "No-interrupt" loop as a micro STOP/START pair 2) Hundreds of tests of STOP/START pairs to interrupt uP operation have worked successfully, in pre-launch with flight hardware and in post-launch with engineering model 3) Cruise mode has worked successfully for four months with no problems. Loaded from Library sequence ??as did before?? The text: HOW COULD WE TELL THAT SOMETHING WENT WRONG? 1) Low count levels 2) Engineering monitor values not updating, but not zero 3) Error diagnostic in MRO 4) RIM time in MRO An EUV anomaly was recognized during the initial analysis of the Monday, May 14th memory readout. The count levels at all wavelengths was lower than expected. A quick check of the EUV engineering monitor readouts for the weekend indicated the multiplexed EUV monitor (E-?) had stopped changing (but had not stopped varying by a few DN) shortly after the real time commands to re-load the Fixed Pattern Noise Table (FPNT) had been accepted by the instrument. An examination of the "error diagnostic" byte (see attachment 1) in the memory readout indicated an "address out of range" error had been detected by the EUV uP software. It was recognized that this error had placed the uP into a self-protect state by forcing the software into a no-interrupt, infinite loop. (This keeps the soft from accidently overwritting itself.) The RIM time bytes in the same memory readout (attachment one also) indicated the uP had enter the self-protect state very close to the time that the FPNT would have begun loading. We have requested timing information from Gaylon McSmith to verify the time of the memory readout and of the FPNT load in order to acertain the exact event which caused the uP bad address fault. The multiplexed engineering value also acts as a verification of the uP no-interrupt, infinite loop condition. We have verified that in this condition the interrupt to update which engineering value is being readout is never entered so the same monitor value is constantly telemetered to the ground. The EUV multiplexed monitor reads out The memory RIM time at halt agrees with the multiplexed engineering value enter ------------------------------------------------------------------------------- Nov 03,93 - KES Just before the Earth 1 encounter, EUV was transitioning from Cruise mode to Encounter mode. A science MRO was done followed by a stop and start pair and a 24EUV command. After the 24EUV command the engineering was not updating so an ISA was written. Instead of doing a Power Off, a full memory dump was first obtained. A single byte was found to have multiple bits disturbed. The Project agreed to send a DML to correct this location. This was done and the EUV began to function properly. ------------------------------------------------------------------------------- From: ZODIAC::SIMMONS "Karen Simmons at LASP/Colorado" 9-NOV-1990 To: @gll_team,PISCES::WHITE 00:44:47.84 CC: Subj: 1st Galileo data at Earth To: Galileo UVS/EUV team From: Karen Simmons Date: Nov 8, 1990 5:00pm MST Subject: Status as we take the first UVS and EUV encounter data The first encounter format EUV data and the first UVS science observation began this morning at 9am PST. Both instruments are functioning as commanded and UVS science counts are as expected (we currently have no visibility of EUV counts.) The delivery of EDR files to Colorado has been delayed several hours due to JPL computer failures but is expected here by 5pm today. We have one anomaly: a new spacecraft command to readout the EUV memory before we switched to encounter mode appears to have malfunctioned and we have lost the last MRO before the encounter mode. We have reported the problem; Orbit Engineering Team is investigating. This MRO contained three weeks of buffered data. There will be no further impact on the encounter operations due to this MRO command. There may be an impact on the post-encounter loads, one of which has already been sequenced. We have not been able to get EUV data printed at JPL, some mix-up about remembering how they did it during the 4-day checkout period. We are waiting for file delivery to Colorado to confirm EUV data health. All UVS and EUV analog remains nominal. UVS is taking Anti-sun data all night and on Friday, does a UVS/EUV cross-calibration all weekend, and does another earth-moon system background map Monday. Attn: **** NOTE, MORE | Charles W. Hord | zodiac::barth below pisces::mcclint zodiac::gthomas zodiac::stewart jplal2::alane issac::rwest zodiac::pryor looney::sandel zodiac::espo lrsp::ajello lrsp::edberg lrsp::ltamppari zodiac::taylor zodiac::simmons G. McNutt via pisces::white pisces::white ========================================================================= From: PISCES::WHITE "Neil White, LASP, (303)-492-7959" 10-NOV-1990 To: ZODIAC::SIMMONS 04:15:42.01 CC: WHITE Subj: RE: euv memory compares KAREN, I have not yet had a chance to check the rest of memory tonight, and will probably do it on saturday. THe memory compares are interesting. I believe the first compare addresses 44A and 44B are TM noise since they do not show up in the 2nd compare. The address in the second at 367F blows my mind, in that our 24DML (which they compare the readouts to) only goes from 0000 to 043F. Trying to assume a typo doesn't make sense, since the address should be greater than 3B1 which miscompares ahead of it. I will probably look for a 38 after address 3B1 that should be a 3B tomorrow. Anyway, this again should not be a problem, in that it didn't show up in compare #1, thus I think it's noise anyway. The only location common to both compares is the one at 3B1 which is the know problem. I checked all 3 fax copies immediately, and it was there on all of them. I had a thought (last one of the day I'm sure) tonight, and honestly don't have a lot of hope of making it fit, but I wondered about the failed attempt to readout the cruise data earlier in the day. Could the attemp have corrupted address 3B1 in some way. The EUV bus adaptor is designed to accept EITHER HIC or EUV ID's when the bus asks the instrument to be the source, and should listen only to the EUV ID when it is commanded. Maybe when they tried to readout via a 24MROH instead of the tried and tested 28MROH, the bus circuitry caused a problem. I cannot recall ever testing an equivelent 24MROH on the GSE, so maybe some side effects are possible??? As mentioned earlier, I doubt seriousely if this could be the case, but I will look into it none the less. Anyway, I'll probably touch base again tomorrow. Later I'm sure.... Neil ========================================================================== From: ZODIAC::SIMMONS "Karen Simmons at LASP/Colorado" 10-NOV-1990 To: PISCES::WHITE,PISCES::ONEIL,PRYOR,SIMMONS 21:32:17.61 CC: Subj: increminating evidence Re: Evidence from our RIM Packets that the SP/ST commands or the 24EUV command caused the problem. I dumped the RIM packets from the two files containing the two hours of LRS data from Tuesday and the data containing the SP/ST/24EUV command. (I will mail them in the next messages.) They indicate the micro was working before the SP/ST command. Here is what I see: a) The SIB and WIB addresses update in both cases. b) The contents of the SIB is non-zero before the SP/ST c) The SIB values just before the SP/ST are larger than their corresponding values from two days before. I conclude from this that the micro was still counting just before the SP/ST command. Now, which one (or more) of these commands "did it"? Karen ========================================================================== From: ZODIAC::SIMMONS "Karen Simmons at LASP/Colorado" 12-NOV-1990 To: @GLLSEQ 16:26:47.35 CC: BARTH,STEWART,PRYOR Subj: Nice Anti-sun data from the weekend We have some nice anti-sun data from the weekend. Will Fax you some plots in a minute. Joe, Wayne reports no Oxygen in Bkg map from Thursday. Our "grown up" child is doing nicely! The adolescent yielded some cruise data from Tuesday and Thursday pre- mode change which points at the SP/ST pair. Nail has just simulated the encounter mode command and it is running perfectly. He will try the Cruise to Encounter change next. Will keep you posted. Karen ========================================================================== From: PISCES::WHITE "Neil White, LASP, (303)-492-7959" 13-NOV-1990 To: ZODIAC::SIMMONS 16:17:27.68 CC: WHITE Subj: RE: EUV DML Karen, Here is a second, more thought out version of the DML I think should be sent. Please compare this to what I gave you yesterday, and they should be the same. 24DML,03B1,C3 Neil ========================================================================== From: ZODIAC::SIMMONS "Karen Simmons at LASP/Colorado" 13-NOV-1990 To: ALTAIR::BARTH,STEWART,PRYOR,LOONEY::SANDEL, 20:43:09.31 PISCES::MCCLINT,PISCES::WHITE CC: @GLLSEQ,IOWASP::WAGGONER Subj: EUV Real-time command To: Galileo UVS/EUV team From: Karen Simmons Date: Nov 13, 1990 Subject: EUV command to be send this afternoon The project has agreed to send the 24DML,03B1,C3. command this afternoon at 3:30 PST to reset the affected byte. Three full memory readout commands will follow it to verify memory. Attn: Charles W. Hord zodiac::barth pisces::mcclint zodiac::stewart zodiac::pryor looney::sandel zodiac::espo lrsp::ajello zodiac::taylor zodiac::simmons pisces::white ========================================================================== From: ZODIAC::SIMMONS "Karen Simmons at LASP/Colorado" 14-NOV-1990 To: ALTAIR::BARTH,STEWART,PRYOR,PISCES::MCCLINT,LOONEY::SANDEL CC: @GLLSEQ,IOWASP::WAGGONER,PISCES::WHITE 00:27:32.25 Subj: We got PHOTONS! EUV IS INTEGRATING AGAIN! We will have a short data file in the morning. Stay tuned... ------------------------------------------------------------------------------- file EUV_ANOMALY.TEX -> EUV_110890.TEX % Slides for EUV Anomaly presentation at JPL (Nov 13,90) \magnification=2000 \hsize=6truein \tolerance=10000 \nopagenumbers \parindent=50pt \centerline {\bf EUV Anomaly - Thursday, Nov 8,1990} \centerline {Karen E. Simmons, C.W. Hord Concurs} \centerline {\it Outline} {\obeylines \obeyspaces \ What Happened, When, How We Recognized It \ Comparisions with Dec, 1989 EUV Anomaly \ Instrument Memory Hardware Description \ Recovery Scenarios \ Future Diagnostic Testing \medskip \medskip } \eject % Page 2 \centerline {\bf EUV Anomaly - Thursday, Nov 8,1990} \centerline {\it What Happened, When, How We Recognized It} {\obeylines \obeyspaces \ Transition from Cruise Mode to Encounter Mode Running since post-Venus (DOY 041) in Cruise Mode 567277:00~~~~~6MROH (ID=24)~~~- Read out Cruise data 567282:78~~~~~24 SP~~~~~~~~~~~- Stop Micro 567284:78~~~~~24 ST~~~~~~~~~~~- Start Micro 567287:11~~~~~24 EUV~~~~~~~~~~- Configure & ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Begin Execution \ All Analog Monitors were nominal \ Science Status Monitors indicated proper response at each command \ Except for Sector Buffer Counts which were = 00 after execution began } \medskip \eject % Page 3 \centerline {\bf EUV Anomaly - Thursday, Nov 8,1990} \centerline {\it What Happened, When, How We Recognized It (Cont)} {\obeylines \obeyspaces \ Suspected DTV error for Sector Buffer value \ When EUV printer came up at 5pm, recognized science telemetry stream contained no photon events \ Quick Look EDR (via LRSP) confirmed no photon events since 24SP command \ Quick Look EDR confirmed proper operation in Cruise Mode up to the 24SP } \eject % Page 4 contains page of raw telem & % RIM packet data from Thursday and Tuesday % Page 5 \centerline {\bf EUV Anomaly - Thursday, Nov 8,1990} \centerline {\it What Happened, When, How We Recognized It (Cont)} {\obeylines \obeyspaces \ Updating Wavelength Integration Buffer (WIB) Address implies proper micro operation: by software definition WIB updates when Spin Packet Prolog is output (each Spin =0 boundary crossing) which in turns set Integration Flag high \ Neil White predicted what portion of software would have to be corrupted. Since Integration Flag set with no counts output then had to be software area which compares commanded number of sectors versus current sector: If current sector exceeds commanded then jump to wait for next spin. \ Full Memory dump indicates one memory byte is upset: address 03B1 was C6, should be C3 \ C3 is the "IF" branch. C6 is an "UNCONDITIONAL JUMP" Since incorrect byte is a legitimate instruction, micro kept running, ignoring all photon events } \medskip \eject % Page 6 Comparision of EUV Anomaly Events \centerline {\bf EUV Anomaly - Thursday, Nov 8,1990} \centerline {\it Comparision of EUV Anomaly Events 1 & 2} {\obeylines \obeyspaces * Anomaly 1 was 1989-364/ * Both time affected two bits of one byte * Both times one bit transitioned from 0 to 1, one from 1 to 0 * Both time affected bits on separate but adjacent memory boards in between other unaffected memory boards * Each of four corrupted bits were in different rows and different columns * Both time affected "Long Branch" instructions; "Long" instructions take 3 cycles instead of the usual two cycles * One occurred during instrument mode transition (#2) and one occurred after 19 hours of encounter mode operation (#1) * One occurred in Encounter exclusive software area; one in area used by both Modes * Never occurred in 7 months of Cruise Mode * Never occurred in Ground Testing or simulation } \medskip \eject % Page 7 Anomaly Conclusions \centerline {\bf EUV Anomaly - Thursday, Nov 8,1990} \centerline {\it Comparision of EUV Anomaly Events 1, 2} {\obeylines \obeyspaces \ Based on our current understanding of SEU events, we believe upset is some kind of EMI event \ Anticipate it may occur again \ No current explanation for EMI } \medskip \medskip \eject % Page 8 Recovery Scenarios \centerline {\bf EUV Anomaly - Thursday, Nov 8,1990} \centerline {\it Recovery Scenarios} {\obeylines \obeyspaces {\bf Primary option: reload one corrupted byte} {\bf Backup option: Full POR with Flight tested configuration} \ Option 1 24DML,03B1,C3; is the command Instrument running now; correcting IF should allow proper operation No hazard to instrument if it works or doesn't work Tested on simulator Does not affect other instruments Immediate visibility in telemetry stream \ Option 2 -- the Backup for acquiring Earth 1 science POR sequence with "35 Sector" command (encounter command we have seen work in Flight; Venus has a different one and is a good test) Real time Command tape built for recovery from Anomaly #1 (includes a Cruise command so needs some work) } \medskip \eject % Page 9 Future Diagnostics \centerline {\bf EUV Anomaly - Thursday, Nov 8,1990} \centerline {\it Future Diagnostics} {\obeylines \obeyspaces \ Do not have a model for generation of EMI \ Simulator memory is commercial memory, may want to test mode changes on spacecraft instrument in EE cruise loads, as time is available. } \medskip \eject \bye ------------------------------------------------------------------------------- diskh:[simmons]EUV_OCT0295.DOC October 3, 1995 ANOMALY DESCRIPTION: The EUV science MRO on 1995-275//21:10 was delivered by email and showed a predominately zero data matrix. The status words in the (Phase 1) MRO, just before the copy of the FPN, indicated the 24EUV command had been received properly but the the time status values were not updating. Further analysis indicated that the 24SP command, issued during the EJ10 Power On in preparation for Torus observations in JAA, must have corrupted one or two bytes of program memory and that although the uP was still running, it was now running in some unknown polling loop which did not cause it to stop or to corrupt itself further. Although the PIs wishes were to simply re-start with a POR, the Project requested a memory verify set. This was agreed to as long as the MROs were part of the re-start sequence and did not include an analysis feedback loop. The IAPs were prepared for transmission on Friday, Oct 6, 1995. Prior to the Command Conference, Jim Marr requested information about what values were in the microprocessor locations after a 24SP corruption. This is what prompted the Project to request us to perform memory verifies. The data from the (May 1995) Testbed case, the LASP summer 24SP testing and all the flight cases are shown below. ANALYSIS: The EUV instrument has suffered four flight anomalies, including this October 1995 case. Three of those four are now attributed to the 24SP memory corruption situation. (The December 1989 is still not understood.) The details of the memory corruptions are addressed elsewhere, however it involves the 1802 microprocessor transition from a Run state to Load state. During this transition, which is not documented in the 1802 User Manual, it is possible to continue micro operations while it is not properly conditioned to to so and thus cause micro memory to be corrupted. This can occur with the design of the EUV CDS Bus interface. The memory corruption is therefore caused by the 24SP command and can be eliminated by not issuing this command. 24SP commands have been removed from the remaining Phase 1 and all Phase 2 sequences. The software changes for Phase 2 no longer require the microprocessor to be stopped in order to load the Fixed Pattern Noise Table. The command remains in the Power Off Library sequence where it is needed to stop the microprocessor before powering down the instrument. Since the memory is lost on Power Off, this is not a problem. submitted by Karen E. Simmons UVS/EUV Instrument Manager =========================================================================== LASP TESTING on BCE: (Summer of 1995) 24SP commands were randomly issued while the microprocessor was running. Of 70 cases when 24SP commands were issued, the following one-byte corruptions were observed. Address original value corrupted value ----------------------------------------------------------- 0000 71 C6 0000 71 00 0019 00 FF 010F 45 00 01B5 4C C6 01B6 55 00 Also, further testing of the 24SP command corruption with a test program on the BCE, indicated it was possible to corrupt numerous locations in memory. The key to the number of corrupted locations and to the value placed into the corrupted location seemed to be dependent on the contents of the CDS command data words present on the line when the SP command was recognized by the microprocessor. We considered that since time and sector broadcasts (which contain a C6 identification value) were the most frequent bus traffic, the C6 value seen in the corrupted locations could very well be these time broadcast ID values. TEST BED EVENT, May 1995: This two-byte corruption was seen in a memory verify following a 24SP command prior to Power off. This corruption did not effect the Test Bed results. Address original value corrupted value ----------------------------------------------------------- 020D,020E 02,06 B5,01 FLIGHT CASES: November 1990 - during a transition from Cruise Mode to Encounter Mode, a 24SP command was issued so a new Fixed Pattern Noise Table could be loaded. Address original value corrupted value ----------------------------------------------------------- 03B1 C3 C6 Oct 11, 1993 - during an EUV Power On after spacecraft safing, the library sequence which loads the Fixed Pattern Noise Table contains a 24SP command. Address original value corrupted value ----------------------------------------------------------- 000F A2 C6 Sept 30, 1995 - during an EUV Power On sequence in EJ10 to configure the instrument to begin taking Jupiter approach Torus data, the Fixed Pattern Noise Table library sequence issued a 24SP command. The corrupted locations are in the section of the MROs that were lost (due to a Madrid loss-of-lock.) The ACE was able to confirm that he saw the s/c power due to the Power Off/Power On commands in the IAP sequence. Address original value corrupted value End of report. ------------------------------------------------------------------------------- Nov 3, 1993 -KES A spacecraft safing on Sept 24, 1993 Powered Off both instruments. A series of delays and DSN problems kept the EUV from turning on until Oct 11,93 and then it was done with half of the EUVON library sequence transmitted on Monday and the other half on Wednesday (both by DACs), followed later on Wednesday by IAPRs to finish the turn on. Three memory verifies were done, which showed bit hits which were all believed to be DSN hits since they were not repetitive. When the science MRO was received on Oct 13, it indicated the data matrix was empty (except for one value), that the FPN table had been overwritten with what looked like the program memory, and the RIM time was a value just after the 24EUV command. An ISA was written and a Power Off with full memory dumps was requested. The memory dumps indiated a memory corrupt (see the file [SIMMONS.GLL_ANOMALIES]EUV_OCT1193.ANALYSIS containing a complete analysis by Neil White. Charlie asked for the instrument to be turned back on, without the memory verifies. Matt Landano was on jury duty and Joe was then at Colorado so no immediate action was taken. ------------------------------------------------------------------------------- From: GLLSVC::KNAVIAUX "Keith @ JPL/Pasadena,CA" 5-NOV-1993 19:27:56.71 To: PISCES::SIMMONS CC: @[KNAVIAUX.DIS]JPLUVS.DIS Subj: Transmission Time of EUV Power On Commands (DOY 286) Hi Karen, I just spoke w/ Jim McClure of the MCT about the transmission times of the EUV Power On IAPS back on October 13th. The logs show that the cmds were transmitted exactly on time, so the timing I put together should be very close to actual. Below is a review of the timing: OWLT = 00:35:05 IAP Package #1 Transmission = 286/20:15:00 IAP Package #2 Transmission = 286/20:40:00 (+00:25:00) IAP Package #3 Transmission = 286/20:55:00 (+00:15:00) I'll do some more checking, but I don't know where the difference in timing (greater than 1 RIM vs. the 1 s/c rotation of ~20 sec) comes from. I believe my numbers could be off by a few seconds, but I don't think they could be of by 40+ seconds. I'll let you know if I can get more information which might shed some light. Keith..... ------------------------------------------------------------------------------- From: GLLSVC::KNAVIAUX "Keith @ JPL/Pasadena,CA" 5-NOV-1993 23:39:03.41 To: @[knaviaux.dis]jpluvs.dis,PISCES::WHITE CC: Subj: New Times for EUV On Commands = BINGO!! Hi Karen, BINGO! I learned some new info from the OET about the command timing for the EUV Power On IAPS and have noted the corrected times below. The difference between the two comes from having to take into account the time it takes to transmit each element at 32 bps. Note only the times of the IAPs have changed and not the Utility commands. This did change the timing of the commands AND increased the time of the 24EUV command by 71.5 seconds (21:30:19.833 instead of 21:29:08.333). So, the discrepancy in the EUV command timing which Neil noticed should now be accounted for with the corrections. Let me know if you come across any further problems and sorry if there was any inconvenience caused by the previous times I sent out. Keith..... *************************************************************************** RBS#1: ===== 284/22:59:59.800 24A 284/23:02:01.133 24DML,0000 284/23:02:01.800 24DML,0020 284/23:02:02.466 24DML,0040 284/23:02:03.133 24DML,0060 284/23:02:03.800 24DML,0080 284/23:02:04.466 24DML,00A0 284/23:02:05.133 24DML,00C0 284/23:02:05.800 24DML,00E0 284/23:02:06.466 24DML,0100 284/23:02:07.133 24DML,0120 284/23:02:07.800 24DML,0140 284/23:02:08.466 24DML,0160 284/23:02:09.133 24DML,0180 284/23:02:09.800 24DML,01A0 284/23:02:10.466 24DML,01C0 284/23:02:11.133 24DML,01E0 284/23:02:11.800 24DML,0200 284/23:02:12.466 24DML,0220 284/23:02:13.133 24DML,0240 284/23:02:13.800 24DML,0260 RBS#2: ===== 286/19:00:00.333 24DML,0280 286/19:00:01.000 24DML,02A0 286/19:00:01.666 24DML,02C0 286/19:00:02.333 24DML,02E0 286/19:00:03.000 24DML,0300 286/19:00:03.666 24DML,0320 286/19:00:04.333 24DML,0340 286/19:00:05.000 24DML,0360 286/19:00:05.666 24DML,0380 286/19:00:06.333 24DML,03A0 286/19:00:07.000 24DML,03C0 286/19:00:07.666 24DML,03E0 286/19:00:08.333 24DML,0400 286/19:00:09.000 24DML,0420 286/19:00:09.666 24DML,0440 286/19:00:10.333 24DML,0460 286/19:00:11.000 24DML,0480 286/19:00:11.666 24DML,04A0 286/19:00:12.333 24DML,04C0 286/19:00:13.000 24DML,04E0 286/19:02:14.333 6MROH,28,0000,15,A 286/19:24:14.333 6MROH,28,0000,15,A IAPRS (OWLT = 00:35:05): ======================= #1 - xmission @ 286/20:15:00 + (336/32) --------------------------------------- 286/20:50:15.500 6MROH,28,0000,15,A 286/21:12:25.500 24ST #2 - xmission @ #1 + 00:25:00 + (1008/32) ----------------------------------------- 286/21:15:47.500 24SP 286/21:17:48.333 24ST 286/21:19:49.667 24DML,0F00 #3 - xmission @ #2 + 00:12:00 + (1008/32) ----------------------------------------- 286/21:28:18.500 24DML,0F40 286/21:30:19.833 24EUV,NORM,COUNT,3,1,CRUISE,19,23 ------------------------------------------------------------------------------- From: PISCES::WHITE "Neil White,LASP,(303)-492-7959" 20-OCT-1993 17:30:58.74 To: SIMMONS CC: WHITE Subj: EUV Analysis Karen, I have given the EUV memory readouts a fairly complete first look, and will give you my observations below. This can be used as a foundation for any ISA closeout action. I do not intend to put any further effort into the investigation without your approval and direction. I believe the following analysis is fairly conclusive, but unfortunately we did not get a full EUV memory readout from 000 hex to FFF hex (my copies show from 000 hex to F9F hex), and the last 96 bytes would have been helpful to assure ourselves that this analysis is correct. I will make some recommendations at the end. NOTE: Unless otherwise indicated, all numbers are in hexadecimal. FACTS / OBSERVATIONS (Relevant to analysis): 1) Program Memory Locations that are not as expected: a) Memory location 00F is corrupted from an A2 to a C6. b) Memory location 4F4 is corrupted from a 90 to a 00. 2) The input buffer indicates a single photon packet with the sequence 00, 6A, 00, 01. 3) The output buffer indicates a single photon has been accumulated at address 97A. 4) The Fixed Patter Noise table has been corrupted (Locations F00 through F7F). The start of the corruption occurs at the location PRIOR to the beginning of the FPN (i.e. EFF), and is corrupted with a copy of the program code from address EFF to the end of visible memory limited by the MRO (address F9F). The corruption includes the C6 rather than the A2 mentioned in Fact #1a. ANALYSIS: The Program Memory corruption at location 00F from an A2 to a C6 accounts for the other unexpected memory modifications. This location is in the very first part of the initialization code for the EUV microprocessor. The A2 is supposed to initialize the low order (Least significant byte) of the (two byte) stack pointer. Instead, the C6 is a Long Skip if Accumulator is Not Zero (LSNZ) instruction. The net results of this modification are two fold. 1) The low order of the stack pointer is NOT initialized to an FF as the original code requires, and thus the stack pointer points to somewhere in page F00 to FFF (the high order is initialized correctly), with the actual value determined by the Power-On value that the microprocessor randomly initializes to. 2) The accumulator contains an FF when the C6 is encountered, and thus the "Skip" is taken, which effectively branches past the next two bytes in the program code. These two bytes, if they had been executed, were to reset the accumulator to 00. Thus the code immediately following this corruption sees a FF in the accumulator rather than a 00. Based upon these observations, a "walk through" of the code produces the following results. 1) Almost immediately following the errant location at address 00F, memory is cleared via a loop structure, from the location of the stack pointer down in address (i.e from the bottom of memory towards the program) for B00 bytes. Normally, this would have cleared from address FFF up to 500. If we assume the low order of the stack pointer powers-up to a F3, then the loop would clear the locations from FF3 to 4F4. This would account for the second corruption of program memory to a 00 at location 4F4 (Fact #1b). After the loop clearing memory is complete, the stack pointer register is now CORRECTLY re-initialized to FFF. The lack of initialization of locations FF4 through FFF would not affect the program execution, in that, this area is reserved for "stack" data, and thus does not need initialized. 2) As a result of not loading the accumulator with zero because of the LSNZ instruction execution, a FF will be output to the EUV Channel Spectrometer. This causes, among other things, the High Voltage to be set to a Level 7. This violates a flight rule. There are two scenarios that can follow from this in the time domain. The first, which has a probability of greater than 90%, is that the High Voltage would be turned off in less than 1 second. The second scenario leaves the High Voltage on for up to one Major Frame, or about a minute. 3) The now corrupted value at address 4F4 is the second byte of an unconditional branch instruction. This gives the microprocessor an absolute address to jump to within the current page of code, where a page is defined as a contiguous section of memory from a low order address of 00 through FF (256 bytes). Under proper operation, this instruction should cause the execution to unconditionally branch from 4F4 to 490, but because of the modification, it will now instruct the microprocessor to jump to address 400. The section of code prior to address 4F4 is in the interrupt routine, and specifically, is part of the pixel processing interrupt code. Therefore, this unconditional branch instruction will only be executed the after the EUV Channel is enabled by command, and some light (counts received by the EUV logic from the EUV Channel) has been observed. Because these two bytes (at addresses 00F and 4F4) are the ONLY two bytes of program code affected at this time, and because address 00F is only executed once during initialization, and last because the interrupt code at location 4F4 is only executed after the EUV is commanded on, the EUV microprocessor would now happily execute the rest of code normally, keeping track of time, updating the Analog Housekeeping mux, and waiting for a command. 4) Some time later, the S/C sent a proper EUV Configuration command (24EUV command). This command was correctly received by the EUV microprocessor. The EUV was then properly configured per the command under software control. This process executed exactly as we would expect, and the EUV waited until the proper roll angle was reached before enabling photon counting by the EUV Channel. At the first occurrence of true "data" from the EUV Channel to the EUV logic, the EUV microprocessor was interrupted to process this data. The interrupt routine took the data from the I/O ports and created a proper input data packet in the EUV Pixel Input Buffer (i.e. 01, 6A, 00, 01 at address 500). After putting these four bytes in the input buffer, an unconditional branch was executed as described in 3) above. The microprocessor then jumped to location 400 rather then the intended 490, which is the beginning of a loop to copy from one portion of memory to another. Since the microprocessor jumped to this location as a result of the modified memory, the pointers and loop counters were not initialized, and thus the microprocessor simply started the loop using values that were relevant during the last intended use of these registers. An examination of the previous usage of these registers indicated that: a) the input pointer initially pointed to FFF and was incremented during each iteration of the loop, thus counting FFF, 000, 001, 002, .... Except for the value at FFF, the rest of the input data was the program code from address 000 forward. b) The output pointer was last set to point to the end of the cruise digital housekeeping buffer, specifically address EFE. c) the loop counter could have been one of many values (it would be hard to speculate), but from the results, it was at least 91 but less than 256 (8 bit counter). Thus, effectively the program code was copied from the FPN address minus one, address EFE, to address F9F or beyond. This explains Fact #4. 5) After this loop, the program continued to execute a portion of the code that processes pixel data, by interpreting the 4 byte pixel packet in the Pixel Input Buffer. This resulted in the decrementing of the first byte of the four byte packet from a value of 01 to 00. After this, the program retrieved an offset from the FPN table for pixel address 6B (or absolute address F6B). This location had been modified from the normal FPN contents to a copy of the program by the loop mentioned in #4 above. Thus address F6B contained a BD. This "offset" value was multiplied by 2, modulo 256, with the result of 7A. This value, 7A, was then added as an offset from the beginning of the output buffer at address 900. Thus, location 97A was incremented to reflect the photon received from the EUV channel. Thus, Fact #3. 6) The execution of the processing of a Cruise mode input packet concluded normally, and the execution of the background polling loop then continued. 7) Because of the Branch instruction modification jumping out of the interrupt routine into the Cruise processing routine, which concluded with a jump to the background polling routine, interrupts were never re-enabled after this first EUV Channel pixel input interrupt was executed. Thus the EUV microprocessor, from this point forward, was simply in a polling loop, waiting for the interrupt routine to pass it a flag saying something has changed, when no interrupts were enabled. So the EUV microprocessor remained in this state, basically waiting to be interrupted, until the power was remove late Friday night, October 15, 1993. Conclusions: The Memory Readouts give us conclusive evidence of the path of execution the EUV microprocessor from the very beginning of execution until power was removed. We conclude from this that a single memory location was corrupted (address 00F) from an expected value of A2 to a value of C6, and that this corruption would cause all the other corruptions in the EUV memory. Also, from this state it is probable that the EUV Channel High Voltage was on at Level 7 for about a second. The source of the corruption of address 00F is unknown. Three memory verifies prior to the beginning of EUV microprocessor execution indicated the correct loading of this byte, so somehow it was modified between the last memory verify and the beginning of EUV microprocessor execution a few minutes later. ------------------------------------------------------------------------------- From: PISCES::WHITE "Neil White,LASP,(303)-492-7959" 2-NOV-1993 22:31:15.06 To: SIMMONS CC: MCNUTT,WHITE Subj: Analysis of EUV Anomoly discovered 10/15/93 Galileo EUV Anomaly of October 15, 1993 Analysis of Data November 1, 1993 Neil White EUV / UVS Instrument Engineer NOTE: Unless otherwise indicated, all numbers are in hexadecimal. FACTS / OBSERVATIONS (Relevant to analysis): 1) Program Memory Locations that are not as expected: a) Memory location 00F is corrupted from an A2 to a C6. b) Memory location 4F4 is corrupted from a 90 to a 00. 2) The input buffer indicates a single photon packet with the sequence 00, 6A, 00, 01. A (00, 6A) with (00, 01) indicates this was a L-a photon. But note, relative to item 3, that it is only by chance that it ended up in a L-a position. It is NOT in the EXPECTED Sector #1 L-a position. 3) The output buffer indicates a single photon has been accumulated at address 97A. 4) The Fixed Patter Noise table has been corrupted (Locations F00 through F7F). The start of the corruption occurs at the location PRIOR to the beginning of the FPN (i.e. EFF), and is corrupted with a copy of the program code from address EFF to the end of visible memory limited by the MRO (address F9F). The corruption includes the C6 rather than the A2 mentioned in Fact #1a. 5) Three (program) memory verifies were executed after the microprocessor load following Power On. Although each verify did indicate "(station) bit hits," none of the addresses were repetitive. Later re-examination of the memory verifies indicated the corrupted program location (00F) was NOT REPORTED in the three memory verifies. 6) The RIM + mf value is entered into the memory by the microprocessor at a location just after the EUV housekeeping data and a few bytes before the FPN begins. The RIM value seen in the science MRO and again in the memory dumps prior to Power off indicate a value of time for the start of the integration period as SCLK=2091414:38, RTI=9 (Decimal). Reconstruction of the IAP timing based on MCT knowledge and OWLT, this SCLK would be 1 RIM and 12 minor frames after the 24EUV command. BACKGROUND: The EUV initially powers up into the "load" mode where CDS memory load and verify commands are allowed to directly access the EUV memory. After power-up, under control of the standard S/C library sequences, CDS will load the EUV program memory, then readout the memory three times to verify the integrity of the load, and finally the microprocessor will be started via a 24ST command. EUV program initialization is begun with the 24ST command (which tells the uP to transition from its current, "load" state to the "reset" state and then to the "run" state). It is the run state that begins the "initialization", and the first corrupted memory location at address 00F is processed. After initialization, the EUV microprocessor basically waits for a 24EUV command before any processing of photon events can occur. The photon events themselves are received from the EUV channel through an interrupt routine which resides between locations 490 and 4F4. It is not until after a 24EUV command allows the uP to process photon events, however, that the program gets to a point where it encounters the bogus 00 at address 4F4 (instead of a 90), and where the majority of the memory corruption occurred (see below). ANALYSIS: The Program Memory corruption at location 00F from an A2 to a C6 accounts for ALL the other unexpected memory modifications. This location is in the very first part of the initialization code for the EUV microprocessor. The A2 is supposed to initialize the low order (Least significant byte) of the (two byte) stack pointer with an FF. Instead, the C6 is a Long Skip if accumulator is Not Zero (LSNZ) instruction. The net results of this modification are two fold. 1) The low order of the stack pointer is NOT initialized to an FF as the original code requires. Thus the stack pointer points to somewhere in page F00 to FFF (the high order is initialized correctly), with the actual value determined by the Power-On value that the microprocessor randomly initializes to. 2) The accumulator contains an FF when the C6 is encountered, and thus the "Skip" is taken, which effectively branches past the next two bytes in the program code. These two bytes, if they had been executed, were to reset the accumulator to 00. Thus the code immediately following the corruption at address 00F sees a FF in the accumulator rather than a 00. Based upon these observations, a "walk through" of the code produces the following results. 1) The code almost immediately following the errant location at address 00F, causes the uP to clear memory via a loop structure, from the location of the stack pointer down in address (i.e from the bottom of memory up towards the program) for B00 bytes. Normally, this would have cleared (zeroed) the working stacks, input and output buffers, etc., from address FFF up to 500. If we assume the low order of the stack pointer powers-up to a F3, then the loop would clear the locations from FF3 to 4F4. This would account for the second corruption of program memory to a 00 at location 4F4 (Fact #1b). The assumed value of F3 fits the data, in that if it was less than F3, the loop would have stopped after reaching the terminal count (B00 memory locations) prior to reaching address 4F4; and if it was greater than F3, the loop would have corrupted more of the program backwards from address 4F4 with values of 00. After the loop clearing memory is complete, the stack pointer register is now CORRECTLY re- initialized to FFF. The lack of initialization of locations FF4 through FFF would not affect the program execution, in that, this area is reserved for "stack" data, and thus does not need initialized. 2) As a result of not loading the accumulator with zero because of the LSNZ instruction execution, a FF will be output to the EUV Channel Spectrometer. This causes, among other things, the high voltage to be set to a level 7. There are two scenarios that determine the time period over which the high voltage is at level 7. The first, which has a high probability, is that the high voltage would be turned off in less than 1 second. The second (low probability) scenario leaves the high voltage on for up to one Major Frame, or about a minute. 3) The now corrupted value (00 instead of 90) at address 4F4 is the second byte of an unconditional branch instruction. This second byte gives the microprocessor an absolute address to jump to within the current page of code, where a page is defined as a contiguous section of memory from a low order address of 00 through FF (256 bytes). Under proper operation, this instruction should cause the execution to unconditionally branch from 4F4 to 490. The section of code between address 490 and address 4F4 is the interrupt routine, and specifically address 4F4 is at the end of the pixel processing interrupt code. Therefore, this unconditional branch instruction will only be executed after the EUV Channel is enabled by command, and some light (counts received by the EUV logic from the EUV Channel) has been observed. Because of the modification, it will now, when executed, instruct the microprocessor to jump to address 400 (a discussion of the results of this jump to address 400, instead of address 490, is given in #4 below). Because these two bytes (at addresses 00F and 4F4) are the ONLY two bytes of program code affected at this time, and because address 00F is only executed once during initialization, and last because the interrupt code at location 4F4 is only executed after the EUV is commanded on, the EUV microprocessor would now happily execute the rest of code normally, keeping track of time, updating the Analog Housekeeping mux, and waiting for a command. 4) Some time later (approximate time given in Fact #6), the S/C sent a proper EUV Configuration command (24EUV command). This command was correctly received by the EUV microprocessor. The EUV was then properly configured per the command under software control. This process executed exactly as we would expect, and the EUV waited until the proper roll angle was reached before enabling photon counting by the EUV Channel. At the first occurrence of true "data" from the EUV Channel to the EUV logic, the EUV microprocessor was interrupted to process this data. The interrupt routine took the data from the Input ports and created a proper input data packet in the EUV Pixel Input Buffer (i.e. 01, 6A, 00, 01 at address 500). Before going on, a brief explanation of the working of an 1802 interrupt is in order. The nature of the 1802 uP implementation requires the exit from an interrupt routine to occur just prior to the entry point of the interrupt module. Usually, near the end of an interrupt routine implemented on the 1802, an unconditional jump is executed to change execution to an area of code PRECEDING the interrupt routine's entry point. This is the purpose of the unconditional jump at address 4F4. The actual exit from the interrupt will usually also re-enable interrupts. Thus the unconditional branch from the end of the pixel processing section (address 4F4) should jump back to the top of the interrupt code (address 490); causing the re-enabling of the interrupts as it exits back to the background routine. In this errant case, where we jump to address 400 instead of address 490, the interrupts are never re-enabled, and we "jump" back into the background code, rather then the normal exit via the 1802 interrupt mechanisms. Now, back to the analysis. After putting these four bytes (01, 6A, 00, 01) in the input buffer, an unconditional branch was executed as described above. The microprocessor then jumped to location 400 (rather then the intended 490), which is the beginning of a loop to copy from one portion of memory to another. Since the microprocessor jumped to this location as a result of the modified memory, the pointers and loop counters were not initialized, and thus the microprocessor simply started the loop using values that were relevant during the last intended use of these registers. An examination of the previous usage of these registers indicated that: a) the input pointer (the address to obtain what to copy) initially pointed to FFF and was incremented during each iteration of the loop, thus counting FFF, 000, 001, 002, .... Except for the value at FFF, the rest of the input data was the program code from address 000 forward. b) The output pointer was last set to point to the end of the cruise digital housekeeping buffer, specifically address EFE. c) the loop counter could have been one of many values (it would be hard to speculate), but from the results seen in the memory dump, it was at least 91 but less than 256 (8 bit counter). Thus, effectively a copy of the program code was copied from the FPN address minus one, address EFE, to address F9F or beyond. This explains Fact #4. 5) After this loop, the program continued to execute a portion of the code that processes pixel data, by interpreting the 4 byte pixel packet in the Pixel Input Buffer. This resulted in the decrementing of the first byte of the four byte packet from a value of 01 to 00. After this, the program retrieved an offset from the FPN table for pixel address 6B (or absolute address F6B). This location had been modified from the normal FPN contents to a copy of the program by the loop mentioned in #4 above. Thus address F6B now contained a BD. This "offset" value was multiplied by 2, modulo 256, with the result of 7A. (The offset value is multiplied by two because we maintain two byte (16-bit) data registers for the cruise matrix. The modulo 256 comes from the fact that we only have a maximum of 126 registers possible, so 126 times two is implicitly supposed to fit in eight bits.) This value, 7A, was then added as an offset from the beginning of the output buffer at address 900. Thus, location 97A was incremented to reflect the photon received from the EUV channel. Thus, Fact #3. (As noted earlier, it is only by chance that this was a matrix location associated with a L-a photon; it is not the correct matrix location for THIS sector 1 L-a photon.) 6) The execution of the processing of a Cruise mode input packet concluded normally, and the execution of the background polling loop then continued. 7) Because of the Branch instruction modification jumping out of the interrupt routine into the Cruise processing routine, which concluded with a jump to the background polling routine, interrupts were never re-enabled after this first EUV Channel pixel input interrupt was executed. Thus the EUV microprocessor, from this point forward, was simply in a polling loop, waiting for the interrupt routine to pass it a flag saying something has changed, when no interrupts were enabled. So the EUV microprocessor remained in this state, basically waiting to be interrupted, until the power was remove late Friday night, October 15, 1993. 8) The time of the integration period captured in the EUV Cruise Memory Housekeeping Data Buffer indicates a time of SCLK = 2091414:38, RTI=9 (Decimal) (Fact #6). Based upon the data delivered to LASP on when CDS should have sent the preceding 24EUV command, there is a difference of greater than one RIM. This is inconsistent with the operation of the EUV, even with the corrupted memory locations. There should be no more than one S/C revolution, or about 20 seconds, between the receipt of the command and start of integration. We would like to request further refinement of the ACTUAL time CDS would have sent the 24EUV command to the EUV bus adaptor to resolve this discrepancy. Conclusions: The Memory Readouts give us conclusive evidence of the path of execution the EUV microprocessor from the very beginning of execution until power was removed. We conclude from this that a single memory location was corrupted (address 00F) from an expected value of A2 to a value of C6, and that this corruption would cause all the other corruptions in the EUV memory. Also, from this state it is probable that the EUV Channel High Voltage was on at Level 7 for about a second. The source of the corruption of address 00F is unknown. Three memory verifies prior to the beginning of EUV microprocessor execution indicated the correct loading of this byte, so somehow it was modified between the last memory verify and the beginning of EUV microprocessor execution a few minutes later. ------------------------------------------------------------------------------- From: BPER::SIMMONS "KAREN SIMMONS AT LASP/COLORADO" 5-NOV-1993 17:22:27.77 To: PUP::JAJELLO CC: @JPLUVS,@GLL_SCI,WHITE,MCNUTT Subj: FYI: statistics of EUV anomaly; recommendations STATISTICS of UVS and EUV ANOMALIES RELATIVE to the OCTOBER 11,93 EUV LOAD ANOMALY Nov 4,93 - K.E. Simmons UVS UVS Anomalies............................... 1 * Nov 5,92: Bit hits seen in memory verifies Action: * Power Off, Power On, memory load, 3 verifies - successful * Recommended remove verifies - done 5 successful loads since UVS On-off Cycles (as of Nov 4,93).......... 17 (+ On now) Cold Start Cycle (no memory verify)..... 1 Power cycles with memory verifies....... 11 Cycles since memory verifies were removed on FEB 10,93; all successful........ 5 EUV EUV On-off Cycles (as of Nov 4,93).......... 18 Power cycles with memory verifies....... 18 Power cycles due to s/c safing, CT/WTs. 11 Power cycles for HIC operations........ 5 Power cycles for EUV anomalies......... 2 EUV Anomalies .............................. 3 * Dec 30,89: Micro stopped, "particle" memory disturb Action: * Power Off, Power On, memory loaded, 3 verifies - successful * Oct 29,90: Memory disturb during mode change Action: * Re-loaded corrupt memory byte - successful CURRENT:* Oct 11,93: Memory disturb after memory load Action: * Powered Off RECOMMEND: * Power On, memory load, NO verifies * Remove verifies from Library sequences * Remove EUV Power Off from Fault Protection ------------------------------------------------------------------------------- From: BPER::SIMMONS "KAREN SIMMONS AT LASP/COLORADO" 7-NOV-1993 17:25:51.18 To: WHITE CC: PUP::JAJELLO,@JPLUVS,@GLL_SCI Subj: EUV memory chips Neil, I spoke to Tien Nguyen (pronounced "whin") @ 818-354-2450. He indicated that the Harris 6504 memory chips that EUV has were used in Magellan as well and HAVE PROBLEMS similar to the TCC 244s. Two problems in particular are possible for us: a) "data contention": a power drop causes a bit flip; seen where power drops from 5.0v to about 3.5v b) "oxide breakdown". The good news is that neither problem propagates on the chips and Magellan has generally just programmed around bad (byte/areas?). I think our next step is to review the 89-364 analysis plus the 1990 and 1993 known flipped bits problems to determine if any one or more specific memory chips are involved. My quick check of the 90 and 93 cases indicate 3 or 4 chips would have to be involved; I need to re-check what you said the original value was suppose to be. Bottom line is that the "decision" tree we established for UVS in 1992 is probably applicable for EUV now as well. Recall it included a "program around" if UVS did not load properly. Karen ------------------------------------------------------------------------------- From: BPER::SIMMONS "KAREN SIMMONS AT LASP/COLORADO" 7-NOV-1993 18:18:11.37 To: WHITE,PUP::JAJELLO CC: SIMMONS,PRYOR Subj: changed bits Neil and Joe, I looked up what bits have been changed in the three "bit hit" anomalies for EUV (hum, I'll check UVS as well.) Here they are: date address changed should have been became ________________________________________________________________ 1989 03B1 C3 C6 ^^oops,=1990 1989 01F5 02 2A 1993 000F A2 C6 UVS1992 00CB 52 12 The bits which flipped in these cases are shown below: 1990 1100,0011 1100,0110 1989 0000,0010 0010,1010 1993 1010,0010 1100,0110 1992 UVS 0101,0010 0001,0010 These are the "sensitive bits" or effected chips, then: -^^-,^^-^ where the ^ means that bit has been hit at least once and - means that bit/chip has never been effected. That indicates that 5 of 8 chips have been effected. That's a little hard to believe. (Note that the UVS did add any new bits and that its a TCC 244 anyway.) The only new info I have since the previous memo is that Neil's analysis of the 1989 anomaly indicates that a voltage change could be involved since he felt the spectrometer had been effected and believed a voltage change could have been responsible. Karen ------------------------------------------------------------------------------- Date: Thu, 24 Feb 2000 15:38:31 -0800 From: "W.Kent.Tobiska" Subject: Galileo is in Safing - Status To: "Ian A.F. Stewart" , Wayne Pryor , Amanda Hendrix , simmons@lasp.colorado.edu Date: Thu, 24 Feb 2000 15:15:44 -0800 To: gem_project < From: Jim Erickson < Subject: Galileo is in Safing Status 2 For your information. -Jim E- >>>> Date: Thu, 24 Feb 2000 15:13:34 -0800 To: Edward.C.Stone-Jr@jpl.nasa.gov, Larry.N.Dumas@jpl.nasa.gov, Gael.F.Squibb@jpl.nasa.gov, Dick Coffin <, griegler@mail.hq.nasa.gov, Charles P Holmes < From: Jim Erickson < Subject: Galileo is in Safing Status 2 Cc: Jane L Platt <, M B Murrill < Galileo Safing Status 2 2/24/2000 3:00 p.m. PST The Galileo spacecraft is presently in safing, with both CDS strings operating, and other subsystems normal. The safing is believed to be a CDS despun bus reset, the third of this encounter. During encounters, the spacecraft is now equipped with a software routine that detects a despun bus reset and enables the CDS to "ignore" it and continue the encounter without interruption. However, this software routine must be disabled during tape recorder playback, which began last night. We haven't previously seen a bus reset happen at this distance from Jupiter, as it occurred at about 29 Rj (Jupiter radii). We are about to begin recovery, and expect to complete the process this evening. -Jim E- James K. Erickson Galileo Project Manager Jet Propulsion Laboratory James.K.Erickson@jpl.nasa.gov ************************** ==================================================================== Date: Thu, 24 Feb 2000 16:15:53 -0800 From: "W.Kent.Tobiska" Subject: Safing - EUV off - no more torus To: "Ian A.F. Stewart" , Wayne Pryor , Amanda Hendrix , Joe Ajello , simmons@lasp.colorado.edu Cc: kent.tobiska@jpl.nasa.gov Hi all, Just got out of a safing meeting. I requested, but was denied, to restore the EUV torus observation after the OTM tomorrow. Erickson indicated that the workload was too great to just make the OTM work much less get science going again. Bottom line is that the torus observations we have to this point of safing (this afternoon - do not have exact time yet) are all that we will get for I27. Safing was due to a bus reset at 29 Rj. -Kent ------------------------------------------------------------------------------- Date: Fri, 25 Feb 2000 10:15:26 -0800 From: "W.Kent.Tobiska" Subject: 2/25/00 Galileo Friday Report To: "Ian A.F. Stewart" , Wayne Pryor , Amanda Hendrix , simmons@lasp.colorado.edu Date: Fri, 25 Feb 2000 08:23:22 -0800 To: Edward.C.Stone-Jr@jpl.nasa.gov, Larry.N.Dumas@jpl.nasa.gov, Gael.F.Squibb@jpl.nasa.gov, Norman.R.Haynes@jpl.nasa.gov, John.R.Casani@jpl.nasa.gov, William.J.Oneil@jpl.nasa.gov, griegler@mail.hq.nasa.gov, Charles P Holmes< From: Jim Erickson < Subject: 2/25/00 Galileo Friday Report Cc: Robert Mitchell <, J C Marr <, Jane L Platt <, M B Murrill <, F ODonnell <, Joyce N Pulliam <,sjoy@igpp.ucla.edu, gem_project <,mbelton@noao.edu, rcarlson@lively.jpl.nasa.gov, cohen@srl.caltech.edu, frank@iowasp.physics.uiowa.edu, donald-gurnett@uiowa.edu, thoward@chaparral.net, mkivelson@igpp.ucla.edu, krueger@dolly.mpi-hd.mpg.de, stewart@pisces.colorado.edu, pdldt@giss.nasa.gov, djw@aplcomm.jhuapl.edu, J A Hodder <, Christopher Russell <, "William S. Kurth" < Galileo Friday Report 2/25/00 The Galileo spacecraft is operating normally. The primary activity over the past week has been the Io 27 encounter on 2/22/00. This was another picture perfect encounter, with normal execution of all planned activities. Close approach to Io was at 6:32 a.m. PST ground receipt time, at an altitude of 198 km. Remote sensing observations and fields and particles recordings of Io were completed without incident. A radio science near-occultation of Jupiter was recorded at the DSN normally. Playback began 2/23/00 at approximately 12:22 p.m. PST ground receipt time. Radiation levels were about average, with no problems identified. The peak radiation level was around 900 (measured by the star scanner in pulse counts), significantly lower than the maximum of 1400 seen in previous GEM orbits. During the encounter a pair of standard bus resets occurred and was handled normally by the on-board recovery software without any effect on the planned sequence. The first occurred at approximately 1:38 a.m. on 2/22/00, and the second occurred during a window from 5:30 p.m. to 6:30 p.m. on 2/22/00 PST ground receipt time. Subsequent to the encounter, a third bus reset hit the spacecraft at 4:45 a.m. on 2/24 PST ground receipt time, forcing it into safing. During encounters, the spacecraft is now equipped with a software routine that detects a despun bus reset and enables the CDS to "ignore" it and continue the encounter without interruption. However, this software routine must be disabled during tape recorder playback, which began on 2/23. We haven't previously seen a bus reset happen at this distance from Jupiter, as it occurred at about 29 Rj (Jupiter radii). The flight team diagnosed the problem and the spacecraft was brought back into normal operations at 9:30 p.m. PST ground receipt time. Playback will resume on 2/26. * * * * * * * * * * * * * * * * James K. Erickson Galileo Project Manager Jet Propulsion Laboratory James.K.Erickson@jpl.nasa.gov ************************** W. Kent Tobiska ------------------------------------------------------------------------------- -------------------------------------------------------------------------------" END_OBJECT = NOTEBOOK END