The next eshine telescope

People are working on using a small RPi computer to control a telescope:

http://www.stellarium.org/wiki/index.php/Telescope_Control_%28client-server%29

Even using the new Pi camera board to take astro-images:

http://www.raspberrypi.org/archives/4170
http://zeusbox.net/blog/2013/05/raspberrypi-camera-board/

Here is someone who has used an Arduino to control a telescope. His idea is to replace stepper motors and use ‘good’ DC motors. He still uses LX200 commands from planetarium software. The software talks to the Arduino which talks to the motors.

Perhaps these ideas can be used to make a system that uses cameras to find the target (Moon) and track it – in a way simpler than this mans system: No GOTO commands – just a small PC or Arduino controlling motors until some target distance is minimized. Using an equatorial mount allows easier tracking once the target is acquired – just one motor spinning.

This guy’s mount has to do meridian flips – probably has code in the Arduino for that. If a fork EQ-mount was used (like on a Celestron or Meade) MFs could be avoided.

We test Hans’ 450D optics by imaging the Full Moon (t_exp = 0.02 s, f=5.6, focal length=300 mm (i.e. tele-lens)). Using IRIS to extract the R G and B fields we align, normalize and average these and plot the profile from Moon disc centre and out into the halo. We get:

The red, green and blue curves represent the halo in R G and B, respectively. The black line is a 1/r³ curve. R, G and B images normalized by their total flux before plotting.

It would seem that, as in the case of the image found on the internet, the profiles of R G and B are very similar, and also of ‘high quality’ – i.e. they are almost at the limit of what is possible in terms of dropoff slope.

This has bearing on choice of future cameras – CMOS or filtered CCD. I think the similarity of the profiles is due to the light having traversed the same optics – which is not the case with the filter-wheel.

I am not sure why the profiles are so close to 1/r³. It seems our optics in the MLO telescope cannot match this.

It should be said that the DSLR optics show ghosting – this can interfere with the DS photometry if unluckily placed – but apparently does not gives us shallow halo profiles.

The ghost image (same size as Moon, positioned at 11 o’clock) is due to internal reflections in the compact tele-lens used. Perhaps an image of the Moon is reflected from the CMOS surface, reflects off the back of the optics and is recorded. The above ghost would be very intense compared to the DS. Similar ghosts are seen in the wide-angle lens image taken with the Sigma camera, but as magnification is less the ghost is easily placed away from the Moon.

One thing to notice is the 2-orders of magnitude of drop in intensity from the disc brightness to the start of the halo – is this what we get with our MLO telescope? Perhaps the 1/r³ drop is an artifact of a high starting level? Need to check that.

IRIS is a piece of Windows software that will readily convert CR2 files into FITS files. It can be done via pull-down menus or via ‘scripts’

A typical script is:

loadcam IMG_7536
save IMG_7536
loadcam IMG_7537
save IMG_7537
loadcam IMG_7538
save IMG_7538
loadcam IMG_7539
save IMG_7539
loadcam IMG_7540
save IMG_7540
…

Image files named IMG_XXXX.CR2 are here being loaded and saved as 16-bit FITS named IMG_XXXX.fit

It is necessary to first, via pull-down menus, set up IRIS to expect a Canon EOS camera (hence it understands to look for CR2 files in the script). You must also set the paths (in Settings…) to where the data are and where the scripts are. When you want to process .X3F images you must pick the SIGMA SD10 camera from the ‘camera’ menu in IRIS.

The script is a text file with extention ‘.pgm’ and is run from the ‘console’ in IRIS – this is the 11th icon along the toolbar. Simply write

RUN nameofscript (omit the .pgm, apparently)

and it will run, saving files for you.

X3F files are not yet understood – IRIS will open a file and save a FITS but there is only one ‘colour-plane’ in the FITS file – in the CR2 files converted above we get 3.

IRIS can be run from ‘wine’ in Ubuntu.

Realistically, we will always be working on telescope mounts that follow something like the LX-200 command set. In order to develop a system for pointing control it may be useful to have a telescope emulator – which this is:

http://miltonhill.us/software/index.html

It is Windows … wonder if there is something similar for Linux?
——————————-
Here is something interesting: http://astropix.nl/astro/LX200.htm Seems like a piece of hardware between a webcam and your telescope. Not free – costs ~100 Euro.
——————————-
This is something that allows tracking satellites which, like the Moon, do not move at a fixed rate: http://eq-mod.sourceforge.net/lxindex.html
——————————-

My problem with all of the above is that they require the mount to be ‘initialized’ before use – i.e. human intervention is needed after a system crash. No good for truly automatic systems. We need something that looks on the sky, finds the Moon, aligns on it, and starts tracking. I do not believe this exists, but we tested, by hand, all components on the MLO system. For Celestron telescopes there is something very interesting:

http://www.celestron.com/astronomy/celestron-starsense-accessory.html

A quick
search on Internet gives many references to DSLR
photometry. Amateur astronomers use DSLRs to observe stellar light curves
(see the AAVSO web
site) and to search for exoplanet transits, sometimes in the form of
amateur/professional collaborations (PANOPTES). There are also examples of the
use of DSLRs in the scientific literature: Velidovsky et al., used a Canon EOS 300D for absolute
photometry of the Moon.

