While it may be hard to build what we want, it is fairly easy to say what we do not want:
We do not want bright light from the Moon to reach the secondary optics – thus a means to avoid that will have to be found. We ought to discuss both external and internal occulters. The internal one was tried and failed – can a better system be invented, based on the same ‘knife-edge-in-prime-focus idea? Could external occulters work? The shadow cast needs to be sharp – it must be far away from the main objective – how do we get it in line with the telescope? How do we change the angle? Should look at digitally addressable LCD arrays of image modulators.
Could non-mechanical SKEs be invented? How about an LCD screen in prime focus with an addressable array of pixels? We place the required shape on the screen so that the BS is coverfed?
Electro-mechanics gave us problems: the SKE broke, the filter wheels stuck, the shutter stuck, it took a long time to get the dome working correctly; the mount had its ‘wild slews’. Some of these problems were of software origin (mount and dome problems in particular, perhaps SKE too, filter wheels and shutter probably not) – but the software was complex in order to make complex hardware move – think simpler mechanics, or design them out of the system, and the software will be simpler. We started by thinking about a dome-free system – revisit that idea.
Why use filter wheels? This was driven by a science idea – perhaps doing wide-band photometry is not useful for science goals? Perhaps it is – but movable filter wheels were a source of trouble – try to use several single-filter cameras and beam-splitters; or one camera with a colour CCD. Look into designing a CCD chip with the filters we want. Any UBVRI CCDs out there?
The Uniblitz shutter failed at times – why have a mechanical shutter? Well, because the camera read-out time was long compared to typical shutter times, so ‘dragging’ occurred if the mechanical shutter was not working. Can we have longer exposure times – or a CCD that reads out faster? Longer exposure times could be obtained if the f-number of the system was larger – but that means a physically longer system. We decided against folding mirrors – but was this a thought-out step? Perhaps the slight dependence on polarization could be designed out somehow? ND filters could also be used – but probably should be fixed or in a foolproof filter wheel. With ND filters, longer exposure times can be had – but then more internal reflections and scatter is added to the mix. Putting an object in the pupil acts to cut down on the image intensity without leaving a ‘shadow’: perhaps a simple device could be placed in the collimated beam, instead of filters – an object would not cause reflections like glass surfaces do. DMA (digital mirror arrays) should be looked into.
The shutter did not work well, but was very expensive. Canon DSLR shutters cost about 20 $ – and seem reliable. All shutters have a limited lifetime – we should think out a way to have easily exchangeable shutters.
Design for less cables. The main cable is an anaconda 20 meters long, thick as a leg. Try to design so that wireless communication (think bluetooth) can be used.
The mount was an equatorial mount – so meridian flips gave us hell. Why not use alt-az mounts? Image rotation can be handled with image rotation devices, or in software. Software solution requires work on “conservative image manipulation” (interpolation is required, but is not conservative unless steps are taken).
Added later: but look here:
http://iloapp.thejll.com/blog/earthshine?Home&post=369
Automation software was written from scratch. Is there no commercial software available that could have worked? Then issues of bugs etc would be in other peoples hands – people with a commercial interest in selling products that worked well to a large audience.
Site choice: Hawaii was extremely good for us – but cost money each year and the distance, despite Ben’s good work, made fixing problems difficult. Let us deploy very close to home for the testing and run-in period, next time!
Above all we do not want systems that are assumed to work! By this I mean we do not want systems that are given a command and after that – without checking – it is assumed that all went well. We want a system that checks, and iterates until a goal is met. So feedback loops – “polling” is the phrase! – perhaps using image processing; position sensors using bar code readers or image analysis from webcams on and in the system, or NFC readers,or in-device compasses and accelerometers.
The design and build was in the hands of relatively few people last time – perhaps we should consider ‘crowd-sourcing’ the design effort? Great way to get lots of ideas (some good, some bad), but above all feedback and interactive discussions. An interested team of ATMs would change the mix!
