SXT Chief Observer's Handbook

Loren Acton, David Alexander, Brian Handy, Hugh Hudson, Piet Martens, David McKenzie, Thomas Metcalf, Nariaki Nitta, Aki Takeda, and Mark Weber

Version 4.3 [Last Updated: December 27, 2000]

Table of Contents

1. Introduction

2. Monitoring the SXT Instrument and Data

2.1 First_light and QUICK

2.2 Check Temporary KSC Reformatted Data

2.3 Check Recent KSC Raw Data

2.4 Patrol Images

2.5 Dark Current

2.6 Stray Light

2.7 Monitoring Attitude Control

2.8 Adjust the Yohkoh Normal Pointing

2.9 Streak Artifacts (``Glitches")

2.10 The South Atlantic Anomaly (SAA)

2.11 How to Obtain and Use Other Yohkoh Diagnostic Data

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

2.13 Reformatting recent data

3. Planning Observations

3.1 The Weekly Visible Diagram

3.3 The SXT Table Plan

3.3 Coordination with Other Instruments

3.4 ARS1

3.5 ARS2

3.6 Fixed Pointing (``ARS0")

3.7 ART

3.8 Filters

3.9 Exposure Control and AEC

3.10 Offpoints

3.11 Use of Parts of the CCD

3.12 Dark Frames

3.13 Diffuser Frames

3.14 Terminators

3.15 Patrol Images

3.16 CCD Bakeouts

3.17 PFI-Dominant Observations

4. SXT Table Loading (SXTSPT)

4.1 General

4.1.1 Viewing Previous Tables

4.2 Using the FACOM Mainframe

4.2.1 Logging On and Off

4.2.2 Basic Procedures and General Notes

4.2.3 MAIN MENU Page



4.2.6 UPLOAD FILES Page (Selecting a file to edit)


4.2.8 COMMON Table

4.2.9 FFI Tables (0-3)

4.2.10 PFI Tables (0-3)



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

4.2.14 COMMAND Page

4.2.15 Maintaining Mainframe Account (ST; PFD 3.8)

4.3 Using Telnet via Flare20

4.4 Overriding NOCHECK flags

4.5 The SXTSPT Table Management System

4.6 Manual Archive Table Updating

4.7 KSC table command archive

5. Communications and Accounts

5.1 GBO Email

5.2 The Yohkoh Operation Report

5.3 The SXT Table Fax

5.4 The SXT WOM Report and Table Plan

5.5 The Bi-weekly SXT Status Report

5.6 Weekly Updates to Web Sites

5.7 The CAMPAIGN Account and Coordinated Observations

5.8 The SXT_CO Account

6. Useful Information

6.1 Directory

6.2 IDL Commands

A: SXT Chief Observer Checklist

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:

Unix > tail_auto, mail

Web >

IDL > first_light, /summary

and review the GBO_MAIL and KSC summary report messages. These functions give a quick overview of the SXT and Yohkoh operations situation.

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

IDL > first_light

IDL > first_light, /summ

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/ accessible on workstations. On isass5 a cron job auto_toban2 runs every 10 minutes. When it finds the new SIRIUS data in, 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)
In the following, we list the most common failures in the reformatting procedure, and recommend appropriate responses.

Mainframe/SIRIUS: If tail_auto shows that no temporary SIRIUS data has recently been created (``No new data since...'' extending over too long a time), then this is likely a mainframe problem. (But could be due to the ISAS internal network.) One common reason is that the limited space on SIRIUS has filled up. The older data will have to be deleted manually by the SIRIUS staff. At other times, the daemon on the mainframe computer is killed for some reason. In another example from the past, a mismatch between two ISAS networks (SSOC and solar) has sometimes been a problem, making it impossible for the mainframe computer (on SSOCNet) to write to the file (on SolarNet). Responsible ISAS parties are Shuto (for the mainframe daemon) and Kato (for SIRIUS). Send a brief email note to the ~sxt_co/.mailrc alias ``reformat''. Its recipients are software@isass0, manager@flare2, sxt_co@isass0, Shuto-san, Kato-san and (the SIRIUS contractor).

Isass5/Flare workstations: If there is no recent entry in the output of tail_auto (indicated by the time of the last line), then one should immediately know that auto_toban2 is not running properly on isass0. Possible manifestations of workstation problems would include the existence of new SIRIUS data but no new reformatted data, or if auto_toban2 is not running. There is also a precedent for isass0 getting confused and running multiple auto_toban2 jobs. (A quick way to check this is to issue the UNIX command:

Unix > ps aux | grep auto_toban2

The solution to this problem may be to have software@isass0 reboot isass0.) The Lockheed Software people (software@isass0) are responsible for the isassN machines, and the Yohkoh workstation managers (manager@flare2) are responsible for the flareN machines. Notify these people if you believe the problem can be traced to the workstations.


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

IDL > first_light, /summ

Unix > tail_auto

Unix > mail reformat# From the sxt_co account.

Unix > ps aux | grep auto_toban2

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.

SFRs (SXT Full-frame Raw Reformatted Images): Currently the best way to grab the SFRs is by using yodat. Each SFR file includes one S/C orbit's worth of data. The data can then be viewed easily with stepper. Some things to look for are CCD ``artifacts'' (damage-enhanced dark current, best visible on short or dark exposures), mis-pointings, severe overexposures, and sequences which are not consistent with the onboard tables. Of course, anything that just seems ``strange'' is worth a second look, too.

SPRs (SXT Partial-frame Raw Reformatted Images): There is a handy widget-based procedure available for looking at the SPRs, named xspr. This code will retrieve and display the data, sorted by unique pointings. There is also a recent SFD shown with the target locations indicated, and a GOES plot which displays the relative times of the SPRs. Things that should be checked include behavior of the ARS mode, target pointing, flare-mode data, and all of the sorts of things listed for SFRs above.

The SPRs can also be obtained and displayed with the yodat stepper combination described for SFRs. When yodat retrieves the PFI data, it asks for input.

You have selected an observing region with multiple PFI N-S

Do you wish to have it "assembled" [Default: Y ] ?

Do you want to avoid images that are missing "PFI strips" [Default: Y ] ?}

