[INSTRM-73] Absolute exposure time Created: 11/Jan/17  Updated: 01/Jun/17  Resolved: 01/Jun/17

Status: Done
Project: Instrument control development
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Minor
Reporter: arnaud.lefur Assignee: arnaud.lefur
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Microsoft PowerPoint 201505-exposure-time-v2.pptx     PNG File exptime.png     PNG File exptime_vertical.png    
Reviewers: cloomis

 Description   

We need to make a philosophical choise about absolute exposure time.
In operation, we don't care too much about this, because exposures are much longer.

However, during our current test, exposure is only few seconds.
The opening of the shutters last about 0.39s
The closing of the shutters last about 0.38s

If we open and close right away, let's call that a 0 sec exposure, here is what the detector actually see in terms of exposure time:

What I would propose, it's to choose the least bad solution :

exptime = (shutter_opening_time+shutter_closing_time)/2 + time_shutters_fully_open
for that "0 sec" exposure above it would give a 0.385 absolute exposure time.

Anyhow, I think that's important enough so I can't be the only one to decide.
The sooner the better.

Thanks.



 Comments   
Comment by cloomis [ 11/Jan/17 ]

This comment is not intended to help, sorry.

Do we know how long calibration exposures will be?
Which axis is wavelength?
Have you tested several shutter mechanisms, or just one?

The choice only really matters at the limit. To the extent that we care, we would want to know the shutter motion time.

Comment by arnaud.lefur [ 12/Jan/17 ]

The wavelength axis was horizontal.
If I reorient the graph according to the orientation we currently have (wavelength => vertical), it would be like this( not sure about the top/bottom orientation)

This graph is totally theorical, it's only based on shutters opening/closing time I've measured.

Comment by shimono [ 12/Jan/17 ]

I put the previous study for normal exposure, which includes

  • shutter cuts in collimated beam, but not directly cuts on focused plane. so difference among pixels are small. (e.g. beam size for one pixel is ~300mm, detector size is ~60mm)
  • shutter moves in horizontal direction, which is wavelength direction

so, I think difference on light coming time range from transient period is not large as total shutter moving time, and we can say real exposure time is 'commanded exposure' plus average of shutter open/close transient time.

Comment by rhl [ 12/Jan/17 ]

As Arnaud says this is probably academic. However, it would be good to respond to Shimono-san's comment about the shutter being in a collimated beam.

The exposure time is probably most important for dark current correction and I hope that there isn't enough dark current for this to matter. If this isn't true we probably have to think about a map for the spatial structure of the exposure time.

However, I think we need to distinguish a bias (exposure time really == 0) from a 0s exposure, so I think we should go with Arnaud's proposal (once we've sorted out the real effective exposure time).

Comment by cloomis [ 16/Mar/17 ]

Do you need anything more on this, Arnaud? I assume you are done, but for the record I agree with you and RHL: 0s should be reserved for when no light is allowed through.

Comment by arnaud.lefur [ 16/Mar/17 ]

At the end, exposure time is calculated as I proposed :
exptime = (transientTime)/2 + time_shutters_fully_open with transientTime = shutter_opening_time+shutter_closing_time
For each exposure: dateobs, transientTime, exptime keywords are generated.

I'm not sure how we can measure that exptime gradient accurately, it's true that in our 1 sec flat we do see that fluxes decrease along with wavelength.
But it's could be also related to halogen spectrum itself.

Comment by arnaud.lefur [ 26/Apr/17 ]

For the one channel, I think the solution implemented is consistent.
An action which we could take internally is to check on Zemax if this gradient is real and to quantify it.
Kjetil and Sandrine would be a good help to investigate that.

Comment by cloomis [ 01/Jun/17 ]

We agreed on the 2017-05-31 ICS/SPS phonecon that the current choice – fully_open_time + transit_time/2 – is what we want..

Generated at Sat Feb 10 16:21:15 JST 2024 using Jira 8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b.