7.9 micron filter curve

Here is a copy of the OCLI 7.9 micron WARM filter curve. The filter was installed in EXES Dec 2010 before we left IRTF. Uses a CaF2 blocker.

Bach Echelle #4 Interferograms

Here are some interferograms from the 4th Bach grating. They believe this meets the specs and will ship it, but believe they can do better and will try. If the 5th grating is better, they'll send that one, too.

It sounds like the PV and RMS wavefront errors are already converted to 10.6 microns, which worries me a bit since I'm not sure these values are actually good enough. The one big error turns out to be a region being cut when the temperature control wasn't quite up to snuff, which is why they think they can do better.

Broadband filter curves

I've received two new filters from Spectrogon. The curves are attached. These filters are meant for use with the lower resolution side of the grating and will be located in the decker wheel.

SB375 & opstables

I tested the array behavior (bare mux before 2010-11-29 and cold array on 2010-11-29) for different opstables to determine the best procedure on how we can run the SB375 on the IRTF. I wanted to put that down in writing since there are some twisted details that we have to look into in more detail.

Some words to notation: When describing opstables or detector reads in general, I use the following abbreviations:

SUR - sample up the ramp
SAD - destructive single samples

T - throwaway frame (detector reset but no conversion)
S - spin frame (no reset and no conversion - used on SUR)
D - destructive read (i.e. read & reset)
N - non-destructive read (i.e. read but no reset)

For the following it is always assumed that getisgimme = 1, hence no deliberate throwaways by the system, i.e. one always gets the current scan.

Findings so far:

1. When the ebox is done with an opstable and a new opstable is uploaded, the array has started already a new run on the old opstable. Thus, the reset behavior of the first frame of a newly uploaded opstable is in fact set by the old opstable, not the new one. The new opstable gets in effect at the second frame, which might still be affected by the reset behavior of the previous scan. This has implications on the construction of opstables for observing sequences. See second and third example at the bottom of this post.
   
   
2. When a new opstable is uploaded, the array stops scanning and returns to row 0 where it starts a new scan. One effect of this is that rows that haven't been reached in the first (the 'original') scan of the new opstable run, have a longer effective integration time, since it took longer to reach those rows, given that the first few hundred rows are read twice.
   
   This effect is not obvious for a non-destructive read. If, however, the scan is a destructive read, the rows addressed twice have been reset by the first (aborted) scan and have 'strange' flux values in the second (the 'final') scan. One would expect them to have a flux level close to the bias level since they were very recently reset, but that's not always the case. In any case, the first frame in a new opstable is corrupt and essentially lost. See, e.g. the first example at the bottom of this post.
   
   The scans following a corrupted scan show a kind of 'recovery' behavior. E.g., considering an opstable with 4 destructive reads and uploading the same opstable again after two runs on it, the first frame after the opstable has been reloaded, is corrupted, as explained before. The next frame, however, is also not quite OK, i.e. is not identical to the ones in the previous opstable or the following frames. It doesn't cancel out with those frames but shows an offset of about -10cts and a slope of of another -10 cts along all columns. This slowly fades away after a few frames.
   
   
