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.