RE: Focus indication

[Tom Droege <tdroege@veriomail.com>]

The original purpose of Mondown was a walk by check that things were 
working OK.  It works just fine for this purpose.  I was trying to add a 
few things to it so that it would be even more useful.  Somehow we got 
stuck on focus.  Probably because it looked easy at first.  I can't find my 
original request to Rob about the focus, but I was after general monitoring 
schemes.  I did find where Rob offered to play WAV files for the various 
errors.  ;^)

Those who have systems are aware that the program beeps a lot.  I can be 
sleeping and wake up because the beep pattern has changed.  Even when 
sleeping I will notice when the home RA pattern does not end.  Then I am up 
on the roof to see why the RA drive has stuck.  This does not happen much 
anymore, but it was a big problem with the old drive scheme.  So it 
goes.  Some of you won't want to do this, but I really want to take good 
data.  Alarms should always be able to be turned off.

OK, the real problem I am after is general monitoring.  Rob has a nice 
scheme.  A program that notices a new fits file, looks at it, and makes a 
presentation.  This is completely independent of everything else - it just 
looks at the directory for a new fits file- so it can possibly have a long 
and useful life.

I don't trust the rest of you to put monitoring features in the new real 
time program.  You will be focused on getting a result.  You will never 
quite get around to it.  I have lived too long with 
experimentalists.  ;^)  The way it is presently written, I could write a 
few line QBasic program that wakes up Mondown at intervals and thus monitor 
what is going on.

Tom Droege

At 08:19 PM 8/6/01 -0700, you wrote:
>Tom, you have now presented a design requirement instead
>of just a blanket 'focus indication.'  This is much easier
>to program towards.  Simple focus is better to perform and
>check with a manual interactive operation such as the focus
>plate.  Testing for nightly problems is a different beast
>and will require a different approach, which is why I am
>glad you have presented the exact problem you want solved.
>   Automatic fwhm calculation is not trivial, as I have
>already mentioned.  Once you want to set limits, then it
>depends greatly on the field that is being imaged.  For
>example, when you are in the Milky Way, there will be
>many more stars and lots of blending.  What kind of fwhm
>is going to be generated as compared to a high galactic
>latitude field?  Do you want to be woken up every time
>a cloud passes over, or every time you get close to the moon
>or approach the Milky Way plane?  There will be things
>that are easy to check, such as clouds or lights, where
>you will have few stars or have a high background or high
>standard deviation.  Other things, like sticking shutters
>or failing drives, may be a lot harder and I am not sure
>fwhm is the answer.
>   Your concept of real-time data quality analysis is the
>right way to go, but I think it will be a blend of several
>different tests, which may or may not include fwhm.  So
>my basic question is how much effort to put into automatic
>generation of this number.  I'd like to see some discussion
>on the list about how people think each of these problems
>could best be detected.
>   Sorry to ramble on so.  I keep forgetting my resolution
>to back off and let others get a few words in edgewise.
>I'll stay quiet for a while!
>Arne