ASI Scheduler
Current version (1.0)
The scheduler program (ascd.c) used on the three "modern"
NORSTAR imagers was written by Trond Trondsen, based partially(?) on
work by Mikko. The idea is that the exposure parameters for each
filter are defined explicitly at the start of the program:
/* -- Filter 1 ---------------------------------*/ #define F1_WAVEL 4864 #define F1_LABEL "4861" #define F1_DESCR "Narrowband, BW = 3.0 nm" #define F1_EXP 6000 #define F1_IIGAIN 2 #define F1_CCDGAIN 0 #define F1_BINNING 2 /* -- Filter 2 ---------------------------------*/ #define F2_WAVEL 4806 #define F2_LABEL "BACKGR" #define F2_DESCR "Narrowband, BW = 3.0 nm" #define F2_EXP 6000 #define F2_IIGAIN 2 #define F2_CCDGAIN 0 #define F2_BINNING 2 /* -- Filter 3 ---------------------------------*/ #define F3_WAVEL 5581 #define F3_LABEL "5577" #define F3_DESCR "Narrowband, BW = 2.0 nm" #define F3_EXP 1000 #define F3_IIGAIN 0 #define F3_CCDGAIN 0 #define F3_BINNING 2 /* -- Filter 4 ---------------------------------*/ #define F4_WAVEL 6304 #define F4_LABEL "6300" #define F4_DESCR "Narrowband, BW = 2.0 nm" #define F4_EXP 2000 #define F4_IIGAIN 1 #define F4_CCDGAIN 0 #define F4_BINNING 2 /* -- Filter 5 ---------------------------------*/ #define F5_WAVEL 0000 #define F5_LABEL "NIR" #define F5_DESCR "Near-Infrared, Cutoff = 650 nm" #define F5_EXP 200 #define F5_IIGAIN 0 #define F5_CCDGAIN 0 #define F5_BINNING 2 /* ---------------------------------------------*/
with the fields described as follows:
/* EXPOSURE PARAMETERS FOR EACH FILTER WHEEL POSITION
For each filterwheel position, specify the following:
F?_WAVEL -> Interference filter ACTUAL center wavelength in Angstroms. Set to 0000 if
this filter is NOT an interference filter (also if NO filter mounted here).
F?_LABEL -> Short (max 15 characters) descriptive label containing no whitespace,
for use in image file name. It is recommend to use "0000" or "NONE" if no filter
is mounted here. For an interference filter of center wavelength of (e.g.)
6304 AA, the label "6300" could be used here, and so on. A mnemonic only.
F?_DESCR -> More verbose text that describes the type of filter, bandwidth, etc.
F?_EXP -> Exposure integration time in MILLISECONDS
F?_IIGAIN -> IMAGE INTENSIFIER GAIN to be used with this filter, range [0-3].
F?_CCDGAIN-> Photometrics Series 300 camera CCD GAIN, in the range [0-1], to be used with
the specified filter. 0 is "normal" gain, 1 is "high" gain.
F?_BINNING-> CCD binning to be employed with this filter. Assuming horizontal binning
is equal to vertical binning, preserving a square aspect ratio. An F?_BINNING
of 1 yields a 512 x 512 image. F?_BINNING of 2 yields 256 x 256, and so on. */
The actual schedule is based on a lookup table with one slot for each second
of each minute of the hour. Each slot contains an integer, with each bit
corresponding to a filter. At any instant, the scheduler program checks the
corresponding slot in the lookup table. If any bits are set then the
appropriate exposures are made.
/* BLOCK 1: Overall imaging schedule. See above explanation... */
for(min=0; min<60; min++) /* define one entry for each sec */
for(sec=0; sec<60; sec++) /* of each min of the hour */
{
if(sec==0)schedule[min][sec] |=(FILT1 | FILT2);
if(sec==20)schedule[min][sec] |= (FILT3 | FILT4);
if(sec==30)schedule[min][sec] |= (FILT3 | FILT4);
if(sec==40)schedule[min][sec] |= (FILT3 | FILT4);
// if(!(sec%30))schedule[min][sec] |= (FILT1 | FILT2 | FILT4);
// if(!(sec%15))schedule[min][sec] |= (FILT1);
// if(sec==0 && min!=0)schedule[min][sec] |=(FILT1 | FILT5);
}
This is extremely flexible, and a few lines of code can set up
relatively complex schedules. Furthermore, a "chain" of exposures
can be associated with a given time bin simply by ORing
multiple exposures.
Dark frames are obtained with the use of a separate lookup table in the following manner:
for(min=0; min<60; min++) /* Cycle through all minutes of the hour */
for(sec=0; sec<60; sec++) /* Cycle through all seconds of the hour */
if(min==0) /* Set the darkflag to TRUE at desired instant */
darkflag[min][sec] =1;
else /* Otherwise, darkflag is to be FALSE */
darkflag[min][sec] =0;
Version 2.0 ?
The current scheme (version 1.0) works extremely well. My only complaints are relatively minor:
- By associating each filter with a single exposure bit flag, it is impossible to "chain" multiple exposures of the same filter.
- Having to edit and re-compile the scheduler for each change is a bit inconvenient. Admittedly, it does make for a single standalone package.
experiment.txt file that
defines possible exposure types, each with a distinct label:
LABEL redline16 FILTER_NUMBER 0 EXPOSURE_TIME 1600 INTENSIFIER_GAIN 1 CCD_GAIN 0 CCD_XBIN 2 CCD_YBIN 2 CCD_X0 0 CCD_Y0 0 CCD_X1 511 CCD_Y1 511 LABEL greenline2 FILTER_NUMBER 3 EXPOSURE_TIME 200 INTENSIFIER_GAIN 1 CCD_GAIN 0 CCD_XBIN 4 CCD_YBIN 4 CCD_X0 0 CCD_Y0 0 CCD_X1 511 CCD_Y1 511and then a
schedule.txt file defining the
sequence of events.
The idea is for the scheduler to determine the current time in HH:MM:SS
format. This is then compared with the first field in each of the schedule
lines until a match is found. For the example given here
:00:05 redline16_DARK greenline2_DARK :05 redline16 greenline2 redline16 :35 redline16 :45 greenline2 greenlin2 greenline2dark frames would be acquired at 5 seconds after each hour, with other exposures at 5,35, and 45 seconds of each minute.
It would be sufficient to use the standard
c library routine strstr. I'm not sure how hard it is to do
simple pattern matching (ie. ??:05:[135][012] ) or even possibly
regular expressions. Probably overkill, but it would add tremendous flexibility.
Once a match is found, any subsequent fields are assumed to be experiment labels.
All experiments will be executed in order, after which the scheduler loops until
another match is found. The one tricky thing is that I think that _DARK
appended to any label should implicitly mean that the shutter must also be closed.
Otherwise we'd have to define at least two experiments (one normal and one dark) for
each filter. This would be a step backwards from the current system.
Something like this proposal would give us (too much?) flexibility. One obvious cost is the potential for trouble if a "experiment" or "schedule" file is malformed. Paranoid parsing should help minimize this possibility.
Also, the instrument name should probably be appended to experiment and
schedule files (ie. experiment_poca0.txt) to allow operation
of multiple instruments.