3. I notice a change in the signal level and the read noise (could also be the amplitude of the odd-even-row effect) between N and D reads, when looking at data from the bare mux. I found this by constructing two opstables, one with 4 nondestructive reads, the second one with 4 destructive reads. When I execute the first table after the array was cycling idle in a destructive pattern, the first frame of opstable 'a' is a destructive read. At a constant framerate of 1Hz, the average flux is 90cts/s, the base level was ca. 7400 cts at the time of my tests. The first frame had thus about 7500cts and a stddev of 36cts (all measurements in a large box in the upper left, avoiding bad regions). Since this frame was a destructive read, the next frame should look the same. But I find that it's flux is about 50 cts above the last frame's level and the rms went up steeply to about 76 cts. The next frame has the expected flux increase of 90cts above the 2nd frame and the rms is 82. From there on, flux raises by 90cts and the rms by 6cts from frame to frame. So the non-destructive read has a stronger odd-even-row effect and has an offset base level in respect to the destructive read?!
   The opposite behavior is observed when I switch to opstable 'b'. The first frame is a non-destructive frame (since it's taken from the opstable 'a'). Its flux is higher than the last frame of the last opstable (exactly as expected since no reset was applied yet). The 2nd frame in the new opstable should thus have even higher counts, since this frame is the first that experiences a reset after the read. In fact I find lower counts than in the first frame (by about -70 cts). The rms dropped from 140 to 102. So the same level as the one found before. The third frame is than a 'normal' destructive read, i.e. fluxlevel is 7500cts and rms is ~36cts.
   
   Is that expected, i.e. should the destructive and non-destructive reads have a different behavior in terms of bias level and odd-even-row effect?
   
   Note (2010-11-29): Looking at data from the cold detector, the dominant 'noise' source is a odd-even effect on all rows. This amplitude of this effect seem to change with reset type and becomes stronger on consecutive non-destructive SUR sequences, hence, does not cancel out when subtracting the first from the last frame on a ramp. This needs further investigation. See, e.g. the second example at the bottom of this post.
   
   
4. When changing framerates, or ctdelay levels, the array also re-starts the clocking when it receives a new setup. This is a similar behavior as when uploading a new opstable. When combining a change in opstable and a change in ctdelay, one sometimes can observe 'double stripes', i.e. the scan was restarted twice. The first time when a new opstable got uploaded, the second time when a new ctdelay was set. Again, the exact behavior depends on the timing, i.e. at which time of the scan the commands are processed. So the exact striping pattern is not fully repeatable.
   

EXAMPLE SEQUENCES:

2010-11-29, b086-b088:

3 opstables where uploaded and executed. Each consisted of 4 destructive reads. The first had two extra throw-aways at the beginning. The plot shows the row-average over all columns for the central 1000 pix (rows 10:1010) for all 12 frames. Note the corrupted frames #5 and #9 where a new opstable was uploaded and started. Its overall flux level is higher (less counts - longer integration time) and it shows a discontinuity after about 300 rows.









2010-11-29, b080&b081:
1 opstable containing of 4 non-destructive reads (N-N-N-N) was uploaded and executed twice. The plot shows the row-average over all columns for the central 1000 pix (rows 10:1010) for all 8 frames from both runs of the opstable. Since the last opstable before this had a destructive read as the first frame, the first frame in this sequence is in fact a destructive read, i.e. the first non-destructive read is frame #2 and the ramp starts with the 2nd, not the 1st frame. Also note the corrupted first frame and the change in the amplitude and vertical distribution of the odd-even-row effect (which looks like noise in the plot).







2010-11-29, b082&b083:
Immediately following the opstable in the previous example (N-N-N-N), I uploaded a new opstable consisting of 4 destructive reads (D-D-D-D) and executed it twice. The plots shows the same as in the previous examples. The first frame is a non-destructive one (since the new opstable was not activated when the scan started). The second frame is still on the ramp, since the previous frame was non-destructive. Note that frame #2 has more cts (not less as expected for a frame on the ramp) and that frame #3 shows a different odd-even-row behavior and median count-level as compared to the other destructive reads following this frame.

SB375 Clock Table Revised

A number of minor errors in the SB375 clocking table have been corrected.  Reference pixels are now properly registered in the first four columns and the last four, and our effective active area is now 1024 rows x 1016 coulmns after discarding the outermost eight columns of active pixels in order to fit the reference pixels ino the 1024x1024 array format required by the existing software.

Because the SB375 busses four reference columns onto a single unit cell amplifier, the new clocktable allows four times more settling time on the reference pixels.  The code appears to work fine, and much of the fine scale horizontal striping has gone away with this fix.  The new clock table (v.1) will be uploaded to PBMA, and is reprinted below for reference:

**************************
# Clocking table generation file for SB375/EXES v.1
#
# This file generates a clocking bit table for use in the EXES instrument.
#
#
# Revision History:
#
# 10.11.18 - Revised to a sample reference pixels instead of outside cols of
#            active pixels, and to fix registration problems.  MMcK
# 10.09.08 - Initial.  MMcK, based on SB226_v2_1.btg
#
# Notes:
# SB375 has no dedicated sync pulses for the row and col muxes.  The sync function is
# accomplished by simultaneous assertion of the two shift register clocks.
#
# Clock labels:
# pR1 = slow (row) phase 1 (-2/-5)
# pR2 = slow (row) phase 2 (-2/-5)
# pC1 = fast (col) phase 1 (-2/-5)
# pC2 = fast (col) phase 2 (-2/-5)
# prston = reset pulse (-2/-5)
# prowon = opposite of prston
#
# Restrictions:
#-prstminimum time tbd (25us?).
#
#-'underlap' or shift register phases must be maintained to avoid unintentional sync
#
#-row and column muxes require a 'preamble' to initialize them.
#
#-preamble consists of asserting both phases to reset, then a period with both phases
# de-asserted, then a period with phase 1 asserted, then a period with both phases
# de-asserted.  First valid row/col address is obtained on next assertion of phase 2.
# Nominal pattern for the preamble is H 5 5 4 for phase 1, H 5 10 for phase 2.  First
# (reference) column is addressed with assertion of phase 2 on timeperiod 16.
# Col mux preamble occurs once per row, row mux preamble occurs once per scan.
#
#-SB375 array format is 1024 rows by 1032 columns, with 1024 columns of active pixels
# flanked by 4 reference columns on each side.  There are no reference rows.
# Reference columns differ from active pixel columns in that a) they have no detector
# attached so capacitance is slightly different and b) a sigle unit cell feeds all
# four reference columns on an edge so the drive current available and time constant
# differ by x4.  We provide 4x more settling time for the reference columns to
# account for this.
#
#-Because our present FPGA software can only deal with 1024x1024 array format,
# can't sample all 1024x1032 elements of the SB375.  The reference pixels are
# presently deemed more valuable, so the clock table digitizes the reference columns
# in place of the first and last columns of active pixels.
#
#-The SB375 resets rows in pairs, with the reset function enabled on the even
# (second) row of each pair.  Odd rows can be reset only after stepping on to the
# subsequent even row.  The row mux will not run in reverse, so it is not possible
# to run a 'delta-reset' sampling scheme as is done in TEXES.
#
#-The clock table is written around a basic building block of 10 time periods per
# unit cell pair. Each unit cell is held valid for 4 time periods, and the
# required underlap adds 2 time periods of overhead per pair.
#
#-The four outputs are sampled simultaneously, so digitization of the 1016 columns
# of active pixels requires 10 * 1016/8 = 1270 time periods. To this time we add 34
# additional time periods to sample the pair of reference columns (16 time periods
# asserted for each ref column, plus two time periods for underlap), plus 10 time
# periods to clock through (but not digitize) the two columns of discarded active
# pixels plus 15 time periods for the preamble and 25 time periods for the reset
# pulse.  In this edition of the clock table we clock all the rows symmetrically,
# whether they are even or odd so that the device is clocked smoothly.  The total
# time for a row is thus 1354 time periods.
#
# There are 1024 rows so the total length of the clock
# table is 1386496 timeperiods.
#
#-FPGA code reserves bits 7 for prst, 8 for SOP, 9 for EOP, 20 for ADC pulse.
#
#
# Mapping of clock lines based on Lab Cable Dwg:
#-CLK1    VrstOff        (Z)
#-CLK2    pC1        (A)
#-CLK3    pC2        (C)
#-CLK4    VnCol        (E)
#-CLK5    VnRow        (G)
#-CLK6    VpRow        (J)
#-CLK7    pRstOn        (L)
#-CLK8    SOP        (reserved)
#-CLK9    EOP        (reserved)
#-CLK10    pRowOn        (T)
#-CLK11    VRowOff        (V)
#-CLK12    VggCl        (X)
#-CLK13    pR2        (N)
#-CLK14    pR1        (R)
#-CLK15    pRefEnable    (d)
#-CLK16    VnpwR        (f)
#-CLK17    VnpwT        (h)
#-CLK18    VnStat        (j)
#-CLK19    unused
#-CLK20    unused
#-CLK21    ADC convert    (reserved)
#-order of labels below determines pinout of clock connector.

TABLELEN        1386496
TIMEPER         1    # ca. 1 microsec per table entry
NBITS           21   # 32 max

VrstOff        L &                                  #set low and stay low
# CLK2:
pC1        H ( 5 5 4 18 ( 4 6 )128 16 26 )1024
# CLK3:
pC2        H ( 5 10 16 6 ( 4 6 )127 4 43 )1024
# CLK4
VnCol        L &
# CLK5
VnRow        L &
# CLK6
VpRow        L &
# CLK7  
prston        L 1329 ( 25 1329 )*
# CLK8
-SOP        L &
# CLK9
-EOP        L &
# CLK10
pRowOn    H &
# CLK11
VRowOff    L &
# CLK12
VggCl        L &
# CLK13:
pR2        H  5 10 1339 ( 1355 1353 )*        # Start asserted for 5

timeper, then off for five, then alternate
# CLK14:
pR1        H  5 5 4 1341 ( 1353 1355 )*        # Start asserted for 5

timeper, then off for five, then alternate
# CLK15
pRefEnable    L &
# CLK16
VnpwR        L &
# CLK17
VnpwT        L &
# CLK18
VnStat        L &
Z19        L &
Z20        L &
# CLK21
-CTC        L ( 30 1 9 1 ( 4 1 )253 21 1 26 )*

Filter Complement for IRTF

For reference, here is the filter complement for the January IRTF run.  The filters have been installed in EXES as follows:


Filter Wheel:

1)  18a (Unchanged from CD9)
2)  N04679+CaF2  (replaces BP4990, using Emmett's 0.75" adapter)
3)  open  (same as CD9)
4)  N07466-9+CaF2  (same as CD9)
5)  Open for borrowed filter  (empty 0.5" adapter installed so we can't lose it)
6)  OCLI 'O'+CaF2  (BaF2 blocker replaced)
7)  OCLI 'P'+ CaF2  (BaF2 replaced)
8)  OCLI W10692-9  (same as CD9)
10)  OCLI 'S'+BaF2  (added BaF2 blocker)
11)  BP13465+BaF2  (added BaF2 blocker)
12)  BP-14100-850  (same as CD9)