It is typical to take the default (``Yes'') to both questions. xspr assembles the data it displays automatically.


If the movie mode in xspr is running too fast for adequate perusal of the images, there is a slidebar on the xspr widget-window that can be used to slow down the frame rate. In stepper one should probably avoid the movie mode and just ``step through'' the data to check it, or use xstepper.

Sample calls

IDL > .run yodat

IDL > stepper, index, data

IDL > xspr

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.


This information is basically on the QUICK pages.

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.

``Darkcal'' Table: Once a week, the CO should switch SXT to the ``Darkcal'' table, and let it run for about a day. This entails changing the Qt-Hi FFI slot to Table #3 on the ENTRY page of sxtspt. (One should look over the FFI #3 page, of course.)


This information is basically on the QUICK pages.

Whether switching to or from the ``Darkcal'' table, one should be sure to update the terminator frame (1-1 slot on Qt-Hi FFI table), if necessary.

The program plot_sld gives a graphic view of the entire dark-current history of the CCD.

Sample calls

IDL > .run plot_sld

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.


As with plot_sld, a first-order check using plot_sls is simply to see if the most recent data points are consistent with the larger temporal evolution.

A program quickstray will check the stray level much more quickly than plot_sls: it reads the last two weeks' worth of Al.1 SFRs and plots the total signal. The signal usually vacillates among three distinct levels, which remain pretty steady over a few weeks' time. You're looking for a discontinuous increase in that signal. This information is basically on the QUICK pages.

Sample calls

IDL > plot_sls

IDL > quickstray

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

IDL > quickatt

IDL > get_att, index, att & pmm, att.status1


This information is basically on the QUICK pages.

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.


The program new_normal_point makes use of the name of the OG containing the current pointing. It reads this name from the file stored in the flare N ~yohkoh/opog directory, and this is updated when OG writer edits the OG on the mainframe. Sometimes this does not happen properly - in this case one of us (Hudson) has to fix things.

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:

An active region is present at the limb (heretofore low latitudes).

The SXT tables keep the shutter open for a large fraction of the time, because of long exposures, high cadence, or both.

AEC is unable to respond to the limb region's brightness because of PFI pointing elsewhere (ARS2 or ARS0).

In a larger sense, this phenomenon is a relatively recent development, during a relatively quiet part of the solar cycle, and is considered to be a reflection of the long term aging and degradation of the SXT CCD. More analysis can be viewed in the ``Calibration'' menu of show_pix. Further analysis of the cause(s) of this phenomenon, and any resultant alterations to SXT operating procedures, are pending, but not very fast.

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:

IDL > loadct,15

IDL > data=bytscl(data,min=80,max=95)

IDL > stepper,index,data

When a streak artifact is discovered during the daily SXT Chief Observer data checks, the following procedure(s) should be followed.

Immediately add DPE=2 and DPE=30 HR dark frames to the FFI table, at low cadence. This will provide improved information for diagnosis of the effect and, perhaps, provide a way to better remove the feature from processed data.

Also, increase the Morning Interval to 4 minutes. This is to see if the recovery is quicker for a longer morning interval.

Evaluate recent SXT tables to determine their possible contribution to the occurrence, and adjust plan accordingly. Note that this effect may be dependent on the two or three-day exposure history of the SXT CCD, and the exact time of the artifact's appearance need not be coincident with all of the problematic tables.

Notify of the artifact. Notify campaign or observing coordinators of any necessary changes in the observing plans.

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.

Patrol images: Patrol images (morning and quiet) are important to several Yohkoh onboard algorithms, including the ARS modes. These images are not included in the most common datafiles, but can be retrieved by the use of yodat. See the sections on ARS1 and Patrol Images for instructions on how to retrieve patrol images.

CCD temperatures: The function gt_temp_ccd extracts the CCD temperature at the time of each image.

Other: There are other programs in the gt_ series, but many of the parameters recorded in telemetry (and hence the reformatted raw data) don't have easy extraction methods yet.

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:


*                                                           NO.    SOE     

*WED 22 Mar
 082 1405 1430 1440 1450  DSS-76   SOL    R, TKG PASS       6376  xxxxxx- 
 082 1545 1610 1623 1633  DSS-76   SOL    R, TKG PASS       6377  xxxxxx- 
 082 1727 1752 1806 1816  DSS-76   SOL    R, TKG PASS       6378  xxxxxx- 
Look up the observation time here, and note the facility number. These values correspond to the following table:
16, 17Goldstone
76, 80, 82Wallops

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.


This system (involving go_go_toban) may change soon; we would prefer an automatic reformatting update that would sense the arrival of new NASA data and run as necessary. In the meanwhile one does not really have to go through all of the precise steps given above; if the data have arrived, your arbitrary choice of t1 and t2 in go_go_toban should work fine.

As of this date, the best way to run go_go_toban is via an rlogin as "software" on isass0, with the /sfd switch set.

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).

Frequent problem: A boxed daily set doesn't include exactly five consecutive passes. Sometimes the SSOC tohbans get confused, and only box the passes that are available to Yohkoh. The correct procedure is to box 5 passes, and cross out the unavailable ones. This is important because a Yohkoh KSC Pass ID includes a pass number, where Pass 1 is the first member of the five consecutive passes even if Pass 1 is unavailable to Yohkoh. The boxes must be drawn correctly to insure consistent pass numbering. Notify the SSOC tohbans.

After receiving the WVD, there is a pair of IDL programs online that the Chief Observer should run, named mk_visible and pr_visible. The mk_visible routine allows the CO to edit the file containing the contact-pass information from the Weekly Visible Diagram. In brief, one selects which KSC Pass on each day of the upcoming week is Pass 1, and then selects the Passes which are available to Yohkoh, according to the WVD. Finally, the information is saved to file. More information on mk_visible can be found in the documentation. This routine should be run weekly after the WVD becomes available from the SSOC tohbans. The pr_visible routine is then used to display the Yohkoh-KSC contacts. This routine has a hardcopy option.


The IDL routine show_contacts can also be used to display the KSC Contact times for a time period.

The IDL routine contacts can be used for time periods for which the ``visible'' database has not yet been created.

Sample calls

IDL > mk_visible, week # `week' is the week-of-year number.

