CsI Window Emissivity

The purpose of this experiment was to quantify the emissivity of the CsI window, by comparing spectral settings looking out at the room to the same settings when aimed at a 77K piece of foam.

We obtained 3 hi-med spectral settings at Ames during CD017, just prior to shipment. 

At DAOF, following about 1 week of operations with the CsI window lens uncovered while attached to TAAS, we took the same 3 hi-med spectral setting emissivity data as well as 3 other settings in hi-med and medium modes. 

spec_room  ; spectrum while looking out at the room, no window cover

spec_ln2; spectrum while blocking the window with a LN2 soaked sponge

spec_dark; spectrum taken with lens wheel mirror in place

Assuming that the room has an emissivity of 1.0, the window emissivity is:

emissivity=(spec_ln2-spec_dark)/(spec_room-spec_dark)

more description here:
http://codgermmck.blogspot.com/2014/01/emissivity-of-krs5-window-in-cd014.html

At NASA Ames and DAOF:

OCLI Q 1173 cm-1; 8.52 um

high-med, [0] - [2] ; 50.329 deg, 4 egos, FT=1s,  slit 4 x 5-pix dash

500<DN<4000
emissivity_Ames= 2.7 %  (large uncertainty due to echelle movement)
emissivity_DAOF= 1.6 %

BP14100 729.4 cm-1, 13.71 um
high-med, [0] - [2] ; 55.935 deg, 100 egos, FT=1s, slit 4 x 5-pix dash
500<DN<4000
emissivity_Ames= 2.0 %
emissivity_DAOF= 1.9 %

Soifer 415.4 cm-1, 24.07 um
high-med, [0] - [2] ; 46.265 deg, 6 egos, FT=1s, slit 4 x 5-pix dash
emissivity_Ames= 4.1 %
emissivity_DAOF= 3.9 %


Other settings at DAOF:

N04679 2142.5 cm-1; 4.67 um
medium, [0] - [2] ; 50.621 deg, 100 egos, FT=1s,  slit 7 x 44 deg arc
emissivity_DAOF= 2.2 %

OCLI Q 1150 cm-1; 8.77 um
high-med, [0] - [2] ; 52.502 deg, 4 egos, FT=1s,  slit 4 x 5-pix dash
emissivity_DAOF= 1.7 %

OCLI Q 1150 cm-1; 8.77 um
medium, [0] - [2] ; 52.502 deg, 4 egos, FT=1s (256 rows),  slit 1 x 44 deg arc
emissivity_DAOF= 1.7 %

OCLI O 950 cm-1; 10.53 um
high-med, [0] - [2] ; 52.502 deg, 4 egos, FT=1s,  slit 4 x 5-pix dash
emissivity_DAOF= 2.2 %

OCLI O 950 cm-1; 10.53 um
medium, [0] - [2] ; 52.502 deg, 4 egos, FT=1s (256 rows),  slit 1 x 44 deg arc
emissivity_DAOF= 2.2 %

 

 

Motor noise

I ran a check to see how much noise is added when the motors are enabled during data taking.  I was hoping that the latest changes to the grounding configuration might have helped, but no joy.

Posted here are two difference images of the dispersed (med-res) FCLS source on slit 1 and the central decker arc.  4.6µm filter, ND out, -1V applied bias, 31 ctdelay, grating @52.5 degrees.

I took noise the way Bob does, and found that in areas off the illuminated band the noise in a fowler-4 is 3.3 DN with the motors enabled, 0.9 DN with them disabled.  The two jpegs posted here are difference images from adjacent 1 sec integrations in the FITS files.  Same stretch is applied to both.

Worth noting that the noise is significantly higher (4.3 DN) if the cal source cables are not connected....this fits with Matt's observation that unterminated motor channels can add noise.  I'll look at the manual to make sure we're running the motors in 'current reduction' mode, which is the factory default on the MID-7604...

Motors disabled

Motors enabled

More Motors

Messed around with the motors a little more this morning, and it now seems to me that disabling/enabling the motors does cause the pots to jump a bit, but there seems to be enough damping from the internal mechanisms to keep the slit features from moving with them....

The end result is that there is a range of a few tens of mV for a given mechanism position.  There is also backlash in the mechanism motions, but that seems to be pretty well controlled with the present motion scheme.

I now think that my problems yesterday resulted from pot readings that were affected by the motor enable/disable cycle that comes with data taking.  These pot reading may have messed with the logic of the motor positioning algorithm, which I didn't understand very well at the time.  Bottom line is that if we get a source on the slit, it should not fall off just because the holding current is cycled on and off, even if the pot says the slit moved in the process.