Since I own
an old Canon EOS 300D I thought I’d try to measure a few fundamental
parameters: readout noise, dark current, and gain factors. The EOS 300D model
is now 10 years old and must be regarded as obsolete. I’ve seen them sold at
Ebay for less than 50 USD. It has a 12-bit 3088×2056 CMOS sensor, ISO settings
from 100 to 1600, exposure times from 0.25 milliseconds to 30 seconds, bulb
exposure of infinite length, but unfortunately no mirror lockup. I used IRIS to
convert files from RAW to FITS (note: without debayering the images), and IDL
for the actual analysis.

The gain
factors were determined by taking pairs of exposures from 0.25 to 100 milliseconds,
selecting a 600×400 pixel sub-frame, and plotting the variance of the
difference frame versus the mean level. Image
sequences were generated for ISO 400 and ISO 800, and the R-, G-, and
B-channels (of the Bayer matrix) were treated as independent data points. The
exposures were taken without lens, and with the camera pointed at a white,
uniformly lit wall. At first, the data points spread out across the graph but
when I discarded all exposures shorter than 10 milliseconds, the remaining data
points fell nicely along a straight line. For shorter exposure times, there is apparently
a large spread in the shutter performance (assuming that the light source is
constant between exposures). The uncertainty fell below 1% for exposure times
longer than around 50 milliseconds. This shutter performance may be a property
of the camera model, but it may also be a consequence of my camera being old
and worn-out.

Figure 1. Percentage difference between pairs of exposures at different nominal exposure times.

The obtained
gain curves are shown in Figure 2. The resulting gain factors are g=2.58 electrons/ADU at ISO 400 and g=1.17 electrons/ADU at ISO 800,
which comply well with figures that I found at various web sites (here,
here). Above a signal level of around 3700
to 3800, the gain curves rapidly levels off to smaller noise values, indicating
an abrupt transition from linearity.

Figure 2. Variance of noise versus signal for ISO 400 and ISO 800.

Readout
noise and dark current was determined by repeating the above experiment, but now
with the camera body capped and going to exposure times longer than 20 minutes.
Figure 3 shows a surprising result: the dark current decreases with time, to levels below the CMOS bias level (128 for
the EOS 300D) which means negative values!
Clearly unphysical, but it could be explained as a consequence of
onboard dark-current subtraction before the CMOS frame hits the RAW file.
Apparently, the camera over-estimates the dark current. Or could it be IRIS
that does these subtractions in the RAW-to-FITS conversion?

Figure 3. Dark current as a function of exposure time.
This behavior can only be
explained by onboard dark current subtraction before storage in the RAW file.

Even if the
dark current signal have been
subtracted in the RAW frame, the dark current noise is still there and this may tell us something about the dark
current signal. Figure 4 shows the dark
current variance as a function of exposure time. Up to 7 or 8 minutes it is a
roughly linear relation, but then the curve bends upwards – more strongly for
the ISO 800 sequence. The camera warms up during long exposures (one can
actually feel the temperature difference) and this is a likely explanation for
the nonlinear behavior in Figure 4. This is actually one of the major
limitations of DSLR cameras: the lack of temperature control causes a time
dependent behavior of the dark current, which is difficult to predict or to
monitor.

Figure 4. Dark current noise (here, the variance) as a
function of exposure time.

The readout noise can simply be obtained as the dark current for zero exposure
time. In Figure 5, we expand Figure 4 by plotting the logarithm of the observed
noise (but now the standard deviation) as a function of the logarithm of the
exposure time. Assuming that the observed noise is a combination of readout
noise and dark noise, and that the dark noise is proportional to the square
root of the exposure time (which it should be for exposures shorter than 5 to
10 minutes), we can fit both the readout noise and the dark current to the
observed data. Using the gain factors obtained above, we get a readout noise of
13.7 or 12.2 electrons, for ISO 400 and ISO 800, respectively, and a dark
current of about 3.6 electrons/pixel/second. This latter figure is highly uncertain,
but it suggests that for exposure times shorter than about 30 seconds the
readout noise dominates.

Figure 5. Dark current noise (here, the standard
deviation) versus exposure time on logarithmic scales.

Some
conclusions:

–
Gain
factors and readout noise obtained are relatively consistent with those found
by others. The dark current is a bit on the high side, but cannot be determined
very precisely.

–
The
camera shutter does not allow exposures shorter than 50 msec with any precision.

–
The
lack of temperature control makes the dark current unpredictable. This is less
of a problem for exposures shorter than 30-60 seconds, since they are dominated
by readout noise.

–
There
is some processing going on before the RAW file, at least a dark current
subtraction.

Even the least processed images – those in RAW formats – do not consist of the
raw, unprocessed data in the way we are used to from astronomical CCD cameras.
The details of this onboard processing are not described by the camera manufacturers. A
simple subtraction of a mean dark current level should not pose a problem for
the ability do photometry. However, if the processing includes scaling,
filtering, bad-pixel removal, “noise reduction”, etc., it may introduce
unpredictable errors in photometric measurements. How can we test this?

Here is a code in python that operates the EMCCD camera from Andor: http://code.google.com/p/pyandor/

You will also need a crucial .so file from the Andor SDK for Linux …

For a very light, DSLR-based system, this is a thought:
http://iankingimaging.com/search.php?q=skytracker

How would the mount swing back for start of observations?
It is controllable from various planetarium software packages.

How would it point fine enough?
With a large enough field it would not matter – provided the necessary detail on the DS was observable – perhaps worth a study of the tradeoffs between field size, pixel size and SNR?