IDL > pr_visible, week=week

IDL > pr_visible, week=week, /hc

IDL > contacts, t_start, t_stop

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:

``STANDARD'': A table to perform routine observations, which has evolved slowly over the mission along with the SXT Team's definition of ``routine''.

``STD+LONG'': A STANDARD table with long exposure, half-res FFIs (Al01 DPE 27, AlMg DPE 30) added for quiet sun observations. We don't do these if the saturation bleed extends to both the top and the bottom edges of the CCD.

``DARKCAL'': A dark calibration table (run overnight as a rule). This table is run once a week, typically on Tuesday.

``STD+DIFF'': A standard table with diffuser exposures in place (also run overnight). This table is run once a week, typically on Thursday.

When selecting the Pass Numbers for which the Chief Observer desires to upload SXT Tables, there are some considerations to be borne in mind. First, OP Tables (Yohkoh's onboard instruction lists) are typically uploaded on the first available pass of each day. To avoid unnecessary crowding of the real-time operations, SXT table uploads are not usually planned for the same pass. Second, there are usually no uploads planned for the last pass of the day, normally Pass 5, since any errors in uploaded tables cannot be corrected until the next day. However, one should note that these are guidelines, not unalterable laws. When there are experienced tohbans on duty the Chief Observer may sometimes use the first or last pass for table uploads. This is particularly useful for campaigns and when extended coverage is required during the KSC passes.

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.


The full archive of SXT sequence tables can be found on $DIR_SXT_ATABLES in ASCII format. These can be grepped for precedents.

The base table (see below) should be recent in time because of the Yohkoh telemetry architecture. If one uses an ancient archive reference, it may contain archaic forms of table pages that you did not intend to edit.

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:

(Note: the target locations are given as x- and y-displacements from disk center, in units of arcseconds.) The program sfd_cds allows one to plot a SOHO or TRACE field of view on a recent Yohkoh SFD image. This is usually sufficient to see what the various instruments will be looking at, one day in advance.

Sample calls

IDL > sfd_cds,[-600,600],[314,314] # Put a 2x2 SXT OR near the northeast limb.

IDL > sfd_cds,[0,0],[510,510],/notv # Overlay a TRACE field of view at disk center.

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.


An ROI that has multiple NS units requires a separate exposure for each one. This is an artifact of the cumbersome DP software on board Yohkoh, with implications for the permissible sampling interval and for CCD overexposure.

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.


Do not forget to DISABLE the morning patrol when setting pointing coordinates through ARS2. Morning patrol would overwrite your selected coordinates.

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.


If ARS1 or ARS2 is enabled, it is still possible to do fixed pointing. This can be useful if, for instance, you're interested in tracking an active region with one set of PFIs, while maintaining a fixed-pointing observation on the polar regions with a simultaneous set of PFIs. Set up ARS1 or ARS2 as usual, select one of the ARS ORs (#0--3,8) for the target to be ``tracked", and select one of the ART ORs (#4--7) for the fixed-pointing target. This only really works for quiet regions or for active regions at the limb if the table runs over the invisible orbits (non-KSC), so be careful; otherwise solar rotation will make your target disappear.

The coordinate entry in sxt_obs_coord is backwards.

Sample calls

IDL > tvscl, data # Display an image for UT datatime.

IDL > sxt_obs_coord, datatime, obstime, side=[64,128]} # Find coords for a 1x2 OR at a future UT obstime.

IDL > lastsfd,index,data (get last full-disk, and continue ...)

IDL > sxt_obs_coord,index,'time of upload' (will rotate feature clicked on forward to time of upload)

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:

1. ART should be ENABLED in the COMMON Table.

2. IRU should be selected in the COMMON Table under ART TFS/IRU.

3. The CO must ask the SSOC tohbans to insert an ART initialize (DC) command into the Pass sheets.

A document describing in detail how to use ART can be found as $DIR_SXT_DOC/howto_art.doc.

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.


Filter combinations are typically given in reverse order of the corresponding wheels, i.e. B/A. This applies in the sxtspt program as well. (MW)

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 ...


You must type the ``/" when adjusting the flush count in the PFI table of sxtspt. Two commonly used flush counts are 4/1/1 and F/2/3. 4/1/1 contributes 0.175 seconds to the image latency, F/2/3 contributes 0.576 seconds (potentially interfering with the cadence). In general, a flush count of A/B/C means (Ax4x8.1 msec) + (Bx45 msec) is added to the image latency. Add this to the image exposure duration when trying to figure image cadence. The third digit (actually Cx2) yields the number of full-frame flushes done during the image setup (filter placement, etc.), and doesn't contribute to the image latency. (DMcK)

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.


We haven't done offpoints in some time because of the complexity involved in terminator image acquisition for stray-light corrections.

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:

IDL > mk_sfc, /check

Note that the current (26-Dec-96) standard settings are DPE 25 for AlMg, DPE 23 for Al.1, and DPE 21 for the ND filters. The entries in /ys/sxt/doc/mk_sfc.param can be altered by a Chief Observer, e.g. to update the exposure levels when necessary. The software system will send an automated email notification to sxt_co when a terminator is successfully added to the database.

; SFC Parameter Configuration File (read by mk_sfc)
; History: 8-nov-1995 (S.L. Freeland)
;DPE(/NuDen) set to 21. LWA, 1-Dec-95
;18-dec-95 (S.L. Freeland) - add adjustable time2sunset window)
;28-apr-96 (S.L. Freeland) - set Delta-Pnt to 0. for Al.1
; 4-nov-96 (S.L. Freeland) - Delta-Pnt->3'', Al.1 & 5'' for others
; 3-mar-97 (T. Metcalf) - Added LaTeX commands and replaced tabs with spaces
;11-Feb-98 (S.L. Freeland) - reduce dlt-pnt -> .01 for Al.1
;You may add comments via ``;''
;Please verify changes with IDL>mk_sfc,/check_param
;DPE may be specified as:
;nn-yy range (inclusive)
;n1,n2,n3 list
;nn single value

Instructions for inserting terminator offpoints in the OP:

The terminator image requires four commands inserted by op_first_guess automatically. These are SXT CNTL MAN, CMPN OBS ON, SXT CNT AT, each spaced by one time unit (32 s). Six time units after the succeeding DAY (SUNRISE) command, there will also be a CMPN OBS OFF (also inserted by op_first_guess). The reason for the six-step delay is to allow time for the image taken at the day/night terminator to be read out into telemetry and be protected there. For offpointing, the tohban must add the offpoint command one time step ahead of the SXT CNTL MAN, and the normal point command one time step after the SXT CNT AT command. The important time is that of the SXT CNT AT command, since this is carefully calculated to match the time the Earth's dawn-dusk line is at the right place. The OP editing thus, of course, must not change this time. Note that preparing the OP is the job of the SSOC tohbans, but the SXT CO needs to understand the process of inserting terminator offpoints at least as well as they do, and sometimes may have to explain the procedure.

The main procedure to use when planning terminator images is op_term_score. Note that this takes a minute or so to run. This program supersedes older software (term_score2, Term_review, update_term) that were not so user-friendly, but should still work and could be used if necessary. A summary of terminator opportunities can be obtained via

Unix > term_short

Information on calibration issues can be obtained by consulting the ``Calibration'' directory of show_pix.


If one needs to get involved with the OP, please note that there is an archive on /f2p/com/yohkoh/opog as viewed from isassN.

Information on current terminator status is now on the QUICK pages.

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

IDL > gtab_comm(index)

the SXT conditions at the time of the patrol image can be obtained. It should also be noted that the program call

IDL > gt_ffi_pfi(index)

returns a 3 for a patrol image (1 for FFI, 2 for PFI).

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

IDL > ii = where(gt_seq_num(index) EQ 0,npatrol)

IDL > if npatrol GT 0 then tvscl,data(*,*,ii) else print,'No patrol images'

Alternatively, use ``select'' in sxt_obs3 or sxt_obs4 and find any images with sequence number 0.

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.


Note that patrol images during SAA can cause pointing problems. (DA)

If no patrol image was dumped at the last pass, or a new region has emerged since the last patrol image, you can sketch the patrol image location pretty easily (DMcK):

IDL > lastsfd,index,data # Display a recent image.

IDL > print,gtab_comm(index) # Note the starting row (typically between 80 and 86). Call that SROW.

IDL > line=intarr(3,512)

IDL > line(0,*)=indgen(512)

IDL > line(1,*)=2*SROW

IDL > line(2,*)=2*(SROW+127)

IDL > plots,line(0,*),line(1,*),/dev

IDL > plots,line(0,*),line(2,*),/dev

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:

IDL > pr_dates_warm

Or, if you need only recent history, the following unix command is also helpful. It lists the table comments which includes the string 'BAKE', searched from all tables uploaded in 2000.

Unix > cat $DIR_SXT_ATABLES/tab00* | grep BAKE

There are some IDL routines (like plot_temps2) which can be used to monitor the progress and results of the CCD bakeout. For help or more information, contact Loren Acton.

Sample calls

IDL > plot_temps2


Bakeout should preferably be done during daylight passes at KSC because otherwise no real-time temperature information is available. In that case the effects of the power commands could not be monitored immediately by the tohbans at KSC. In addition, the CCD temperatures come up immediately on the KSC displays during daylight hours, since images are being taken and they're included in telemetry.

Orbital precession brings a 3.5-week period of daylight KSC passes every seven weeks or so.

Samples of the bakeout command plan (case of Dec-00):

11-Dec-00 pass 117:36 UT load bakeout table "001211 P1 ARS0 BAKE*"
pass 219:17 UTTEC off
pass 320:59 UTheater on
12-Dec-00 pass 219:21 UTheater off
pass 321:03 UTTEC on
pass 321:03 UT load standard table "001212 P3 ARS1 STD*"

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

heater onSXT CTL MANU
heater offSXT CTL MANU

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:

IF the upload table in question is meant to be the next one that will be uploaded, the Chief Observer should send the file to KSC using sxtspt and include the relevant info on the SXT Table Fax to the tohbans. It is possible for the CO to send a file to KSC days before the upload pass, as long it is the next table to be uploaded.

IF the upload table in question is not meant to be the next one uploaded (e.g. the CO is preparing one or more tables in advance), then sxtspt should not be used to send the file to KSC (i.e. do not generate a TCU command). This upload file's ID should be explicitly described in the SXT Table Fax as having not been sent to KSC. The KSC tohbans should be explicitly and simply requested to pull the file when they're ready for it. We have a special Japanese-language fax cover sheet for this contingency. This would normally occur only when there are multiple SXT uploads to be done late at night when the SXT CO cannot physically be at ISAS.

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

IDL > print, gtab_entry(index(5)) # Finds ENTRY table at time of index(5).

IDL > print, gtab_comm('3-mar-96')

IDL > print, gtab_ffi('3-mar-96', 2)} # Prints sub-table FFI#2.

IDL > print, gtab_pfi('3-mar-96', 2)

IDL > print, gtab_roi() # Present ROI upload table.

Unix > cd $DIR_SXT_ATABLES # Prepare for grep.

Unix > grep MW tab970531*


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.

Logging off: One need merely type logoff |ENTER| at the READY prompt. One will then have to press |ENTER| once when the account charges are displayed.


Note that for those unfamiliar with these mainframe computers, a set of asterisks (``***'') means only that you must press |ENTER|.

Wrong keyboard entry often locks up the keyboard by converting it to Japanese character entry. If this happens, ALT-KANJI returns it to the proper state. The KANJI key is the one next to the numeral 1. At the lower left there is a reset key that permits you to proceed.

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.

Arrow keys: These keys move the cursor about the menu page by one character in the corresponding direction. The operator should bear in mind, however, that there are only certain ``slots'' on the menu for valid input, so the arrows are most useful if one knows exactly where to go on the page. Use the |TAB| key to find the input slots.

|TAB|: This key moves the cursor to the next input space, left-to-right, and top-to-bottom. The cursor can be ``rolled'' between the top and bottom of the page.

|SHIFT|+|TAB|: Reverse motion of |TAB|.

Text: One types normally in an input space to insert a value. Lowercase is suggested, as the use of the |ENTER| key can be verified by the conversion to uppercase.