Today I took a series of frames with each of the slits centered on the FCLS source.  The source was positioned at the place slit 4 landed on a particular move, but given that the position of slit 4 from one move to the next may vary on the order of a slit width, this FCLS position isn't especially significant.  It's about 1.2mm off the HIPO foresight position of 45.75, 31.112 (maybe 4.8" of arc).

Here is a list of slit positions taken to coincide with the 10µm FCLS source positioned at TAAS (X, Z) of (44.7, 30.6), which maps to pixel (452, 487) in this configuration:


Slit   V ctr.@(452,487)  indicated angle    after dis/en cycle
  1         6.2634           59.966          6.2505V/60.547deg
  2         5.5998           89.500          5.5886V/90.0deg
  3         4.9304          119.550          4.9241V/120.0deg
  4         4.2646          149.550          4.2543V/150.0deg
  5         3.5969          179.750          3.5953V/178.75deg
  6         2.9280          209.700          2.9252V/210.0deg
  7         2.2604          239.800          2.2526V/240.0deg

Note that in every case the disable/enable cycle caused the pot reading to change, but the slit as observed on the display did not move and the source position in the slit was maintained.  A number of times the disable/enable cycle cause the volt_err dialog to pop up, but I just said 'yes' to setting the angles based on the voltages read.

We might be able to use the able above to refine placement of the slits in the init file.  They should be exactly 30 degrees apart, but they are not.  The delta from 30deg centers off the position of slit 1 is:

Slit       Delta from 667mV centers          Delta from 30deg
  2                -0.0028V                        0.466deg
  3                 0.0003                         0.416
  4                -0.0012                         0.416
  5                -0.0002                         0.216
  6                 0.0021                         0.266
  7                 0.0030                         0.166


Might try massaging the init file with these numbers to see whether we get correct slit registration (modulo pot backlash/read errors, or course).

Trouble in Motor City??

Today I checked the zero positions of all the mechanisms (apart from the flip mirror, which I do not want to mess with).   Those were ok, but in the course of the tests I began to suspect that enabling/disabling the motors may be causing inconsistencies in slit positioning....will need to look at it more to be sure.

I spent way too much time trying to figure out why I couldn't keep the FCLS 100µm source on slit 4 while I was scanning though all the slits saving images.  It was quite inconsistent.

Eventually, to determine where the motion issue was, I did a series of measurements of slit center position going back and forth between the slit wheel open position, slit 4, and slit 7.  It was rock-solid and the slit position on-screen did not move at all.

But when I tried again to image the FCLS through the series of slits, the source immediately fell off the slit when I started taking and saving frames through the 'observing sequence' tab.  I moved from slit 7 to slit 6, measured and recorded the pot reading, then collected a frame.  The source (which should have been close to centered) was not on the slit, and when I rechecked the pot with an 'update all', I got an error dialog stating that the voltage and degree settings did not match within the volt_err limit, even though no move had been executed.

My hunch is that when the motors are disabled during the 'observing sequence' operation, the mechanism relaxes a bit and the slit shifts in the FOV.  The back-and-forth moves I had done did not involve the 'observing sequence' pane so the motors were continuously enabled, so the fact that they were very repeatable in that test may not translate well to actual observing.

If this hunch turns out to be true, we might find ourselves setting up on a target and then having it fall off the slit when we actually take data.

Curtis has said that he's experienced dropping steps with the motors, even when operating through the LabView GUI.  I need to look at this further, and hopefully we'll find it's something else (that's easy to fix!).


In other news, it turns out that the s/d/f cassette wheels zero positions were all very close, but the lens wheel was obscuring our view of the s/d/f aperture when set to 'open' from the pulldown menu. I shifted the volt_zero from 7.003V to 7.028V, and I believe it is good now.

I next moved each of the slits into position and noted the pixel positions of each slit end, and then inferred the position of each slit center. here is what I got for each of the selections in the pull-down slit wheel menu:

slit        top        bot        center        Approx. width
  7      (396,896)   (542,86)    (469,491)          48 px.
  6      (394,895)   (539,85)    (467,490)          20
  5      (394,895)   (539,84)    (467,490)          16
  4      (391,895)   (536,86)    (464,490)          12
  3      (391,893)   (535,85)    (463,489)           9
  2      (387,893)   (529,86)    (458,489)           5
  1      (386,892)   (528,87)    (457,489)           5

So the slits are in close but not perfect registration, and there is no point in the field of view that fits in all seven slits.  I decided to center the FCLS on slit 4, which would get at least some light through in slits 3-7.  I had meant to collect images through these slits at this FCLS position, and that's when I ran into the problem with the source falling off the slit :(

