Rally, thanks for the very productive comments and information you have provided on the ASCOM aspects of the project. They provide the sort of 'discussion points' general knowledge we need.
I think you hit the nail on the head with your comment "Someone just needs to:
1 - Make the hardware controllers,
2 - Write an ASCOM driver,
and
3 - Write a Windows interface !!!"
You've spelled out well the priorities and associated tasks we need to address, once we've decided on which functions we are trying to include in the controller.
I don't see myself as any sort of "code dog", and my knowledge of the procedures needed to write an ASCOM driver is non-existent, and I must confess, I don't have much interest in learning at this stage in my life, but I'm sure in the IIS group we have others who are competent and have the knowledge.
I see my role as more of a 'startup catalyst' to organise getting the project up and running, while donating those of my skills which may be of some use.
Some may also pop up from other places in the Astro fraternity with already-written drivers or such. So having the objective of making the controller ASCOM-compliant is a worthy one and I feel should be fundamental to the project concept.
I see us presently at the "pre #1" (make the hardware controllers) stage. We need to identify which functions the controller will handle, based on inputs from members. We should then prioritise the functions by demand and ability to achieve them, including the ASCOM aspect, and then decide on the type of hardware controller that is most suited to the task. Once we have done that, we can then assign knowledgeable members to concentrate on the ASCOM and GUI aspects of the project.
Perhaps a simple XL spreadsheet approach is the way to compile such a list with all the factors available on it for reference. I don't mind doing that.
In the meantime, perhaps some feedback from interested members on this overall approach would be useful, as well as further inputs on desired functions, based in the info available so far.
I don't have any firm preference on how "all-singing, all-dancing" this controller should be, except the quite obvious one that the more complex we make it, the longer it may take to come to fruition.
So perhaps the "Keep It Simple" one is a good way to start until we have identified our individual capabilities. Of course if a lot of the hardware and drivers is already available, simplicity can be readily achieved whilst making a more capable unit.
So far functions that have been identified as desirable by myself and Steve include:
Focusing
DC power monitoring
Weather and related Dew monitoring/control
Dome/roof control
Lighting controls
CCTV Camera switching
CCD temp monitoring
Security monitoring.
Any comments on other useful needs?
I will come up this weekend with a spreadsheet list on these showing possible hardware controllers, costs, and present ASCOM status, so that we can move towards the prioritisation of efforts, depending on demand, achievability and cost. I must admit, so far I see nothing overly demanding.
There are also the basic design concepts such as LAN, Wireless, PC hardware, standalone ability, GUI approach, etc to be addressed early on.
The group will also need to review each function to get a firm grasp of what the users expects/needs it to achieve. That will come after the list has been compiled.
There's also the persistent subject of future basic machine shop needs for hardware, brackets, etc.
Anyway, time for more inputs from the floor.
Cheers
but it works
on only one channel.
