search

LowellObservatory / All-Sky

Repository for the All Sky Camera software used at the DCT (and perhaps Anderson mesa)
1 stars 0 forks source link

Testing Procedures #2

Open loxlig opened 5 years ago

loxlig commented 5 years ago

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?

dyerlytle commented 5 years ago

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.

TedDunham commented 5 years ago

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.

loxlig commented 5 years ago

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]