SXT Chief Observer's Handbook

Version 4.3 [Last Updated: December 27, 2000]

Table of Contents

1. Introduction

This handbook is designed to help newly trained Chief Observers (and possibly old hands) to carry out SXT Chief Observer duties and observations. It should be read with reference to the Red Book where descriptions of the SXT design and Yohkoh operations are given in detail. The Duty Checksheet (see Appendix) provides a shortlist of the normal duties of the Chief Observer as described herein, and indicates when such duties are generally performed. A copy of the Checksheet should be filled out for each week.

In general the SXT Chief Observer is one of the ``tohbans'' who operate Yohkoh. The Chief Observer job rotates among a list of persons whose names can be found in the isass0: /0p/sxt_co/.forward file. Because SXT is the most complicated instrument onboard Yohkoh, and because its command functions are incorporated into the spacecraft digital processor (DP), there is an intimate and sometimes cumbersome relationship between SXT commanding and spacecraft commanding. An SXT Chief Observer should be sure to make personal contact with each week's Yohkoh tohbans, both at SSOC (Sagamihara) and at KSC (Kagoshima) if necessary to be sure that there is adequate communication. Simply sending a fax is no guarantee that it will be read and understood except in the most routine of circumstances. Depending upon the tohban at KSC, a last-minute table name change or cancellation ought to be followed up by a telephone call.

The Chief Observer (CO) is responsible for the SXT, monitoring the data as they arrive and also the monitoring the health of the databases generated by SolarSoft.

The Chief Observer is also responsible for scientific decisions regarding the use of the telescope and the preparation of appropriate command uploads. This includes routine operations, such as the weekly sequence-table changes, and also infrequent ones such as bakeouts and eclipse planning. These operations are best understood by examining previous tables used for these purposes. During a campaign observing program the Chief Observer ensures that the SXT is in the appropriate mode and making the appropriate observations, and maintains regular contact with the campaign collaborators.

In general the first functions in a Chief Observer's day would be:

2. Monitoring the SXT Instrument and Data (All the Time!)

The Chief Observer needs to stay abreast of the operational status of the SXT. There exist sophisticated (and otherwise) software to assist with checking the data, and to monitor known specific operational and calibration items. This section addresses the most common of these procedures and issues with which the CO should be familiar (of course). More information can be found in the Yohkoh Analysis Guide, in the isass0: /ys/site/doc directory, and by perusing the ``Calibration'' menu of the show_pix IDL program.

Yohkoh dumps data to ground stations in Kagoshima (KSC) and elsewhere (the NASA network) many times per day. The KSC data is are available almost immediately (the delay for reformatting is usually about 45 minutes), and should be checked right away (or first thing in the morning if the KSC passes are very late at night). Both the full-frame and partial-frame images should be checked.

Examining SXT data for problems is something of an art, involving alertness and experience. The novice CO can make a good start by (1) becoming familiar with the issues raised in this section; (2) studying the hows and whys of SXT and Yohkoh operations (maybe with a turn at being an SSOC tohban!); and (3) looking at the data.

2.1 First_light and QUICK

The IDL program first_light shows current data useful for scientific planning, and its routine output is available on the Web. There is also a Web interface (QUICK) for quick checks of many of the data, software, and database functions described below - these pages emphasize the technical stuff. First_light produces a GOES plot of the previous day's activity together with KSC contact times for the current day. The GOES plot includes SAA passes and spacecraft night times together with an overlay of the times of Yohkoh PFI and FFI frames. The first_light program also runs pr_evn for some software specified period of the previous day, giving times for which Yohkoh data are available (here an event means a change between QUIET and FLARE modes or where there is a data gap). The number of available images is printed out together with a list of FFI's (noting where there are gaps in the data) and the number of unique pointings. These pointings are shown superimposed on SXT images which also contain a NOAA grid with active regions identified.

The first_light procedure gives a lot of useful information in addition to that noted in the preceding paragraph. The first and last times contained in the index structure is displayed (fmt_timer). The comment lines of the last upload table are shown and its stored address given. (Be warned that this does not always provide the correct information; see the comments about the indirect table archive system in the ``SXT Table Loading: General'' section). In addition, a statement of the thin Al flux detected and a comment on the solar activity is also displayed. The number of unique pointings is given along with corresponding heliocentric locations, mispoint information, any SAA passages and any spacecraft night time encountered.

Even nicer, first_light also obtains the last available ground-based observatory images of the following types: Kitt Peak Magnetogram, Kitt Peak He 10830, Big Bear H-alpha and Nobeyama Radioheliograph. These are displayed together with the last SFD image in the same window. These images, in principle, allows the Chief Observer to examine the latest solar observations over a range of wavelengths and to make SXT observation decisions based on this data. The actual contents of the image page have varied in the past depending upon what is wanted, and it is easy to make substitutions from the GBO database.

In general, first_light and quick provide convenient guides to what is going on scientifically and technically, and the Chief Observers should ask for changes, or just make them, if they want something different.

Sample calls

2.2 Check Temporary KSC Reformatted Database

After a KSC pass, the downlinked data move automatically from KSC to ISAS, to be lodged in the SIRIUS database system, thence copied into the workstation system and reformatted by auto_toban in IDL. All of this should take no more than about 45 minutes. The Unix script tail_auto monitors all of the steps, and frequently shows problems. The tohbans should understand how to read the tail_auto logs and be prepared to report problems. An even more direct way to see if things are going OK is just to look at $DIR_SITE_NEWDATA and see if the new data have arrived via all the transfers and reformatting machinery. It should take about 45 minutes total, from telemetry to on-line. The SXT CO should identify any problem and report it to software@isass0 so that automatic reformatting resumes as quickly as possible. In order to do this, the SXT CO needs to understand how the temporary data are created. There are a few steps involved as described below. In addition, the SXT CO is encouraged to review the documentation isass0:/ys/site/doc/auto_toban.doc.

After each KSC pass, a daemon recognizes the arrival of the new SIRIUS data and reports its presence to a file (/ys/site/logs/srspas.new) accessible on workstations. On isass5 a cron job auto_toban2 runs every 10 minutes. When it finds the new SIRIUS data in srspas.new, it starts the job called go_toban, which first transfers the SIRIUS data to the flare1 staging disk (/flare1_raw_tlm_mount/v1/yymm) with the UNIX script srsget (on flare1) and then reformats the data to be written to the usual $DIR_SITE_NEWDATA directory. Note that there is an alternate backup directory in case of problems with the /yd3 disk, so if tail_auto shows that things are going well but you can't find data, try looking in $DIR_SITE_NEWDATA2. The NEWDATA directory must be filled up before the NEWDATA2 one gets used.

One way of isolating a problem is to check the log file of auto_toban2. This can be done by issuing the command tail_auto at a UNIX prompt. It lists the last 30 lines of the /ys/site/logs/auto_toban2.log file, which is normally updated every ten minutes. In a normal case, they look like:

 2-May-2000 21:40:13.00  NNW: No new data since  2-May-2000 20:20:13.00 
(   9 checks)
 2-May-2000 21:50:10.00  NEW: ---- Total of           2 new uniq files 
covering     98121.0 records
 2-May-2000 21:50:10.00  NEW:      SA229 0005020800 00/05/02 11:21:04 
12:08:46 072962
 2-May-2000 21:50:10.00  NEW:      SA228 0005020800 00/05/02 12:07:36 
