RMG IOTA Run May 1 - May 14 Log of PICNIC noise work *** Note: error in comparisons with NICMOS cam background corrected in update notes *** ----------- UT May 8 02 ----------- * run vxworks DAQ with UPS bypassed: no difference dark room, cold plug scanners off: iota26: NR=NL=1 iota27: NR=NL=4 scanners on: iota28: NR=NL=1 iota29: NR=NL=4 ----------- UT May 9 02 ----------- * set up scope looking simultaneously at: FSYNC, LSYN, SAMPLE, ADC-IN * Timing of NReads & NLoops ------------------------- - tint_1(ms) is given measured and printed by DAQ software for Npoints=8, Nbad=4 (to see most pulses on scope) - tint_2(ms) is given measured and printed by DAQ software for Npoints=256, Nbad=70 (typical operation) - tint_scope(ms) is given by separation of LSYNC pulses (for NLoops=1) or by separation of Nloops LSYNC pulses - they are meant to measure integration time per point in scan note: ---- 1) up to NR=3,NL=2 I can see every single pulse on the scope, and it all looks perfect 2) I can also verify that all pulses are there for any NReads and NLoops=1: OK 3) after that I can only verify that all SAMPLES are there (one per NRead per pixel): OK 4) after NLoops=4, tint_1 is actually measured using Npoints=32, Nbad=8 ******** 5) on the scope one can see that the number of Nbad actually sampled x2 what is entered in the IDL/observe program!! ******** NReads NLoops tint_1 tint_scope tint_2 -------------------------------------------------------------- 1 1 0.375 0.35 0.348 2 1 0.625 0.49 0.495 3 1 0.688 0.64 0.641 4 1 0.875 0.78 0.788 1 2 0.750 0.68 0.692 2 2 1.062 0.98 0.982 3 2 1.375 1.27 1.278 4 2 1.688 1.56 1.568 1 3 1.125 1.03 1.035 2 3 1.562 1.47 1.472 3 3 2.000 1.92 1.912 4 3 2.375 2.34 2.348 1 4 1.396 1.375 1.379 2 4 1.979 1.95 1.960 3 4 2.562 2.54 2.545 4 4 3.146 3.125 3.129 1 5 1.750 1.72 1.720 2 5 2.458 2.44 2.449 3 5 3.208 3.17 3.179 4 5 3.938 3.89 3.909 1 6 2.083 2.05 2.061 2 6 2.958 2.93 2.937 3 6 3.854 3.80 3.813 4 6 4.708 4.69 4.692 1 7 2.417 2.40 2.404 2 7 3.458 3.43 3.427 3 7 4.479 4.44 4.449 4 7 5.500 5.49 5.472 1 8 0.375 doing 1,1! 0.348 2 8 0.562 doing 1,1! 0.495 ... ... ... ... ... 8 8 0.438 doing 1,1! ... ... ... ... ... ... 1 8 0.438 doing 1,1! 0.348 Conclusions ----------- 1) Software-measured and scope integration times agree. 2) Software measured tint probably has some overhead included that looses importance as a larger number of points are taken in the scan, hence the much better agreement between columns 4 and 5. 3) These numbers make some sense ... at least the combinations I have tried, the tint go in proportion to the NLoops for the same NReads. 4) Beyond NLoops=8 or NReads=8, we actually get a NL=NR=1 readout! This is odd ... I thought people have oberved in these modes ?? Perhaps this is another intermittent bug, or is there a limit to those counters in the CPLD?? ----------------------------------------- note, to follow up later: in terms of the noise peaks in the power spectra, I seem to get the better defined narrow peaks for modes that have NReads=1, and any NLoops. ----------------------------------------- * Signal & Noise as a function of NReads & NLoops ----------------------------------------------- - this addresses the mean signal we get and noise in the sense of rms of each scan, not the features we see in the power spectrum, which will be addressed later - could not record data due to iota disk space problem - record some data by hand, get a rough idea - cold plug, dark room, data for pixel 1, VxWorks_DAQ - I have modified option 3 of IDL/observe (rawscans.pro) to display scans as data/(nreads*nloops) and a normal power spectrum, and prints mean & rms for each scan; this is my tool for everything that follows (also subsequent days): NR NL mean(du) rms(du) tint(ms) ----------------------------------------- 1 1 0.3 7.0 0.35 2 1 0.6 5.5 0.49 3 1 0.8 4.2 0.64 4 1 0.9 2.8 0.78 1 2 0.7 5.5 0.68 2 2 1.0 3.0 0.98 3 2 1.25 2.4 1.27 4 2 1.5 2.0 1.56 1 3 0.9 6.0 1.03 2 3 1.3 2.1 1.47 3 3 1.7 1.9 1.92 4 3 2.1 1.8 2.34 1 4 1.1 5.1 1.375 2 4 1.6 2.1 1.95 3 4 2.1 1.9 2.54 4 4 2.7 1.8 3.125 - see plots of mean vs. tint and rms vs. nreads*nloops - both seem to approximately do the right thing. ------------ UT May 10 02 ------------ * Added power spectrum plot to my Pentium code that samples scans of a PICNIC pixel. This will be useful when addressing the power spectrum noise features we see in the PICNIC scans when sampled by the CPLD/VxWorks system, starting probably tomorrow. ** note: it turned out that data could not be saved yesterday not due to disk space problem, but due to modification made by Ed Wilson (NASA Ames) to a DAQ file. * Therefore, I repeat yesterday's experiment but this time recording data for later analysis. Note that in addition to getting the signal increase as a fn of int time and the noise (in the sense of scan_rms) as a fn of nreads&nloops, this data set tells us the amount of dark counts + light leakeage the PICNIC gets (see approximate numbers above: - dark room, cold plug (scanner equipment unplugged, which we determined previously has no effect) NReads NLoops file ----------------------- 1 1 iota0 2 1 iota1 3 1 iota2 4 1 iota3 1 2 iota4 2 2 iota5 3 2 iota6 4 2 iota7 1 3 iota8 2 3 iota9 3 3 iota10 4 3 iota11 1 4 iota12 2 4 iota13 3 4 iota14 4 4 iota15 * The PICNIC t-domain Intermittent Large Spikes --------------------------------------------- - These are large +- spikes that sometimes appear on the third pixel sampled on certain readout modes (nreads&nloops), one or several per scan. Not to be confused with the features seen in the power spectrum, which is a separate problem. - Both EP and I suspect that this is a digital CPLD related problem, not true analog or digital noise in our system - Yesterday I did not have this problem, today I do ... so find out some things about it: -- Why always 3d pixel sampled? I am now actually sampling different pixels than the ones we normally use on which IONIC puts the light, and the problem appears, therefore this is not intrinsic to a particular pixel, but any 3d pixel -- Looking on the scope at SAMPLE and ADC_IN while this problem appears reveals nothing unusual, the analog pixel signals and where they are sampled are OK, and SAMPLE itself does not go off someplace weird or anything for the 3d pixel -- If I disconnect the dewar from the ADC, the problem persists, therefore this has indeed nothing to do with our analog signals. Same thing if ADC input is shorted (and J2 jumper closed as it must be) -- The level of the spikes is +-40K, which is not even a possible output of the ADC (range: +-32K), this leads further support to the idea that it is some sort of CPLD or data handling screw up; the fact that it is intermittent points more to a CPLD problem than a strictly software problem though -- This problem occurs, when it occurs, for the following combinations only, of the 16 combinations in NReads&NLoops 1->4: bad: NR=4,NL=3; NR=3,NL=4; NR=NL=4 as far as I can tell from my experience, that seems to be always the case -- Note: for the data files taken tonight, just ignore pixel 3 in those modes * Levels of Power Spectrum Noise Features --------------------------------------- - While I am playing these games, and as a preliminary for getting serious about the problem of the power spectrum noise features, record some numbers using my normal power spectrum plot, to get the relative importance of things: 1R1L, ADC shorted: rms=1du ps_noise_max=0.05 1R1L, connected to dewar, cold plug: rms=7du ps_noise_max=2.0 2R2L, connected to dewar, cold plug: rms=3.5du ps_noise_max=0.5 4R4L, connected to dewar, cold plug: rms=2.1du ps_noise_max=0.1 -- Note: those numbers for ps_noise_max correspond to the tallest features in the power spectrum. When one switches to the display we normally use when we observe (ftrack.pro instead of rawscans.pro) they look huge and are labelled 10^12!, they look much more dominant than in the normal power spectrum of un-corrected scans (corrected means sum divided by difference, of complementary pixels; and normal power spectrum is in contrast to cross-scpectrum used by EP fringe tracker) ... for whatever this observation is worth. Also, this makes me worry that fringe tracker uses this signal to identify a fringe ... * PICNIC Background Contamination ------------------------------- - How much signal do the pixels get which does not belong to the star? - PICNIC looking at warm shutters through clear optics, H filter: Note: the representative numbers in cols 3 and 4 come from the rawscans.pro display, for pixel 1 NR NL mean(du) rms(du) file -------------------------------------------- 1 1 0.4 7.5 iota16 2 1 0.7 5.0 iota17 3 1 1.0 4.2 iota18 4 1 1.1 3.5 iota19 1 2 0.9 5.0 iota20 2 2 1.3 3.5 iota21 3 2 1.7 3.1 iota22 4 2 2.0 2.5 iota23 1 3 1.2 4.5 iota24 2 3 1.8 3.1 iota25 3 3 2.3 2.6 iota26 4 3 2.7 2.4 iota27 1 4 1.5 3.7 iota28 2 4 2.2 2.7 iota29 3 4 2.9 2.5 iota30 4 4 3.6 2.1 iota31 Conclusion ---------- - My real time estimate did not always catch the expected increase in rms due to the extra shot noise from background photons, but there is definitely an effect here, as well as in the mean signals, which will quantified better using the data files - Taking these initial estimates at face value, and considering the longest integration time mode (4R,4L), we get 3.6du of dark+background signal in tint=3.125ms (see above table of tint), or 3.6/3.125=1.15du/ms - According to my thesis, the NICMOS system had a background signal at K' band of: 586 e/s = 586 e/s * 1/3.2 du/e = 183 du/s = 0.183 du/ms - Therefore, the PICNIC system accepts a H band 1.15/0.183=6.3 times more background than the NICMOS system did at K' band! - Is this consistent with the limitation in observing faint sources reported by JDM and JPB? - From the above measurement with the detector looking at the cold plug, we get that even in that case (2.7du/3.125ms=0.86du/ms) we now have 0.86/0.183=4.7 more extra signal than the NICMOS system had when actually looking out through K' - This would naively indicate that the problem is with photons somehow reaching the detector even when we think it is sealed, rather than due to the lack of a proper optics baffle ... perhaps next time the dewar is opened we could try extra al foil sealing, or does the new filter wheel let more stuff in? or is it because we could not fit in the lower part of the cold shield in this dewar? ... what do Wes/Nat think? ** Note: noticed at the end of the night that MGL had left some tank lights on, which in the past were seen to introduce noise, I hope it did not contaminate tonight's measurements ... ------------ UT May 11 02 ------------ * More on Background ------------------ - Record some more data to provide more constraints on where the PICNIC dewar background signal is coming from (outside, inside?): VxWorks DAQ system, NReads=4, NLoops=4 (highest integration) dark room, scanners off Numbers below for immediate estimate are mean and rms of 10 samples read from display (rawscans.pro): Condition mean(du) rate(du/ms) file (tint=3.125ms) ---------------------------------------------------------- H looking out 7.87+-0.15 2.52 ... at closed shutters (a) H looking out 3.57+-0.05 1.14 iota32 at closed shutters (b) cold block 2.95+-0.07 0.94 iota33 cold block plus 2.47+-0.06 0.79 iota34 al foil tight against dewar window - Note: the first measurement at H above (a) has much higher mean, inconsistent with previous measurements ... this turned out to be because it is daytime now and I had lab curtains not well closed! - Note: these data are in ~/Data/2002May10/, it is early pm now - Note: for the record, today t-domain spikes of pixel 3 are here ... Conclusion: ---------- - The PICNIC detects a difference depending on what we do outside the dewar even when the cold block is on, therefore the cold block is not a perfect light seal: when I blocked the dewar window with al foil, signal went down by 16% - Even with cold block + al foil (reflects on the outside, emits little to the inside) we get 0.79du/ms / 0.183du/ms = 4.3 times more signal than NICMOS system looking out through K'. However, the al foil is still a warm surface, so I am not sure how to separate its emission from photons landing on the detector from other directions inside the dewar ... * PICNIC Reset & Saturation Levels - Analog ----------------------------------------- - With cold plug and fast reads (almost no signal input) the scope measurement at ADC_IN shows that the pixel signals are at +4.5V, slightly below the +5V upper limit of the ADC: OK - With maglight near dewar window, scope measurement shows that saturation of the pixels occurs at -6.0V, somewhat below the -5V lower limit of the ADC: OK * PICNIC gain(e/du) ----------------- - The above measurements allow us to estimate a _nominal_ gain for the system (e/du): Assume a nominal full range of 150.000 e (from NIRSPEC documentation, can't find a Rockwell quote) Assume a pixel full range in volts of 0.45V, from Rockwell => gain1 = 3.0e-6 V/e Our full range at the ADC_IN measured above is 10.5V, therefore our pre-amp chain gain (not gang!) is: => gain2 = 10.5V/0.45V = 23.3 (this ~agrees w. design value: 20, and with lab measured value of 20.1 excluding small gain ADC pre-amp) The full range of the ADC is 65535du: => gain3 = 65535du/10.5V = 6241.4 du/V so: gain(du/e) = gain1*gain2*gain3 = 0.44 or: gain(e/du) = 1/0.44 = 2.3 - In Oct2001 I took data to _measure_ this quantity using the "Poisson statistics method" and got gain(e/du) = 2.9 - 3.2, depending on the pixel. This discrepancy (~20%) can be explained by the assumptions in the nominal values above, for example, I was under the impression that the full well was deeper than 150K electrons, which goes in the right direction. * Gain(e/du) and Read Noise -- Poisson Statistics Experiment ---------------------------------------------------------- - Take some more data to re-do the "Poisson statistics method" measurement, can't hurt. Do this at 2 representative readout modes only. cold plug, VxWorks DAQ, gradually increase light level shone onto cold plug, then to get more light in, open to H and put white diffuser in front of dewar window, maglite on variable dc supply as before, in addition to the files I record some numbers for inmediate plot, they are means of 5 samples read from display, for pixel 1 data in ~/Data/2002May11/ --------------- NReads=Nloops=1: --------------- mean(du) scan_rms(du) file ----------------------------------- 0.33 8.86 iota0 2.18 8.43 iota1 4.51 9.24 iota2 7.06 9.09 iota3 13.37 8.96 iota4 36.53 9.32 iota5 57.09 9.54 iota6 76.44 10.05 iota7 91.0 10.66 iota8 125.81 10.99 iota9 158.0 12.0 iota10 - Note: sometimes during this experiment, well defined peak in power spectrum would show up - Note: towards the end, pixels approached saturation -- watch for non-linearity! --, not all at the same time, probably my illumination is not uniform For reference: after the 256 samples in these scans a pixel is right at saturation at the end of the scan if the mean is ~198du --------------- NReads=NLoops=4: --------------- mean(du) scan_rms(du) file ------------------------------------ 3.8 2.2 iota11 8.2 2.7 iota12 13.1 2.9 iota13 18.0 3.0 iota14 34.0 3.7 iota15 63.7 4.2 iota16 120.0 5.9 iota17 164.0 7.1 iota18 140.0 6.5 iota19 - Note: pixel 3 is showing the t-domain spikes, as is common in this mode Conclusions: ----------- - This seems to behave properly. From the slope and intersect of the variance(du^2) vs. mean(du) plots with the data from the table above, I get (preliminary): NR=NL=1: sqrt(intersect) = noise_du = 8.52du 1/slope = gain = 2.39 e/du noise_e = gain * noise_du = 20.36 e NR=NL=4: sqrt(intersect) = noise_du = 1.97du 1/slope = gain = 3.68 e/du noise_e = gain * noise_du = 7.25 e - Recall, these noise figures are per double read, in principle sqrt(2) smaller per read - As previously stated, the base noise for this camera (1L1R) is somewhat higher (23%) than for the NICMOS one (20.4 electron instead of 16.6 electron, per double read). Hopefully this is due to the extra noise we see in this system, and when we fix it (cross your fingers!) we'll do as well or better than with NICMOS. - In this experiment, the noise went down by a factor of 20.36/7.25=2.8 between 1R1L and 4R4L, instead of the expected sqrt(16)=4. This, or equivalently what we get in the noise vs. number of reads experiment of UTMay09, may also be due to the extra noise. * Noise Peaks seen in Power Spectrum ---------------------------------- - This another problem we want to evaluate: often the noise spectrum shows a very well defined peak, which moves around in frequency on t-scales of minutes, from of order 50Hz to of order 1000Hz. During real data acquisition, they seem to have non-negligible power compared to the fringe power, plus they confuse the fringe tracker if they fall in the region of expected fringe frequencies. - This pm I had some appearances of this problem, so tried to find out some things about it: -- strengh: ps_noise_max = 6, in same units as measurements of UTMay10, recall when I do not see these features, I measured ps_noise_max = 2 (under same conditions); so these are 3x higher also recall from UTMay10, and re-measured today, that with the ADC shorted, ps_noise_max = 0.05; so these are 120x higher than minimum possible noise; assuming comparing with ADC shorted is a fair comparison -- is this signal seen somewhere else in the system? looked at: ADC_Vcc, ADC_Vee and ADC_Vdd (analog and digital supplies): nothing however, by the time I did this, the peaks had gone down by x3, so maybe not conclusive. because of this I wait to have a more clear situation before continuing to look other places -- Note: To look with the scope I had to put the ADC card on an extender, and this allowed me to clearly verify (put in, put out) that doing so increases the scan_rms noise by ~ x2 (7 to 15du in 1R1L); so we seem to be definitely susceptible to pickup! -- Used Pentium readout and its power spectrum display: power spectrum seems much more featureless ... but hard to tell with my crappy display, will have to look into this more recorded one set of data: cold plug, 1L1R, p_pic1.dat ------------ UT May 12 02 ------------ * More on Background ------------------ - At Wes's suggestion, get backgorund levels at K' to help discriminate between thermal and scattered/reflected emission: NReads= NLoops = 4, tint = 3.125 ms, VxWorks DAQ Condition mean(du) file ---------------------------------------------------------------- cold block + 2.5 check: same as last time:OK shiny al foil K' + 46.65+-0.41 iota0 shiny al foil K' + 53.32+-0.16 iota1 black al foil (both sides) K' + >2000 -> 900 iota2 (cooling off during black al foil acquisition) (both sides) heated w. heat gun K' looking out 114.54+-0.35 iota3 H + 2.69+-0.04 iota5 shiny al foil - Note: t-domain spikes on pixel 3 are here, as usual in this readout mode - Note: EP has arrived today, and reminds me that in the past he was accidentally subtracting 1 from nreads and nloops, so that when we thought were doing 4 and it was working fine, we were actually doing 3, which does always work. Therefore this problem has appeared now not because it was not there before, but because we never actually tried 4 reads or loops Comments: -------- - Recall, for NICMOS looking out through K' we had 0.183du/ms signal. The equivalent number for PICNIC is 114.54/3.125=36.6du/ms, or 200x larger - I guess what we are trying to decide is whether the large PICNIC background is due to (a) larger solid angle viewed by the pixel because of lack of baffle, or (b) many photons reaching the pixel through scattering routes due to poor sealing/shielding, or a combination of both. Frankly, I still don't see how these experiments can disentangle the two ... for example heating the al foil puts in both a warmer blackbody directly into the pixel field of view, and a fountain of photons to be scattered all over the place inside the dewar ... no? However, we know our geometry, so one could calculate the solid angles of the pixel looking out both for NICMOS and PICNIC, and if the increase in background is much larger than that ratio, then we know that the dominating effect is something else, no? * Noise Peaks in Power Spectrum ----------------------------- - I have some of that tonight (~1500Hz), so do some tests: -- switch to Pentium readout: nothing obvious on screen record some data: p_pic2.dat (had K' on) p_pic3.dat (cold plug) p_pic4.dat (H + light in, to get some signal) -- back to VxWorks: still there data file: iota4 (cold plug) -- look at analog levels on BIAS board (ADC was checked on UTMay11): all levels are OK, and when looking DC-coupled on a 50mV scale I see nothing like a sinusoidal pattern (at any t-scale) Note however that, looking at the scan in the t-domain I see nothing obvious either, the signal is ~20du peak-to-peak, so if the sinusoidal noise is hidden in there at the, say, 10du p-p level, then that is 1.5mV, which we probably will not be able to see on a scope ... ------------ UT May 13 02 ------------ * Noise Peaks in Power Spectrum ----------------------------- -- Modify ftrack.pro so that I can record data w. ADC shorted (used to crash, probably due to division by 0...): ADC shorted, J2 closed: iota6 iota7 (still in ~/Data/2002May12/) -- Disconnect the optical table from the earth ground: noise goes down by ~x3 (note: scan_rms stays about the same, but power spectrum peaks go down by that factor): 1R1L, cold plug: ps_noise_max = 2.0 iota8 (still in ~/Data/2002May12/) EP thinks this is due to ground loop involving that connection plus the fact that the piezo scanners voltages to the VME also connect the VME ground at the optical table (verified with ohmmeter), through the mounting of the piezos themselves same as above, but also actually plug in and power all piezos and picos on/near optical table: still OK iota0 (in ~/Data/2002May13/) -- record some more data: 1R1L, cold plug, VxWorks DAQ: ps_noise_max=2.0 rms~7du iota1 4R4L "" : ps_noise_max=0.1 rms~2du iota2 -- All this time we have been using the ADC board from the NICMOS system, for historical reasons (previously PICNIC ADC bd was blamed for slightly higher occurrence of spikes since then gone -- the proble of the LD motors I believe) Use PICNIC ADC bd in PICNIC system: pixel level after RESET is above the ADC upper limit (+5V). For some weird reason we cannot bring this into range using the ADC bd pre-amp offset trimming pot. So we instead do the right thing: adjust dewar pre-amp dc offset (VB3). We had to change it from +3.80V to +3.85V: now OK Pixel saturation level is -8V Using PICNIC ADC bd, noise is as before, not worse: 1R1L, cold plug, VxWorks DAQ: ps_noise_max=2.0 rms~7du iota3 (DAQ crash) iota4 4R4L "" : ps_noise_max=0.1 rms~2du iota5 - Note: all these test files acquired without the rest of the VxWorks system running (just PICNIC DAQ on cpu2) result in header files with screwed up fields in the Target Information section, some I will have to modify them by hand or modify our data reader routines - Note: tonight, we are not experiencing the t-domain spikes, for whatever reason! - Note: when comparing Pentium and VxWorks data, remember that VxWorks after RESET acquires Nbad points (usually 70) and then the Npoints of the scan (usually 256), but only the Npoints are stored. Therefore any transients after RESET will look different in Pentium and VxWorks display and data. To facilitate comparison between Pentium and VxWorks acquired data later, get some Pentium files with 512 points instead of 256: cold plug, 1R1L: p_pic5.dat (256 points,100 scans) cold plug, 4R4L: p_pic6.dat (256 points,100 scans) cold plug, 1R1L: p_pic7.dat (512 points,50 scans) cold plug, 4R4L: p_pic8.dat (512 points,50 scans) (these then also are with the PICNIC ADC bd) * What is the Strengh of those peaks in the Power Spectrum? --------------------------------------------------------- - First to all, recall that the only improvement we have made in this respect is reduce the frequency and strengh of those features, by about x3, by un-grounding the optical table - To answer this, I have used: (a) archive data for NICMOS cam, taken with FLUOR (b) data taken with PICNIC/VxWorks (b1) one set with optical table grounded (b2) one set with optical table not grounded (c) data taken with PICNIC/Pentium, optical table (c1) one set with optical table grounded (c2) one set with optical table not grounded and computed the power spectra using exactly the same code, to be able to compare the different cases. All data files are taken under the same conditions: NReads=1, NLoops=1, cold plug. I even took the precaution of using the same number of data points for each scan, to avoid possible FFT scaling problems (which I don't think exist in this code). - You could know the answer already for most of these cases, using the numbers for ps_noise_max I have been reporting. Here is a summary of typical numbers and filenames of representative plots, case by case: as before ps_noise is the height of the tallest power spectrum features, for a typical scan, or for the worst case, which happens in about 20 of 100 scans the figures with extension "bad" are also selected as worst case, _most_ of the scan power spectra are _not_ like that. what happens when you un-ground the opt table is that you _never_ get those (a) ps_noise_typical = 1.5 ps_noise_max = 2.0 scan_rms = 7du file: fluor_psnoise.ps (b1) ps_noise_typical = 2.5 ps_noise_max = 8.0 scan_rms = 8.0 file: picnic_vxw_psnoise_bad.ps (b2) ps_noise_typical = 1.5 ps_noise_max = 2.0 scan_rms = 7.0 file: picnic_vxw_psnoise_good.ps (c1) ps_noise_typical = 0.5 ps_noise_max = 2.0 scan_rms = 4.0 file: picnic_pentium_psnoise_bad.ps (c2) ps_noise_typical = 0.5 ps_noise_max = 0.5 scan_rms = 4.0 file: picnic_pentium_psnoise_good.ps Conclusions: ----------- - Right now, particularly with optical table un-grounded, PICNIC camera controlled by VxWorks DAQ behaves identically to what we have always had for NICMOS system - The "bad" data sets have occasional features in the power spectrum that can be about 3-4 times worse. It was reliably determined that these go away un-grounding the optical table. But we should keep an eye on it to make sure that they are not just intermittent and we have been fooled in this conclusion - The Pentium readout of PICNIC seems to result in lower scan_rms (about 1/2) and smaller power spectrum features. But we must be cautious with this comparison since the readout program is not identical to that of the VxWorks (samples less pixels) ** Together with previous determinations that: signals make sense (signal grows linearly with integration time), multiple reads is implemented correctly, noise averages down with mutiple reads, noise in the sense of scan rms are normal, and experiment of Poisson statistics give reasonable results, and good noise figures, leads me to conclude that we seem to be OK from the point of view of the basic camera properties. ** Next observers should keep an eye on these things to provide additioanl information, make sure we haven't missed something that changes. Remember, if you see a funny noise feature, switch to "observe option 3 to get numbers to quantify it. ** We must quantify what sort of sensitivity limitation the extra background in this camera imposes on us, and eventually eliminate it. ** Also, PICNIC system seems to require even more time to settle than NICMOS after (a) RESET and (b) accesing a pixel. Someday we might want to understand that and if possible reduce those settle times.