There is one display for each CCD head. The upper figure on the display shows the current CCD temperature and the lower figure shows the set temperature. The temperature controllers will immediately begin cooling the chips to the set temperature by running the peltiers at their maximum power of -55%. However, it is possible to damage the peltiers by allowing them to cool by more than 5 degrees per minute, so it is essential to immediately increase the set point to 5 degrees below the current chip temperatures using the up and down arrow buttons to the right of the temperature displays. Once attained, drop the set temperatures by approximately 5 degrees per minute until the desired temperature of -40 degrees is reached. Once the chip temperatures have stabilised at -40 degrees, check the peltier power levels by pressing the left-hand turquoise buttons on the temperature displays once. The power level should be approximately -30%. If the value is close to or equal to the maximum value of -55% then the heads may have lost their vacuum and need to be pumped down. Alternatively, the water chiller might be running at too high a temperature. You can return to the temperature display by pressing the black button in the middle.
The following windows should then appear: The "Camera" window provides information on the commands used to control the EMCCD, which are sent to the SDSU controller. The "Filesave" window provides information on the commands used to define the quantity of data to be expected, which are sent to the SDSU-PCI card in the rack PC. The java-based GUI (known as udriver) sends the xml documents containing the camera and filesave parameters to the SDSU controller and PCI card via the http protocol. Note that if you have to shut the system down for some reason, you should always press ctrl-c in the filesave window before the camera window, otherwise you might need to reboot the rack PC to get the system running again.
You can then type any of the pipeline reduction commands, e.g. rtplot. In order to run the system whilst observing, it is necessary to access the data on the rack PC over the server. To do this, open an xterminal on the rack PC and type:
AutoLogger is a c-shell script which produces a log of ULTRACAM observations on a web browser. AutoLogger also provides status information on the current run, outputting an audible and visual alarm if the CCD temperatures rise above -40 degrees, if the GPS stops working and if the file size goes over a user-defined limit. Please refer to the Troubleshooting section for advice on how to deal with the problems reported by AutoLogger.
The AutoLogger script runs in real time on the rack PC. The script works by polling the directory containing the data (usually /data) and extracting information from all the xml files it finds. For each ULTRACAM data file, it also determines the start/end times, file size, number of frames and exposure time. Comments on each run are input using an optional comments file, which must reside in the same directory in which AutoLogger is run. An example of the optional comments file can be found here - it is essential that you do not change the format of the file, i.e. the two header lines and the order of the columns. Any keyboard character can be used in this file except < and >.
To run AutoLogger whilst observing on 2010_04_24, for example, open an xterm on the rack pc, logged in
as observer (see Software startup for how to do this). Then type:
emacs 2010_04_24_log.dat & - and enter the run number and comments for any runs already taken
> /data (the directory on the rack PC to which data is written)
> 2010_04_24_log (the name of the log file - omit the .dat)
> 6000 (the file size at which you wish a maximum filesize alarm to go off)
> y (to test the speaker volume level)
(AutoLogger /data 2010_04_24_log 6000 y typed on the command line will also work).
The script will run indefinitely, polling the data directory a few times every minute and looking for changes in either the data files or the comments file. If it finds a change, it will update the log displayed on the web browser. To exit AutoLogger, just type crtl-c, but only do this when AutoLogger says that it is safe to do so. The final log is written to a file in html format - in the example above the resulting file would be called 2010_04_24_log.html.
To view the logs from previous nights, open a web browser on the rack PC, avoiding the use of the konqueror browser, which would clash with AutoLogger if running. Then load the html log file, all of which are stored in /home/observer/AutoLogger.
Tom Marsh has written an excellent observing check list which is well worth running through each night to ensure you've not forgotten anything. It is also full of useful tips to get the best quality data as efficiently as possible.
One point not covered in detail in Tom's checklist is the reacquisition of targets. If you are going to repeatedly revisit a target, it is usually desirable to be able to reacquire it onto the same ULTRACAM pixel with no time-consuming tweaking of telescope position. To do this, it is imperative that you note down the following information once you've acquired a target for the first time:
At the end of the night, ensure that AutoLogger has been correctly shut down and that data taking has completely finished. Run the script end_of_night_tasks from the data reduction PC. This archives the original data, which is stored in /data on the rack PC, to two large-capacity USB disk drives in the control room. The script also makes a copy of the data on the archiving disk /data1 in the rack PC, and a subdirectory of /data. The script is self-explanatory to run, and is described in more detail in /home/star/archiving.
To take data in drift mode, it is recommended that the observing system is started (see Software startup) with the "-q" (for "quiet") option as follows:
The above command suppresses the frame number from being written to the filesave window, reducing the demand on the data reduction PC. It is recommended that you do not overload the rack PC, data reduction PC and ULTRACAM internal network with non-essential tasks when running in drift mode at the highest frame rates in order to minimise the chances of crashes.
If the sky is bright, you might notice that the top part of a window has a different background level compared to the bottom half. This occurs when it is impossible to fit an integer number of windows in the image area and hence part of each window exists on the chip (and hence accumulates sky) for slightly longer than the other part. To negate this effect, put the focal plane mask in the beam. The focal plane mask can also be used to prevent bright stars lying on the same column as your target star but on a higher row from corrupting your image. The slide is also useful if you want to minimise the light falling on the chips when taking bias frames and darks.
The focal plane mask is most easily moved from udriver by pressing the Focal Plane Mask button on the observing tab. The slide can also be moved by logging into the imedia PC. You can do this from the data reduction PC in a number of ways:
This will list the various options available to you on the command line.
The red and green filters are relatively straightforward to change: simply unfasten the two velcro strips holding the top edge of the foam baffle down, remove the foam piece and replace the filter. The blue filters are more tricky. Carefully slide out the cartridge containing the filter you wish to remove. Using the 15cm metal ruler found in the ULTRACAM tool box to prevent the blue foam ring from slipping, slowly slide the new filter cartridge into the filter slot (you may feel the ball-bearing retainer click into position when complete). Slide the metal ruler out, remembering to check that the two syringe needles for the dry-nitrogen flushing system are still attached to the blue foam ring. Don't worry if the blue foam ring is not centrally located over the CCD window - it would have to be seriously out of position to vignette the field. Make sure you keep the metal ruler parallel to the filter, CCD head and re-imaging camera at all times to ensure that you don't inadvertently scratch the outer surface of the re-imaging lens, CCD window or filter with it.
Always use the optics handling equipment (e.g. latex gloves, lens tissues, air spray) when changing filters - you can find these either in the blue briefcase or in the "optics handling equipment" box in one of the ULTRACAM packing crates. When blowing air across the filter, be sure to hold the can steady and upright, otherwise propellant may fall on the filter. It is also wise to make a few test blows into the air before spraying the filter. A head torch to assist with the filter change can be found in the tool box.
Unless you can spot a broken or disconnected network cable, this usually happens because the rack PC has crashed. Go into the dome, turn on the LCD monitor in the rack and hit return on the keyboard. If the normal login prompt does not appear, then the rack PC has probably crashed. If you are unable to bring it back up, switch to the spare rack PC, which is located in one of the black crates, and contact one of the ULTRACAM team.
There has been one occasion when the data reduction keyboard stopped responding, probably due to an illegal combination of keystrokes. This was fixed by killing the windows one by one until the offending window had been killed and the keyboard started responding again.
If you are unable to get the data reduction PC working again, you can switch to the spare data reduction PC ULTRACAM2, or the ULTRACAM laptop magnetar, which are both stored in the black crates. Please refer to Paul Kerry's user guide for details on how to do this.
This hasn't happened with the new data acquisition system installed in early 2010. If it does recur, one reason could be because you have filled the /data disk. Another reason could be that you are pushing the system to its limits either in terms of data rate or frame rate. The former occurs, for example, when using drift mode at high-frame rates with the fast readout speed. If you experience a crash, try running the same application with the slow readout speed, in quiet mode, which should be more stable.
If you are determined to try to remove it, first try power cycling the SDSU controller and then allow it to settle down by taking some images for a while before measuring the readout noise again. If the pickup noise persists, try rearranging the cables. Experience has shown that by far the most important factor seems to be the arrangement of the data cables running between the SDSU controller and the CCD heads. Without disconnecting them, try altering the position and angle of these cables with respect to each other using cable ties to hold the data cables in place. If this fails, adjust the position of the other cables on the instrument so that none of them passes close to the data cables and their connectors. The aim here is to try to separate any power-carrying cables from cables carrying data, although I'm not convinced how much this helps. It might also be worth avoiding tying cables together in loops, but again I'm not sure this makes much difference.
If the above fails, ensure that the chiller is not too close to the electronics rack, as I've noticed pickup from this before on the NTT.
If you still have no luck, you could try the various earthing cables in the cables box in the black crates. Connect the plug to a mains socket and then try earthing the instrument and/or electronics rack to this same point. Try to see if there are alternative routes to earth from the instrument, e.g. I once noticed the metal pipes carrying helium to the WHT Cassegrain focus were touching the top of the (isolated) electronics rack. If you have no luck with this, and you've noticed that the pickup noise is particularly bad on one of the chips, you might be able to isolate the problem by swapping the peltier power supplies around by exchanging the cables going into the power supplies at the rear of the electronics rack (and power cycling them in the process). If you have no luck with this, check the dome environment to see if anyone has turned on equipment which might be interfering with ULTRACAM and, if possible, ask them to turn it off.
This is a rare, intermittent fault which occurs when a new run is started. The bias level on the red CCD suddenly jumps to a very high or low level, sometimes with a loss of sensitivity and an increase in the readout noise. Note that Tom Marsh has implemented a check in rtplot which issues a warning if it detects an abnormal bias level. It can usually be fixed by simply stopping the run and restarting it. If this does not work, try it again. If the problem persists, try a system reset by clicking on the System reset button when in expert mode on udriver, followed by an Initialise.
If this fails, try switching the SDSU controller on and off, which can be done remotely using the remote power module (see above).
Please refer to Paul Kerry's user guide.