Decker Wheel:

3)  Soifer 22um  (same as CD9)
4)  OCLI 07053-9  (same as CD9.  No replacement specified...we won't use it @ IRTF and I elected to change next time the Decker is out)
5)  BBP5030-5725  (same as CD9)
6)  BBP5500-6000  (same as CD9)

We'll have another opportunity to iterate at the IRTF when we install the borrowed filter.

SB375 ROIC now installed in EXES

After a minor fanout rework, an SB375 bare mux has been installed in EXES.  The image at right shows the 'string of pearls' produced by the not-quite single mode laser as seen by the SB375.  The device is operating nominally.

Below are the signal assignments for the eBox used with EXES with the present fanout rework.  These are provisional, and will be updated when the cabling is completed and a new fanout installed.

Because of cable differences between tha lab dewar and the EXES instrument, bias and clock assignments vary between the two installations.  Jumper settings too.  Please check for updates in the lab book before using the table below.

eBox & jumper assignments for the SB375 in EXES:

• DC01:  VnPwR (JP7 in, JP8A)
• DC02:  VddOutRef
• DC03:  VddCL
• DC04:  VDet
• DC05:  VddUC
• DC06:  VddOut
• DC07:  VssUC
• DC08:  VSlewRef
• DC09:  VnStat + VnPwT

