You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 6, 2022. It is now read-only.
Once testing begins with a camera using prototype software there will be several options for controlling the camera to explore.
The use of GoQat has already been tested but needs more testing. The most recent version of GoQat was unable to recognize the allsky camera at DCT, so that will have to be addressed. Another is to use INDI drivers for controlling the camera and some testing using INDI has already been done. Another possible option will be to talk directly to the camera via the USB port using Python.
Is it better to pursue all camera control options more or less in parallel, i.e., nearly simultaneously, or will it be better to exhaust one method of controlling the camera before moving on to the next method?
The text was updated successfully, but these errors were encountered:
My approach would be to try to get the INDI driver working. It seems like the cleanest approach and has already been tested a bit and found to work in a slightly different circumstance.
In cases like this I like to keep as much in-house control as reasonably possible. "Reasonably" is related to how much effort is involved. In this particular case the INDI driver approach seems like the best compromise and prototype software demonstrating feasibility has already been written. I'm more comfortable with this decision if we have access to the INDI source code in case there are bugs in it or it has to be modified later due to hardware, OS, or Python changes. Let's discuss further this afternoon.
Ted,
This sounds "reasonable". I have a copy of the source code written in
C++ that I was just browsing through yesterday. Its very clean code
by the way.
I'm on the hill and go for a meeting today if Dyer is ok with webbing
to the meeting.
Len
On Tue, 15 Jan 2019, TedDunham wrote:
In cases like this I like to keep as much in-house control as reasonably
possible. "Reasonably" is related to how much effort is involved. In this
particular case the INDI driver approach seems like the best compromise and
prototype software demonstrating feasibility has already been written. I'm
more comfortable with this decision if we have access to the INDI source
code in case there are bugs in it or it has to be modified later due to
hardware, OS, or Python changes. Let's discuss further this afternoon.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub, or mute the
thread.[Am6xcFgzUkxy8UvzZURGYJpsmviE3tGvks5vDf3agaJpZM4aACdC.gif]
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Once testing begins with a camera using prototype software there will be several options for controlling the camera to explore.
The use of GoQat has already been tested but needs more testing. The most recent version of GoQat was unable to recognize the allsky camera at DCT, so that will have to be addressed. Another is to use INDI drivers for controlling the camera and some testing using INDI has already been done. Another possible option will be to talk directly to the camera via the USB port using Python.
Is it better to pursue all camera control options more or less in parallel, i.e., nearly simultaneously, or will it be better to exhaust one method of controlling the camera before moving on to the next method?
The text was updated successfully, but these errors were encountered: