Small RPi-based telescope w. Canon lens in a small alt-az mount driven by steppermotors. All data access done via WiFi.
Power transfer to rotating base done via 6mm ‘stereo jack’ as axis.
What did we learn from the first try?
Small RPi-based telescope w. Canon lens in a small alt-az mount driven by steppermotors. All data access done via WiFi.
Power transfer to rotating base done via 6mm ‘stereo jack’ as axis.
In our very first eshine teleeescope (the 0’th) which went to La Palma for testing, we had placed the knife-edge on the surface of the CCD and did prime-focus imaging. We could control the pointing with software (clicks on a star atlas) and could rotate the camera in its ball-bearings so that the knife-edge was aligned as required.
With a somewhat larger CCD or CMOS, higher pixel count and an image scale that allowed the Moon to be well imaged in the half that was not covered by knife-edge we might be able to design a system with minimal movable parts – just the mount to point and a motor to rotate the camera. No secondary optics (we would not need a colour FW as we would be using a modified RGB CMOS). No shutter (provided CMOSs read out really fast so that there is no ‘dragging’).
We could go back and inspect our La Palma images – most of them were made with an attempt at the SKE.
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?
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!