[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Shutter timing
The stamp is really pretty fast. I think it will do 10,000 QBasic commands
a second. I think it is just a question of the right code. Everything is
designed so that the users can change the code.
As you all know, on a big system like this with several people writing code
it will be a pain to coordinate everything. The operating code and the
stamp code need to be able to be changed while still keeping everything
running. This is a standard problem, and I am sure that you programmers
have some good solutions as to how it should be approached.
My emphasis has been to get images as fast as possible while being able to
solve hardware problems. It is time now to start realizing the full
potential of the Mark IVs.
Tom Droege
At 11:47 AM 6/22/00 -0700, you wrote:
>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