12:20:43 025159
 2-May-2000 21:50:10.00  REF: GO_TOBAN to run from  2-MAY-00  11:21:04 to  
2-MAY-00  12:21:43 (   1.0108333 hours)
 2-May-2000 22:01:06.00  RFS: SRSGET/REF took:    5.57 min, and OBS, EVN, 
PNT SFD, and SL stages took: 5.32 min
 3-May-2000 14:00:12.00  NNW: No new data since  2-May-2000 22:10:21.00 (  
96 checks)

Note that the SIRIUS machine is often (but not always) turned off on Sundays. This can result in tail_auto showing the ``ERR: SRSPAS_RUN" error repeatedly. The machine is reliably turned back on Monday morning, according to a schedule listed in a weekly (Japanese-language) e-mail notification. Netscape can display these for you.

Sample calls

2.3 Check Recent KSC Raw Data

Once you have ascertained that the reformatted data are available, they should be examined. Here we try to give an idea of what to do.

2.4 Patrol Images

The patrol images are vital to SXT operation, since without their correct use severe overexposure and damage could result. In general a new dump of the patrol image buffer is available each time a new table is uploaded. See the detailed instructions given in the ``Planning Observations: Patrol Images'' section.

Tip

2.5 Dark Current

Dark current arises in the data due to the physics of the CCD. This effect, but not its fluctuation, can be corrected for by subtracting ``dark frames''. The Chief Observer is responsible for uploading a special Dark Calibration table once a week, and for keeping an eye on the long term dark frame database to uncover any anomalies.

Sample calls

2.6 Stray Light

The SXT suffers from a problem of stray light entering the telescope and creating a general background on the CCD. This stray light (visible wavelengths, not X-rays) gets into the telescope tube because of the damage to the entrance filter and reaches the CCD around the filters. The results are especially bad for the thin Aluminum (Al.1) filter, because it is so thin it actually has tiny pinholes. Stray light impinges through these upon the CCD directly. The effects of stray light on SXT images can be subtracted reasonably well, since the fluctuation in the image is not too large, except for Al.1. The effects of stray light on the SXT images can be seen in the ``Calibration'' directory of show_pix.

Calibration for the effects of stray light on the SXT CCD requires taking ``terminator'' frames, so named because they are taken as Yohkoh passes into S/C night. These are discussed in more detail in the ``Planning Observations: Terminators'' section of this Handbook.