|SPACEBAR|: Type spaces over your input to erase it. Be sure to press |ENTER| when you are done editing the page.

|ENTER|: Pressing this key will save all of the changes one has made to the current page. On the ``entrance'' menus, one will be forwarded to the next menu according to the values that were entered. Among the actual upload tables, |ENTER| saves changes but does not change pages. The |ENTER| key is also the expected input whenever sxtspt enters a holding pattern and displays a set of asterisks (``***'').

|PF3|: This is an important key, as it is used to save and exit the SXT command tables, so it shouldn't be used until one is certain of the tables. It is also used to exit sxtspt by returning through the ``entrance'' pages, one-by-one, back toward the level of the operating system prompt. It should be mentioned here that if one is editing the SXT upload tables, and wishes to abort, one presses |PF3| once to exit. The very next page (the UPLOAD FILE UPDATE menu) will allow one to use |PF11| to avoid saving the changes and overwriting the template file.

Print key: In the IDL counting scheme, from the lower left of the keyboard, the print function is the uppercase of the (0,1) key, labeled ``INSATSU'' in Japanese. Two pushes dumps the screen. The printer paper must be positioned manually each time if the page breaks are to come out right. Some of the pages in sxtspt need to be printed (with your input) to be included with the SXT Table Fax to the tohbans. The following sections will indicate which pages need to be printed.

Reset key: In the IDL counting scheme, from the lower left of the keyboard, the reset function is the (1,0) key. If the session somehow becomes hung, or one is receiving error messages, this key may be tried.

The actual SXT upload tables are composed of five separate types of command-sequence table, with four sub-tables for the FFI and PFI sequences (and each of those have two pages!). The five types are ENTRY, COMMON, FFI, PFI, and ROI. Not all need to be edited for each table change. Anything edited will be transmitted to the spacecraft and archived.

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.

|PF7|/|PF8|: Moves one backwards/forwards among the five table types.

|PF9|: There are four sub-tables for the FFI table, and four for the PFI table. This key cycles one forward among the sub-tables of either type.

|PF10|/|PF11|: Only half of an FFI or PFI sub-table (e.g. PFI #2) will appear on the screen at one time. It is helpful to think of ``left'' and ``right'' sides of a sub-table, where the left side is the one that appears by default. The left/right side can be viewed by pressing |PF10|/|PF11|.

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.

Use this option to write, edit, or simply look at one of the upload tables.

Option 2: GENERATE TCU COMMAND After the SXT upload tables have been prepared, they must be transferred to the KSC tohbans. If the upload table in question is meant to be the next one uploaded, the SXT CO should use this option to send the file to KSC. If this table is further down the upload queue than that, then don't send it. Ask the KSC tohbans via the SXT table fax to retrieve the file remotely, so that there is a record of the request. However, the request should also be done directly by phone, since the fax is not a completely trustworthy means of communication.

Option 3: TABLE FILE UTILITY This option is for manually updating the archive tables. This is not normally necessary. More description is given in the section entitled ``Manual Archive Table Update''.


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.)

Preparing a new table based upon the currently uploaded table: In starting to write a new table, it is almost always the best approach to start with the current table as your template. This ensures that the un-edited parts of all tables stay current. This is the recommended choice. The reason for this is that the on-board files are not updated for pages that are not called out in the ENTRY table, so that they can get obsolete. Choose 1 - CURRENT TABLE on this page.

Fixing or updating the most recently prepared table, which has not yet been uploaded: For example, you have already used sxtspt to prepare and save the next upload table, but then you realized there was a mistake or change to be edited. Select 5 - UPLOAD TABLE on this page, and 2 - UPDATE on the next page.

Preparing a new table based upon a recently uploaded table, but not the current one: There are five slots in which to write upload tables in this program. These are periodically recycled, but one can use any of these as a basis for a new table. For example, the CO may plan a complicated upload table for special observations, which he or she wishes to use more than once during the week. The CO could follow this option to retrieve the special table, instead of having to entirely reproduce it from the current onboard table which may be significantly different. Any time the CO does not use the current onboard table as a basis, he or she should check the entire table to make sure there are no entries inconsistent with current observational and operational requirements. Select 5 - UPLOAD TABLE on this page, and 1 - CREATE on the next page.

Here are the possibilities presented on this page.

TABLE ENTRY NUMBER: Simply determines at which sequence table one will start editing. Not very important since one will be able to cycle among them anyway. The standard entry is 1 in the first space, and nothing in the second.

BASE TABLE: Select only from Options 1 and 5, according to the discussion above. The choice of Option 1 will send you to the sequence table selected under TABLE ENTRY NUMBER. The ARCHIVE files store old tables (these are stored by date and by name, optionally, but we have not bothered to put names on them as a rule). The TEMPLATE files store templates of useful tables. This feature is of little value because of the ``parallel tables'' practice of invariably editing from the current table (see above).


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.

Option 1: CREATE For preparing a new table from one of the previous upload tables.

Option 2: UPDATE For fixing or editing an upload table which has not yet been uploaded to Yohkoh. It doesn't matter if the table in question was previously sent to KSC, as long as it hasn't been uploaded yet, and the KSC tohbans will receive notification with sufficient advance time to accommodate the changes.

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.


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.

ENTRY TABLE: The Yohkoh data processor (DP) can operate in one of several modes, and the SXT software allows different observation tables for these modes. The modes are distinguished by the telemetry rate (High and Medium) and the observing mode (Quiet and Flare). The CO uses this table to command which onboard sub-tables will be used under the different modes.

Here are the traditional assignations of the observing sub-tables.

QT/HI FFI:0(Bake),2(Regular),3(Dark Cal)

If you change one of these entries, be sure to print a hardcopy of the corresponding new sub-table for inclusion in the SXT table fax, even if you don't make any changes on that sub-table itself.

EXPOSURE LEVEL TABLE: Ignore this table.

COMMENT AREA: This area contains two lines in which to include basic info and identity items within the upload table. The most important items to include are the date, time and pass of the upload in JST and UT, the SXT Table ID which will appear as the upload filename, and the initials of the Chief Observer. Other items that are generally included are the ARS mode, the shape of the Qt/Hi PFIs, the terminator filter, and a brief descriptor of the main observation plan. It is straightforward to copy the model of the current onboard table, which is displayed.


