Earthshine blog

MOVEMOONTOREF is a command to place the center of gravity of the Moon’s illuminated disc in the center of the image. Has been tested with GOTOMOON which must preceed it.

Seems to work.

This image of the Moon was obtained on JD 2455849.
Notice the strong saturation at the lower left corner – on the sky! Other parts of the Moon are safely exposed in the 10000-30000 counts range.

Here is a supposed ‘dark’ frame showing something similar:
Most of the dark frame is at the bias level of 397 – the corner shoots into 65000!

This was during our ‘everything looks like a bias frame we think something is getting stuck’-period.

Both frames above are available in the BADEXAMPLES/ directory as FITS files.

Various things failed and none of the planned observations could be obtained:

Telescope did maverick meridian flip that we cut short as it neared the floor.

The camera flatlined for none of the known reasons.

Then some part of the FW or rotary stage system got stuck. There is an issue with the large rotary stage acknowledged by several parties. I additionally think the FW can get stuck at times – witness the failed VE1 observations on JD 2455849.

PXI is at the moment unreachable over the internet following an iBoot power cycle that failed to re-boot the machine.

Upper plot shows (red labelled crosses) observed relationship between dome azimuth (value next to cross) and telescope azimuth/altitude. The contours are due to a bi-linear interpolation.
Lower plot shows the same data but interpolated with ‘kriging’.

After speaking to Ahmad yesterday about the shutter performance I am not
sure we fully understand it. If I understood Ahmad correctly there will
be shutter dropouts now and then due to the temperature-related issue
that causes the shutter simply to not open. Then there is the issue that
sometimes the shutter opening time is measured close to zero without
actually being close to zero – an issue due to an occasional ‘spike’ in
the signal from the shutter which causes a timing circuit to start and
stop very quickly.

So these two modes can lead to images that have a measured exposure time
of close to 0 – about half actually are close to zero and the rest are
OK but the measured exposure time is no good.

Can the measured exposure time be trusted for other situations?
Apparently it depends on how short the requested exposure time is.

I took about 200 images of the moon from our database and extracted
requested and measured exposure times as well as the total counts in
each image. I then considered the standard deviation of the fluxes
(=counts/time) for both the measured and the requested exposure time. I did this for increasing exposure times by raising a lower limit on the
times considered.
The black line is for measured
exposure times and the red is for the flux based on the requested
exposure time. For exposure times below 10 ms the standard deviation of
the flux is smallest if you use the requested exposure time. For
exposure times longer than 10 ms the standard deviation is smallest if
you use the measured exposure time.

The result is the above graph. We only have data for exposure times up to 25ms – this can be extended later.

There is a clear change in behavior at 10 ms . this is also reflected in this

lab report by Ahmad and Rodrigo.

It would seem that only very shaky
results can be had for exposure times below 10 ms. That is, if you
really need the absolute flux in an image do not expose under 10 ms.
CoAdd mode will still work, of course, since the whole image is affected
in the same way by shutter variability and we do not need accurate inter-image fluxes for
this mode to work.

The issues here do have an impact on the ability to work with the
non-simultaneous modes, and some careful analysis of the measurement
error is needed – e.g. by using a constant-flux lamp in the dome or just the inside of
the dome or the clear sky during shorter intervals.

As the lamp is now accessible we can test this!