From hudson@isass0.solar.isas.ac.jp Tue Jun 2 16:26:35 1998 Date: Wed, 20 May 1998 13:10:39 +0900 From: "Hugh S. Hudson" To: kosugi@laputa.mtk.nao.ac.jp, ogawara@flare2.solar.isas.ac.jp, sxt_co@isass0.solar.isas.ac.jp, tsuneta@sxt2.mtk.ioa.s.u-tokyo.ac.jp, watanabe@uvlab.mtk.nao.ac.jp Subject: Yohkoh routine re-pointing H. Hudson 20-May-98 Notes on Yohkoh offpoint procedures Lately we have gotten into something of a routine for Yohkoh re-pointing on behalf of the SXT terminator program. These notes explain how to use the software available as of mid-May, 1998. 1. General The objective currently is to maintain the Yohkoh "normal pointing" to as small an area as possible. The reason for this is to increase the density of Al.1 terminator images, both in space and in time, thereby to improve the stray-light corrections. In practice the size of this normal pointing zone cannot be smaller than the regular orbital drift motions, caused probably by thermal stresses on the spacecraft around the orbit. The annual variation would be much larger than this range, and there is also a slower (secular) variation that we need to follow. Other factors might affect decisions about pointing, but in practice have not done so recently. One factor is the number of HXT fiducial marks that may be covered. We ignore this now, but it may become an important consideration in the future as HXA limb-finding becomes more difficult with the ageing of the system. Another factor, also currrently ignored, is the build-up of CCD damage at the "standard" limb locations. 2. Monitoring the pointing There are two pieces of code in normal use. TERM_REVIEW shows the pattern of the terminator database (SFC) positions, but does not yet give a good illustration of the 3-D (x,y and t) pattern. The /comp switch compares these positions with those of the most recent SFDs. QUICKATT shows how well the HXA limb-finding is working by checking the appropriate quality flag in the ATT database as it develops. 3. Computing the new pointing This is a somewhat delicate business still because the software is not very good. Basically one determines an offset using TERM_REVIEW,/set, interactively - this again shows the SFC positions relative to the current pointing, and lets you point and click. The output is printed to screen as increments to the Euler angles X and Y, which are of course not the same thing as spacecraft x and y. These are defined in terms of spacecraft motion in the documentation header for POINT_HEX2. The normal pointing is defined by OG #032 (decimal). The name of this command is a unique identifier interpreted as the absolute (x,y) position with respect to the spacecraft pointing reference. This drifts, of course, so the "absolute" numbers really are just a name. However the differences in (x,y) between two consecutive names will be close to the angular increment, so this is another check on the plausibility of a new commanded location. With the offset increments established, one uses the IDL command POINT_HEX2,[a,b],/name to generate the hexadecimal command list. This program prints a simulated mainframe page, so that it can be compared almost directly with the mainframe OPOGEDT program. The routine is to run this program twice, first to match the Euler angles [a,b] with the current OG name. Then the increments in Euler angles obtained from TERM_REVIEW,/set can be entered and the final hexadecimal commands will appear. A future improvement of this 3. Changing the pointing This requires operation of the mainframe program OPOGEDT, which is a potentially dangerous task and should be left to an expert. OG #032 (decimal) must be updated according to the new commands generated in the IDL software. Then, the following steps: a) request an OP+OG upload from the tohbans b) request an ROG #032 (decimal) from the tohbans, at any time after the upload, but in daytime if possible so that the KSC tohbans can confirm the motion. It should always be small enough so that ARS won't be far off. It may not be perceptible unless they look closely. c) a pointing request e-mail should be sent to the KSC and SSOC tohbans, and to SXT_CO. The archive is on the directory /0p/sxt_co/terminator/pointing_request. d) the OG notebook at SSOC should be updated with a copy of the new OG, as printed following the OPOGEDT session. This print archive also archives the OG in yohkoh/opog. e) the pointing notebook at SSOC should be updated with a copy of the e-mail pointing request. Ordinary tohbans should not run OPOGEDT for OG editing. Please deal with a supertohban, Watanabe, Kosugi, or Hudson for this.