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.