The center of slit 4 measured above is about 1.11mm of FCLS travel from the HIPO boresight (~4.5" of arc).

The 100µm pot is defocussed mostly in the spectral dimension.  It's about 13.5 x 3.6 pixels, but that might not mean anything since we're in camera mode and we care most about hi-res focus.

Tomorrow we'll look more at the motor issue, and hopefully come off the TAAS for some gas-cell tests.

TAAS1 Platescale

Today I scanned the FCLS across the array on a 5mm grid spacing. The files are saved on gus in /..../cd017_2014mar/15, files cold.lab.00008-00056. More details in Vol. VII of the lab book, pp. 67-70.

Data taken in camera mode, using the 4.6µm filter with the slit and decker wheels open. They are single destructive images (D0), 0.5s integrations.

Here is a single composite image:

I would like an actual astronomer to weigh in, but my guess at the measured plate scale from the lines on the image is about 21 pixels for each mm of FCLS travel. Matt gave me a number from memory of 4.1" per mm on the FCLS, so my caveman estimate is 0.2"/pix. Sound believable??

BTW, the green line on the image stretches from (30,30) to (60,30) in (x,z) FCLS coordinates, and from (228,699) to (694,283) in pixel coordinates. The yellow line runs from (40,35) to (45.75,30) in FCLS, and from (474,481) to (314,481) in pixel-land.

The grid isn't perfectly square because I used round numbers in FCLS except for my starting x-value or 45.75. This is the x-val for the HIPO boresight (45.75, 31.112). The boresight is just low and left of the place where the green and yellow lines cross in the image. You can also see a quite persistent burn-in of a deckered med-res spectrum that was on the array overnight.

Network Problem with LabView Apparently Solved

After some packet sniffing we have determined that the delay we've been experiencing when querying the Agilent from the GUI has been due to gus flailing about looking for the Agilent via the WINS service. Can't say that I completely understand what's going on, but we verified that the delay goes away when we turn the NetBIOS service off.

Which would be all good, except that windows file sharing seems to depend on the NetBIOS service, thus we can't access the disk on gus without it.

So we added two lines in the host file on gus (located at C:\Windows\System32\Drivers\etc\hosts):

10.4.2.3 EXESAGILENT
10.4.2.1 bryce

This seems to cure the problem, presumably by heading the name resolution process off at the pass, before it resorts to the dysfunctional WINS service. WINS (a microsoft implementation of NetBIOS) apparently depends on the existence of a WINS server somewhere on the network. My hunch is that we have such a server somewhere on the usra network in N211, but that no such service runs on the SIL. So while we had thought our problem hinged on the availability of a network DNS, it might really have been WINS we were missing.

With the modified hosts file, we can leave NetBIOS working (thus file sharing) and still access the Agilent without a noticeable delay. Hopefully we haven't broken anything else in the process :)

DAOF SCHP

We put the DAOF SCHP at the coordinates provided by Ted Dunham.  Results are in the image.  The green circles are my estimates of the center and radius of the SCHP and EXES cold stop.  The red circle is how the LCHP should appear based on measurements of their diameters.  If LCHP is the same as SOFIA secondary, our cold stop is 10% (by area) oversized with the CsI lens.  This is consistent with Kristin's findings that we seem to have a larger f-cone and Curtis and Mark's work with the FCLS (best imaging focus at 250 mm into EXES - forward of the plate).

I'll try to put some numbers in this and relate to previous TAAS work later.

CD 17 Darks

The data used for this analysis was taken during cool down 17 with the science detector and the lens mirror in place. A total of ten frames were used.  Each frame had 14 reads.  All of the reads were subtracted from the first read (hence why there are 13 data points on each plot).  The statistics quoted in the plots below were calculated using a 100x100 pixel subregion in the center of the array.

- The average DN/s was 5.7, excluding the first two data points.
- The noise was calculated by measuring the standard deviation within the subregion and then multiplying by 0.707 since the difference of two frames were used.  The average noise value was 3.6 DN.

Linearization of Individual Frames

This post describes the method used to linearize individual frames.  Below is a description of how the algorithm works.

To calculate a fit that is independent of time, I examined the linearization with respect to the rate (DN/s).
We want r_ideal = DN/s = Constant
But due to non-linearity, what we see is r_obs = Dn/s = a0 + a1*DN + a2*Dn^2
To eliminate time we can use r_ideal/r_obs to find a DN correction factor
We will define the constant as the maximum rate.  To find the constant in r_ideal, fit a polynomial to the rate vs DN for each pixel in the array, take the derivative of polynomial, and find the root.  This result is DN_max.  Plug this value back into the polynomial to find r_max:
                    r_max = a0 + a1*DN_max + a2*(DN_max^2)
I then created an array of the a0, a1, a2, and r_max values at each pixel (this file is called linearity_corr.fits).
This array can then be used to linearize any array using the equations:

       > DN_correction_factor = (1/((a0/r_max) + ((a1*DN_org)/r_max) + ((a2*(DN_org^2))/r_max))
                                            > DN_linearized = DN_correction_factor*DN_org


An IDL program called linearization_corr.pro, which utilize the above equations, has been uploaded onto the Everything EXES Dropbox under  /analysis/cd17/linearization/, along with linearity_corr.fits.  The IDL program requires you to input a text file with a list of images, the directory where the images are located, and the prefix name of the files.  This is described at the top of the IDL program.  

* One known issue with this program is that the files used to create the linearization array did not have significant signal in the upper and lower parts of the frame, which means that the corrections on those pixels are not very good.   

Below are examples of single pixels on images with different egos and frame time patterns that have had their individual frames linearized using linearization_corr.pro.


Example 1:  25 1 egos (N2 S0 N3 S0 N3 S0 N1 D0); Frame Time = 0.5s

Example 2: 6 1 egos (N0 S0 N0 S0 N0 S0 D0); Frame Time = 1s