Observing overheads

One of the main persistent issue has been a general increase in the observing overheads for NOTCam. The observing overheads are divided into three main types: readout overhead, data storage overhead, and telescope dither overhead. Because of the way the data acquisition was designed for NOTCam (not optimized for many dithers and short exposures typical for IR work), and because of the long readout time of the controller, the overheads are already substantial to start with. Several tests were made with NOTCam run differently, old vs. new acquisition program, local versus remote disk file storage, controlling the CPU time of the computer, etc.

Some of the increases in overheads are understood. The time it takes to complete a telescope offset has slightly increase to assure that the telescope has stopped moving before a new exposure is taken. Likewise, the main reason for the higher ``data storage overhead'' was due to a safety feature that was introduced because of problems related to the communication between the data acquisition computer and the TCS. This feature was removed, but there is still a small increase due to the detailed way that the sequencer works and due to the fact that the data is not stored on a local but external disk.

The ``readout overheads'', on the other hand, are less well understood. Specifically, there are night to night and month to month variations. Moreover, for the ramp-sampling mode there are frequent events of much larger overheads, a kind of extra hick-up in the data acquisition, where the whole program could stall completely for up to 90 seconds during an exposure command.

As part of the investigation in to the unexplained overheads of the readout times especially of NOTCam some tests were done using the old instrumentation computer and MOSCA. One potential source of the extra readout time is due to repeated reads caused by PC board read errors. With MOSCA and the old marissa PC board lots of read errors occurred but by using the same board but with a different PLD (main control chip) installed no read errors occurred. Recording all the occurrences of read errors with NOTCam and comparing this number with the readout time should show if this is the cause of the overheads.