---------------------------------------------------- Notes on star tracking, OT shifting, and prediction: ---------------------------------------------------- The basic idea behind OPTIC's operation is that it is tracking 1-4 stars found the "lower" CCD regions via "shutterless video" while the "upper" parts of the CCDs are accumulating a science image. Shift corrections are applied to the science regions during the exposure to compensate for image motion. There are therefore a number of related but different functions which must be carried out for this to work: 1. Guide stars have to be tracked at high speed 2. Guide star positions have to be analyzed 3. Temporal predictions need to be made for where the guide stars will be at the next iteration. 4. Spatial predictions need to be made for how to translate guide star position in the lower regions to image motion in the upper CCD regions. These will be discussed in turn, with emphasis on how the user can influence and optimize the performance. Tracking guide stars -------------------- Once a guide star has been identified by its location, otcom can read out a small box of CCD containing the star. It rapidly clocks the lower, guide region of the CCD horizontally to bring the patch to the xoffset requested by the sgformat, then rapidly clocks it vertically to the yoffset, then does a normal readout with the requested binning and size. All of this is done while leaving the rest of the array quiescent. The parallel clocking presently occurs at a rate of about 12 usec per pixel, so there will be a small horizontal smear on one side of the star image left behind by the guide star (or any other source in the field, but generally the guide star is the brightest thing present) as the pixels are clocked by. After the patch is read out, a new clean patch is clocked down under the star for the next integration, and this will leave a small vertical smear on one side of the star. As an example, if the box size is 16x16, binned 2x2, the half width of 16 pixels will take approximately 190 usec to move out from under the star and so the integrated light in the smear should correspond to approximately 190 usec of exposure. The DSP code in otcom is quite general, but does optimize the shutterless video clocking strategy when more than one star is being read out. Since the read out is done in parallel, all four amplifiers are read out, although any lower region which is being used for science will not have any charge shifted to the amplifier so the image which otcom receives is just a bias. This clocking time of 12 usec per pixel can get quite long if the guide star is found on the opposite side of the chip from an amplifier -- as much as 40 msec. This clocking time and the readout time of about 6 usec per pixel are overheads which are lost to guide star integration. The overheads can be as small as 10 msec for small patches found close to the amplifiers or as large as 40 msec for large patches which are a long way from the amplifiers. Note that although there are no restrictions placed on guide star box size or binning, if the box encounters the edge of the lower CCD region you will get a truncated image. Xoptic is presently compiled with a limit of 32x32 on guide images, so that is a practical limit to the guide image size, although since the binning is arbitrary it is possible to read out fairly large regions rapidly. Because the guide regions are being read out so rapidly and are so small, the "bias level" is not very flat -- it has a component with an exponential decay away from the amplifier with an e-folding of perhaps 20-50 pixels. Also because of the desire for speed it is not possible to get a bias level in the usual way by emptying the serial register. Therefore if otcom is requested to do bias subtraction in the "tparams", it starts each exposure with a few iterations, analyzes them in terms of this constant+exponential model for bias, and then uses these parameters later for bias subtraction. You may note that the edge pixels of the guide box are not bias subtracted -- they are generally corrupted for various other reasons and are not used. Also it is possible to get a bad fit because of an incompletely erased CCD or a very bright background seen when the video bias is taken. If this happens, consider turning off the bias subtraction. Analyzing guide stars and temporal predictions ---------------------------------------------- Otcom does quite a careful analysis of the guide star images, although it could be improved quite a bit. If bias subtraction is requested, the bias is first subtracted. A sky level is determined in a robust way from the four corners (ignoring edge pixels) as the second largest value. The highest pixels is then located and a half width (HWHM) estimated in x and y by running down from the highest pixel. Two marginal cuts through the image are extracted in x and y by summing around the highest pixel to +/- 1 HWHM. A Gaussian is fitted in each direction which provides a center and FWHM in each direction. Finally the signal is added up within +/- 2.5 FWHM of the center to provide a total flux for the star. Once the stars positions are known it is necessary to make some sort of prediction where they will be at the next iteration. This has two implications -- the guide boxes are small enough that we need to follow the guide stars fairly accurately if we are not to lose them, and the accuracy of our prediction influences how well we will do in removing image motion in the science regions. These have somewhat different requirements, in that we need to be quite conservative in the guide star location prediction because we can tolerate a many pixel error and not lose the star, but if we lose the star the exposure is ruined. The standard temporal prediction method simply uses the most recent location as the prediction. Another possibility offered is a bit of code which makes a prediction based on the previous N observations. The idea is to find linear coefficients which multiply the previous N to accurately give the present value. Clearly for uncorrelation motions the coefficients should be zero, but for constant, sinusoidal motions (telescope shake) the previous three points could give a very good prediction. If requested, otcom goes through the previous time history of positions and does a fit for such coefficients and then applies them to the present motion. The coefficients get updated every iteration, so the predictions for sinusoidal motion, for example, get better as data collect. Also this has the ability to adapt to changing conditions such as phase, frequency, or amplitude of motion. The predictions must now be used to calculate how to move the guide boxes to follow the stars. The normal mode is to use the median shift of all active guide stars (plus a shift of 0 thrown to the median as a vote for conservatism), so as to have some immunity to losing a guide star because of a cosmic ray. This has the drawback that the guide boxes are all locked together so if a star is not centered after the initial tweak-up of guide box positions it will stay uncentered. Two other possibilities are to simply take the predictions at face value, but it is very easy to lose a guide star this way. Another possibility is to use the previous positions as well, and an option can be provided via "tparam" to use a median of all guide stars and the three previous iterations as well. The maximum guide box shift permitted in an interation is also limited by the "Max" parameter of "tparam", and the ratio of the indicated shift to the actual shift is governed by "Gain". In cases (such as when the UH2.2-m dome rotates) where violent image motions occur, these may be used to maintain lock on the guide stars even though they may be lost for a few frames. It would be good to use some sort of signal to noise information in the guide star analysis, but although the psf analysis returns a signal to noise for each star, this is presently not used for guide decisions. Spatial predictions ------------------- The guide stars are not cospatial with the science regions, so it is an interesting question, given temporal predictions of where the guide stars will lie, to guess where the images will shift in the science regions. Otcom provides a single method at present to do this. Each science region gets a weight from each active guide star. This weight depends on the distance of the center of the science region from the guide star, and can be varied by use of an "exponent" in "tparam", where the relative weights go as the inverse distance to the "exponent" power. So for example, and exponent of 0.01 is nearly a uniform weight of all guide stars. An exponent of 1 is weighting as inverse distance, and 2 weights as inverse distance squared. If you simply want to use the nearest guide star you could use a huge exponent, or this special case is also obtained with a negative exponent, nominally -1. We have done some experiments at the UH2.2-m to look for temporal correlations between different guide stars, which would indicate coherent turbulence blowing across the telescope pupil, and on some occasions we see such correlations at a reasonable timescale (of order 1 sec). However, they are at very low level compared to the overall image motion at the 2.2-m, so I've never had an opportunity to try to exploit temporal correlations to use the time history of guide star positions as well as their spatial locations to make science shift predictions. (The UH2.2-m mirror normally is at +2.5C, the closed telescope tube at -1.5C and ambient at -2C. The vast majority of seeing and image motion is usually generated within the telescope tube so our task of removing image motion is very simple: everything moves together.) Although there is a lot of censorship on the use of guide star positions for guide box motions, there is presently no censorship on how the guide star positions get used for shifting the science images. There should be. Summary of guide/shift iterations --------------------------------- An iteration consists of the following steps in host and DSP: 1. Issue OTF with 16 args which are the shifts applied to the 8 regions for OT tracking, and mask/shifts used on the 4 guide regions to align the guide stars for readout. 2. Host commences non-blocking DMA read on the guide regions, ships off the previous frame to the video display, occasionally issues telescope guide commands, then waits... 3. DSP immediately applies shifts to indicated subset of 8 science regions 4. DSP waits for gstime 5. DSP applies OT shifts to guide regions to bring them into alignment for a subsequent readout using ccd.G parameters. 6. DSP does normal readout of guide regions using guide parameters 7. DSP clocks down a clean bit of CCD to the guide regions 8. Host receives guide image, calculates actual GS exposure time (which is the full iteration time minus the time spent reading out) 9. Host inserts time and location stamps into 3 trailing dead pixels 10. Host unscrambles guide data 11. Host subtracts a bias from video frames 12. Host analyzes guide frames for guide star centroids, etc. 13. Host predicts where the stars will be next iteration 14. Host calculates shifts for guide boxes to follow guide stars 15. Host calculates OT shifts to apply to science regions