@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ @ @ MTA Monitoring Report 7/14/00 - 7/20/00 @ @ @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Archive of all weekly reports http://asc.harvard.edu/mta/REPORTS/weekly.html Archive of Monthly reports http://asc.harvard.edu/mta/REPORTS/MONTHLY ************ Radiation ************* From Friday July 14 0800 UT through Monday 1200 UT July 17. No observations were made. This period included 2 radiation passages. There was a large X-5 flare from the Sun. Large Hard proton (1073-1802 KeV) fluxes from the Sun. Kp reached 9. Soft proton (130-214KeV) rate reached 900,000 particles per cm2-s-ster-MeV On Thu, 20 Jul 2000 05:51:04, a radiation violation of the USAF Kp index has occurred. Value = 6.00 (limit: Kp=6) (see: http://asc.harvard.edu/mta/ace.html) ************ CTI trend ************* On Jul 14, CTI of CCD4 dropped; however, this is due to a squeegee test. *********** ACIS Focal Temperature ******** The base temperature was slightly lower between DOY 196 and 199 (-120.03 C). There are three peaks as usual. Day (DOY) Temp (C) Width (DAY) 196.8 -110.5 0.25 199.4 -111.3 0.25 202.1 -111.5 0.26 ************** MTA Problem Tracking ***************** There are several reopened items: AIOBP5CV: IOE B +5V CONVERTER VOLTAGE (PCAD) AOVAMPWR: VDE-A MUPS PWR ENABLE STATUS (PCAD) C28VMONB: 28V MONITOR - B (CCDM) CIUB15V: +15V IU B (CCDM) CIUB5V: +5V IU B (CCDM) CUSOB28V: +28V USO B (CCDM) All, except AOVAMPWR, were sent on 7/17. AOVAMPWR was triggered on 7/18. Followings are previously opened ones: AOMOMMON,AOPSAMUL, AWD3TQI, AWD1TQI,AWD4TQI,AWD2TQI,AWD5TQI,AWD6TQI AWD[1-6]TQI are always tripped when running SCS @107 while in normal pointing mode (Jeff Shirer jshirer@head-cfa). ******** Trending *********** AOSUNEC1,2,3 (UNIT VECTOR FROM THE SPACECRAFT x, y, z) completed the cycle as expected. There are several others msids showing similar cyclic trends, but not clear as these ones. ************* Telemetry *********** HKABIASLEAKI (HK A bias leakage current) of Ephin voltages shows repeatedly moved into yellow warning zone this week (14, 17, 19, and 20). The yellow warning range is 0.8-1.0, and the peaks are almost to the top. This always occurs during radiation passage *********** Photon Page ************ BSID DETECTOR GRATING TARGET ANALYSIS - --------------------------------------------------------- 701 ACIS-S HETG X0918-54 OK 5 ACIS-S HETG TWHYA SOME TG ANALYSIS FAILED (S/W) 716 ACIS-S HETG GX 5-1 OK 717 ACIS-S HETG GX 9+1 ANALYSIS MISSING 241 ACIS-S HETG NGC 4486 OK 1754 ACIS NONE LINEAR 1999 S4 OK 1753 ACIS NONE LINEAR 1999 S4 OK 1748 ACIS NONE LINEAR 1999 S4 OK 1749 ACIS NONE LINEAR 1999 S4 OK 584 ACIS-S NONE LINEAR 1999 S4 OK 1752 ACCS NONE LINEAR 1999 S4 OK 1751 ACIS NONE LINEAR 1999 S4 OK 1750 ACIS NONE LINEAR 1999 S4 OK 642 ACIS-I NONE NGC 1333 OK 1730 ACIS NONE M33 OK ******** Notes from experts *************** Pixel scale and coordinate offsets for individual ACIS chips - ------------------------------------------------------------- Maxim Markevitch http://icxc.harvard.edu/cal/platescale/acis_scales.html Summary: The measurements are done using the star cluster NGC 2516 and offset LMC X-1 observations. The LMC X-1 celestial coordinates have been measured from the two recent optical CCD exposures using the Tycho-2 reference stars, and are (84.911842, -69.743193) deg +-0.2". The ACIS observations were processed in May, after the known aspect errors (the 2" ACIS drift and some others) have been corrected. By now, the average aspect offset of each of the four detectors have been calibrated by numerous iterations (using the star cluster data), so that sources observed at the aim point have correct coordinates (to < 1"). What remains to be calibrated is the plate scale and possible offsets and rotation of the outlying chips relative to their currently assumed locations. The HRMA focal length in the fits file headers is 10061.62 mm and the ACIS pixel scale is 0.4920"/pixel (implying 24.00 micron pixels). The procedure consists of finding centroids of the X-ray sources in each chip and identifying them with stars from the cluster catalog. Then the predicted ACIS x,y (or sky) coordinates, calculated from the celestial coordinates and the WCS keywords in the ACIS fits headers, are compared to the observed x,y coordinates. A linear coordinate transformation (offsets along the detector X,Y axes, rotation and rescale factors along the two directions) was fitted to the coordinate differences by the least-squares method. Each star offset was weighted by N/r^2, where N is the number of photons from the star and r is the PSF width at its position. Success in reproducing ACIS bias/event interleave failure (OBSID 371) - --------------------------------------------------------------------- Peter Ford (pgf@space.mit.edu> I have succeeded in reproducing the ACIS anomaly that first occurred during OBSID 371 on June 26 and led to the loss of data from two CCDs during OBSIDs 371, 659, 861, 795, and the CTI/CAL run, 62011. (See the ACIS anomaly report at "http://acis.mit.edu/axaf/spr/prob0133.html"). Suspecting that the anomaly was caused by the run that preceded OBSID 371, I ran the ACIS engineering unit in a simulation of OBSID 62015 and OBSID 371, as we did in Chandra on June 26. The anomaly showed up on the 16th repetition of the pair. My simulation used the "standard" patch load with optional cc3x3 and event-histogram patches (aka release-B-opt-B with cc3x3+eventhist-B-B-B). The details of the engineering unit runs are in "~pgf/acis/regress/test.raw.bias/" on the CSR LAN. Recall that OBSID 62015 used a non-standard configuration: a bias-only run using a raw-mode parameter block. Jim Francis and I suspect that this left the flight software in an anomalous state that triggered the FEP failures in the subsequent OBSIDs and which was only corrected by power-cycling the FEPs on June 28th. Having reproduced the problem, Jim and I can (hopefully) track it down to its root cause--presumably a s/w error in the science and/or bias-trickle tasks within the ACIS BEP, perhaps confined to raw-mode, but we cannot be sure at this stage. We can, however, eliminate a random SEU as the cause. Since launch, we have executed a total of 26 raw-mode runs (24 TE, 2 CC). With a single data point from last night's test on the engineering unit: one failure in 16 raw-mode runs, I recommend that, until we understand the cause of the anomaly, we either perform a warm-boot after EVERY raw- mode science run, or power-cycle the FEPs after the run that follows that raw-mode run. Warm booting would be my choice when the raw-mode run is executed by CAP during a R/T contact. When executed from the daily load, it would be more conservative to power-cycle the FEPs rather than reboot the BEP, with the slight chance that one or more FEPs may lock-up during the run that immediately follows the raw-mode run.