The next eshine telescope

This paper discusses the use of DSLRs in astronomy:
http://adsabs.harvard.edu/abs/2012JAVSO..40..815K

Perhaps this should be looked at: http://www.rts2.org/

I note that the AstroPhysics mounts (Some models) are supported along with “indi driver” mounts, Meade and Losmandy (we have all three types), as are Andor and Starlight Express CCDs. An impressive range of dome controllers, filter wheels, weather stations (including the Boltwood sensor which is the one we ought to have got …), and focusers are supported.

Perhaps worth trying this software on a simple Meade GOTO telescope?

Note wiki and list of HOWTOs: http://rts2.org/wiki/

Added later: Have now installed it and had a first look. Hmmm. Seems tricky 🙂

Our whole system (except ‘woof’ which only did data handling) was based on Windows. We know very little about Windows. We use Linux. Now we have a problem!

Windows allows spaces and non-alphanumeric characters in path and filenames – Linux does not. Accessing files from Linux that sits on a Windows HD is difficult …

We think a future system should be entirely based around Linux. For one thing, scripting ‘simple commands’ would be easier. Labview is available for Linux, but I’d like not to use Labview in the future as it is licensed = $$$.

Can the various hardware bits be – easily – commanded from Linux? Or must one use Windows?

The pointing of the telescope was not perfect. We set the pointing by calibrating the mount on a target field of stars the position of which we found using image-analysis software (see astrometry.net). The centre of field was then added, by hand, to a setup menu, and the telescope would centre well for a while. After a meridian flip, or after a few days, the centring was not so good any more.

We tested polar alignment by the drift method, but results were not clear. We are thus unsure why the pointing of the mount would deteriorate.

GOTO telescopes have calibration modes where a sequence of observations at different parts of the sky are made so that a pointing model can be calculated and used. We could not do this – we did one pointing and updated the model based on that – we needed a way to access the ‘build a pointing model’ system by software. Even to do this automatically.

We had the basic ingredients of a system to take pictures of the Moon and centre accordingly, but it was not functioning robustly.

The dream solution would be something like this: the system is lost and does not know where it points – so it takes a picture of the sky and gets an astrometric solution – then it gets more – if one solution does not work it gets more pictures, at random
above-horizon, places – and keeps going until a solution is found. Then it goes about its work. Sigh.

We needed to focus the system now and then – but it turned out that this was when the wrong filter had been selected. In view of this, there may never have been a focus problem – as long as the filter was correctly selected the system would proceed to set focus to that filter.

There was never an automatic ‘set the focus’ operation, but perhaps this was not needed? It would have been required if we had gotten the NDs up and running as a known laboratory-tested focus point for these may not have been at hand, and then it would have been necessary to find it by hand and setting a fixed value.

We were housed in a fine house at MLO, using the Groundwinds old dome.

Extra hardware had to be installed to move the dome correctly. The dome would ‘stick’ on the track now and then and screech its way round. It was not fast – 2 minutes for a full circuit.

A never-fixed software problem had to do with addressing the position –
after some operations the dome ‘had to’ perform a full circuit before
it was happy to go to where we wanted it to go.

Most problems were our fault – it took a long time to generate software that pointed the dome opening where the telescope was pointing. This is standard stuff in commercial ‘observatory software’.

The equatorial mount we got was a 1200 LX-200 GOTO mount from AstroPhysics. Once we stopped sending the wrong codes to it it worked fine. Like all LX-200s (all?) there is ‘wild slewing’ if commands arrive in the wrong order. We had a timeout that was too short and a code was sent before the last one was done – messaging during slewing is a seriously bad idea for LX-200 mounts.

Once working as it should, we saw it was a rugged and accurate mount – pointed where we wanted it to point within a few arc minutes. Only problem – as with all equatorials – is the need for meridian flip. This was never automated, so we were stuck with the default which is that slewing across the meridian is not impossible, and highly catastrophic. So we put in limit switches and stopped the scope before the meridian – did the MF – and re-centred.

Alt-AZ would not have a MF but images would rotate. Can image de-rotators work well? And automatically? And without adding extra scattered light?

Is there a “don’t message while slewing”‘ issue with alt-az LX-200 GOTO mounts? I think there is.

Need to review how “indiserver” and “ascom” setups work for various types of mounts!

The Andor iXon-897 BV CCD camera had some properties we need to review

The RON was low (2 ADU/pixel in practise, 1ADU/pixel in the brochure …)

The bias pattern was strong, as it is on thinned CCDs. The level of the bias was temperature dependent and as the camera was cooled in a thermostat loop the mean strength of the bias pattern had to be adjusted for this. We did this by using only bias frames taken just before and after the science images and scaling a ‘superbias’ field. If the superbias was representative of the actual pattern we are probably doing well _ but this in itself should be tested. We certainly have the data! All shout: Student Project!

Linearity: We have data that suggest that the CCD was not ‘99% linear’ as all CCD brochures promise. As the evidence depends on the shutter being linear with exposure time we have to revisit this.

We had ‘dark bands‘ matching the width of the Moon, in the readout direction. While we may have compensated for this by doing ‘profile fitting’ also in the row direction of the image we would like to know what was going on, and choose a future CCD accordingly.

CMOS: they are available in 16-bits (Andor) and colour (in DSLRs: expensive!). Now, what was the benefit of using CMOS instead of CCD? Need to compare linearity and readout speed.

Some aspects of the expensive Andor were of no practical use for us: ability to have EM – that caused the bias average bias to flicker by +/-1 counts (not pixels – the average!). Faster readout modes were available, but never used – they cut into dynamic range or gave more noise. An internal shutter was a possible option but was not chosen – so we had to rely on the dodgy external one! A possible coating and enhancement of the blue-sensitivity was not chosen – choosing it would have left the red-sensitivity unaltered, so why not get it?

Cooling with water was possible but never used as it would be just so much more plumbing to worry about.