Old-Photons. At first I thought “Old Photons” was a really cunning name for an observatory.

Our galaxy is about 100 thousand light years in diameter and contains many of the objects an amateur astronomer will focus their CCD on. The images we capture of these objects are in fact images of the way these object were thousands to a 100 thousand years ago.  From the place photons originate within these objects it takes this much time for these photons to travel to us. For objects outside our galaxy we wait even longer. The nearby Andromeda galaxy is 2.5 million light years from us and the images we take today show us its appearance 2.5 million years ago.

But then I had a troubling thought. The electrons I collect in my CCD are due to old photons, but then,… Do photons age?… Do they get old?.. Are there such things as old photons?

The faster you travel the slower time progresses for you, as you arrive at the speed of light, time slows to a stop. Since photons zip along at the speed of light they don’t experience time and so they don’t get old. It’s a bit confusing because from our perspective they do get created and are absorbed in my CCD. How can something that does not experience time have a birthday and an end?

The image above is a screen capture of the observatory at work. The screen shot was taken while it was observing M31 shown below.

• When the screen shot was taken, the lights in the observatory were temporarily turned on. The webcam gives the ability to see what is going on, it is almost like sitting outside.
• Lower to the left is Celestron’s NexRemote PC interface to the mount. It is an emulation of the hand controller and provides a COM port access of the mount to the control SW.
• Below this is remote shooting control for the canon DSLR that rides below the telescope.
• On top to the right of the webcam viewer, is the central controlling application, ACP Scheduler. It shows the dispatcher is activated and observing jobs are dispatched as objects pass overhead. It is set to prefer objects that are near meridian. Usually the only thing to do is launch this application, and enable the dispatcher. It then looks after launching all other needed applications. The dispatcher holds access to the lists of all queued observing targets, it prioritizes them and dispatches according to rules including avoiding moon lit nights, objects position in the sky.
• Below to the left is the small control that is part of the Celestron mount ASCOM driver. It provides the ASCOM mount interface that other applications connect to.
• The larger application below this next to the Canon DSLR app is MaxPoint. This application provides pointing corrections. It interfaces to the ASCOM Celestron driver, and is trained with a grid of 100 points across the night sky. A pointing error refers to the difference between where the mount points in the sky compared to the commanded pointing instruction. Based on the 100 observations a model of the errors is created and used to correct the mount. Because of MaxPoint the rest of the applications not do not have to contend with these errors. Because this is a permanent setup training is done very infrequently. Once a year and only if physical adjustments to pier or mount are made.
• The large application to the right on the bottom is ACP Observatory Control.  This is the application that executes the activities needed to run the observatory. It is mainly script based. Scripts are triggered by conditions or desired jobs from the dispatcher. Currently it was running AcquireScheduler script, which accepts object target, and observation parameters from the dispatcher. It also monitors the state of the weather and also coordinates telescope and dome (roof) movements.
• Above, the small window shows the state or activity of the dome.
• FocusMax is the larger application on the top. This application is has access to the stepper motors of the focuser and the CCD. FocusMax learns information about the optical path and CCD and formulates how to find focus from the slope of measured star Half Flux Diameter versus motor position. It can monitor temperature and make adjustments thru the night as temperature effects the physical length of the telescope. The observation plans given to the dispatcher are configured to ask ACP Observatory Control to do a focus run prior to every set of images. Usually a half flux diameter of 4 pixels is as good as it gets.
• The large application lower to the right is my partially self coded weather application. In the plot the ambient temperature was -11C, the sky temperature was a chilly -43C and the difference was 32C. The application uses a threshold of 15C to declare overcast conditions. This application runs in the background updating 1 per second. A written updated file provides ACP Observation Control with a trigger to “shut-er-down” on bad weather. Jobs that are interrupted are re-queued.
• Camera control is part of MaximDL which is the imaging engine. It shows two cameras are connected and running. Camera1 is the main CCD, Camera 2 is the auto-guider. Camera 1 is cooled and was set to -20C, since it was a cold night the cooler was running only at 5%.
• MaximDL is the large window to the right. It shows the most recent image, and periodic images from the auto guider. MaximDL initiates filter changes, focuser updates based on differential filter focus requirements, initiates main CCD exposures, runs the auto-guider, evaluates and initiates guiding corrections. Upon completing each image capture it calibrates each image and plate-solves the image. Plate solving data is stored in the image file for use in alignment and stacking post-processing.
• The strip graph below shows guiding performance over the past 15 minutes. The mount has been periodic error correction programmed and 0.5 to 0.6 arc-sec rms guiding errors are typical performances.

Data files for NGC224 M31 181115 are available at My Google Drive

Adrien.