• CLK01:  ØRstOff
• CLK02:  ØC1
• CLK03:  ØC2
• CLK04:  VnCol
• CLK05:  VnRow
• CLK06:  VpCol
• CLK07:  ØRstOn
• CLK08:  SOP
• CLK09:  EOP
• CLK10:  ØRowOn
• CLK11:  ØRowOff
• CLK12:  VggCL
• CLK13:  ØR2
• CLK14:  ØR1

• JP01:  IN (Reference clock shields to AGND)
• JP02:  IN (Tie ØRefEnable to AGND)
• JP03:  IN (Reference AGND to DGND)
• JP04:  B  (Tie VnStat to VnPwT)
• JP05:  OUT  (Would tie VnPwT to DC12)
• JP06:  A (Tie VidleRef to AGND)
• JP07:  IN  (Tie DC01 to VpNwR)
• JP08:  A  (Tie Vsub to AGND)
• JP09:  IN  (Reference bias shields to AGND)
• JP10:  IN (Reference output cable shield to AGND)
• JP11:  IN (Reference output cable shield to AGND)
• JP12:  IN (Reference output cable shield to AGND)
• JP13:  IN (Reference output cable shield to AGND)
• JP14:  IN (Reference output cable shield to AGND)

Row reset now working.

Turns out that clocking the reset pulse to the -5.5V (asserted) level was causing enough loading on the VrstOff line to reset all of the unaddressed rows, effectively applying a global reset.  Dropping the reset clock (prstOn) to -2V/-4.5V does not eliminate the loading, but reduces it to the point where the reset is only applied to the intended row pair.

