Some BCS Operations Notes R.D.Bentley, Nov 91. Updated 14-Dec-92 1 HIGH VOLTAGES a) Switching The high voltages units are normally switched "on" and "off" using the HVA SET, HVB SET and HVS RESET commands which set and reset a logical flag. These commands are used in the day and night OG's (the HVU's are normally turned off at night). The high voltages are disabled during the SAA by the use of the RBM flag line - this is also a logical flag which is separate to the commands above and whose state is not directly reflected in BCS telemetry. If these HV commands are used in any other pattern (e.g. if reset and set are used in the entry and exit of SAA), unexpected states can occur (i.e. HVU's turning on at night). There is also a power switching relay for each High Voltage unit. If it is necessary to turn off the BCS high voltages without changing the contents of the OG's, commands to these relays (HVA POWER ON, HVB POWER ON and HVAB POWER OFF) should be used. However, these commands should NEVER be included in on-board command sequences (OG's) otherwise there will be no way to disable the HVU's short of turning off the spectrometers. Turning the spectrometers off has not been considered desirable since we encountered a problems with the relay just before launch. The microprocessor has access to two control lines that allow it to turn off the HV's (it cannot turn them on again). In normal running, there is a routine in the microprocessor which monitors the background (if enabled and an SAA threshold is loaded) and will turn off the HV's if a threshold is exceeded. Once this routine has acted, it continues to send HV OFF commands until reset. The HVU's can only be turned on by doing an HV RESET command, followed by HVA SET, HVB SET commands. (Note: routine currently not enabled, 5/11/91.) The same control lines are used to disable the HVU's whenever the micro enters kernel mode. This is a safety feature - it makes no sense to have the micro running Kernel mode, with HV's on. HV's can be turned on normally after exit from Kernel mode. b) Voltage control The trim level on the HVU's is used to control the high voltage level and hence the gain of the detectors. The electronics were setup so that the two detectors, despite the difference in the energies of the photons that are observed, would be at nominal gain with a trim level of 4. The trim levels are set to 0 if the microprocessor enters Kernel mode, and are set to 4 and 2 for BCS-A and BCS-B respectively during the source calibration (the BCS-B trim level needs to be changed so that the gain of the detector is depressed sufficiently for Fe 55 photons to be seen in the PHA). At all other times they should both be 4. Should the gain of the detectors change over the course of time, it may be necessary to adjust the HV trim level. This should only be done in consultation with MSSL personnel. In order to make a permanent change, it will be necessary to modify the setup OG used when rebooting the BCS Page 2 microprocessor since it is this that sets the values. Any changes to the trim levels should be logged in the file BCS_LOGS:HV_LOG.DAT. 2 SCA DISCRIMINATORS Limits on the photon energies accepted in each channel may be set using the SCA discriminators. There are two SCA's per channel (LOW and HIGH), and the values are normally set using ROG #60 hex (96 decimal). If the values are to be changed, mark up the OG and give it to the Tohban to be loaded into the OG store in the spacecraft. The values can then implemented by executing ROG #60 at the next KSC pass. Confirmation of the new values can be made by examining page 4 of the BCSQLGD programme. All changes of the SCA values should be logged in the file BCS_LOGS:SCA_LOG.DAT. The IDL routine DETECTOR_SUMM may be useful to determine the actual times that the SCAs were changed (record the time after all have been changed). 3 DETECTOR SOURCE CALIBRATION Once every 2-3 weeks, we need to calibrate the BCS to ensure that the detectors are healthy. The source calibration takes about 10 minutes and should be done at night, outside of the SAA; the data should be protected by declaring "Campaign Mode". It is best to use a night sandwiched between KSC passes - avoid the pass itself and make sure that there is at least 8 minutes between the end of the calibration and the start of an SAA (i.e. use a night were the SAA is well towards the end or beginning of the night if the SAA is during night), try to avoid areas with a high orbital background. Do the calibration in the middle of the week - you have a better chance of getting the data in a reasonable time. The standard BCS Source Calibration is given on a control sheet. The wait times are specified, only the start time needs to be specified. Inform SXT you are scheduling one in case they have a reason why it should not be done at the selected time - this is because the sequence of OG's sets SXT Control Manual which resets the SXT table. Wait in OP OG #65 SXT CNTL MANU 1 OG #30 CMPN MODE ON 1 OG #97 BCS SRC CAL ON 20 wait ~10 minutes OG #98 BCS SRC CAL OFF 1 OG #31 CMPN MODE OFF 1 OG #64 SXT CNTL AUTO A photocopy of the OP list that contains the source calibration should be filed in the binder as soon as the calibration has been planned - this is to ensure that we can retrospectively look for the data if for some reason it is not reformatted immediately. When the data has been reformatted, use the IDL routine BCS_PHA to extract and plot the PHA data for each channel. The PHA data is contained in the DP_SYNC structure, so do not forget to request this data. I have never managed to make this routine 100% foolproof, so I usually run it once to the screen to check whether I need to use different limits other than the ones determined automatically, and Page 3 then I select the PS plotting option and run again. The plots of the PHA data should be filed with the header copy of the OP list in the binder. The results from the fits (the centroid and the FWHM values) should be logged in the file GAIN_LOG.DAT. The contents of this file can be plotted using the IDL routine GAIN_PLOT4 - set plot to PS if you want a hard copy (I usually only bother every few times). A summary of the time that a source calibration occured, together with the temperature, HV level and radioactive source counting-rate, may be obtained by running FIND_CAL within IDL. It is also possible to use this routine to search for calibrations that were incorrectly logged. 4 DETECTOR STIM CALIBRATION Once every few weeks, the linearity of the BCS needs to be calibrated. The stim calibration takes about 5 minutes and can easily be done during a day or night Real-time pass at KSC (or from the OP). The HV's are turned off by the start OG and will need to be turned on again at the end if it is daytime, non-SAA at the end of the calibration. NOTE: QUIET/HIGH or FLARE/HIGH is required since the PH data is needed - ACS/HIGH or any other HIGH will not be of any use!! ROG #63 BCS STIM CAL ON wait 5 minutes ROG #64 BCS STIM CAL OFF If daytime, turn HV's on again HVA SET HVB SET 5 MICROPROCESSOR KERNEL MODE The microprocessor has a small kernel code that it executes when it is first started, but normally executes its main programme. Whenever Kernel mode is entered, certain devices are set to default parameter values. Thus, the SCA's are set to 00 and FF (hex) for each channel, the HV trim levels are set to 0 for each channel, and the HV's are continuously commanded off (see section on High Voltages). On exit from Kernel mode, these things need to be reset to their proper values. This is done when recovering from an SEU - see the section on this. Kernel mode may be entered if the CPU is affected by an SEU, or crashes for some other reason (the latter ought not to happen - I hope). Kernel mode can be recognised by the presence of 7A,08 hex in the second row on micro DHK bytes (W66, F256n + 60 and 61), and by the fixed values in the 2nd byte on the first row (W66, F256n + 29), and counting byte in the 1st byte on the first row (W66, F256n + 28). Normally the first two bytes on the first row are a 16 bit clock. These can all be seen in the DHK block on page 7 of the BCSQLGD displays. See the Telemetry Document for more information. The value of the BCS clock is one of the variables plotted on the CPU_DIAG plot. When the microprocessor is running normally, this 16 bit word should rollover every 8192 seconds (~2.3 hours). If the microprocessor has crashed, it will rollover every few minutes. Page 4 6 SEU'S Because of the altitude of the orbit of Solar-A, it is likely that the spacecraft will suffer from Single Event Upsets (SEU's). An SEU is a bit change that occurs within the Random Access Memory (RAM) of the BCS microprocessor and may affect the running of the instrument. Experience from the WFC on ROSAT, and the SXT and BCS so far on Solar-A, an SEU rate of around one per 2-3 weeks can be expected. Most SEU's will probably occur within the South Atlantic Anomaly (SAA), particularly if the satellite apogee is within this radiation belt. In the normal mode of BCS operation, a routine runs continuously in the microprocessor which calculates an Exclusive OR checksum and sets a flag if the result, exclusive OR'ed with a loaded value, is not zero. This flag is shown on page 7 of BCSQLGD (MEMCHK, in the top, left corner), on the plot CPU_DIAG, and on the SA plots. The SA plots are checked by the Yohkoh Tohban each day, although it is likely that most of the SEU's will be caught by the daily checks by the BCS Tohban. If an SEU occurs, the procedure is to reboot the microprocessor (dump to find the SEU, recopy the code, apply any patches, dump again to confirm the new load and restart normal operations). Previously, the reboot was done using ROG's and a Real Time Command Request Sheet. However, the procedure was modified (by Watanabe-san) so that the commanding of BCS memory dump can be done from the MS computer - this allows the MS computer to compare the dump with a stored image of the contents of the microprocessor memory and check for possible problems. Notes: 1) Normally, there will be one none-compare by the MS computer on the first memory dump, and none on the second dump. In the event that the SEU caused secondary damage to the microprocessor code, there may be more than one error on the first dump, but if the reboot has been successful, there should be zero errors on the second dump. 2) The patch of the microprocessor requires several ROG's to be executed in sequence. Each ROG must be allowed to finish before the next one is started, otherwise the following ROG will be ignored. If at the second memory dump there are a few errors (10-20), the most likely source of error is mis-operation by the KSC Tohban - that is, the ROG's have not been executed correctly. Although this issue has been raised many times, it seems impossible to ensure that this procedural mistake is not repeated several times a year. If it does occur, the reboot must be repeated from the start. 3) Because of an interface problem, the nature of which has not been identified, if the BCS Memory Dump is commanded from ACS Mode, or Night Mode (i.e. a mode in which no PH data is output) an extra byte is inserted at the start of the dump and the entire dump is shifted by this one byte. On the workstations, using IDL, this does not cause a problem - the location of the start of the dump is determined by looking for the starting bytes. However, on the MS computer, such a failure to switch to Quiet-Hi or Flare-Hi from Night or ACS-Hi will result in many thousands of non-compares. It is possible that the reboot went perfectly successfully, but because the MS computer code is unable to find the dump, it is safest to repeat the procedure. 4) Because of the way the DP is constructed, whenever the BCS-MEM-H is complete the DP automatically switches back to the current, normal mode. If the spacecraft is in night, this will result in the spacecraft entering NIGHT-LOW. Thus, at night-time, the BCS-MEM-H should always be Page 5 followed by a ACS-H or QT-H command to ensure that high bit-rate continues. 5) The last command sent during the reboot is the checksum value that is to be used by the microprocessor to look for an SEU. This must be recalculated each time the patch is modified. The command must be related twice - first to load the by and then to force a comparison to be made. If it has executed correctly, after the second time the memory check flag should have been cleared. 6) Some SEU's may affect the telemetry stream and so the SEU flag may not be raised. You should also check that the microprocessor is running correctly (clock rolling over, spectra coming out) when checking the proper operation of the BCS instrument. All SEUs should be logged in the file BCS_LOGS:SEU_LOG.dat. The IDL routine MEMCHK_TIMES is useful when trying to determine the time, and geographic location (in or out of SAA) of the SEU. The IDL routine DUMP_COMPARE should be used to extract the dump from the telemetry and compare it with the basic ROM copy. This programme normally outputs to the screen. However, if the variable TTL is set to 2, then the output is directed to a file (MEM_COMP.LIS) which can be printed later. Remember that there are two dumps each time a BCS Recovery is performed because of an SEU (or the BCS micro is patched). The location affected by the SEU should be determined from the first dump (by comparing it to the second dump the last time it was rebooted) and should also be logged in the file BCS_LOGS:SEU_LOG.DAT A printout from MEMCHK_TIMES, and the results from the comparisons of the two dumps from DUMP_COMPARE should both be filed in the binder. 7 MINIMUM THINGS TO LOG Sometimes an "event" is known to have occurred, but the data has not been returned for one reason or another (reformatter run at the wrong time, DSN data excluded, etc.). Just about everything can be determined retrospectively, so long as we know roughly when the "event" happened. Thus as a minimum, please log the following: SCA and HV settings Approximate time of change (within a day) in the two files SCA_LOG.DAT and HV_LOG.DAT which are located on BCS_LOGS: SEU Approximate time that the BCS Recovery was performed. A photocopy of the KSC daily log (FAXed to the SSOC each day) should be made and filed in the binder. Source Calibration Photocopy of OP load that scheduled the calibration filed in binder. Stim Calibration Photocopy of OP load, or command sheet filed in binder. 8 SOME ADDITIONAL COMMENTS Page 6 8.1 Printouts I usually use PSLASER to output text to the laser printer. This puts proper margins on the pages which makes it easier to file. Two symbols are setup, TEXTP and TEXTL which can be used to print in the normal style (portrait) and in lineprinter style (landscape). All the logs would need to be printed with TEXTL since they use >120 columns. (It can be very frustrating if the byte that contains the SEU disappears under the hole made by the hole punch) 8.2 Logicals All the log files are kept on the directory [YOHKOH.BCS.STATUS], which has the logical BCS_LOGS associated with it. The required IDL software is under YUKON:[BENTLEY]. 8.3 Dates All dates are numeric in the form dd/mm/yy.