Blog Image

The next eshine telescope

Design ideas and tests for a new generation of automatic earthshine telescope

What did we learn from the first try?

iOptron skytracker

Pointing Posted on Mon, September 30, 2013 16:13:44

For a very light, DSLR-based system, this is a thought:

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?

Sigma SD10 in the astro-literature

CCD Posted on Mon, September 16, 2013 11:28:14

Papers from astrophotography articles that mention the Foven sensor in the SD10 camera:

This paper reminds us of a few things, namely that the camera (like all? CMOS and consumer-grade CCDs) has internal mechanisms for performing dark-subtraction – you do not get to do this by yourself. Exposure time is limited to 2min.

Note also these abstracts found in the ADS:…212.2404B….1M

This paper may be of general interest:

Foveon sensor in Sigma SD10 camera

CCD Posted on Wed, August 28, 2013 15:50:27

A Canon DSLR camera has an IR-blocking filter that has to be removed before the camera allows us to obtain data similar to the B,V, VE1, VE2 we wish to have. It is evidently complex to remove the IR filter form a Canon body – lots of small screws, unbending of glued bits and fragile parts everywhere.

An alternative is the Sigma SD10 camera with the Foveon sensor. The removal of the IR filter from a Sigma SD10 is trivial – one finger can pop the filter out in a second. The SD10 costs about 180 UKP (body only) while the SD15 costs 590 UKP.

Virtues of a CMOS camera

CCD Posted on Wed, August 07, 2013 10:47:31

We could do away with some of our woes if we used a DSLR CMOS camera instead of the current system. There are several benefits, and a few drawbacks:

PROs: With a DSLR camera we would get RGB colours at the same time, at the same sky conditions, and at the same focus setting. Alignment issues would go away. Shutter precision issues would go away.
With the modifications described in this paper

we would even get the NDVI index which is what we wanted to get by using VE1 and VE2 filters.

a) The shutter would be at the focal plane, instead of in the pupil. This could mean that fast exposures were not possible – insertion of a fixed ND filter woudl extend exposure times.
b) With CMOS chips at best being 14 bit (16 bit exist but cost a lot) we could probably not use the ‘direct imaging mode with BS and DS in same frame’.
c) Dark Frame issues appear murky for CMOS cameras. And what about cooling to get stability?

Neutral issues – i.e. same problem as before: We would still need an SKE to block the BS.


1) Use an unmodified DSLR to check what the halo structure around the Moon – or Jupiter – looks like in R G and B. If these are the same – which is not the case with Johnson B V and not at all with VE2 – then we might be on to a system to get ‘same-halo images’ with known subtractive benefits! We could then go on and modify a DSLR camera and get the NDVI Index and see if halo issues are reduced.

DSLR cameras

CCD Posted on Tue, July 30, 2013 12:56:34

This paper discusses the use of DSLRs in astronomy:

Control system using Linux

Software Posted on Mon, June 24, 2013 08:27:31

Perhaps this should be looked at:

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:

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

Operating system

Software Posted on Thu, May 23, 2013 08:02:38

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?