We're clocking nominally now.  The image at left was taken at ctdelay = 5, which give almost 4Hz frame rate.  It's a difference between two slices of a SUTR 8-1-4-4 file.  The fluorescent bulb in the ceiling light is saturating so it comes out dark in the difference.

There are still some clocking issues to deal with.  We are not presently sampling the reference pixels as we want to, and I need to make up some short-scanning clock tables, but these are pretty simple adjustments.

At this stage I think we're ready to install the SB375 mux in EXES and image the 'string of pearls'.

Investigating row reset on the SB375

The rest pulse is specified in the clock table as:

prston        L ( 2585 25 )*

Which in the world of btg means 'start low, remain low for 2585 clock periods, then assert the rest line for 25 periods'.  The asterisk indicates that we wish for the pattern to repeat to the end.  Each row takes 1305 periods to clock out, so two rows takes 2610 periods.  We wish for the reset to be applied for the last 25 periods, thus the 2585-period low level.

Since we're seeing what looks like global reset, I'd like to verify that the SB375 is indeed capable of a row reset by resetting a single row.  Let's try leaving it low for the first 512 rows (668160 periods) then run a row pair as normal (2585 L, 25 H), then go low for the remainder of the table, like:

prston      L 670745 25 &;
prowon    H 670745 25 &;

Note that pRowOn is meant to complement pRstOn.

After verifying that the snippet above made the desired changes in the clock table, and that the scope reflects the desired changes in the reset pulse, the frame at left was acquired. This is the fourth scan of an SUTR set.  The top half of the image (the part after the reset pulse) has all been reset to a different value than that in the lower half (pre-reset).  The lower half is being reset as well, though in this image it was digitized before the reset wasw applied.

As far as I know the SB375 is incapable of global reset, but apparently more study is required.....

Reset issues

Looks like the reset pulse is performing something more like a global reset than the intended row-reset....not sure why.  Signal is greatly reduced in the last scan of a SUTR set, as would be true for the SB226 with its global-only reset scheme.  Scope shows the first row of the last scan is saturated (as it should be for the conditions), but the second row is not.  Might be a synchronization issue(?).  Grrrr.  Will experiment with the clktable to sort out why.

eBox Clocking the SB375

Our eBox is presently clocking a warm bare mux at 3.8Hz scan rate (!).  The pinhole-image of the ceiling lights at right was obtained at this speed (ctdelay=5).  This speed will probably not be useful once we cool to LHe, but for the moment we seem to be in good shape.

Included here for reference is our 'Version 0' .btg file for the SB375.  If you want to spend some time staring at it you can see the details of how we're running the device.  This file is passed as an argument to the btg.exe to create the .bt file for upload to the eBox.  It will need tweaking to properly sample the reference pixels, but that's a minor fix.

# Clocking table generation file for SB375/EXES v.0
#
# This file generates a clocking bit table for use in the EXES instrument.
#
#
# Revision History:
#
# 10.09.08 - Initial.  MMcK, based on SB226_v2_1.btg
#
# Notes:
# SB375 has no dedicated sync pulses for the row and col muxes.  The sync function is
# accomplished by simultaneous assertion of the two shift register clocks.
#
# Clock labels:
# pR1 = slow (row) phase 1 (-2/-5)
# pR2 = slow (row) phase 2 (-2/-5)
# pC1 = fast (col) phase 1 (-2/-5)
# pC2 = fast (col) phase 2 (-2/-5)
# prston = reset pulse (-2/-5)
# prowon = opposite of prston
#
# Restrictions:
#-prstminimum time tbd (25us?).
#-'underlap' or shift register phases must be maintained to avoid unintentional sync.
#-FPGA code reserves bits 7 for prst, 8 for SOP, 9 for EOP, 20 for ADC pulse.
#
# Notes:
#-each row asserts pC1 and pC2 128 times, ctc 256 times.
#-prst is asserted 1 time every other row.
#-at TIMEPER = 1us, each UC takes 5us.  Each row 1325us, each scan 1.36s.
#
#-order of labels below determines pinout of clock connector.

