Re: INDI or ASCOM Alpaca?
Michael Fulbright <mike.fulbright@...>
1.toggle quoted messageShow quoted text
I think this is just good practice to provide documentation for high end devices. This used to be the default but in recent years more and more rare.
I imagine most developers would take their chances on having _any_ information compared to the decade+ old protocol documentation that currently exists.
Well they would except the protocol documentation doesn't seem to even exist any more - the two links a web search turns up:
both give 404 errors.
Fortunately I have a copied safely stored away and the date of the document is "Text modified: 07-04-06".
Case in point - sending a "pulse guide" to the mount.
The 'G' level documentation says the command is ':Mnxxx#' where 'n' is the direction and 'xxx' is the duration in milleseconds.
For longer pulses you have to do a convoluted sequence for changing the mount move speed to guide, then initiate and time a mount move and then terminate the move.
To make it more fun there are apparently no return codes for any of the steps you have to do nor a way to verify the mount is at the guide speed before you move it
So on the off chance the change rate command failed you might move the mount for 2500ms at slew speed, for example.
Hopefully there has been progress in the protocol design so you can do this with a saner atomic operation.
I found by experimenting my 'V' level CP4 will actually accept up to 9999ms for a guide request but since this is not documented I am not going to release code to the public with it coded that way.
I could ask Howard and he could confirm it but that doesn't really help the AP community as now the info is available but obfuscated in source code somewhere.
Having adequate and up to date documentation should be the minimum hurdle when producing high end equipment. I would venture most low end mounts have better documentation available. I know the Explore Scientific PMC-Eight INDI driver I helped with gives documentation for the entire (admitted very simple) protocol API to developers.
I believe it would be possible to make parts of the protocol required for decent operation of the mount available without spilling the secret sauce or undermining sales of APCC.
Here we get into the 'non-Windows' crowd which is statistically a minority across the general public and therefore more difficult to make a business case for. I hear rumors that most institutional users of AP mounts are predominately non-Windows but I have seen no firm studies to show this. Clearly AP would benefit in knowing this info as it could be more relevant to them than say someone who writes general purpose software.
What I think is important is to have a minimum level of support for alternative environments. As long as the information is available for tools to be constructed by motivated individuals or business interests to construct a solution I don't know that I would expect AP to do more in terms of writing software on these environments.
I would just be happy with running these apps on alternative OS/architectures. The Raspberry Pi is such an under-powered platform I wouldn't waste time trying to get stuff running on it.
I really am not sure developing and writing software for anything other than Windows is a good business case for AP. I would never suggest it as unless institutional users are demanding it I don't know demand is great enough.
I suspect there are a large number of technically talented people with AP mount that could make some impressive things happen if given enough information. AP just needs to stoke the fire slightly.
I don't really know how to respond about Alpaca because as far as I know it is all theoretical.
I don't personally see myself ever having one machine talk to another at the device control level over a network. It is an interesting theoretical possibility with INDI but for imaging I've found it too hindered by network traffic that I just run all things locally on a computer dedicated to the mount/camera at the mount.
If Alpaca means 'ASCOM-like' drivers can be written so the source is more cross-platform compatible (you can recompile it on another arch) then that sounds like a good step. My understanding is the 'COM' part of ASCOM has been a bit of an albatross for awhile now that made this not possible.
I will fully admit I'm an outlier for these things. I enjoy developing code for my astro equipment as much as I enjoy using the equipment. If the software I have doesn't do it how I'd like it done I change it or write new code to do it.
For this to be possible I just need enough knowledge of what is under the hood so I can tinker.
But I suspect what I want for different reasons would actually help a wide swath of AP users who just want to avoid Microsoft in any way possible. That is not just a 'PC/Mac' thing any more - people can have many legitimate reasons to not deal with a particular computer vendor these days. I prefer to not get into whether a particular solution is 'best' or 'right' - it all comes back to personal choice on the user side and is it a legitimate business case on the supplier side.
At least if the documentation is up to snuff the user has a recourse for a solution even if the supplier cannot justify constructing the solution from a business viability viewpoint.
I appreciate AP considering the use cases of all users - hopefully we can move towards wider support of some fashion.
On 4/27/19 1:07 PM, 'Ray Gralak (Groups)' groups3@... [ap-gto] wrote: