Noise

First look at some of the noise data taken last Friday:

With the blackbody switched off we saved a series of 200 consecutive destructive scans.  Collecting these scans in an IDL data cube, then drilling down through each pixel position to calculate the per-pixel standard deviation yields the following noise map:

Map of single-sampled noise in SCA115 (T=7K, 3s scan)

If we bin the noise values we get the following distribution:

Histogram of single-sampled noise values (electrons)

The histogram looks a little bimodal, and in fact on close examination one output looks brighter than the others in the noise map.  Overall the median pixel noise is about 65e.   I'm cooking the cds and sutr versions of this data presently, and we'll be able to try optimizing when/if we get more helium in :)  Slowly, surely....

Getting Even

Following the fiscal year-end helium drought, we are now cold again in the bench dewar with the science array.  To recap two posts from August:

-  Data taken with a constant voltage on the ØRowOn line showed a ~25% difference in slope (gain) and a substantial offset that can be zeroed out by adjustment of the VrstOff level.

-  Per guidelines from Raytheon, the ØRowOn pulse was to be clocked opposite the ØRstOn pulse to mitigate/eliminate this effect.

-  The MIRI folks at JPL have published two documents that seem to offer conflicting solutions to this problem.  In an internal doc they suggest clocking ØRowOn identically on destructive and non-destructive frames.  In an SPIE paper the remedy is to never clock ØRowOn.  This discrepancy may just be a typo, but taken literally it's a different approach.

-  Our data up to now has not clocked ØRowOn at all, similar to the MIRI SPIE recommendation...we still see odd-even slope differences of about 25%

In the lab this week we've collected a series of non-destructive frames using the old clock table (the one used at the IRTF) with varying values for the VRstOff voltage, which seems to adjust the offset between odd and even rows, but not the gain.  The array was staring at a 40K blackbody with a scan time of 3s.  Here is a plot for of mean pixel values for even and odd rows at three different VrstOff values:

Turns out that both even and odd rows maintain their slopes as VRstOff varies.  The even rows (which are connected to the output circuit during reset) don't shift much, but the odd rows shift vertically as VRstOff changes.  The slope of the even rows differs as before.

Using our new clock table, which nests application of the reset pulse within a de-assertion of the ØRowOn line so that neither row of a given pair is connected to the output circuit during reset, we see more symmetric behavior.  There is more detail in the lab book, but the basic message is captured in this plot:

Here we have slopes that differ by ~3% and only a small offset between odd and even rows.  VRstOff still works as an offset between even/odd rows, and can be adjusted to suit.  I believe that with the new clock table the odd/even effect is no longer a significant issue.

Flexure from echelon wall installation

We see a significant amount of displacement of the position of the input beam on the echelle side paraboloid depending on whether the echelon wall is installed or the temporary echelon side support wall is installed. The photo above shows the input beam locations on the target I put over the paraboloid mirror. The grid spacing is 1/4".  

The position of the laser spot on the slit wheel is also slightly affected by which wall is installed on the echelon side. With the support wall in, the spot hits the pinhole, and with the echelon wall in, it misses the pinhole in the slit direction by about 0.5mm. This is not directly the cause of the large displacement of the beam on the echelle paraboloid.

Unfortunately, the shimming of the flip mirror and the adjustment of the flip mirror stop were done with the support wall in instead of the echelon wall. Over the next few days I will be redoing the FOE shimming, flip mirror shimming and positioning of the flip mirror stop with the echelon wall installed instead of the support wall.

Pupil Image

I looked at a couple pupil images from Jan 15.  They are in the figure with two stretches (a hard one and a softer one).  The exposure time was much too long (10 seconds at 800 cm-1), so thing are heavily overexposed.  We were not letting light into the optics box, so this is purely light we don't need.

The bright, roughly horizontal bar near row 600 got fainter when we pulled the echelle screwdriver that drives light across the echelle.  The grating, not seen in this image, would be in roughly the region within the red ellipse.  The four spots toward the upper left are unknowns to me.

Pinhole Diffraction Effects

I was going back through some old notes and wanted to make sure this was available to all.

When we use the pinhole with the gas cell, we will get spots that depend on the size of the pinhole (designed to be 108 microns, but probably larger because of the etching process), the magnification from the slit plane to the detector plane (should be 1:1 and is probably very close to that), and diffraction, which will depend on wavelength.

I looked at this issue a couple years ago for a couple wavelengths, but today I ran my routine at 1 micron steps from 4.5 to 28.5 microns.  The points are in the plot below.  The fit is

sqrt(3.75^2 + ((lam-4)/2.2)^2)

Not particularly easy to remember, but the plot should help.

Lakeshore temperature probe positions

The Lakeshore controller has 8 sensor inputs from the two 32-pin "D" connector cables coming from EXES.