TABLELEN        1336320    1305 us/row * 1024 rows = 1336320us
TIMEPER         1   # 1 microsec per table entry
NBITS           21   # 32 max

Z1        L &
# CLK2:
pC1        H ( 5 5 ( 4 6 )126 4 31 )1024
# CLK3:
pC2        H ( 5 10 ( 4 6 )126 29 1 )1024
# CLK4
VnCol        L &
# CLK5
VnRow        L &
# CLK6
VpRow        L &
# CLK7  
prston        L ( 2585 25 )*
# CLK8
-SOP        L &
# CLK9
-EOP        L &
# CLK10
pRowOn        H ( 2585 25 )*
# CLK11
VRowOff        L &
# CLK12
VggCl        L &
# CLK13:
pR2        H  5 1300 ( 1304 1306 )*        # Start asserted for 5 timeper, then off for five, then alternate
# CLK14:
pR1        H  5 5 1294 ( 1306 1304 )*        # Start asserted for 5 timeper, then off for five, then alternate
# CLK15
pRefEnable    L &
# CLK16
VnpwR        L &
# CLK17
VnpwT        L &
# CLK18
VnStat        L &
Z19        L &
Z20        L &
# CLK21
-CTC        L ( 13 1 ( 4 1 )255 16 )*

CD9 tasks (copy of email)

Here's a copy of the email I sent this morning to Mark and Andreas regarding CD9 tasks. -mjr

Now that we're done with CD9 and the data are transferred, we should
talk about the analysis. I've already got Jesse working on the CD8
mapping of the central wavenumber compared to grating resistance, so
I'm not going to include him on this email.

As I see it, we did the focus grid in med mode, the focus grid in
hires mode, checking the 7.4 micron filter for leaks, looking for the
glint, the filter mapping, and the paired pinholes. Anything else?

In dividing these tasks, some are already done, some of us may be busy
with hardware (Mark?), some of us are busy with software (Andreas),
and some of us are parasites..... Anyway, scream if you are unhappy
with this division:

Med mode focus grid - already analyzed for best focus. Could be
looked at in terms of grating parameters since we have so many lines
in a single setting and could check grating equation for each of them
(want to know effective size of pixels, so better worked on after
paired pinholes). Deferred for now.

Hires mode focus grid - already analyzed for best focus. Could be
looked at to properly calculate resolving power, but not going to care
right now since we're over R=100,000. Deferred for now.

7.4 micron filter - no leaks. Done

Glint - gone. Done.

Filter mapping. hires obs of continuum in each and every filter with
echelle spaced 400 ohms. Want to go through and look at each echelle
setting for each filter and evaluate in terms of leaks, relative
throughput, number of orders, spacing between orders, and, eventually,
the central wavenumber (as determined by grating resistance). All
this information will get fed into Andreas's software to help a person
set up an observation. I'm going to take this as my second priority.

Paired pinholes. hires and med mode obs of paired pinholes at
Q-branch. Med mode done at two mirror positions. Analyze for
platescale assuming the pinhole separation is as designed with caveat
that Andreas found the spacing had a jump. I'm going to take this as
my first priority.

In other words, unless you guys are looking for something to do, all
you have to do is keep on me to get these things done. Oh, and keep
yourselves productive for the IRTF readiness review in early Nov.

Leak in 7.466µm filter fixed

This afternoon we took some data intended to verify that the leaking of third-order light through the 7.466µm filter had been fixed by the replacement of the BaF2 blocker used in CD8 with CaF2.

Looking back at CD8 in the lab book, found a reference to leaking third-order light in B_10_08_18/b222.fits.  Here's the image.

