Page History

-- not well shielded from thermal fluctuations

This could affect the Slope images because the "flux/s" might vary from group to group

Marcia Rieke: the pixel clocks will not vary, only the recorded times.
-- this can be fixed in post-processing
-- time = time_start + num_groups * time_per_group
-- Tom/Jarron/Everett also confirm laboratory results

Kevin: Bigger issue:
The clock gets adjusted 'automatically'
-- possibly during a science exposure

They are going to change the time-correction `dribble` was changed from 16 u-sec per second to 1 u-sec per sec

Proposed Solutions
1) Special telemetry mnemoinc (called SCTA_OFFSET)

2) Use instrument clocks

3) Stay in units of electrons

Kevin: What is the focal plane electronics temperature variation?
Marcia: We can't know about it on orbit, but it could be a few degrees

Kevin: JStans wrote that there should be a 0.36ppm / K stability
-- if the drift is a few K, then we are looking at ~1ppm over that drift

Marcia: OTIS is probably a better estimate of that stability

Jarron: We don't need to necessarily access the FPE clocks, because he can just update the headers or add a keyword that has the pre-computed integration time

Loic/Kevin: agree

Kevin: then as long as our slopes are computed with respect to the frame-time clocks, we can make accurate e-/s counts

Tom: Either way, we are limited in absolute time by the spacecraft clocks

Kevin: can we access the clock in the FPE?

Tom: Do we need that?

Kevin: That is the next question. Do we trust the instrument clocks enough for relative time calibrations

Jarron: Yes. definitely. we tested that in the lab and in OTIS/CV3

Marcia: the FPE pages (?table information) can be either fast or slow; and the FPE clocks may be on the slow pages which (?) update every 10 seconds.

Kevin: Do all instruments keep the same instrument clock settings?

Jarron: I know the NIRCam and NIRSPec keep different clock settings. Especially if NIRSpec uses IRS2 mode.

Marcia: Every instrument uses a slightly different telemetry stream

Loic: for NIRISS it is ... (?)

Kevin: {ACTION ITEM} STScI representatives need to find the equations for how long an integrations takes for each instrument and mode. Needed for DMS to design how to compare the timing arrays.

Pierre: NIRSpec has TSO-like data from CV3

Loic: Same for NIRISS (TSO-like data from CV3)

Kevin: [Action Item] examine timing arrays from CV3 TSO-like data

Kevin: The community does not know what to qualify as "saturation"
Could each team make recommendations to the community here?

Marcia: We can look it up quickly. But it should be ~80% full well
-- that is well into non-linearity, but NL can be correct to high precision.

Tom: Could you recommend what level is desireable?

Kevin: We are looking for ~1% after correction

Loic: Each team for TSOs has its own saturation levels that converge to magnitude limits.
-- i.e. NIRSpec 65k for saturation; NIRISS has 72k, etc

Kevin: what is your definition for saturation

Loic: I think it is 90% full well

Kevin: and what about non-linearity?

Loic: the NL grows linearly with %FW, so at 90% FW, it should be about 9% non-linear

Kevin: What about the error on the correction?

Loic: That is a fair question, but not necessarily trivial. We need to look into second order effects.

Kevin: We don't want the community to push towards the 90% saturation limit without knowing the caveats.
-- we want the community to be able to estimate their level of risk.
-- there has already been confusion in planning obs

Loic: Okay. The error on the NL correction results in an error on the PPM of the final spectrum.
-- a 1% error on NL is a 1% error on the ppm
-- it is probably a second order thing
-- the bigger question is how is your results effect by saturation

Kevin: That is more reason to advise people to stay away from saturation.
-- should people avoid saturation completely

Jonathan: do you mean saturation at the first group or anywhere up the ramp?

Loic: it matters depending on the error (i.e. persistence). if we saturate at group=10, can we use groups 1-9?

Jarron: If we use groups 1-9, then we are making assumptions about the errors. any time we make assumptions about the persistence, we are added error into the results.

Loic: will any proposal be rejected if there is any saturation anywhere?

Kevin: They will definitely not reject saturated proposals, some peoples' science depends on it.

Kevin: Sarah gave slides that suggest MIRI might recommend saturation because if you have less than 5 groups, then there is difficulty in stability (1st/last frame effects).
-- if we run through 6 frames (saturated), then the last frame effect is on the saturated frame, instead of the last science frame.

Marcia: We should also inform people that the throughputs may be off by as much as 10%, which will affect these limits as well.

Marcia: one last thing: the JDox page says "check saturation limits with ETC"; so we (IDTs) need to make sure that the ETC is giving the right saturation limits.

Tom: The JDox pages give a more favorable result. The ETC may be using a static Gain for each instrument

Jarron: Everett, did you compare our simulations with the ETC?
Everett: Yes. a few months ago.

Maria: Tom, could you have the student you mentioned send us the notebook? We would like to check these numbers with our ETC

Loic: For NIRISS, the agreement is well below 5%

Marcia: For NIRCam, it depends on which SCA you are on. The values on the screen (exoctk.stsci.edu) are not what we expect for NIRCam.
-- the LW detectors should say max pos. sat. ~80k
-- the SW detectors should say max pos. sat. ~100k

Loic: For NIRISS, we have it at 90%

Maria: For NIRSpec, 65k counts already include bias

Kevin: [ACTION ITEM] Could each team rep send me those numbers in an email, with caveats for how we got these numbers -- to add to JDox

Pierre: These values are delivered to the ETC, if we send it in an email, then the ETC gets new numbers and we don't send new numbers to JDox, then there could be inconsistencies.

Kevin: We want to make recommendations to people that are aligned with the ETC; so please send us the ETC numbers.

Jarron: I am looking at JDox now and see that the numbers match, but in ADU instead of electrons.
-- Is it possible that the units on the ExoCTK page are in ADU instead of e-?
-- the numbers on ExoCTK match the ADU from JDox
-- the numbers on the Jdox for e- is correct

Marcia: for (..?) SCAs, we can basically digitized full well above the bias level

Kevin: DMS is designing CalTSO3-Spec.
We need to get nominal aperture sizes for integration with vanilla pipeline to extract spectra
-- Jonathan looked at the NIRCam data and found 22 pixel box (+/-11 from the spectrum) for aperture; then 42 pixels for bg

Marcia: keep in mind that the bottom 4 pixels are the reference pixels and not background pixels.
-- but the pipeline should also incorporate the reference pixels into tracking DC-level offsets, outside of the flux-background levels.