----------------------------------- OPTIC --- 021217 --- John Tonry ----------------------------------- ---------------------------- General hardware description ---------------------------- The Orthogonal Parallel Transfer Imaging Camera (OPTIC) consists of two Lincoln Lab CCID28 2K x 4K chips mounted side by side in a dewar. The gap between them is 1mm, approximately 60 pixels. The dewar connects to SDSU-2 electronics which contains a 12-board backplane. At present there are seven boards present: Timing board - the DSP which runs the whole thing Utility board - another DSP which does auxiliary functions Clock board (serial) - controls serial clocking on both chips Clock board (chip1 parallel) - parallel clocking for chip1 Clock board (chip2 parallel) - parallel clocking for chip2 Video board (chip1) - biases and video processing for chip1 Video board (chip2) - biases and video processing for chip2 The connection between the dewar is by a pair of 18" 128-pin cables, and the connectors on the dewar go directly to the CCDs so PLEASE NOTE: These pins are fairly delicate and it takes a lot of force to put on these connectors, so be VERY certain that - no male pins are even slightly bent out of line - ease the connectors together before tightening - you, the dewar, and the controller box are grounded together The SDSU-2 controller box is in turn connected to a power supply box via a 6' cable, a host computer via a pair of fibers (fragile, vulnerable connectors!), and the shutter and TFW filterwheel via a 15-pin, optoisolated Dsub cable to the TFW controller box. There is also a BNC connector which can be used as an alternate TTL shutter signal, and there are two TFD's on the focal plane which are brought out to BNC connectors. At the UH2.2-m approximately 30-50VAC exists between the metal of the back of the telescope and the AC ground found at the outlets on the dome floor, so it is essential that the dewar and SDSU boxes be insulated from the telescope and power brought up from the dome floor. The SDSU controller talks to a Dell Dimension 4300 host computer with a 1 GHz processor, 0.5 Gb of memory, and 80 Gb of IDE disk, of which 65 Gb is available for data storage. It has a CDR drive which can be used with to burn CDs. This seems to be reasonably reliable, although it does not check that you might overfill the CDR: mkisofs -R -J MY_DIR | cdrecord -v fs=6m speed=8 dev=0,0 - Don't try do this if you are loading the CPU, especially taking data! This will write the entire directory "MY_DIR" onto the CDR. Note that these will make "MY_DIR" the root of the CDR, i.e. a file MY_DIR/myfile will appear as /mnt/cdrom/myfile when you have mounted the burned CD. A typical night's observing, once compressed, will fit on four CDRs, taking about 10 minutes apiece to burn at 8x. The computer permits ftp and telnet as well as scp, ssh, etc, but please be careful about security. Communications is through an SDSU-2 PCI interface board. The host is nominal running RedHat 7.3 Linux, although the kernel was rebuilt in order to enable IDE disk DMA as well as to provide a source tree that the device driver could be compiled with. The default kernel is called "2.4.18-3new", and "2.4.18-3" is the basic RH7.3 kernel. The device driver is provided by Sidik Isani at CFHT, currently v2.11. ----------------------- General CCD description ----------------------- These CCDs have a number of unique features. 1. They are capable of "orthogonal transfer", i.e. the charge can be noiselessly clocked horizontally as well as vertically, which permits tracking of image motion and fast readout of guide stars. 2. They are each split into four regions with different clock lines so that each region can be clocked independently. These regions have no interruption of the metrology of the pixels however. 3. They have serial registers at both ends, and OPTIC is normally run using one amplifier at each end, hence four amplifiers altogether. In many ways it looks like four 2k CCDs butted together. This is the nomenclature normally used instead of the "chip1 and chip2" above. 2048 2048 <===============> <===============> --- +---------------+ +---------------+ | | CCD1 lower | | CCD3 lower | 516 (sic) | |---------------| |---------------| | | | | | 2052 | | | | | | CCD1 upper | | CCD3 upper | 1536 | | | | | | | | | | --- |---------------| |---------------| | | | | | | | | | | | | CCD0 upper | | CCD2 upper | 1536 2052 | | | | | | | | | | |---------------| |---------------| | | CCD0 lower | | CCD2 lower | 516 --- +---------------+ +---------------+ <===============> <===============> Various useful parameters include: pixel size 15 um readout time (unbinned) 27 sec readout time (binned 2x2) 8.5 sec CCD thickness (enhanced red response) 40 um read noise 4 e- gain 1.4 e-/ADU full well >80K e- non-linearity presently <1% to 30K ADU, but 5% at 50K ADU? dewar hold time 24 hour The results of a readout through four amplifiers are always rotated and flipped in the output file into a physically consistent picture. The bias strips for all four regions are found on the right hand side in two stripes, with the left stripe from the left chip and the right stripe from the right chip. The top of the output image corresponds to the side of the dewar opposite the connectors. With a normal view of the sky (e.g. a lens or a Cassegrain focus) the parity of the output image is conventional, i.e. east is found counterclockwise of north. With another reflections off a flat mirror the parity is flipped. Note that readout parameters refer to each quadrant and each amplifier, so that reading out 2048 x 2052 gets the entire mosaic. Also offsets are amplifier-centric, i.e. a read with an offset skips pixels upstream of the amplifiers in the serial and parallel directions, which may cause a surprising piece of the CCDs to be read. The amplifiers of the four quadrants are normally found in the lower left and upper right corners, but if the "geom" specification in the "status" command or the "CCD?GEOM" FITS header is 2 instead of 0 the amplifier is found on the opposite side of serial register. Although the four regions in each chip are fundamentally the same, the "lower" regions enjoy the ability to reach the amplifiers without disturbing the upper regions. Therefore the "lower" regions are potential locations for guide stars, and the control software will permit you to specify zero or one stars in each lower region to be used as guide stars. When exposing, the software quickly clocks a small patch which you specify around each selected guide star first horizontally and then vertically over to amplifier. This does not disturb the image in the upper regions or any unselected lower regions. The software then does a readout of the small patch, analyzes the guide stars, possibly performs shifts on the non-guide regions, and then pauses for another guide star image to collect. The overhead involved in reading out these small guide patches varies from 10 msec to 30 msec, depending on whether they are all close to their amplifiers or on the other side of the chip. ---------------------------- General software description ---------------------------- The software which normally runs OPTIC is called "otcom". The location of all software is /usr/local/inst, where subdirectories include bin - binaries, should be first in path config - setup files for telescope and filter wheel doc - documentation dsp - DSP code for the SDSU controller etc - sample save files and sound files pro - Vista procedures script - scripts for otcom src - source code for otcom The normal place where data are saved is /b0/optic. This should be writable for all users. General observers normally should log in as "obs" and there is a root account known as "otroot". See somebody knowledgeable about passwords. When otcom starts up it first checks to see whether it can communcate with the interface, initializes it, then checks to see whether it can communicate over the fiber to the SDSU controller. If so, it reads a telescope configuration file and filter definition file. Finally, it begins accepting socket connections from client program(s) which is typically the TCL GUI called "otgui", as well as accepting commands which are typed at the window where otcom is run. An important thing to do at this point is to "download the DSP code". The DSPs in the SDSU controller boot from ROM, but need specialized code which is adapted to the particular CCDs and hardware connections and which can run the needed routines. For OPTIC, the normal DSP code is called "optic4.lod" for the timing board and "opticlub.lod" for the utility board. These are automatically downloaded when you type "df" at otcom. In principle this ought to be done as part of the initialization, but it isn't (yet). Otcom has a very simple interpreter which accepts commands (any unique abbreviation is acceptable and case does not matter), and carries out actions such as "clear 4" (clear the CCDs four times), or "go" (perform a readout", or "status" which lists the important variables and state of the camera. These will be detailed later. The GUI allows the user most of the functionality of the command line interpreter in a more intuitive graphical format, but it is important to realize that the standard input of otcom is normally accessible for typed commands. Each command which the GUI passes on to otcom is echoed in the GUI's log window, and these commands can be typed directly in the "Command:" entry window of the GUI or at otcom's standard input. The reason that it's worth going beyond the GUI is that otcom has a script facility (described below) which can be extremely useful, but it only uses the command set, of course. Most of the communications from otcom are shown in the log window of the GUI but not all. In particular (this is probably a bug), if otcom requires interaction with you, perhaps because you entered a command with unacceptable arguments or because you are trying to overwrite an existing file, it does so via the otcom's standard input, *not* the GUI. Therefore otcom should never be run purely as a server in the background, but should be run as a normal program in a window of its own. If OPTIC is run as a conventional CCD there are no other windows which the user needs to know about. However, if OPTIC is run with guide stars or in tracking mode there are two other windows which might appear. The command "FGS" (Find Guide Star) is a kludgey thing which takes a quick exposure of the lower CCD regions (i.e. bottom 516 pixels), binned 2x2, and pops up an image from which the user can select guide stars. It's use is described below in detail, but this is how the user chooses stars (or not) for guiding and enters the coordinates. When the user has selected "OT" mode and starts an exposure, another window, called "XOPTIC", pops up which shows video of the guide stars and various statistics about them (also described in detail below). Finally, OPTIC has a few utilities which are good to know about. One is called "othead" which will dump out one line of header information from an exposure (or a title line with no argument). This is helpful for making an automatic log of a night's observing. See below for more details. The other important utility is called "conflat". The result of OT shifting an image is that each pixel in the final image has actually been integrated on a variety of physical pixels. An exposure during which OT shifting has taken place normally writes several auxiliary files in addition to the final image: myprefix_fgs.??? - guide star locating image used by fgs myprefix_gsc.??? - guide star locations which were chosen during fgs myprefix_gs.??? - table of guide star locations and properties myprefix_ot.??? - table of where each pixel was integrated myprefix_tg.??? - telescope guide commands (if enabled) myprefix_vid.??? - 3D FITS file of all video images Conflat takes an unshifted, unbinned flatfield and convolves it according to the data in the '_ot' file so that it agrees with the OT convolution which took place in the image file. A note about file names. In some people's opinion, a mandatory suffix of ".fits" for FITS files is stupid and contributes to the general problem of RSI, and the refusal of the FITS standard to recognize unsigned 16-bit integers also stupid, given the properties of A/D converters, and is curiously in conflict with the 2880 byte block size and mandatory byte order on which FITS is based. Otcom by default writes files which consist of a prefix and a 3-digit suffix, e.g. "/MI5/bond.007", and writes *unsigned* 16-bit integers. If you don't like the file names, create a script which will rename them after the fact. If you insist on *signed* 16-bit integers (with an appropriate BZERO), you can use the "set" command described below to enable it. ---------------------------------- Starting tutorial on running otcom ---------------------------------- Here's a simple session you might carry out which will illustrate most of the important features of OPTIC. What you type is indicated by a >> prompt. Start up otcom: % otcom OTCOM v2.1 logonly: Found SDSU card at /dev/lotuspci0, fd=3 Interface is alive,logonly: Fiber reset to SDSU GEN2 mode interface is reset Controller alive, please download DSP code! Reading tel_config info from /usr/local/inst/config/tel_config Tel: 3.5m at f/6.3, Scale: 0.141"/p, Inst: OPTIC: 4-10-2 & 4-3-2 Reading from filter file /usr/local/inst/config/filters.def Filter #0 is 'V', ZP = 26.50 Filter #1 is 'R', ZP = 26.50 Filter #2 is 'U', ZP = 24.00 Filter #3 is 'z', ZP = 25.10 Filter #4 is 'W022', ZP = 25.00 Filter #5 is 'B', ZP = 26.40 Filter #6 is 'I', ZP = 26.40 Filter #7 is 'W021', ZP = 25.00 Setting default params. cmdqueue: Communications to clients started on port 9511 error: Can't read symbol ST_SH... Have you downloaded yet? 001> selectserver: new connection from 127.0.0.1 on socket 5 Client 0 on descriptor 0 from server stdin (127.0.0.1) Download the DSP code as requested: >> df High voltage off... info: Downloading ./optic4.lod... logonly: 477 symbols defined info: Verifying downloaded code... info: Downloading /usr/local/inst/dsp/opticlub.lod... logonly: 730 symbols defined info: Verifying downloaded code... warn: P:0x000091 -- 0x000004 sent, 0x053779 received logonly: P:0x000091 -- 0x053779 OK now Found all the symbols, proceeding with clock rewrite... Boot code updated to allow >7 arguments... info: Filter is positioned at 3 Frame: 001 File prefix: '/tmp/ccd' Filter 3 'z' Shutter 0 Science: bin 2x2, origin (0,0), size (1024,1026), 32 bias, 4 amp, texp 1.00 Guide: bin 2x2, origin (1,1), size (16,16), geom 0,0 0,0, texp 0.050 GS at: 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 Params: nwipe 1, shut 1, read 1, wrdat 1, track 0, wrot 0, wrvid 0 OT track: alg 10, wait 5, gain 1.00, max 8, regions 11111111, wgt -1.00, bias 1 Tel guide: on? 0, rmin 2.0, tmin 1.0, gain 0.50, PA top 0.0, EccwN? 1 Turn on the high voltage: >> pon High voltage on... status: 0 p5v 5.05 p15v 16.4 m15v -16.4 p35v 36.0 Check that it happened: >> volt status: 0 p5v 5.05 p15v 16.4 m15v -16.4 p35v 36.0 Set the temperature regulation to -105C (necessary every new download): >> temp -105.000000 status: 0 tccd -104.9 tset -105.0 telec 22.1 hperc 0 Set the file prefix and file number: >> fp /b0/optic/021217/f status: 0 fp /b0/optic/021217/f >> fn 24 status: 0 fn 24 Check out the status of everything >> st Frame: 024 File prefix: '/b0/optic/021217/f' Filter 3 'z' Shutter 0 Science: bin 1x1, origin (0,0), size (2048,2052), 32 bias, 4 amp, texp 20.00 Guide: bin 2x2, origin (1,1), size (32,32), geom 0,0 0,0, texp 0.050 GS at: 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 Params: nwipe 1, shut 1, read 1, wrdat 1, track 0, wrot 0, wrvid 0 OT track: alg 10, wait 5, gain 1.00, max 8, regions 13331111, wgt -1.00, bias 1 Tel guide: on? 0, rmin 2.0, tmin 2.5, gain 0.50, PA top 180.0, EccwN? 0 Set up for a dome flat, full chip, unbinned, 32 bias, 6 sec exposure: >> auto 1 1 1 1 0 0 0 >> sf 1 1 0 0 2048 2052 32 >> et 6 Take an image and write to /b0/optic/021217/f.024: >> go Take a snapshot of a field where you want to guide. (If all you want to do is use OPTIC as a conventional CCD with telescope guiding, this is all you need to ever do.) >> auto 1 1 1 1 0 0 0 >> sf 2 2 0 0 1024 1026 32 >> et 2 >> go After examining it, move the telescope to place a suitable guide star in position. It was found at 412 611 and you want it at 100 100, these coordinates being of the previous image which is binned by 2: >> telescope xyoff 412 611 100 100 2 Find the guide star(s) and mark them with a 4 second snapshot: >> fgs 4 This pops up an image of just the "lower" regions, binned 2x2, so you get an image which is 2048 wide by 512 tall, and it is displayed with a 2x compression so you see 1024 x 256. The four "lower" regions are delineated with a green cross. You then make a selection in each of the four lower regions, either hitting "e" in the displayed image to make no star selection or "x" to choose a star. (A current bug will cause the selection to fail if the star has saturated to the point of pushing the data to 0. If this happens, use "C" on the nearest bit of non-zero star. This whole FGS routine really needs work.) When you hit the fourth key (either "e" or "x") the window disappears and a new status display should show you non-zero numbers for the guide stars you have selected. If for some reason a selected star is not given reasonable coordinates, try fgs again. You are now ready to take an OT image. Set the auto parameters, choose a 200 second exposure time and a full frame, unbinned readout, a 50 msec guide star exposure time (plus overhead), and go! >> auto 1 1 1 1 1 1 1 >> sf 1 1 0 0 2048 2052 32 >> et 200 >> gt 50 >> go This will pop up a new window called XOPTIC which has lots of interesting features described below. It is for your amusement and is not important for the exposure and star tracking. In previous versions it was possible to change things such as bin factor and guide star exposure time on the fly; they will probably be restored someday. When the exposure finishes the auto parameters will cause the shutter to close, the CCD to read out, the image to write to f.026 (f.024 was the dome flat, f.025 the snapshot; the fgs image is called f_fgs.026), and various other data files pertaining to the tracking to f_*.026 (described below). ---------------------------------- Detailed listing of otcom commands ---------------------------------- Download DSP code: ------------------ df - this tries to turn off the high volts and then downloads the code to both timing and utility boards. Power on: --------- pon - turns on the high volts (i.e. +/-16 and +36. The idea is that we want the +5V on and stable so that the DACs which will supply voltages to the CCD are stable before their power is turned on.) poff - turns off the high volts. tdl - test data link, pings the CCD controller Verify temperatures and voltages: --------------------------------- temp - view temps of CCD and electronics temp -105 - set CCD regulation temp to -105 volt - view voltages Status: ------- status - shows what's doing, crowded but pretty complete: Frame: 001 File prefix: '/tmp/ccd' Filter 1 'R' Science: bin 1x1, origin (0,516), size (2048,1536), 32 bias, 4 amp, texp 1.00 Guide: bin 2x2, origin (1,1), size (16,16), geom 0,2 0,2, texp 0.020 GS at: 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 Params: nwipe 1, shut 1, read 1, wrdat 1, track 0, wrot 0, wrvid 0 OT track: alg 0, wait 5, gain 1.00, max 8, regions 11111111, wgt 2.00 Tel guide: on? 0, min 2.0, gain 0.35, PA top 0.0, EccwN? 1 The first four lines are relatively self explanatory, although it's important to realize that the guide box specification has two parts. There is a common "bin origin size" for all stars, which is used in reading out the little regions around them. The "bin" and "size" define the box parameters, and the "origin" defines where the boxes are shifted prior to readout. An origin of (0,0) or (1,1) is good. The fourth line defines the center location for each of the stars (or zero if that region is not going to be used). It is set by fgs or guide. The fifth line describes the OT tracking parameters which are explained in detail above. The sixth line does the same for the telescope guide parameters. Usual sorts of CCD control commands: ------------------------------------ fnumber N - set the running file number to N fprefix xx - set the file prefix to xx, i.e. output file will be xx.N sformat - set the CCD readout format. This can take 7 arguments or otcom will prompt you for them if you do not supply them. The arguments are (in order) xbin ybin xoff yoff xsize ysize nbias e.g. sf 2 2 0 0 1024 1026 32 where the bin factors can be 1-N, the offsets are measured in physical (not binned) pixels, and the sizes and number of bias overclocks are in binned pixels. etime T - set exposure time to T filter (N) - request or set the filter to N (UH2.2-m and TFW only) go - do an exposure. This can perform a large variety of actions depending on the "auto" parameters. There are also piecemeal versions of go: clear (N) - clear the CCD (N times) shutter A - open/close the shutter if A is "open" or 1 / "close" or 0 expose - open shutter (if auto permits), wait, and close shutter rc - read out CCD (and write files if auto permits) wf - write files (according to auto) auto - set up the automatic actions to be undertaken with "go" This can take 7 arguments or otcom will prompt you for them if you do not supply them. The arguments are: #wipe do_shut? readout? wr? do_OT? wr_OT? wr_vid? #wipe = number of clears before an exposure do_shut? = 0/1 to open the shutter for an exposure readout? = 0/1 to readout after the exposure completes wr? = 0/1 to write the image to a file after readout do_OT? = 0/1 to follow guide star(s) and do OT shifting wr_OT? = 0/1 to write the (all important) OT data file wr_vid? = 0/1 to write the 3D FITS file of the GS video some examples will make this clearer: normal snapshot auto 1 1 1 1 0 0 0 bias or dark frame auto 1 0 1 1 0 0 0 (depending on et=0 or et>0) focus frame auto 0 1 0 0 0 0 0 (would be preceded with clear, and followed with an auto 1 1 1 1 0 0 0 and an "rc" or an auto 0 0 0 1 0 0 0 and a "go") OT tracking image auto 1 1 1 1 1 1 1 *LONG* OT image auto 1 1 1 1 1 1 0 exercise CCD auto 1 1 1 0 0 0 0 (maybe while looking at signals with an oscilloscope) tel cmd - do a telescope command. There are a variety of commands available for a given telescope. You can probably count on the following ones: tel roff E N = do an offset from the current position of E and N arcsec tel xyoff dx dy = offset dx,dy unbinned pixels tel xyoff xfrom yfrom xto yto = offset to-from, unbinned pixels tel xyoff xfrom yfrom xto yto bin = offset (to-from)*bin tel afocus F = set the telescope focus to F tel dfocus D = change the telescope focus by D Note that the "tel xyoff" command depends on otcom knowing the orientation of the CCD; see the gparams command below. At the UH2.2-m there is a large variety of commands which are probably already familiar to users of tcdcom At WIYN there are three other commands: tel info = dump out the telescope's idea of things tel filter N = set the filter to F (note that this currently uses N=0-7 for WIYN filters 1-8, sorry) tel exptime T = set the WIYN shutter exposure to T this is overridden by "et" if T>4 sec, and et>4 sec, but defines the actual exposure for 1> Most of the GUI should be familiar from the descriptions of the otcom commands above. Starting at the top: The upper left has a menu bar with four items: Init - Power - Download - (df) - Exit View - OT params Tel - On/Off - Windscreen - Mirror Cover - Dome Fluorescents - Dome Incandescents Help - all bogus, as yet. The Init commands are explained above (pon/poff, df) The View command pops up a window to control the OT parameters (tparam) and will be discussed in detail below. The Tel command, for the UH2.2-m only, implements some telescope commands which are helpful for taking dome flats. The upper middle shows the voltages, and is green if they are in range and red if not (the volts command). The upper right shows the CCD temperature (temp) and an entry window where the temperature can be set, followed by the electronics temperature. Again a green color indicates good values and blue or red indicates too cold or hot. Between the CCD temperature and the CCD set temperature is a little thermometer graph which shows the percentage of heater which is on to maintain the CCD temperature. The next line in the GUI is an entry window for setting the file prefix (fprefix) and file number (fnumber). Clicking on these allows you to enter a value and hitting return within the window executes the command. There can be a slight annoyance with these (and other entry forms) which is that they are updated every time a command is executed, or every 30 seconds if otcom is otherwise idle (the otcom heartbeat). If you happen to be typing in a value during the moment that a heartbeat takes place your entry will be wiped out and replaced with the current value (which you were trying to replace). Clearly the code could be better, but it may be a while before I get to it. In the meantime, keep an eye out and if it happens you have 30 seconds before it will happen again. Right of these entry forms is the filter selection buttons. They indicate the current filters and if you click on a button it will execute the command (filter) to change filter. At WIYN the filter is controlled through the telescope command, so these buttons are not correct. The next line is the exposure time and format control. The left half is the science observations, ETime sets the exposure time in seconds (etime), and you can choose a 1x1 or 2x2 full-frame readout with the two buttons. Clicking the Other button will pop up a new row which offers complete control of readout format (sformat). There is a button to execute the command and another to dismiss the popup. << see gui_sf.gif >> To the right is the guide time and format control. You can select the guide exposure time in milliseconds (gtime), and guide formats which are binned 2x2 and have size 16x16 and 24x24. Other formats can be obtained with the "Other" button which pops up a new row which offers complete control of guide readout format (sgformat). << see gui_sg.gif >> The next row down is the exposure control. To the left is the control of the auto parameters. Three buttons are available: "Snap" to take an unshifted snapshot (auto 1 1 1 1 0 0 0), "OT" to take a tracked image (auto 1 1 1 1 1 1 1), and "Other" which pops up a new row where each of the auto options can be checked off and then set. << see gui_auto.gif >> The right half of this line has buttons to do an FGS (with default exposure of 2 seconds), a GO (the button changes to PAUSE and RESUME) during an exposure, but caveat emptor), an elapsed time counter, a button to open and close the shutter and indicate its state. The individual exposure commands can be accessed by using the "More" button to pop up a new row with "Clear", "Expose", "Read", and "Write". << see gui_expose.gif >> The two essential and variable telescope guide parameters are visible at the left of the next line. PA displays (and sets) the PA of the top of the detector. The checkbutton tells whether telescope guiding is enabled or not. The "Gpar" button pops up a row which offers control of the rest of the guide parameters (gparams). << see gui_gpar.gif >> The right half of this line is used to issue telescope offset commands. The "Focus:" entry can accept an absolute focus value and hitting Enter will issue the "telescope afocus F" command. At present there is no way to do a "tel dfoc" command from the GUI. The next two entries are used to enter offsets in arcseconds and issue them to the telescope. The "XYoff" button pops up a new window which offers the two "tel xyoff" formats, two arguments for an offset in unbinned pixels and five for a from,to x,y pair with a specified bin factor. << see gui_xyoff.gif >> The "View - OT params" menu item pops up a window which shows the current OT parameters (tparam), as well as offering a menu to set the prediction and tracking algorithm. To the right is an attractive schematic of the two CCDs whose color reflects each region's use. Guide stars are drawn in this window, and because of what appears to be a bug in Tk they are never deleted until the window is dismissed and reinvoked. << see gui_tpar.gif >> Finally, there is a log window where the commands which are being issued to otcom are echoed after a ">>" prompt, and output information from otcom is printed. Below this is an entry window in which you can type any command and send it to otcom. This will be sent if you hit enter or if you click the "Run it" button. To the left of the command window is a little button which changes state with each heartbeat, i.e. with each command or every 30 seconds. The lower right has a "Macro" button which can be popped up to select a script. Selection of a script and use of the "Open" button will do a "call script", but it's far easier to just type it. This might evolve to a list box with the most recently invoked scripts which could be reinvoked with a button click, but the GUI is already getting a bit crowded and I tend to type the commands anyway. ------------------------------------------------- Booting up the computer and startup at a new site ------------------------------------------------- 1. Boot up the default kernel (2.4.18-3new) 2. log in, save old XF86Config files, run Xconfigurator (as root) for the monitor you are connected to. The video board will not probe properly so you need to tell it "32 Mb". 3. startx to begin X. 4. run neat (as root) to set up network (DHCP we hope) 5. insert the SDSU PCI driver module (as root) cd /usr/local/inst/src/otcom/Driver/lotuspci-2.11 insmod lotuspci.o lsmod 6. Make sure that disk DMA is on (as root): "hdparm -d1 /dev/hda" 7. Edit the files in /usr/local/inst/config (create your own and change the two soft links "tel_config" and "filters.def"). If you don't want to communicate with a telescope TCS, comment out the TELESCOPE line in tel_config. 8. Connect up the dewar, controller, fiber between the controller and host. Power on the controller and three LEDs should go on in the controller box dark window (more lights will come on when the high volts are powered on via software). Look for the green LED on the host interface board which indicates fiber communications. If not on, try swapping the fibers. 9. Start otcom and check to see that it reports communications with the driver, interface, and controller. Download ("df") and see if it executes without reporting an error. Power on ("pon") and see if it executes without reporting an error. Use "volt" to examine the voltages. Nominal is 5V, +/-16.5V, and +36V. Verify that all the LEDs are on in the dark window on the controller box. Check the CCD temperature ("temp") and electronics temperature. OPTIC should bottom out around -110C below ambient, and the electronics cannot go above 38C or so before getting flakey (the A/D's get locally very hot and when they thermally shut down they draw a lot of current and generally trigger the power off). If the electronics get too hot, remove the perforated plate on the end of the electronics box. The CCDs normally want to run somewhere between -100 and -110C, so set the temperature regulation ("temp -104") to somewhere above bottom. Read out ("go") and see if there appears to be sensible data in all four quadrants (bias should be around 1000 ADU, noise around 2.8 ADU if the CCDs are cold). ---------------------------------------------------- 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 8 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 130 usec to move out from under the star and so the integrated light in the smear should correspond to approximately 130 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 8 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 20 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 this is presently not done. 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 ------ XOPTIC ------ Xoptic is the program which accepts a socket connection from otcom or videoplay and displays the video images and parameters which are sent to it. Originally intended to run on a Sparc2 at the same time as the CCD control program, it tries to be as efficient as possible and is written at the Xlib level. The socket communications is set up to be non-blocking (so that otcom can never hang waiting for the display) and uses a handshake to tell otcom when xoptic is ready to accept a frame. Xoptic has a lot of controls which are non-obvious because I didn't want to use up a lot of display real estate with more intuitive graphical cues, and in keeping with its lightweight nature, will only accept a limited number of X events per iteration. Nevertheless it can be quite adaptable to the user. There are three windows across the top. The left shows the incoming video frames. There are always four, corresponding to the four CCD guide regions. Even a guide star is not being read out in a region, the amplifier is still providing a readout and the noise is displayed by Xoptic. The normal zoom factor for xoptic is 4, i.e. four screen pixels correspond to one (binned) CCD pixel. There is a scale of arcseconds shown in the lower part of this image, which should be correct if the tel_config file is correct (otcom) or SECPIX? parameters in the FITS header (videoplay). Pixels which are 65535 are displayed as bright green. The middle image is the "radar" display. The left images show the guide stars in their guide boxes, but the guide boxes can move all over the CCD if the telescope guiding is not good. This radar display shows the center of each star on the CCD relative to the starting point, and can move quite far compared to the star images in the guide boxes. Clicking the left button on this window will recenter the dots relative to their position at that moment. The right image is a leaky average of the incoming video. The leak time can be adjusted using the "Leak" button below (the left mouse button decreases the number, the right button increases, and the middle button sets it to 0 which means don't update the display). The leaky average can be rezeroed using the "ZeroAve" button below. Below the image windows is the "stretch bar". This is a logarithmic graph from 20 to 65535. When the display is autoscaling you will see a green bar fluctating back and forth with numbers at either end labelled. This is the threshold and saturation for the display. If you click the left button on the stretch bar you will fix the threshold value at that value and the saturation whereever it happened to be. If you click the right button you will set the saturation value. Putting the saturation below the threshold is OK even though the green bar goes wrong -- it just inverts the color map. The botton half of the display has some buttons in the middle and two strip charts on the left and right. The "Bin" button displays the current bin factor and the "dt:" button the frame time (they used to permit you to control it, and may do it again someday). The "Palette" button cycles through a B/W, inverse B/W, and rainbow palette. The "Auto" button indicates whether autoscaling is on. Left button decreases the contrast, right button increases. The left strip chart shows the seeing FWHM as a function of time. The image for which this is being displayed is controlled by the "Img" button, left button decreases, right button increases, orientation of 0-3 is the usual. Zero FWHM is at the bottom, the left button decreases the number of ledger lines (decreases the FWHM at the top of the scale), and the right button increases the number of ledger lines (increases the FWHM at the top of the scale). The middle button cycles through a display in units of arcsec, arcsec and pixels, and pixels. The FWHM samples are shown in green and by default are smoothed with other samples. If you want to see the raw samples, the "AveFWHM" button toggles between raw and smoothed. There are also occasional little red ticks which are the FWHM being calculated for the leaky average, every leak time. They generally track the green points but are slightly higher, as you might expect. The strip chart on the right shows the magnitude of the selected star as a function of time. As always, left button decreases the number of ledger lines (full scale is fewer magnitudes), and right button increases the number (full scale is more magnitudes). Clicking the middle button near the top of the window pushes the scale downwards (moves the scale to lower magnitudes) and clicking the middle button near the bottom of the window pushes the scale upwards (moves the scale to higher magnitudes). When run from otcom, the magnitudes are based on a zero point provided in the configuration file filters.def, and should be reasonably accurate, although no account is taken of airmass. Clouds are dramatically apparent. When run from videoplay, the magnitude zeropoint is simply taken to be 25, although in principle it could be obtained from the FITS header entry "PHOTOZP" written by otcom. The bottom line lists several numbers, in a slightly different format depending on the size of the window. In the small size the labels are: Integration time # Frame number ( frames_dropped frame_time ) FW: FWHM of the selected star (unbinned pixels) rms: rms motion of recent radar positions (unbinned pixels) sky: sky level max: maximum pixel --------------------------- Bugs, notes, and specifics: --------------------------- Unknown command 127.0.0.1 ------------------------- Very occasionally the message "unknown command 127.0.0.1" will appear on the server's output, and the very next command will cause otcom to crash with a segfault. I have not been able to track this one down yet, because it is extremely intermittent. If it happens, just restart otcom (and otgui) Disk DMA -------- If you find the system really grinds to a halt just after a readout and write to disk, so much so that the mouse is only barely responsive, you probably do not have disk DMA turned on. As root execute "hdparm -d1 /dev/hda". Resetting --------- If otcom is completely unresponsive, or is acting weird, this is the sequence of things to check. Generally speaking you should not have to go beyond (4), and even that is very rare. If you do have to go beyond (4) be sure to let me know along with as much diagnostic information as possible. 1. Is otcom hanging because it's trying to communicate with the TCS? These communications can block for a long time if the TCS is not talking. Try to get the TCS going again. 2. Try a "tdl" to see whether you can talk through the interface to the controller. It may clear things. 3. Try a "pof" / "pon" cycle. Try a "pof" / "df" / "pon" cycle. 4. Try killing otcom and restarting it. 5. If you see a message like "read failed: Resource temporarily unavailable" it means that the driver is hung up. You may be able do diagnose things with a unix "dmesg". You can remove and reload the driver (as root) with rmmod lotuspci cd /usr/local/inst/src/otcom/Driver/lotuspci-2.11 insmod lotuspci.o 6. If necessary you may have to cycle the power on the controller at the telescope. This is the power switch on the power supply box. You then need to restart otcom, redownload, etc. WIYN notes ---------- At WIYN otcom does not directly control the filter wheel, nor does it have the shutter control it would like, and the communications with the TCS depends on having a server running which sometimes can be unresponsive. Since otcom is not completely integrated into the WIYN environment it is possible for it to hang up instead of ignoring an unresponsive system. The communications with the WIYN system is via a server called "simplesock.tcl" on ivory. This is found in ~wiyn/tonry and is started using the script "startserver". Otcom connects to this server and extracts information or makes requests for offsets, filter choices, or exposure time. Typing "tel info" at otcom is a good way to see whether this server is running and communicating. The WIYN filter wheel has eight positions and can be set from otcom using the "tel filter N" command. Note, however, that out of perversity otcom uses N=0:7, whereas WIYN uses M=1:8. Don't get confused! The filter information displayed in the GUI is incorrect at WIYN, and the "FILTER" entry in the FITS header is wrong, but the "TELFILT" entry in the FITS header should be correct. If the "tel filter" command should bomb, you may need to reinitialize the filter wheel. Log into pearl as wiyn_ccd, execute a "start-fsa", and then do a "filter init". You can also do a "filter set M" command from this process. The WIYN shutter has surprises. It is a rotating disk which is reputed to provide extremely accurate exposure times, although the disk sweeps across the focal plane at a modest rate. The basic function is to accelerate for 60 degrees, sweep across the focal plane at a constant speed for 60 degrees, and then decelerate for 60 degrees, either leaving the focal plane illuminated or dark depending on the phase of the shutter. The difficulty for OPTIC is that the latency between a "shutter" command and the actual exposure to light can be quite long, certainly at least 1 second and probably more like 1.5 seconds until the entire array is illuminated. Upon closing the focal plane is not dark for at least 1 second after the "shutter close". I have therefore implemented a "shutter delay" function for WIYN, which causes the "shutter close" routine to pause for a while before returning so that the array really is dark before the next step happens, such as CCD readout. This delay is determined by the "Tmin" parameter used by telescope guiding (gpar), since OPTIC does not do telescope guiding at WIYN. Set it to 2.5 sec to be conservative. If it is too short you will see what looks like vignetting at the very top and bottom of the array when you read out a short exposure -- it's the pixels read out before the array is illuminated. A similar problem is that the start of the OT tracking loop depends on a quick look at the guide stars before erasing the CCDs and starting the observation. I have another delay of "Tmin" inserted there so that the array is really illuminated before the guide star quick look commences. Because of its slowness the WIYN shutter also needs a special mode for exposures of less than 4 seconds. For exposure of 1 to 4 seconds the shutter ignores any "close" command it might receive and simply goes through its own timing for an exposure which commences when it receives a "shutter open". In order to get short exposure times you must issue a "tel exptime N" to the shutter before starting an exposure, where 1 mylog foreach i (myprefix.???) othead $i psf >> mylog end videostack ---------- Videostack is a utility to read a 3D FITS file, stack all the frames, and write a 2D FITS file of the resulting average. It assumes unsigned short images. The syntax is videostack input_3d_file output_2d_average [silent] fitstile -------- Fitstile will read a 3D FITS file and write a 2D FITS file which has the individual frames laid out in a tile, starting at the lower left and working right and up. The syntax is fitstile input_3d_file output_2d_tile [options] and options include -first N first frame to use -last N last frame to use -ntile N number of frames to use -sky S subtract this from final image -book arrange tiles as characters in a book: upper left to lower right -grid draw grid lines between tiles videosum -------- Videosum reads a 3D FITS video file (prefix_vid.nnn) and writes an output file which is supposed to be identical to the guide star file (prefix_gs.nnn) already written by otcom. Good for checking for bugs in the psf routine and otcom. Syntax: videosum input_3d_file videoplay / xoptic ------------------ Videoplay reads a 3D FITS video file and replays it in real time on the screen. It can take an additional argument which is taken to be a frame time for the display in seconds. videoplay input_3d_file [frame_time] Videoplay, like otcom, forks off a child process which runs the program xoptic. This in principle can be on a different machine, but at present is hardwired to run locally. Because X is so wonderfully inefficient at passing data back and forth, xoptic does all the X display (coded in Xlib for historical reasons and efficiency), and it receives a fairly compressed data stream from videoplay (or from otcom). conflat ------- Conflat is an extremely important utility which convolves an unshifted (stare mode) flatfield in accordance with the shifts which were performed for an OT tracked image, and writes a new flatfield which should flatten the OT tracked image. The result of OT shifting an image is that each pixel in the final image has actually been integrated on a variety of physical pixels. An exposure during which OT shifting has taken place normally writes an auxiliary file called myprefix_ot.??? - table of where each pixel was integrated Conflat takes an unshifted, unbinned flatfield and convolves it according to the data in the '_ot' file so that it agrees with the OT convolution which took place in the image file. The basic syntax is: conflat flat_field ot_file out_file For example, suppose that f.115 was a stare mode flatfield in the same filter as an OT tracked observation f.087. You could make a flatfield for observation 087 by: conflat f.115 f_ot.087 flat_115.087 There are a few things you should beware of with the current conflat. (a) It assumes that it has *unsigned* short data (b) It assumes that the bias is present (which conflat will subtract) These are easy restrictions to lift, but if you get garbage results from conflat stop and think whether you have written short integer files or whether you have done some processing on the flatfields which has subtracted bias or rewritten in floating format. Vista (source found in ~src/vista and ~src/mongo2k): ---------------------------------------------------- Vista is a handy means of displaying images if nothing else, and it is used as part of the fgs routine. Look at the file "Howto.Vista" to get a sense of how to use it.