It's apparent that there are two overlaid patterns of orders....the more widely-spaced set shouldn't be there.

Today we went back to the same echelle angle and filter, this time using the pinhole:

The pinhole makes for narrow orders but less overall light...the integration time was increased bay a factor of three over that for b222 to check whether there might be faint leakage  between the orders, but none appears.  Looks like the CaF2 did the trick.

SB375 @ 1 sec. Scan Time (part 1)

Dzung and Bob ran a series of tests with an SB375 array to see how well it works at 1s scan times. If it works well, operation at the IRTF will be more like TEXES in terms of observing schemes.

The data have been moved to the 'SaltLick' server in the EXES lab. You can find it in /Reduced/SB375_Det_Lab/EXESSB375_SCA_128_100915. There are four subfolders:

- DKI_BB7K_7K_varyVdet_varyFD_1

- DKI_BB7K_7K_varyVdet_varyFD_2

- PhotoI_BB45K_7K_varyVdet_varyFD_1

- PhotoI_BB45K_7K_varyVdet_varyFD_2

The folders ending in '1' are taken at 1s scan time, the others at ~2.7s scan time. Within each folder are a series of frames taken at different integration times and different detector biases. What I'd like to know first is whether the detector response is comparable at the two scan times.

Ran the data through the 'aida_getstats' IDL routine to gather summary statistics, plotted here:

This is a messy plot. The data show mean-pixel signal for different integration times and biases. Each series shows discontinuous segments, each of which corresponds to a different detector bias. At a given bias, there are 11 measurements at frame delay values times incremented by 1s from one point to the next, over a range of zero to ten seconds. The 2.7s (blue) data took longer to collect due to increased scan time. The data plotted are all fowler-4 results.

Ideally these segments should all be straight lines, since the detector response should be linear at a given bias and the integration time is changing linearly. The fact that the segments are not straight shows that the detector response is non-linear. The 2.7s (blue) data beyond about 7.5ks (and the 1s data beyond 5ks) elapsed time are essentially flatlined, because the

detector is saturated. The very early data is curved because low detector bias levels lead to early debiasing effects. Basically, most of this data set is not useful.

But let's look at the third segment in each set, which is not railed, and not at zero bias. For these segments, the applied bias is -1V, and while we see some curvature, we don't hit a hard rail anywhere.

Units are arbitrary, and there is an offset between the two curves, but the signal is actually a little higher for the 1s-scan time based on slope. This may be due to a slightly higher effective bias at each integration time due to the faster scan time (less debiasing), but it would be nice to see some data collected with less photon flux in the detector FOV so that more of the data could be analyzed. Dzung is taking another cut at this experiment this week.

More work to do, but this set of data is encouraging. I was concerned that the array would not respond at this speed, or that it would fail to reset, etc. So far, so good.

Analysis: Lo-Med Res Focus in CD8

Data source: B_10_8_17/b000.fits - b022.fits.
Lab Notebook reference Vol. 2 pp. 86 - 88.

Notes: Data collected at -2V applied detector bias, T = 7K, 14.1µm filter, pinhole.

Purpose:

1. Quantify spot size as function of echelle turns

2. Verify echelle best focus

3. Calculate echelle resolving power at best focus

4. Investigate grating parameters and determine grating input angle using spot locations

5. Calculate km/s per pixel at best focus for this grating angle

6) Compare km/s spot size to theory for this angle and grating parameters

1) In this data set the echelle was set to the C2H2 Q-branch. A sample image (at nominal best focus of 14T) is shown here:

Odd/even variation is apparent, suggesting broadening is not an issue in this data. We can use ImageJ to make a profile plot along the line:

An unfortunate fact is that we did not save a rinsed cell at each focus position in this set, just at the initial (14T position). Using Matt's clickfit idl procedure in 2D mode is going to be problematic. To get a idea of focus we can use ImageJ to grab profile plots and then fit them with gaussian profiles in Kaleidagraph. Let's try to select the same line in each frame, and do an x- and a y- gaussfit.

File : turns : FWHM-x : FWHM-y

boo5.fits : 14T :

Turns out that it isn't worth pursuing this much further without the rinsed cell data. Will retake (with rinses) in CD9.