We have 5 temperature sensors connected through these cables. The Lakeshore display labels map to the instrument locations in the following way:
Lakeshore display number     instrument location
--------------------------------     -----------------------
C1
C2  X-plate
C3
C4 Intermediate shield

D1
D2 O-box
D3 Nitrogen shield
D4 Helium radiation shield

Flip Mirror Shim/Alignment

(a)

This post shows the EXES alignment in medium res mode. I measured the position of the beam on the echelle paraboloid and the detector plane using paper screens in order to select the best angle for the flip mirror in lo-med mode.

For the alignment on the echelle paraboloid mirror, we are interested in having the input beam and the dispersed beam hit the mirror in a line along the long axis of the paraboloid mirror.  According to the optical design, the input and dispersed beams should each be +/-20mm from the midpoint of the long axis of the paraboloid mirror.

We also would like the beams to hit close to the center of the mirror along the short axis of the paraboloid, but this is a secondary concern to the having the beam at the detector centered in the echelle-echelon direction as well as the input and dispersed beams in a line,  with a separation of 20mm each from the center of the paraboloid long axis (as described in the previous paragraph).

(b)

To help in this alignment I made a screen of card stock and grid paper, and taped it to the side edges of the paraboloid mirror. The mirror dimensions are 7.5”x5”. I marked the center along the short axis at 2.5” from either long edge of the mirror.

Along the long axis, I marked the midpoint at 3.75”, as well as parallel lines at +20mm and -20mm to this line, where the input and dispersed beams should hit.

I also made a screen of tissue paper and cellophane and placed it over the output beam position just before the detector focus.

OK, so that’s the context.

The status now is that we have the input and dispersed beams hitting the paraboloid along the center long axis line. The input beam is about 5mm from the position where it should be along the long axis (it should be at 20mm toward the fore-optics side and it is at 15mm). I will readjust the flip mirror stop to change this position.

(c)

Figure (a) shows the target on the echelle paraboloid. It has flaps cut into it so that we can measure the positions where the beams hit the mirror, and then when the flap is pulled back we can see the beam after it reflects from the mirror.

In Figure (b) the beam has been stopped down to about 0.5” and the input beam, coming from the flip mirror is shown. As meantioned it should be about 5mm farther away from the viewer, but this will be fixed by readjusting the flip mirror stop.

In Figure (c)  the dispersed beam is shown. It falls in a line with the input beam because of the flip mirror shimming and the adjustment of the dispersion screw on the parabolloid.

In figure (d), the beam position at the detector is shown. The cutout in the note card is slightly misleading. The center of the detector in the ruler long axis is located at 0.75” along the ruler. As a consequence of the flip mirror shimming and the steering of the parabolloid, the beam hits about 2/16” to the left of the center.

(d)

Software Organization

Documenting here the state of EXES software as Andreas heads off to greener pastures:

-  Best source of documentation is Andreas' Software Development Guide, filename 'EXES_software_development_guide_DRAFT.pdf'.  I've copied this file to the SaltLick server in the EXES lab, under the /Doc directory, and also on NSCKN under '5.0 Payload>Software>GUI'  Andreaas also provided a primer on using the svn repos, and that has been copied to SaltLick as well.


-  Our source code (both java and c++) are under subversion control at http://app.devzing.com/exes/subversion/ .  Presently Andreas, Matt, Curtis and I are able to access the subversion repositories.  If anyone else needs access, I have the admin login and can create new accounts.


-  Following Andreas' instruction, I have installed NetBeans on the Mac Mini in the EXES lab, and linked it with the subversion (svn) repository containing the java code.  After doing so I am able to build the GUI from source code on both the mac mini and on my linux machine.  I've verified that I can also make and check in software changes to the repository.


-  On the PC side, I have modified the directory structure on the host PC so that the development version of the code is written to C:\exesV2.  The current (~stable) version of the EXES software is in the C:\exes folder.  Once we are ready to 'release' EXES 2.0, I'll archive the present C:\exes folder and rename exesV2 to C:\exes, so that the latest stable release can always be found there.  We'll keep the MGT pointed into that folder as well, so that to run anything other than the latest release you'll have to dig for it a bit.


-  The Tortoise svn client Andreas installed for us now points to our svn repositories.  Only the \src and \build subfolders are synchronized.  In general, the \build directory needn't be updated via svn, as that will upload a bunch of uninteresting.obj files.  The \src directory should be kept up to date.


After setting this up, I checked out the code and then built a new version of the c++ app exes.exe.  Building this app places it in the \build directory, but we move it up to the next level directory (alongside \src and \build) to run.  At this point we are able to build new versions of the c++ and java gui from source, and I've verified that they work together.  I need to read more to understand the limitations of the development versions, but I plan to start using them going forward.