[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Shutter timing
Don't go for overkill on the shutter timing. We probably don't need to
control or know the exposure time to better than 1% in my opinion.
Photometry will rely on relative brightness of stars for the applications I
see the Mark IV being used for. The only thing controlling exposure time
buys us is more accuracy in subtracting darks and I believe 1% would be more
than adequate for our purposes.
Mike G.
-----Original Message-----
From: Chris Albertson [mailto:calbertson@logicon.com]
Sent: Thursday, June 22, 2000 2:48 PM
Cc: tass@listserv.wwa.com
Subject: Re: Shutter timing
Dave,
I think you are right. If we need to know the exposure time to
within milliseconds the only way is to have a hardware timer
with an independent shutter position sensor. Nikon did this
in the F5 camera. Even though the shutter is quartz timed there
is an independent shutter timer that provides feedback to the main
timer to compensate for ware over time and to detect a failure.
That may be overkill for our application.
Software on the PC _should_ be able to control the shutter to within
1/10 second. With typical exposures being on order of 100 seconds
this gives 0.1% error. That is very good. We can also look at the
values of the non-image pixels. They collect dark current in proportion
to the exposure time. It may make sense to scale our dark frames
based on the average value of the non-image pixels. We could then
correct out even that 0.1% error.
If the STAMP were a faster computer it _could_ control the shutter
timing itself while still processing commands from the PC but the
STAMP is a very slow computer.
"Gamble, David" wrote:
>
> If you have a real time clock on the Stamp, you should be able to get
around
> this problem. It would just report when the shutter opened and closed in
> real time. Or you could tell the Stamp to open the shutter for a
> predetermined time using the RTC as a reference. I have a 2 wire serial
> thermometer chip which has a built in real time clock that would not
require
> additional I/O ports from your current setup. I have yet to try it out, as
> the commands are a little complex. I can dig out the spec sheet if you
want
> to check it out.
>
> -----Original Message-----
> From: Tom Droege [mailto:droege@wwa.com]
> Sent: Wednesday, June 21, 2000 3:11 AM
> To: Chris Albertson; tass@listserv.wwa.com
> Subject: Re: Shutter timing
>
> Chris,
>
> This does not work. Here is why. The delay - typically ten seconds - can
> occur anytime. Suppose I record when I send the command to the stamp to
> open. There might be a 10 second delay before it actually opens. Suppose
> I record the time I get the ack. This might have been delayed 10 seconds
> after Windows got around to telling me about it. I have considered
> this. I think there is no solution until we get a real time operating
> system. Or at least something that works around Windows.
>
> I run with Windows because my present system for reading an image is Image
> Scientist. It is convenient to switch back and forth between a DOS window
> and Windows to read the images. Things would work better under a DOS
only,
> preferably in an old version of DOS. But I am testing and convenience is
> more important than the best possible data.
>
> Tom Droege
> At 05:19 PM 6/19/00 -0700, you wrote:
> >Tom writes,
> >
> > > Also per the notes, this does not guarantee that all images
> > > are of comparable length.
> >
> >Tom,
> >
> >I know about your problem with serial port timing. One thing I
> >am doing that you could maybe do in your BASIC software is to
> >record the _actual_ times. In other words you capture the wall
> >clock time just after the shutter opens and just after it closes
> >even if the open and close times get messed up by the OS. So the
> >final FITS files header would record the actual rather then intended
> >exposure time. This would likely only require a few small mods to
> >both your QBASIC program and to the raw-to-fits program. (I'd
> >suggest the QBASIC program would write out any housekeeping data
> >after the pixel array.)
> >
> >My Linux based software will record the time (of day) when the STAMP
> >sends an ACK. I am designing things so that the software is "ACK
> >driven". The Linux software can queue up STAMP commands far faster
> >then the serial link could deliver them. My serial port handler
> >queues outbound commands at any time and issues them to the STAMP
> >whenever the STAMP sends an ACK or a power up version message.
> >
> >
> >--
> > Chris Albertson
> >
> > calbertson@logicon.com Voice: 626-351-0089 x17
> > Logicon, Pasadena California Fax: 626-351-0699
>
> **********************************************************************
> Please ensure email address and references to
> Acacia Resources Limited are changed to
> AngloGold Australasia Limited effective immediately.
>
> Email addresses are changed by replacing acacia.com.au
> with anglogold.com.au
>
> **********************************************************************
--
Chris Albertson
calbertson@logicon.com Voice: 626-351-0089 x17
Logicon, Pasadena California Fax: 626-351-0699