The Chief Observer should occasionally (i.e. weekly) check the stray light behavior using plot_sls. This plots the SXT scattered light engineering data (which are obtained from the dark frames entered in positions 2-1 and 2-2 of FFI Table #2). Since the leak after the 17-Nov-92 entrance filter failure is intense enough to show signal at the CCD even with the CCD closed, we use these data to monitor the size of the unwanted aperture in the entrance filter.

Tips

2.7 Monitoring Attitude Control

The HXT Aspect Sensor (HXA) is used to calibrate the attitude (ATT) database. As this instrument ages, the apparent diameter of the Sun changes, possibly affecting the ATT data. A good idea is to make a cursory check of the ATT data after each day's passes by using get_att. The tag att.status1 it returns should nominally have the value 8. If most of the samples don't have this value, the experts need to be notified. Notify them via software@isass0, realizing that one of us (Jean-Pierre Wuelser) is the real authority.

Sample calls

2.8 Adjust the Yohkoh Normal Pointing

On behalf of SXT, the CO is in charge of Yohkoh re-pointing. The objective is to maintain Sun-center coordinates with as little scatter as possible, in order to increase the density of Al.1 terminator images (both in space and in time). This should 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 may need to follow. As of 2-Jul-99 we have adopted a new target pointing that attempts to steer the limb of the Sun away from the positions of greatest dark-current problems.

To monitor the pointing, use the program term_review. Its output routinely appears on the QUICK Web pages, so it does not actually have to be run manually. When used with the /comp switch, this plots the positions of images in the SFC data base (marked diamonds) and the most recent SFD images (marked by asterisks). Ideally, this ``shot pattern" should be very tight; if the recent SFDs are at one extreme of the grouping, it may be time for an adjustment to the normal pointing. A good criterion for this would be a displacement of four FR pixels or so. Normally the largest drift is NS.

As of November, 1999, new software is available for adjusting the normal pointing. From the sxt_co account, idl directory, run new_normal_point (no arguments!). This program computes the repoint necessary to bring the Sun center position (judged from the 20 most recent SFD images) to the target position (see the QUICK page for its pixel values). The program writes a file to the archive ~sxt_co/terminator/pointing_request, and this file should be e-mailed to alias "point" from the sxt_co account. In addition please fax it to the tohbans and confirm that they can and will implement the new OG - only certain persons, listed in the fax, should edit the OG.

Tip

2.9 Streak Artifacts (``Glitches'')

This phenomenon manifests itself as three or four bright pixel columns on the CCD, coming from a limb region. A streak is easily observed in the full-frame images, especially in short exposures or in dark frames. Previous instances (see 12-Dec-96 for an example) have demonstrated a half-life of about a day. A high open-shutter time fraction (> 15%) can cause a glitch, so be wary of exposure-intensive campaign requests.

The appearance of a glitch certainly results from overexposure of sensitive pixels at the limb. This has occurred when the following three criteria were met:

To look for these faint features, use yodat to select some recent short-exposure dark FFIs (several DPE=2 quarter-res dark FFIs are made each week, as of jun-98). Then view them with enhanced contrast, via:

2.10 The South Atlantic Anomaly (SAA)

The Earth's magnetic dipole field is not strictly geocentric. This results in an area over the South Atlantic ocean where the radiation belts dip down, and this produces observable effects in SXT images and performance. Images taken during SAA often contain particle tracks from proton hits. These are mostly in small groups of pixels because the CCD is so thin. There is also a general background glow level, so that dark corrections become more difficult.

The SXT Chief Observer should bear in mind that Yohkoh's high energy sensors are switched off during SAA passage. One consequence of this is that FLARE mode cannot be triggered, and the SXT CCD is at risk of having to deal with a high intensity X-ray flare with quiet rate tables.

2.11 How to Obtain and Use Other Yohkoh Diagnostic Data

The Yohkoh software suite is large, and provides for many different ways to cross-check the data and the operation of the satellite. In this section we mention diagnostic methods that might be useful in certain circumstances, or if the CO is just looking for more information.

2.12 How to Obtain and Use Non-Yohkoh Data for SXT Operation

We have many databases available via automatic ftp transfer, covering most of the bases for science operations. Many of these GBO data (Ground-Based Observatories, which incidentally includes GRO/BATSE flare data) are in weekly files. GOES is a special case. For access to the weekly files, rd_xda works fine, or even simpler is the function get1gbo, which has as one argument a file specifier (e.g. ``gkm'' for Ground-based Kittpeak Magnetogram; see help_prefix for a full list). GOES data come from rd_gxd, plot_goes, and goes_tek in order of simpler interfaces. Much of what any CO needs is shown on the first_light panel, and if it isn't, we should probably put it there.

2.13 Reformatting recent data

On occasion there's a need to check for recent data and run special reformatting. Data from the NASA groundstations normally undergo final reformatting about once a week or when a full week is in. This isn't always quick enough for impatient chief observers, so the following process is an end-run around this process. This gives a head start on campaign observations or special phenomena, such as that X30 flare. There are three steps to this process. First, look in /f2p/com/yohkoh/wallops for the appropriate DSN file, e.g. "solass.w13.5". The last digit is a version number when passes are added or canceled, you want the one with the highest number. In this file, one sees lines of stuff that look like:

*-------------------------------------------------------------------------------

*DAY START BOT EOT  END   FACILITY USER   ACTIVITY          PASS   CONFIG/ 
WRK
*                                                           NO.    SOE     
CAT
*-------------------------------------------------------------------------------

*----------
*WED 22 Mar
*----------
 082 1405 1430 1440 1450  DSS-76   SOL    R, TKG PASS       6376  xxxxxx- 
xxx
 082 1545 1610 1623 1633  DSS-76   SOL    R, TKG PASS       6377  xxxxxx- 
xxx
 082 1727 1752 1806 1816  DSS-76   SOL    R, TKG PASS       6378  xxxxxx- 
xxx

Next, there are two steps in the process: first, log onto the mainframe as usual, and call up the program TO INF. This is menu-driven and lets you (tediously) search in the separate directories for the ground-stations, to see what data have arrived and are available. Using the information from the DSN file, we go right to the correct directory from the first menu. Enter some start and stop times in the selection window to see what files are available. For Wallops the data arrival time is usually the afternoon after it's taken, weekends excepted, but DSN stations may take longer. Next, armed with the time range of data available, one runs the following:

IDL > go_go_toban, t1, t2

(from isass0 or isass1 only, and only as user SXT_CO), where t1 and t2 are start and stop times. This launches a batch job, perhaps on flare20, and eventually the data will appear in their proper place on $DIR_SITE_NEWDATA.

Tips

3. Planning Observations

Routine observing with SXT is a relatively simple task in terms of preparing a weekly plan and making the upload tables. However, special operations, such as campaigns or eclipses, normally require much more work and more careful planning and checking of the SXT table uploads. Some general points to bear in mind are discussed here.

We begin by covering some of the tasks necessary for planning in advance, and progress to technical aspects of preparing a set of sequence tables for uploading. The next chapter shows how to run the program sxtspt one uses to generate the mainframe files containing for the sequence tables.

3.1 The Weekly Visible Diagram

The Weekly Visible Diagram (WVD) is a graphical display of the week's KSC passes, and is used by the tohbans and the Yohkoh Chief Observers. After the Orbital Elements arrive (usually on Wednesday), the SSOC tohbans in B-toh will prepare the Weekly Visible Diagram for the upcoming week and fax a copy to D-toh. The KSC passes to be kept or deleted are determined and marked for the CO by the SSOC tohbans. The SXT CO should attach the original fax to the magnetic clip located on the exit door from the D-toh ``small room''. Make a xerographic copy to work with and use as a reference; even though it's hard to read it is sometimes more convenient than pr_visible or show_contacts.

The WVD will have five consecutive passes outlined for each day. A daily set of five passes may "rollover" to the next UT day. A number (zero to four) of the passes in a daily set may be crossed out, indicating that they are not available for Yohkoh's use. Theoretically, the SXT CO can ask for deleted passes to be given back to Yohkoh if the health of the SXT is seriously threatened, but this should be a ``last resort'' measure. In practice, any potentially dangerous situation for the SXT should be discussed with more knowledgeable people, starting with the SXT "supertoban" group. (The "supertoban" position rotates among J-side people who are responsible for the SXT software in the Yohkoh DP; contact them via e-mail to sxt_st@flare2). Pass deletions are negotiated over several weeks, and should not be tinkered with by the time they reach the SXT CO. One day (typically Sunday) will be marked as a Yohkoh Holiday, and will not have a set of passes boxed At the time of record, we're getting two contact passes on holidays from the new KSC 34-m dish. These are downlink only and thus can't be used for SXT sequence-table uploads.

The preparation of the WVD is the responsibility of the SSOC tohbans, and not that of the SXT CO. However, there are certain things one can expect to see on the WVD, and it behooves the SXT CO to understand the reasons for any significant deviations from these. Questions should be directed to the SSOC tohbans (yohkoh@flare1 and/or telephone).

Tips

3.2 The SXT Table Plan

Once the Weekly Visible Diagram has arrived via fax from B-toh, and the mk_visible and pr_visible routines have been used to create a list of the Yohkoh KSC contacts, the Chief Observer needs to formulate the SXT Table Plan for the upcoming week. This item is a weekly schedule of the SXT Table IDs that the CO intends to upload, and is part of the report that the CO presents each Monday at the Weekly Operations Meeting (WOM). Previous WOM Reports with SXT Table Plans can be found in the isass0: ~sxt_co/wom_rep directory. These should be referred to for examples and as templates.

The plan should include all anticipated table loads, with their correct names and times, and ideally should be available the Friday before the week being planned in order to allow the SSOC tohbans to do their job properly, i.e. the CO should email the SSOC tohbans on Thursday or Friday to notify them of the SXT Table Plan for the upcoming week, or at least the plan for Monday's table loads. Every table upload requires manual editing by the SSOC tohbans of the daily command sheets (the fundamental fax mechanism by which the SSOC tohbans and the KSC tohbans exchange lists of real-time commands for Yohkoh). Thus advance warning of a table upload is essential, and the nominal minimum time for this advance warning is 24 hours.

The weekly Table Plan will normally incorporate routine tables, which might include the following:

Each Monday morning at the Weekly Operations Meeting the Chief Observer presents a report based on the previous week's operations and observations together with the Table Plan for the upcoming week. The SSOC tohbans will use this version of the Table Plan to plan their own operations during the week, although they must wait for day-by-day confirmation of the SXT Table uploads from the SXT Chief Observer. Even though it is OK (and sometimes unavoidable) for the SXT CO to modify the Table Plan as the week goes on, it is best to give the SSOC tohbans as much advance notice of changes to the plan as possible.

Previous tables can be reviewed for hints/reminders/clever techniques. See the section on ``Viewing Previous Tables" in Chapter 4.

Tips

3.3 Coordination with Other Instruments

The SXT Chief Observer is responsible for coordinating SXT observations with other instruments, whether for planned campaigns or for informal overlapping coverage of the Sun. (e.g. recently, SXT PFI targets have been coordinated with SOHO/CDS targets during routine observing.) This job includes SXT table construction, handling email communication, and sending reports. Here we describe things useful to planning observations with other instruments.

When using ground based data, such as H-alpha or He 10830 data, to plan coordinated observations, such as filament campaigns, a useful routine is gbo_obs_coord. This accesses the latest available GBO image of your choice, scales it to the last SFD image available and then allows you to select coordinates, via sxt_obs_coord.

Coordination with SOHO and TRACE is made simpler by the fact that those observatories have put their plans --- including pointing information --- on the web, and also send e-mail notifications that sxt_co receives. SOHO and TRACE targeting coordinates can be found at the URL:

Sample calls

3.4 ARS1

The SXT instrument has two Automatic Region Selection (ARS) modes that allow the PFI targeting to be updated according to onboard algorithms. There is also the option of turning ARS off (informally called "ARS0", which corresponds to disabling ARS). The ARS mode is selected in the sxtspt program on the COMMON page.

ARS1 is the standard mode of operation. A morning patrol image is taken and the brightest active region chosen as the PFI target. The four brightest locations found by the on-board ARS software are listed in the ARS entries of the ROI table. This is superseded by the triggering of a flare flag or by a quiet patrol image, which will occur at a programmable interval. The normal observing region is 2X2, or 128x128 full-res pixels.

See the program ars_show for a simulation of this SXT observation mode.

See the section on ``COMMON Table" in Chapter 4, for the proper settings to set up ARS1.

See the section on ``OBSERVING REGION (ROI) Table" in Chapter 4, for more information about selecting the OR for PFIs.

Note that the patrol image is a half-height FFI, and there is a distinct possibility that the brightest region will not occur within the search region. To guard against this the KSC tohbans have standing instructions to dump a patrol image each time the table changes. To see this dumped image in the reformatted data, select the -776 option in yodat, where it will appear by itself in a line below the first normal sequence of exposures (the 1-1). The information reported in the index for this file will be trash. There is software to manipulate these images, but the main thing is to be sure that the brightest region is in the field of view - otherwise the AEC (Automatic Exposure Control) could get way, way off.

Tip

3.5 ARS2

If ARS2 is chosen then the location of the PFI observing region must be set by the Chief Observer on the ROI page of sxtspt. This is different from fixed pointing in that the center of the PFI is occasionally updated to the brightest pixel. Consequently, there will be some movement of the PFI with each patrol image. This mode is useful when one wishes to track a bright region over a time period for which the solar rotation is significant, to the exclusion of jumps to other (brighter) active regions in response to ARS analysis of the patrol images.

See the section on ``COMMON Table" in Chapter 4, for the proper settings to set up ARS2.

See the section on ``OBSERVING REGION (ROI) Table" in Chapter 4, for more information about selecting the OR for PFIs. ARS2 may use any of the ROIs designated for ARS, namely 0-3.

Refer to the section on ``Fixed Pointing'' to learn how to use sxt_obs_coord to select target locations.

Tips

3.6 Fixed Pointing (``ARS0'')

Many special observations require fixed pointing (usually designated ARS0) at a particular location on the solar disk. This operation is carried out by use of the OR Table (ROI page of sxtspt). In order to choose the correct location one should use the program sxt_obs_coord. This allows one to obtain the coordinates of the chosen target at the time of the observation from an earlier SXT image (which is most easily obtained with lastsfd). The location of the center of the OR is given in CCD coordinates as well as heliographic coordinates. It is the CCD coordinates which are entered in the OR Table but in the SXT table fax to the tohbans, both sets of coordinates should be included.

Note: the CCD coordinates used by Yohkoh on-board software and mainframe computer programs differ from ordinary coordinates. They are centered at the SW corner of the CCD and are in Q resolution, i.e. 256x256 increasing from W to E and from S to N.

The number of the OR table used for the fixed pointing should be entered in the appropriate column of the corresponding PFI Table. Although any of the nine ORs can be used for ARS0, it has been the convention to use OR table number 4 for fixed pointing observations. This means that an ART table entry is used. However, no DC command to initialize the ART function is included on the SSOC tohban Pass sheets.

Fixed pointing also requires the disabling of the ARS mode. This is done in the COMMON Table of sxtspt.

Tips

3.7 ART

The ART function is a particularly useful mode of operation when offpointing is planned. The observing region is chosen by the Chief Observer and the coordinates (see ``Fixed Pointing'') are inserted in one of OBN #4--7 in the ROI Table. The PFI frames will then target those coordinates and remain there until a new table is uploaded. The ART function allows the OR to be tracked even when the spacecraft is offpointed, using the gyros (IRU) as a reference.

When using ART it is important to ensure that the following is done:

3.8 Filters

The control of the SXT filters is important since this provides the diagnostic capability of the SXT for temperatures and emission measures. SXT has two filter wheels. Filter wheel A has several filters which are used for calibration and maintenance purposes, as well as two filters for the now-defunct optical aspect telescope. For most X-ray images, the ``Open'' setting is used. There is a neutral-density X-ray filter (a mesh) with approximately 10% transmission, used to increase the dynamic range. A quartz filter allows UV into the CCD for annealing; a diffuser provides smooth irradiation to allow for flat-field checks.

Filter wheel B hosts the five "analysis filters". See the SXT_CO daily checklist or print, gt_filtb(indgen(6),/str) for a list of filter numbers and names.

Tips

3.9 Exposure Control and AEC

The control of the exposure times is also very important and should be carefully tailored to the observations required. If the Automatic Exposure Control (AEC) is enabled, the PFI exposures are adjusted automatically for each table entry, based on the flux within the OR selected for that entry. The maximum allowable exposure can be set by the appropriate entry in the AECH0 slot of the COMMON table. The same value of AECH0 applies to all entries for which AEC is set. Fixed exposures are obtained by disabling AEC in the PFI Tables.

Because of Yohkoh's DP limitations, the AEC works only on the PFI signals themselves. However, a PFI frame exposes the CCD to the whole Sun, not just the target region. Thus the CCD is unprotected by the AEC against excess exposure resulting from a source on some other part of the Sun, unless it is bright enough to trigger flare mode. Not only can overexposure damage pixels of the CCD, but a charge saturation can ``bleed back'' over an image as the serial register is shifted, resulting in an unusable image. There is a commandable guardband which can be used to minimize this problem. For long PFI exposures it is necessary to set the guardband to maximum. Otherwise, charge build-up in the serial register from the fast transfer to get to the PFI will bleed back into the PFI.

The guardband can be set for each PFI frame separately in the sxtspt program. On the right-hand page of each PFI table is a column named ``FLS'' where one sets flush count, of the form ``#/#/#''. The guardband is the first of the three entries, and the number indicates units of 4 CCD rows (or use ``F'' for Full). Fast transfer of the serial register allows one to quickly bypass irrelevant data to reach the ROI, but also allows charge buildup in the register. The guardband is the set of rows immediately preceding the ROI, which are exempted from the fast-transfer, so the charge buildup will be able to drain. The second and third numbers in ``#/#/#'' set the number of full-frame flushes to be carried out prior to making the exposure. The purpose is to clear out dark current which may have accumulated since the last exposure. This dark current can be significant if the cadence is low (e.g., due to long exposures, or larger-than-usual PFIs).

The AEC needs a few exposures to evaluate its adjustments. A PFI sequence table should have a minimum of three entries, otherwise the AEC will be subject to instabilities. On the other hand, a long sequence table (e.g. long exposures, lots of sub-loops) means a slow response time ...

Tips

3.10 Offpoints

Occasionally, it is necessary and/or desirable to offpoint the spacecraft, say to look at polar coronal holes, to obtain images of the extended corona, or to observe one of those rare but beautiful transits of Venus. Offpoints can be inserted manually by the SSOC tohbans but it is preferable to edit the OP command table because this is more general (i.e., allows one to control the spacecraft during the ``invisible orbits''). If an offpoint is required this information should be conveyed to the SSOC tohbans with clear instructions for them to follow. This is done rarely enough nowadays so that the instructions need to be re-invented by one of the veterans (a Super Tohban, Watanabe, or Hudson usually). Until this procedure is codified, the CO must consult with one of these veterans.

Normal offpoints, for which an OG exists or has existed and is on record, include a 4 arcmin North offpoint, an 8 and 16 arcmin South offpoint, an 8 arcmin West offpoint, an 8 arcmin East offpoint, a 4 arcmin NE offpoint, an 8 arcmin SE and an 8 arcmin SW offpoint. These are absolute pointings from the spacecraft reference coordinates (which drift slightly on various time scales; see show_pix) so if you follow an 8 arcmin South offpoint with an 8 arcmin East offpoint the spacecraft will point 8 arcmin to the East. It is possible to do fixed PFI pointing while carrying out an offpoint. If this is required then the appropriate number of CCD pixels should be added to or subtracted from the target coordinates to allow for the new ``center'' of the field-of-view, unless the ART function is selected.

New OG's for new offpoints can be created at will using the software in the isass0: /0p/sxt_co/terminator/analysis directory. In each case, however, the new OG must be presented to somebody (often Hudson) who knows how to operate the mainframe program SAOCS and the OG editor and how to update the files in B-toh. The new OG's must then be uploaded with the daily OP whenever possible.

Tip

3.11 Use of Parts of the CCD

One technique which is useful if one requires faster cadence of FFI images of a given resolution is to use only a portion of the CCD. Using half of the CCD, for instance, effectively doubles the FFI cadence. This can be particularly useful when making full resolution coronal hole observations or doing transits of Venus or Mercury. To choose a part of the CCD is a simple matter of entering the correct CCD coordinates (starting row and OR "width", which means ``height'') in the second page of the appropriate FFI table (reached by |PF11|).

3.12 Dark Frames

Generally, one should always use the Dagwood sandwich filter (AlMg) for the taking of dark frames. The filter itself makes no difference with the shutter closed (dark) but the AlMg has been shown to be sufficiently good in terms of reducing the small amount of stray light which gets around the shutter. For special observations, such as in an X-ray bright point campaign, it is sometimes useful to take PFI dark frames. This is really only useful if one requires fixed exposure, fixed pointing images. In this case, the dark frames can be matched in exposure to the PFIs and can thus be used to improve statistics or to follow time variations of the dark signal (yes, these happen and are nominally corrected within sxt_prep). One should be careful to note that under ARS2 observations there will be some movement of the PFI with each patrol image and under these conditions PFI dark frames are not useful enough to merit the interruption of the PFI observations. The standard FFI dark frames are quite good except perhaps for very faint features.

3.13 Diffuser Frames

These are taken on a weekly basis to monitor the CCD condition. They are filter pair B/A = 1/4, and the exposures are DPE=2 (very short because of the entrance-filter ruptures). One is in normal compressed mode (the C of HC1N), and the other is in ``low-8'' mode (HL1N). The latter mode telemeters just the least significant bits. The two images can be put together with restore_low8, which produces a single image with spectacular and hard-to-view dynamic range.

3.14 Terminators

The terminator images (1-1 in the FFI Qt/Hi table) are used to correct SXT images for straylight and for background subtraction. The terminator database needs to cover all of the analysis filter combinations, and should cover the regions of the offpoint coordinates for which there are data. Hence, the Chief Observer should frequently change the FFI Qt/Hi 1-1 entry to make sure that the terminator program is proceeding efficiently. The main problem is that the Yohkoh spacecraft pointing, while extremely stable, does drift a bit with time. The drifts are on orbital, seasonal, and secular time scales. The SXT stray light in depends quite sensitively on the actual spacecraft pointing, so a relatively dense array of terminator images is needed for proper corrections. This applies mainly to the Al.1 filter, so a good practice is to change the terminator filter setting every upload, and to make every other filter change go back to the Al.1 setting.

A terminator opportunity is normally taken at each day/night transition of the spacecraft for which op_first_guess feels that the conditions are right - high-rate telemetry, no SAA, etc.; the image is the 1-1 entry in the SXT exposure sequence table and comes at the time of the SXT CNTL AT command which restarts the SXT sequence tables at the beginning, and is normally an OG in the OP program table. The op_first_guess software normally selects all available opportunities. The SSOC tohbans may remove terminator opportunities at their discretion, if the OP is too long and would overfill the 128-command buffer. The weekend OP is often full, so op_first_guess does not schedule terminator images then in order to save space. We use the program op_term_score to follow the incremental growth of the SFC database following successful acquisition of terminator images. This program requires a time range, normally just the beginning time; this is the current epoch for aperture-filter damage or normal-pointing target. At the time of writing this start time is "11-Feb-00", on which date the normal pointing was adjusted to its current location (see the fids.html plot for a graphic overview of the normal pointing positions).

Under special circumstances a terminator image can be explicitly scheduled at a given offpoint location. This will involve an offpoint/normal-point command pair. These two additional commands need to be edited into the OP by the SSOC tohbans, so this calls for detailed exchange of information between the Chief Observer and the tohbans. This would be done to cover the region near a given offpoint location, and is not to be undertaken lightly because many opportunities must be scheduled before a good sampling of the terminator can be obtained. When doing this the CO should refer to a specific OG number and terminator opportunity when requesting an offpoint, on the SXT table fax, and should follow up directly with the SSOC tohbans.

Each terminator image is incorporated into the SFT archive. From this, the mk_sfc software screens out the unwanted data and does the final preparation of an SFC image, which is the one used by leak_sub. The criteria include time, pointing offset, and exposure time (DPE), and are listed in a file called by mk_sfc --- you can see the input file by entering:

Tips

3.15 Patrol Images

The KSC tohbans now (7/25/97) routinely dump an SXT patrol image at every table change. The archive of patrol images can be accessed by the Chief Observer using yodat (see below). The index file is not correct, but by using

To check the patrol images look for FFI's with a sequence number of zero. For example, if you read in an SFR file with yodat, the patrol images can be accessed as

The north-south extent (width, R1W in the SXT COMMON table) of the patrol image is hard-wired to 127 macro pixels and this value should not be changed. However, the patrol image can be shifted north or south. When high-latitude activity is present the patrol image should be shifted to include the activity. The nominal starting row number is 72 (R1S in the SXT COMMON table). A larger number moves the patrol image to the north and a smaller number moves the patrol image to the south. CAUTION: StartRow + Width < 255, so the start row should not exceed 128.

Tips

3.16 CCD Bakeouts

As time passes, the SXT CCD slowly accrues contaminants (believed to be mostly water ice). The solution to this is to occasionally let the CCD warm up to +20 degrees Celsius for approximately a day. Ideally, this operation should be performed once every three months or so. One can refer to previous bakeouts to see how to set up the tables. To find the times of these, try:

Sample calls

Sample of the OG command sequence (case of Dec-00):

3.17 PFI-Dominant Observations

The memory allocated to SXT consists of two buffer arrays, one 4 times as large as the other. We normally use the larger one for FFIs (``FFI Dominant'') but they can be switched in ``PFI Dominant'' mode. This happens in flare mode in any case and results in a 2-sec cadence for 1x1 ORs. This mode should be employed judiciously, since it quadruples the wear and tear on the mechanisms. The common page in SXTSPT contains an FFI/PFI switch, normally in the FFI position.

4. SXT Table Loading (SXTSPT)

4.1 General

The operation of the SXT is controlled by preparing SXT Tables with a mainframe program named sxtspt, and uploading these tables during a KSC pass. Unlike the satellite OP tables, which are linear and specify commands at certain absolute times, the SXT Tables consist of infinitely looping sequences (each with specifications of exposure time, filter selection, etc.) and thus will continue to run until manually interrupted or replaced with another set of tables.

The SXT observing sequence tables are created and archived in the ISAS mainframe computers, transferred to KSC, and implemented on board in the DP software. The responsibility for this system is on the ``J'' side of the fence, and there is a rotating ``super-tohban'' to whom detailed questions should go. This person is identified in the weekly report of the Yohkoh operations meeting and can be reached via e-mail as sxt_st@flare2.

The reliance on the mainframe computer (SSOC #1, manager is K. Shuto of ISAS) causes many headaches. The operating system, on the IBM EBCDIC pattern (true fact), is archaic and baffling to foreigners and also to most younger Japanese. The normal operation of the SSOC #1 used to be done from B-toh via a G-150 terminal, which is actually a sort of workstation, and now can also be done via an emulator running on a PC in D-toh. The instructions in Using the FACOM Mainframe refer to direct access to a G-150 terminal. As of 1996, there has been a usable interface to our ordinary workstation displays via telnet, so that the table creation can be done much more conveniently. This is described under ``Using Telnet via flare20''.

After creation, the upload table must be transferred to KSC. This operation can be done directly by the SXT CO, or remotely by the KSC tohbans. The important thing to remember here is that only one SXT upload table at a time can be waiting in the mainframe ``queue'' at KSC for upload. Here is a simple algorithm:

4.1.1 Viewing Previous Tables

Table information is not a part of the regular telemetry stream from Yohkoh and therefore does not appear in the reformatted data directly. Instead a system of table numbering and updates exists, and there are databases in the Yohkoh system under the $DIR_SXT_TABLES and $DIR_SXT_ATABLES directories for binary and ASCII versions, respectively. These are updated automatically whenever a table write/read command uplink occurs, but this indirect archive system occasionally has a problem, so watch out for mysterious effects, especially in the real-time (KSC dump) data.

The gtab_xxxx routines print these tables to an IDL session, albeit in a slightly modified format, and can be called by index structure, time, or table number. You can grep from Unix directly on the ASCII table files to guide yourself to a reference table.

Sample calls

4.2 Using the FACOM Mainframe

As of the beginning of this millenium, the backup access to the mainframe (other than the emulator on the Unix machines) is an emulator on the PC in the "small room" of D-toh. It is located in the SW corner and has a Japanese-language operating system. The icon for the emulator is labeled GS8300 EISEI, where EISEI is written in Kanji. This replaces the G-150 terminal which used to be in the "big room", but there is still one of those in B-toh.

The entire process of working at the terminal directly is complicated by the obsolescence of the interface and the fact that many messages and the keyboard are in Japanese. The COs now regularly use a telnet session, but the interface merely emulates (not perfectly) the mainframe original. Thus, the explanation of using sxtspt on the mainframe directly is given in this section, and one can refer to the Using Telnet via Flare20 section for procedural modifications.

4.2.1 Logging On and Off

The emulator program should come up directly when the icon is clicked. At the READY prompt, you should type logon tss sr0001 and proceed as below. 1. For USERID type sr0001 |ENTER|. 2. For PASSWD type ******** |ENTER|. 3. Type ex sxtspt |ENTER| at the command prompt --- this runs the table software sxtspt and brings up its main menu. If this does not work, type prof pre(ql) |ENTER| and try again.

4.2.2 Basic Procedures and General Notes

SXTSPT works with a set of menus, each one of which may be edited by inserting characters at the right places (found by the |TAB| key or prior knowledge) and pressing |ENTER| to save the changes to the pages. It is possible to forget to press |ENTER| before passing along to the next menu page, so a useful tip is to do your entry in lower-case characters. These will be adjusted to upper-case when |ENTER| is pressed, and then the menu will look right.

The menu population includes various administrative tables and displays of the actual command sequence tables that control the SXT exposures. First we list some commands that apply throughout sxtspt.

The upload table menus are at the same hierarchical level, i.e. one can cycle through these menus, and enter or leave the loop from any member page. Use of the |PF3| key on any of these pages will remove you from the loop and keep the changes to all of the pages that you have saved with |ENTER|. Here are a few more movement keys for use with these menus.

4.2.3 MAIN MENU Page

On this page one typically only uses options 1 and 2. Option 3 is seldom used, and option 4 never is.

4.2.4 TABLE DATA DISPLAY Page

The entries to this page and the next are dependent upon the context within which the CO wishes to work on an SXT upload table. There are three main possibilities which the CO will routinely encounter, and we discuss these next. (If a situation occurs which doesn't seem to fit any of these, speak to one of the more experienced COs.)

4.2.5 CREATE/UPDATE Page

This page is reached by selecting 5 - UPLOAD TABLE on the preceding TABLE DATA DISPLAY page. The description for that page explains how to make the selection on this page, since the two are closely related. The |PF11| key will cancel and abort back to the TABLE DATA DISPLAY menu.

4.2.6 UPLOAD FILES Page (Selecting a file to edit)

Simply enter the number of the upload table you wish to use. The |PF11| key will cancel and abort back to the CREATE/UPDATE menu. The |PF3| key, on the other hand, will save.

4.2.7 ENTRY/EXPOSURE Table

This is one of the command menus for the SXT upload file. A hardcopy of this page should be printed for inclusion in the SXT table fax.

4.2.8 COMMON Table

This is one of the command menus for the SXT upload file. If any changes are made to this page, a hardcopy should be printed for inclusion in the SXT table fax.

The COMMON table is used to determine the general mode of SXT operation. Usually, only the functions mentioned here are changed on a regular basis. The others are best left to the more experienced Chief Observers.

4.2.9 FFI Tables (0-3)

These four FFI sub-tables are command menus for the SXT upload file. For any pages you change, a hardcopy should be printed for inclusion in the SXT table fax.

FFI #1 is normally reserved for Qt/Me observations and FFI #2 is for Qt/Hi mode. FFI #0 and #3 are used primarily for special observations, e.g. dark calibration. The tables control the full frame observations via filter selection, choice of resolution and exposure control. The FFI tables are also used for the taking of terminator images (position 1-1 in FFI Qt/Hi) and can control whether the shutter is open or closed by declaring if a normal or dark frame is to be taken.

Generally, the CO is only concerned with the filter choice (B/A), and exposure (DPE) for each frame in the sequence. The resolution of a frame is specified as the first letter in the RCN column. (F = Full; H = Half; Q = Quarter.) The CO should also have an understanding of the use of the sub-loops in the sequence tables. The number of iterations for each sub-loop is set at the top of the table. (See the Red Book for a description of how these loops work). Careful planning of the FFI table entries allows the full versatility of the SXT observation modes to be realised.

The ``full versatility'' does not include much ability to plan out specified sequences over long time intervals, however. The main reason for this is the lack of a real-time clock on Yohkoh. Complicated exposure patterns must be done with adroit use of the loop counters and dead reckoning about how much time has elapsed since the last SXT CTL AT, which resets the tables. We often do this for special circumstances, such as rocket launches during invisible orbits or transits of Mercury. A precise anticipation of the image times, however, is probably only possible for a great Yohkoh wizard, and only with hours of patient work, so it's usually necessary to accept some margin of error.

4.2.10 PFI Tables (0-3)

These four PFI sub-tables are command menus for the SXT upload file. For any pages you change, a hardcopy should be printed for inclusion in the SXT table fax.

PFI tables #1 and #2 are used for normal quiet mode operations (HI and ME, respectively), number 3 for flare mode operations, and number 0 for special operations. The PFI Tables are a bit more complicated than the FFI Tables --- one must consider AEC parameters and Observing Region Numbers (OBN) in addition to things like filters, resolutions, and exposure times. The loop iterations of the sequence can be set at the top of the table.

Tips

4.2.11 OBSERVING REGION (ROI) Table

This is one of the command menus for the SXT upload file. If any changes are made to this page, a hardcopy should be printed for inclusion in the SXT table fax.

The ROI (Region of Interest) table is used for selecting the size and center position of the PFIs. There are four ARS and four ART rows. When ARS is enabled, slots 0--3 will contain the locations of the four brightest observing regions, and slot 8 will copy slot 0. The four ARS slots will be updated periodically (after patrol images) during Quiet mode. Only the FL-ARS slot (8) will be updated during Flare mode. The standard ARS observations normally use OBN 0 (first row). OBN 4 is used when doing ART or fixed pointing observations, and then the location of the PFI is entered in CCD coordinates and can be determined using sxt_obs_coord.

A PFI is a ``mosaic'' of unit frames. A unit frame is 64x64 CCD pixels, so the Field of View (FOV) size of a PFI depends upon the mosaic pattern as well as the resolution. The size (or ``shape'') of a PFI is given as n x m, where n gives north/south units, and m gives east/west units. Because of the way the hardware works, any number of units can be exposed and read in the east/west direction at once, but the north/south direction is processed one unit at a time. Hence, a 1x2 PFI is made of one exposure, but a 2x1 PFI is actually composed of two exposures.

The SXT CO Team often uses OBN 8 for medium-rate data, for the following reasons: OBN 8 is the dedicated flare mode entry, and it contains a copy of the top ARS region OBN 0. Thus with a 2x2 full-res ROI in OBN 0 for high-rate data, and a 1$\times$1 medium-res ROI in OBN 8 for the medium-rate data, one can almost maintain continuous coverage of the top ARS location with a common field of view (128x128 FR pixels, or 64x64 HR pixels).

Tips

4.2.12 UPLOAD FILE UPDATE Page

A hardcopy of this page should be printed for inclusion in the SXT table fax, after one has entered the new table ID, but before one presses |PF3| to proceed to the next menu.

After one has finished editing the command menus, one presses |PF3| and is brought to this page. The purpose of this menu is to select which stored upload table one wishes to overwrite with the new upload table. The recommended procedure is to overwrite the oldest file.

Tips

4.2.13 UPLOAD FILES Page (Selecting a file to send to KSC)

After the upload table has been created/updated, you will want to transfer it to KSC. An exception is when there are two or more table uploads planned for a single night; in this case you will want to transfer only the first table, and then ask the KSC Tohbans to perform the second transfer after the first upload is completed. It is compulsory to send an e-mail and (preferably) a fax or phone call each time you transfer a table. The reason for this is that during operations for other spacecraft at KSC, there may be an interval in which a new table file will not be transferred automatically. It then requires a manual operation at KSC, and they need to be alert to the need for it.

Sending a table to KSC begins at the MAIN MENU page of sxtspt (see earlier subsection). Select Option 2: GENERATE TCU COMMAND. This will bring you to the UPLOAD FILES page; simply type the number of the upload table you wish to send, and press |ENTER|. This will bring you to the COMMAND page; see the note below about errors and command counts on the COMMAND page.

Tips

4.2.14 COMMAND Page

This is the page with which the SXT CO can send an upload table to KSC.

Upon first arriving at the COMMAND page you should see a counting of the commands you're sending, something like:

COMMAND COUNT = 15 / COMMAND BYTE = 45

The exception to this is you might see an error code of the nature,

WARNING ; CURRENT TABLE UNMATCH WITH THE LAST UPLOAD TABLE

UNMATCH COUNT : 15 ;

COMMAND COUNT = 15 / COMMAND BYTE = 45

It means that the table you are overwriting does not match the table that is currently on board the spacecraft. Either the table you're overwriting hasn't been uploaded yet, or there's been a problem with the table archiving. At this point it's not a bad idea to make a printout of the screen for documentation, in case this turns out to be a sign of some problem. This situation can arise from one of (at least) three causes:

4.2.15 Maintaining Mainframe Account (ST; PFD 3.8)

The batch jobs created by sending command tables to KSC will haunt the SR0001 account until explicitly deleted. It is common policy to limit the number of past batch jobs to about 6 or 8. If they become too numerous sxtspt stops running. The most recent jobs should not be eliminated since they can be an important record and diagnostic tool if a problem arises with an upload table. The st and pfd 3.8 commands (at the READY prompt) help to keep an eye on the mounting jobs and to trim them occasionally. We now archive these print jobs via the IDL program KSC_commands run after each table creation.

4.3 Using Telnet via Flare20

It is now possible to telnet to the mainframe (SSOC #1) from any of the workstations, and operate the program sxtspt this way. The access route is solely via flare20, from which one needs to do a telnet using the access alias "mainf1":

4.4 Overriding NOCHECK flags

The sxtspt software does error checking and will often not allow you to do potentially disastrous things. If you need to get around this, as for example to request an OPEN/OPEN shutter configuration, you will need to use a special input mode. You will need to use a mainframe workstation to do this, because the emulator for the workstations does not have a PF22 emulation. It is extremely dangerous to use NOCHECK, because (we believe) this allows SXTSPT to overwrite parts of the DP memory if errors are made. This can have unknown consequences for SXT exposure parameters, for example. The safest way to proceed with NOCHECK is (a) to be absolutely sure that you need it; (b) to alert the current Supertohban that this is happening, and consult about it; then (c) write and save all parts of the table that you can do without the NOCHECK enabled. Then, and only then, log on via the mainframe terminal and edit the table files ONLY WHERE YOU NEED TO by following the following procedure: Proceed normally, but press |PF22| as soon as you get to the second page of sxtspt (the TABLE DATA DISPLAY page). You will be asked a question, to which you respond with NOCHECK at the right place on the page. Edit the problem command and save again. This procedure (overriding with NOCHECK) should never be necessary in the normal run of things except for entering 1-1 OPEN/OPEN entries.

4.5 The SXTSPT Table Management System

SXTSPT maintains an elaborate and confusing set of files, which are used for several purposes. These files in particular are used for confirmation of the upload in real time, i.e. the tohban runs sxtspt during the contact pass and compares the TABLE READ result (download of the table just uploaded with TABLE WRITE) with the edited table. This is the final check that the on-board table matches what resides in the command computer at KSC, i.e. that no telemetry errors occurred during the uplink.

4.6 Manual Archive Table Updating

The update of the sxtspt table archive occurs automatically when the checking is done (see the discussion under ``The SXTSPT Table Management System''), but if there is a problem a manual update may become necessary. The instructions for this are as follows:

4.7 KSC Commands Archive

Since May 1999 we have been routinely logging the Compare and Command files, which still need to be deleted routinely from the mainframe, in a workstation account. This is handled by an IDL program KSC_commands, resident on /0p/sxt_co/idl at present. This launches an ftp to the mainframe, gets the files, and puts them in the proper archive.

5. Communications and Accounts

The operation and maintenance of the SXT is complex, and the functions of the SXT Chief Observer are necessarily interrelated with those of many other people. In this chapter we discuss the ``communication responsibilities'' of the CO job. This includes preparing, sending, and receiving reports, representing SXT in coordinated observations, maintaining the sxt_co and campaign accounts, keeping in touch with the Yohkoh tohbans, and alerting the rest of the SXT Team to non-ordinary situations.

5.1 GBO Email

The KSC tohbans send out an email after every Yohkoh pass, which briefly describes the pass and whatever they did and observed during the real-time operations. Copies go to the sxt_co account, as well as to many GBO (Ground Based Observatories) and other people not directly involved in Yohkoh operations. Hence, it is important that the tohbans do not make any inappropriately alarming statements or they run the risk of propagating misinformation about SXT's status to a wide community. If such a case arises, the CO should act quickly to correct the tohbans' statements and to explain the nature of the miscommunication.

In ordinary conditions, the GBO mail is a useful summary for the SXT CO. Any SXT operations (e.g. an SXT Table load) during the pass will be mentioned among the comments. If there were any problems with the SXT, the KSC tohbans should have already faxed or emailed a notification to the CO, separate from the GBO email.

The archive for GBO mail is on the sxt account at flare1.

5.2 The Yohkoh Operation Report

After the day's KSC passes are over, the KSC tohbans send out this report by email and fax. It lists the real-time commands they issued, as well as any instrument errors they encountered. The fax copy should be two-hole punched and filed in a binder titled something like ``Yohkoh Operation Reports''. This binder is usually located on the desk to the immediate left of the D-toh facsimile machine.

5.3 The SXT table fax

The SXT table fax is the main mode of communication between the SXT Chief Observer and the SSOC and KSC tohbans. After the Chief Observer has decided on the day's observations and sent the appropriate table to KSC for upload, a fax is prepared with all of the important information and is then forwarded to the tohbans. The fax should be clear and concise since not all of the tohbans are fluent in English. The best approach is to follow previous examples. The fax should contain the correct table ID and the pass number at which it is to be uploaded. A brief description of the planned observations, detailing changes of filter, exposures, fixed pointing locations, terminator offpoints, etc., and the names of the relevant mainframe files should also be included. The Chief Observer should append the hardcopies of the mainframe printouts for that upload file, indicating clearly with handwritten circles or arrows the changes made.

Note that this document is called a ``fable'' fax, and not a ``daily'' fax. Each upload table necessitates its own SXT fax, even when there is more then one SXT table planned for a day's passes. If the upload table was prepared but not sent (e.g. the previous table has not yet been uploaded), the CO should either wait and send the table fax after sending the upload file to KSC (including the COMPARE and COMMAND batch job names), or send the fax with an explicit and emphasized message that the KSC tohbans are expected to transfer the table remotely. In the case where there are special or particularly important instructions, the Chief Observer should contact both SSOC and KSC tohbans by phone, in addition to writing the instructions clearly in the SXT fax. A direct telephone contact should be made with the KSC tohbans in case a remote transfer is required, at least for the first time during a given week of operation. One must assume that the tohbans will not read the fax at all except for perhaps the table name.

An SXT table fax must be sent each time a new table is transmitted to KSC, even if it's only an update.

The SXT table fax cover pages are archived in the ~sxt_co/ksc_fax directory. The fax should be sent to KSC and B-toh. The instructions for this should be posted on the wall behind the facsimile machine, but we include them here as well.

CONTINGENCY

The CONTINGENCY field of the table fax should tell the KSC tohbans what to do if things go awry. We've homed in on a set of three standard messages reflecting the following possibilities:

5.4 The SXT WOM Report and Table Plan

One of the responsibilities of the SXT CO is to attend the Yohkoh Weekly Operations Meeting (WOM), which is regularly held on A-toh, 6th floor at 10:30am Monday morning. At this meeting the CO should present a report of the previous week's observations, and a plan for the beginning week's SXT Table loads. The WOM reports are archived in the ~sxt_co/wom_rep directory, and the most recent one should be used as a template. The SXT Table Plan is described in Chapter Three. Be sure to take copies of the WOM Report/Plan to hand out to the attendees. Usually 10 copies, double-sided are made, with the alias "print_wom" (lpspr -K2 -X10 $ | lpr).

After the Operations Meeting, and after any last minute changes have been made, the WOM Report/Plan should be emailed to the plan alias from the sxt_co account.

5.5 The Bi-weekly SXT Status Report

Every two weeks or so, a detailed (page or two) report of SXT observations and issues should be drawn up and emailed to the status alias from the sxt_co account. Past reports are filed in the ~sxt_co/sxt_status_rep directory. Recent ones should be followed as examples. This report goes to a wider audience than the WOM reports, and even more care should be taken to produce a professional presentation. Much of the content can be taken from the corresponding WOM reports.

Tips

5.6 Weekly Updates to Web Sites

Beginning in June of 1999, there are three webpages that must be updated weekly by the SXT Chief Observer. These do not have to be very elaborate, but should be done every week.

The first is a weekly report to NASA's Office of Space Science. This takes the form of three or four sentences summarizing Yohkoh health and the week's operations. The report must be filed on Friday, or at least you must enter Friday's date in the appropriate place on the form. To file the weekly report, crank up your favorite web browser (Netscape is currently installed on the isassN machines) and go to the website:

http://ossim.hq.nasa.gov/OSSIM/home.htm

You will be prompted for a username and password; use yohs for the name and ******* for the password. Previous weeks' reports are viewable.

The second weekly web page is the SXT coordinated observations (campaigns) catalog at URL:

ftp://isass0.solar.isas.ac.jp/pub/sxt_co/sxt_catalog.html

Use your favorite editor to enter last week's campaign data. Since SXT rarely runs more than one campaign per week, this entails very little work. The format is self-explanatory. If in doubt about participants or JOP number, compare with SOHO's monthly calendar at:

http://sohowww.nascom.nasa.gov/soc/head_calendar.html

The third weekly webpage is more involved. This is the SXT Weekly Notes page at URL:

ftp://isass0.solar.isas.ac.jp/pub/sxt_co/SXTweekly.html

Each week the SXT Chief Observer updates this page to give a brief summary of instrument health, solar activity, and a ``Science Nugget" describing something seen in recent data. This is also typically done on Fridays, but doesn't have to be. Making this webpage entails several steps:

5.7 Coordinated Observations

We maintain two Web pages for coordinated observations: completed ones are found on sxt_catalog.html, and the forthcoming ones on sxt_future.html. These should be routinely maintained.

We strongly encourage coordinating observers to deal with us through the sxt_co mail username, so that we all can pitch in. Often we create an alias in the .mailrc of the sxt_co account to serve as an exploder for e-mail advice.

Finally, we try to keep an eye out for targets of opportunity - currently sigmoids, TILs, and fat streamer bases - for various persons. See the templates page for details.

Tips

5.8 The SXT_CO Account

The Chief Observer should always use the sxt_co account on isass0 which has been set up specifically for CO duties. This account contains various directories for terminator studies, weekly table plans, daily SXT faxes and the SXT status reports as well as the .mailrc and .plan files, mailing lists, campaign notes and various software routines. Some of the software is not on the general Yohkoh software tree because of its extreme lack of generality, so it should be run locally.

When sending out email in the ``official'' capacity as SXT Chief Observer, one should do so while logged on as sxt_co. This ensures a proper return address on the email for identification and replies. Email sent to the sxt_co account is automatically forwarded to all members of the SXT CO Team. There is no inbox for the sxt_co account itself.

Obviously, the CO is responsible for maintaining this account. Personal files are the responsibility of the owner, and should either be cleaned up at the end of the duty period, or moved to a personal sub-directory of sxt_co.

6. Useful Information

6.1 Directory

6.2 IDL Commands

Listed below are several routines that have proved useful for general Chief Observer work; there are of course many more. If more information is required about these routines use doc_library, doc_library2, fastdoc, xdoc, chkarg, or your favorite documentation program.

A: SXT Chief Observer Checklist

The sxt_co checklist can be found at:/0p/sxt_co/documents/co_check_list.ps