Type text in lowercase so you will be reminded to press |ENTER| before moving on.

Be careful to use |TAB|, not |ENTER| or |CR|, to end the first line of text in the COMMENT AREA.

When creating a new table from an old table, remember to change the filename.

Characters in the red color on the FACOM terminal don't appear on the emulator version.

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.

AECH0: The maximum exposure allowed to AEC before it must switch to the next set of filters. This is a global parameter for AEC, meaning that it applies to all of the sequences. A specified DPE can override it, however; it only applies to AEC. Usually it is set at DPE=26, which means that that the shutter-open fraction is about 1/2 for quiet conditions.

QT ARS ENA/DIS: Turns the ARS mode for normal operations on or off. Enable for ARS1 or ARS2; disable for ARS0.

QT ARS 1/2: Select ARS1 or ARS2 mode. QT ARS must be enabled.

MON PTL ENA/DIS: The morning patrol images can be disabled here, e.g. for ARS0 mode or ARS2 mode.

QT ARS INTVL: Set time interval between QT mode patrol images. Entry is in units of 32 sec.

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.

DPE: Exposure level.

B/A: Filter combination. E.g. 3/1 = AlMg/Open. An entry of 7/7 means NOP, i.e. no operation.

RCN: First letter indicates the resolution of the PFI. (F = Full; H = Half; Q = Quarter.)

EXP: Usually Normal (N) or Dark (D). The dark calibration table (FFI #3) should be mostly dark frames, of course, but the normal FFI sequence does not include darks because the variation of dark level is so predictable (except during SAA).


The telemetry rate for Qt/Me is 8 times slower than that for Qt/Hi. Accordingly, table FFI #1 (the usual ME rate table) is usually set up with resolutions one step lower than that of the corresponding Qt/Hi FFIs, thus gaining back a factor of four in the movie cadence.

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.

AEC: Turn AEC on or off for each frame.

DPE: Exposure level. This is the starting level if AEC is enabled, and it should be adjusted for solar conditions.

OBN: Refers to location entry on ROI Table. See next section.

RCN: First letter indicates the resolution of the PFI. (F = Full; H = Half; Q = Quarter.)

F#0: Filter combination. An entry of 7/7 means NOP, i.e. no operation.

F#1/2: Alternate filters available to the AEC. This is in case of saturation in a ``thinner'' filter. It only occurs in major flares.

The rest of the page (|PF11|) displays more information. It is vital to check these entries any time a new sequence is entered (i.e. a B/A = 7/7 is changed to a real observation. Typically, the CO will be mostly concerned with the primary filters, resolutions, exposure times, and OBNs. This page also contains the PFI setting for Normal or Dark frames.


The telemetry rate for Qt/Me is 8 times slower than that for Qt/Hi. Hence, one usually sets the Qt/Me PFIs to resolutions or sizes one step less than their Qt/Hi counterparts.

It is possible to use the PFI tables in complicated ways. For example, once can switch between two different ORs and by using the loop counters efficiently the time spent on each OR can be regulated. This is one way to get around Yohkoh's lack of a real-time clock. (DA)

Starting AEC values can be gotten easily via goes2dpe.


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).


Note that this way (``NSxEW") of referring to the size and shape of ROIs, while technically identical to the order of dimensions in the OR table in sxtspt, is exactly opposite to how it's commonly described. This can be confusing, particularly when discussing coordinated observations with other observatories, so watch out for that. (DMcK)


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.

SELECT TABLE NUMBER: The cursor starts here, at the bottom of the page. Type the number of the table you plan to overwrite.

Overwriting the Table ID: Use the arrow keys to move the cursor up to the line containing the doomed table ID. Type the new information directly over the old. Lowercase is recommended, since it will visually remind you to press |ENTER| before departing this screen. Be sure to change the date and pass number in PASS-ID, and the table ID under COMMENT.

|PF11|: This negates everything you have just done to the command menus in sxtspt. This is the key step if you wish to abort your work on the upload table, or if you were only browsing through.

When satisfied, press |ENTER| to store, then print the screen, and press |PF3| twice to return to the MAIN MENU where you can exit or send the upload table to KSC.


The table ID you provide here had better match the corresponding entries for the COMMENT AREA of the ENTRY/EXPOSURE TABLE, the faxed message, and if possible the weekly plan.

An IDL program checkfax, currently under development, provides an additional way of checking consistency in the table fax. It's important because there are many little details that can confuse communication.

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.


If you forgot to print out this screen for the SXT table fax when you were writing the upload table, you can do it now. It is a good habit to print this screen at the earlier opportunity so that you have this second chance available. (MW)

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:


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




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:

1. One reason this may happen, which is not a problem, is the table you're sending to KSC is an update of one that was previously sent, but that hasn't been uploaded. Perhaps you found an error in the table and now you're correcting it before it gets uploaded. If you're sure this the case, then no special action is necessary. Continue with the table transfer.

2. Another situation which can result in this error message is perhaps you planned to do more than one upload on this day, and you've tried to transfer the second table before the first upload was complete. In this case, your best course of action is to exit sxtspt immediately (press |PF3| two times); then either wait until the first upload is finished, or ask the KSC Tohbans to do the second transfer when they've completed the first upload.

3. If neither of these scenarios describes your situation, there's a fair chance that either the previous upload was not fully successful or there's been a glitch in the table archiving. Contact the Super Tohbans and send mail to sxt_co. Do not try to continue with the attempt. Exit sxtspt by pressing |PF3| two times. If the table that is currently onboard the spacecraft is a relatively ``safe" table, then you can tell the KSC Tohbans to cancel today's upload; if however today's upload was meant to replace a potentially risky table with a ``safer" one, you may want to consider asking the KSC Tohbans to turn SXT off (the "SXT HALT" real-time command can be issued from KSC) until you get the table situation straightened out.

Assuming there's no error codes, you will want to go ahead with the table transfer. On the COMMAND page, there are two options available in the list, and both are used. Ignore the option listed parenthetically at the bottom of the page.

|PF3|: Leave the menu. To cancel sending the commands to KSC, use this key before selecting Option 1.

Option 1: GENERATE TCU COMMAND Choose this option first by typing 1 at the ENTER NUMBER prompt. The cursor will move to the password line by the |TAB| command. The password is ******. Press |ENTER|. (This sends the commands to KSC.) The screen will switch to a process message. There will be a set of stars (``***''). Press |ENTER| to acknowledge transmission of the commands to KSC. You will be returned to the COMMAND screen with a message about using |PF12| to compare the file. Do this step next.

|PF12|: This step is done after sending the commands to KSC (Option 1). It will compare the current file with the upload you have updated. The screen will again switch to a process message which names the batch job you have just submitted. This name will be of the form SR0001#, where # is one of [0--9,A--Z]. Make a note of this filename and include it as the ``COMPARE'' file in the SXT table fax. Option 3: COMMAND FILE LIST Choose this option last by typing 3 and pressing |ENTER| (no password necessary). This will create a batch job to list the commands. This job will also have a name of the form SR0001#, which should be included in the SXT table fax as the ``COMMAND'' file.

And for completeness (but not for use)...

Option 9: GENERATE TCU COMMAND (LOAD ENTIRE TABLE) Don't even think of trying this option. Option 1 generates a command sequence from only those parts of the upload table which have changed. This option will regenerate the entire upload table. This process takes up an entire KSC pass, if it fits at all, and is provided solely for recovery purposes.


There is a slight delay for the batch jobs to process and be given a name. It is possible to receive notification for one option while in the middle of another. To avoid mix-ups, I wait a few moments after entering |PF12| or Option 3 and before acknowledging the ``***''. (MW)

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.

st: Typing st or status will list the current batch jobs and return to the READY command prompt. Batch jobs are of the form ``SR0001#''. If there are too many, use pfd 3.8 or cancel.

pfd 3.8: Type pfd 3.8 to enter this program. The menu of options is pretty self-explanatory, but one only needs to use D (Delete), and maybe L (List). To delete, enter d on the command line and change the file name via |TAB| and arrow keys, then press |ENTER|. One should delete the oldest files. Use |PF3| twice to exit.

cancel SR0001# p: This command form can be typed at the READY prompt to directly delete a batch job.


Note that st shows the jobs in a different order than does the logon list, generally oldest-to-newest.

With the ``cancel'' option one can delete multiple jobs by just changing the job number on the screen (arrow keys and overwrite) - very convenient.

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":

flare20 > telnet mainf1

and then respond to the first question (``terminal type'') with 17. The rest of the session proceeds as described in the section ``Using the FACOM Mainframe''. There are, however, a few necessary modifications to the keyboard input, which we describe below. The |TAB|, |ENTER|, and arrow keys should function in the same manner.

Function keys (|PF#): On the G-150 terminal or its PC emulator, one uses the function keys [|PF3|--|PF12|]. These keys are mapped as ``|ESC|+numeric'' to one's workstation. On a DEC keyboard (with no escape key), type the |CTRL| key and the ``['' key simultaneously to create an escape command. The numeric will be of the set [3--0,``-'',``=''] to correspond to the set [3--10,11,12].

Printing: It's best to create the hardcopy fax via cutting and pasting from the mainframe emulator window into an ASCII fax file, with ^L's to separate the pages. This approach, as opposed to our earlier screen-dump (pdump) approach, allows you to check the fax details with checkfax before printing it.

Cancelling a hung session: If the session gets hung and you need to start over again, it is possible to cancel the SR0001 job according to the following instructions (thanks to T. Sakao for this recipe). Then one logs on as SR0001 again and tries once more.

To cancel a mainframe job, log in as one of QLSA02, QLSA03, or QLSA04. Check the wall above the mainframe terminal if this step is not clear. At the READY prompt, type OPER |ENTER|}, and then type C U=SR0001 PURGE |ENTER|}. Here the OPER probably stands for ``Operator", U for ``User", and C for ``cancel". This should result in a message like SR0001 CANCELLED SUCCESSFULLY at which one types END |ENTER|} and the job is done. You return to the READY prompt and log out of this session. If these instructions don't work, do not panic--- there is a time-out sequence that will kill the failed SR0001 job eventually.


The new installation of Common Desktop Environment has provided a wide variety of color schemes for X-windows on the isassN machines. This means that the output of pdump may be different for each user's particular setup. If you find you're getting ugly printouts (like white text on a black page, which doesn't FAX well), try one of these pdump alternates (DMcK):

Unix > alias pdump "xwd | xpr -rv -device ps | lpr -s -h"

Unix > alias pdump "xwd | xpr -gray 4 -device ps | lpr -s -h"

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:

1. Start sxtspt and proceed to the MAIN MENU.

2. Select Option 3 - TABLE FILE UTILITY.

3. On the next page, select Option 1 - GENERATE ARCHIVE.

4. Enter the time range during which the TABLE READ occurred, after confirming that the Sirius database contains the data from this interval.

5. Press the |ENTER| key as the program scrolls through its messages, which will include the date and time of the TABLE READ command that it finds.

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.

1. Press the thin grey button at the lower left of the upper panel. The upper panel stands at a non-zero angle to the floor.

2. Press ``Yes'' on the middle panel.

3. Press the ``SSOC'' button on the lower panel, and then ``Yes''.

4. Press the ``KSC'' button on the lower panel, and then ``Yes''.

5. Press the ``Send'' (diamond emblem) button on the middle panel.

After faxing, the originals should be filed in the SXT CO Binder. The cover page should be emailed to the fax alias from the sxt_co account.


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:

  • 1) The current table is safe and should just continue:

    "If there is a problem with the upload, please try again on the next pass. If you have no chance to upload the table today, you can continue to use the current table until tomorrow. The current table is safe."

  • 2) For ARS2 operation:

    "If there is a problem with the upload, please try again on the next pass. If you have no chance to upload the table today, please contact the SXT_CO. They may prepare and send a new table."

  • 3) The current table is safe for a pass or two, but should not run through the invisible orbits:

    "If there is a problem with the upload, please try again on the next pass. If you have no chance to upload the table today, please contact the SXT_CO or SXT_ST. They will request you to execute the SXT halt operation on the last pass."

  • 4) We have to stop using the current table immediately.

    "If there is a problem with the upload, please cancel the table upload today, and contact the SXT_CO or SXT_ST. They will request you to execute the 'SXT Halt' operation on the next pass."

  • Tips

    Beware the possibility of the fax machine running two pages through together, thus missing a page in the transmission. (MW)

    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.


    It is possible to add a personal touch and still be professional. Mentioning an SXT observation or result (from the reporting period) that you found exciting or interesting is a good and acceptable way to convey enthusiasm to the ``higher ups'' who have to read lots of reports. (MW)

    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:

    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:

    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:

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

    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:

    1. Go to the /0p/ftp/pub/sxt_co directory, and copy the file SXTweekly.html to a new file called YYMMDD.html, where YY, MM, and DD are the obvious numbers for the date.

    2. With your favorite editor, update the YYMMDD.html file to reflect this week's solar activity, special operations, etc. Include your ``Science Nugget" and any images. Previous weeks' webpages are available for review. Make a note to change the week ID number in (i) the header, (ii) the link to the weekly operations report (of the form table_plan.98_22), and (iii) the weekly GOES plot (of the form goes98_22.gif).

    3. Upon exiting your editor, copy the new webpage to SXTweekly.html, overwriting whatever was there. Also copy the automatically generated image weeklygoes.gif to a new file goesYY_WW.gif, where again YY and WW are the year and week ID.

    4. Copy the Weekly Operations Meeting report for this week, found in the file /0p/sxt_co/wom_rep/table_plan.YY_WW, into this directory. To make an html-ized version use:

    IDL > plan2html,table_plan.YY_WW (output YY_WW.html)

    5. Finally, edit the file index.html to include a link to your new YYMMDD.html file.

    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.


    There is an IDL routine called which can be used to prepare a summary report of SXT observations. This is useful for campaign communications. (MW)

    Sample calls

    IDL > sxt_obsrpt, starttime, stoptime

    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

    SXT Chief Observer: The person responsible for the SXT instrument. Email to this account goes to all members of the SXT CO team, who can thus be identified from the ~sxt_co/.forward file. We encourage people to send to this account (or at least cc) for SXT business, instead of to an individual, although the person currently performing CO duties is the one normally expected to reply. This person should be notified of operations issues, SXT observational and scheduling issues, problems and anomalies, and questions about SXT.


    phone: 042-759-8147 (D-toh south room)

    fax: 042-759-8469 (D-toh south room)

    SXT Super Tohban: The current expert on all technical matters pertaining to SXT. This person should also be notified immediately of any serious problems with the telescope.


    SXT Principal Investigators: L. Acton (U.S.), T. Hirayama (Japan).

    SXT CCD specialists: L. Acton (CCD), S. Freeland (camera).

    software@isass0: People at Lockheed (SXT-US) responsible for SXT software, workstation, and data processing issues.


    Workstation setup: ISAS is responsible for the flareN machines, and NASA (Lockheed) is responsible for the isassN machines.


    Yohkoh KSC tohbans: The tohbans at Kagoshima Space Center who handle the real-time operations for Yohkoh, as well as checking the OP and command sheets.


    phone: 0994-31-6003 (Kagoshima)

    Yohkoh SSOC tohbans: The tohbans at B-toh, ISAS who help prepare for Yohkoh operations. They are responsible for preparing the daily OP and command sheets for real-time commanding.


    phone: 0427-59-8398 (B-toh, 2nd floor)

    Yohkoh Project Manager Emeritus: Y. Ogawara

    Yohkoh Project Manager: T. Kosugi

    Yohkoh Assistant Project Managers: S. Tsuneta, T. Watanabe.

    Yohkoh Instrument chiefs (Japanese): SXT - Tsuneta, HXT - Kosugi, WBS - Yoshimori.

    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.

    ars_show: This provides an onscreen simulation of how the onboard ARS1 software selects a PFI observing region. The best way to find out about this is to play with the software.

    checkfax: Surveys an SXT table fax to check for various possible goofs.

    contacts: Lists KSC contacts. An alternative is show_contacts.

    get_att: Returns ATT database records.

    gtab_ffi(tabletime, subtable): Displays onboard SXT FFI table at time tabletime (you can also enter a time-bearing structure here, such as an index). Which one of the four FFI tables is shown is determined by subtable. There are several gtab_xxxx routines and these can be very useful on occasion.

    goes2dpe: Estimates the proper starting exposures for PFIs from recent GOES data. Also shows what yesterday's DPEs actually were. Note that in doing so, it does not discriminate between QT and FL mode! (see also quick_dpe.html.

    goes_summary: Produces summary of GOES events for dates specified.

    goes_tek: Produces summary of GOES flux with FFI and PFI images and UT/JST.

    laser[, /portrait]: Plotting mode.

    lastsfd: Retrieves most recent SFD images.

    new_normal_point: Computes hex commands for a new normal pointing OG.

    .run plot_temps2: Plots CCD temperature at different test points (uses index structure).

    op_term_score: Standard code for tracking the terminator (SFC) archive.

    plot_sld: Surveys dark-frame measurements.

    plot_sls: Surveys stray-light measurements.

    pprint: From within set_plot,'ps sends plot to printer without creating save file.

    pr_gev: Lists GOES events.

    pr_visible: Lists the KSC contacts.

    pr_nar: Lists GOES active regions.

    quickatt: Surveys ATT status for recent data.

    quickstray: Shows total signal in recent Al.1 FFIs, allowing a quick check for new light-leaks.

    rd_orb: Accesses the orbit database.

    sfd_cds[, /notv]: Plots SOHO, TRACE, GBO, or SXT field of view on a recent SFD image.

    sho_data: Allows the determination of the average DN count rate in user-selected region or solar feature; useful for choosing exposures.

    sxt_his2dbase: Returns the SFC or SDC (leak or dark) index and data used for a given image. Helpful in tracking down bad corrections.

    sxt_obs_coord: Allows the determination of the coordinates for fixed pointing. This uses the differential rotation algorithms to determine the location of any user-selected region and any selected time.

    term_review[, /comp, /set]: Summarizes the terminator pointing situation.

    yopos: Shows where the satellite is at a given time. This makes a nice plot, but for details use rd_orb.

    A: SXT Chief Observer Checklist

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