Earthshine blog

The above is the result of testing flux constancy in images taken of the Hohlraum lamp on a given night, through all filters. Since the lamp is constant and the telescope is not moved then, provided that the FW and shutter works, it should be possible to get constant fluxes for each filter. The above shows that this is hardly the case.

In the first five panels (left to right, top to bottom) we see histograms of the fluxes (cts/s) derived by opening images, subtracting the bias, and extracting the total flux as well as the exposure time and filter name from the headers. We see that in no filter is there a prevalent flux – that is, either the lamp altered its brightness or the FW never acquired the requested filter or the shutter was miles off (so that the requested exposure time was nowhere near the one we got). The bottom right plot shows the fluxes plotted in order of acquisition – since we see straight sequences I think the lamp is not the problem – but the shutter and or the FW is.

Near the top we see a special pattern – this is understood when inspecting the list of of filters and fluxes:
6712986.9 _VE2_
6714074.6 _VE2_
103523071.0 _VE2_
103529310.0 _IRCUT_
18201912.2 _IRCUT_
18202890.8 _IRCUT_
18206373.8 _IRCUT_
18204287.7 _IRCUT_
18206416.7 _IRCUT_
18205757.8 _IRCUT_
103526333.0 _IRCUT_
103539529.0 _V_
8245622.5 _V_
8245177.7 _V_
8244685.3 _V_
8247179.9 _V_
8246506.9 _V_
8247198.6 _V_
103533820.0 _V_
103570347.0 _B_
6290177.6 _B_
6288536.8 _B_

We see that when the filter supposedly changes, the flux is all strange given the otherwise regular sequence.

So: never use the last or first image in a sequence from a stack! Whether this has been the case throughout the 1.5 years of data we soon have, is to be revealed by further analysis. For now, let us simply reject all first and last images in all sequences.

Added later:

A quick look at the NGC6633 images shows the ABSENCE of the above problem:
8660536.8 _B_
8661084.9 _B_
8659963.1 _B_
8629954.5 _B_
8661203.9 _B_
8630249.1 _B_
34529656.0 _VE1_
34784961.7 _VE1_
34790632.0 _VE1_
34526064.7 _VE1_
20713556.2 _VE2_
20713411.2 _VE2_
20713019.0 _VE2_
51780586.5 _IRCUT_
51774002.0 _IRCUT_
52019051.0 _IRCUT_
51776315.5 _IRCUT_
52013538.0 _IRCUT_
51770409.5 _IRCUT_
52012276.5 _IRCUT_

The filters did NOT act strange when changed. So – more intermittency, but also a lesson: check all sequences of images for the above problem!

We need a cloud sensor at MLO. It can be used for at least two things – it can gather a record of sky conditions for us that we later can use in selecting the best data – and, in our wild fantasies, it could be integrated with a control system so that it warned of clouds and shut the dome.

I have started some experiments on simple sensors and data-loggers to see what can be done. This is a link to an image of the output from a sensor running in Denmark at the moment.

The system consists of a thermometer-chip (LM335a) and an IR thermometer sensor (LMX90614) both sitting on an Arduino and being read once a minute. The signal is processed further by off-line software and a the plot is generated in IDL.

The two sensors are complementary – the thermometer chip reads the ambient air temperature (actually, it measures the temperature of the chip body) and the IR sensor measures the temperature of the sky above the sensor in a 45 degree cone.

In general, the air radiates with a temperature that is the ‘air temperature’ but the presence of clouds increases the downward longwave radiation field, and the absence of clouds decreases the downward longwave forcing – this causes the readouts from the two types of thermometers to form a cloud detector via a normalized signal based on the ratio of the two. The day-night cycle can be seen in both signals and is removed by taking the ratio, while the passage of clouds is seen as wiggles.

At the moment the system is just a prototype based on a loosely wired breadboard design, but if it works it can be hardwired as a dedicated PC board and permanently interfaced to an Arduino and packaged as a weather-resistant sensor. It relies for protection now on just some cling film (IR-transparent) and I need to experiment with glass and harder plastics of various sorts. Then I will move it to DMI and operate it from the roof there, and eventually we could move it to Mauna Loa.

I see it at first as being read from a USB port on the Linux machine there, offering up the present type of plots and generating a database for archival use, and only later would we try to incorporate it into a more automatic control system, as envisaged originally.

LM335A is the left chip – flat side is facing viewer, pins are 1,2,3 from left.
LMX89614 is the right chip – pin numbers are (1 – lower left, 2 – lower right, 3 – upper right, 4 – upper left (IC is actually round). The capacitor is 0.1 muF. The lower left resistor is 1k the other two are 4.7 k.

After completing the analysis of the best focus for all filters I am completely confused. It looks like all filters have the same focus near 24000:
Of the above only VE1 is a little different. ‘double rows’ of points imply there were two sets of images exposed at different times.

Note that if the minimum radius is near the same value, and the scale factor is the same then the ‘volume’ of the star image is the same – but the exposure times were the same .. usually there is a factor of 20 less photons in the B filter compared to V … so the above test has not selected different filters. And yet the command is there in the script:

…..
SETFILTERCOLORDENSITY,VE2,AIR,,,,,,,
SETFOCUSPOSITION,FOCUS097,,,,,,,,
SHOOTKINETIC,10,5,512,512,VE2_FOCUS097,,,,
DOMEAZ,,,,,,,,,,,,,,,,,,,
SETFILTERCOLORDENSITY,IRCUT,AIR,,,,,,,
SETFOCUSPOSITION,FOCUS080,,,,,,,,
SHOOTKINETIC,10,5,512,512,IRCUT_FOCUS080,,,,
DOMEAZ,,,,,,,,,,,,,,,,,,,
………

The entire script is here:

I started noticing this ‘same exposure time in all filters’ problem some weeks ago – but it was intermittent.

I am going to ignore the new settings for focus for now and see if I get reasonable exposures next time I use the moon script.

What on EARTH is going on????

Extending the lower limit on the search for a good focus we now have a preliminary result for the B filter:

The plots show various focus-related quantities against focus position. The first two panels shown (on lin-log and lin-lin scales) the radius of the fitted Moffat profile. The next shows the standard deviation of the image, divided by the mean value of the image, the fourth box shows the exponent of the fitted Moffat profile, and the last box shows the vertical scale (height, really) of the fitted Moffat profile.

The various properties – which should all be maximum (or minimum) at the best focus – indicate values of best focus from 24500 to 26000, with 25500 being perhaps the least uncertain.

The focus we use at the moment for the B filter is 28250 – outside the range found here. That value corresponds to almost a doubling of the width of the Moffat profile.

We do not understand how the setting can be that much off – possibilities include that something happened during transportation or that the addition of the heater has changed the focus position.

Perhaps Ahmad has an original INI file from the days in Lund and could check what value was found best a year ago?

Perhaps Torben could see Torbjörn, or whoever understands the mechanical design in detail, and ask whether the heater could be warping the optical bench? Temperatures to 60 degrees C is seen on the clip-on thermometer in the dome.

The good news is that if better focus positions can be found for all filters in the above way then we should be seeing less fuzzy images in the future – it seems we have a FWHM PSF now that is about 2 pixels.

For some time there have been intermittent focus problems with the system – especially the VE2 filter would go in and out of focus for no discernable reason. The focus is supposedly set, in scripted mode, by referring to focus positions from a script. The currently used focus positions are:

[FOCUSPOSITIONS]
; The names made of (Color filter) + (ND filter) + (Knife Edge DF)

IRCUT_AIR_SKE = “28750”
IRCUT_ND_SKE = “29000”
B_AIR_SKE = “28250”
B_ND_SKE = “29000”
V_AIR_SKE = “30750”
V_ND_SKE = “29000”
VE1_AIR_SKE = “28750”
VE1_ND_SKE = “29000”
VE2_AIR_SKE = “24000”
VE2_ND_SKE = “29000”
AIR_AIR_SKE = “29000”
AIR_ND_SKE = “29000”

As the focus seemed more and more unreliable I defined a new set of positions in order to be able to test on stars from 28000 to 31000:

FOCUS090 = “28000”
FOCUS091 = “28100”
FOCUS092 = “28200”
FOCUS093 = “28300”
FOCUS094 = “28400”
FOCUS095 = “28500”
FOCUS096 = “28600”
FOCUS097 = “28700”
FOCUS098 = “28800”
FOCUS099 = “28900”
FOCUS100 = “29000”
FOCUS101 = “29100”
FOCUS102 = “29200”
FOCUS103 = “29300”
FOCUS104 = “29400”
FOCUS105 = “29500”
FOCUS106 = “29600”
FOCUS107 = “29700”
FOCUS108 = “29800”
FOCUS109 = “29900”
FOCUS110 = “30000”
FOCUS111 = “30100”
FOCUS112 = “30200”
FOCUS113 = “30300”
FOCUS114 = “30400”
FOCUS115 = “30500”
FOCUS116 = “30600”
FOCUS117 = “30700”
FOCUS118 = “30800”
FOCUS119 = “30900”
FOCUS120 = “31000”

I then ran, in steps of 100, over all these positions in all filters for 5-15 images in each position. I fitted a Moffat profile to the brightest source in each image and plot here the radius (sqrt(rx² + ry²)) of the profile:

[Sorry for the poor quality of that plot – a downloadable pdf of that plot is here:

The width of the distribution of points is due to repeated trials in some cases. Scattered points far from the general relationship are shutter failures.].

The result is, apparently, that all minimum-radius occurs at the leftmost side of the plot – i.e. at or below 28000 – this is not at all close to what we use from the scripts. What is going on?

Is the fitting of a profile a bad way to estimate best focus?

Is the setting of the focus from the System INI file misunderstood somehow?

The start of the script used to run these tests is here:

SETDATASOURCE,PROTOCOL,,,,,,,,
CCDCOOLERON,,,,,,,,,
SETIMAGEREF,0,0,,,,,,,,,,,,,,,,,,,
STARTCYCLE1,10000,,,,,,,,
WAITMINUTES,0.01,,,,,,,,
ENDCYCLE1,,,,,,,,,
PROTOSEGMENT1,,,,,,,,,
SETDATASOURCE,PROTOCOL,,,,,,,,
CCDCONFIG,CCDCONFIGSETUP-DEFAULT,,,,,,,,
CCDINIT,,,,,,,,,
OPENEXTSHTR,,,,,,,,,
IRISOPENCLOSE,OPEN,,,,,,,,
TRACKSIDEREAL,,,,,,,,,
SETMOUNTRADEC,15,45,00,02,18,57,,,,,,,,,,
MOVETOCOORDS,,,,,,,,,,,,,,,,,,,
STARTCYCLE1,1,,,,,,,,
DOMEAZ,,,,,,,,,,,,,,,,,,,
SETFILTERCOLORDENSITY,VE1,AIR,,,,,,,
SETFOCUSPOSITION,FOCUS090,,,,,,,,
SHOOTDARKFRAME,0.0762,1,512,512,DARK,,,,
SHOOTKINETIC,10,5,512,512,VE1_FOCUS090,,,,
SHOOTDARKFRAME,0.0762,1,512,512,DARK,,,,
DOMEAZ,,,,,,,,,,,,,,,,,,,
SETFILTERCOLORDENSITY,VE1,AIR,,,,,,,
SETFOCUSPOSITION,FOCUS091,,,,,,,,
SHOOTDARKFRAME,0.0762,1,512,512,DARK,,,,
SHOOTKINETIC,10,5,512,512,VE1_FOCUS091,,,,
SHOOTDARKFRAME,0.0762,1,512,512,DARK,,,,

etc etc and then next filter.

Anyone? Help?

Here are some data relevant for performing a better alignment of the mount. By taking pairs of images with 10 minutes between in the East, South and West, while tracking at sidereal rate, it is possible to see which way the centre-of-field drifts and from that deduce where the mount polar axis is pointing and how it should be corrected to point more closely at North. Center-of-field is determined from astrometric plate solutions using astrometry.net.

The center-of-field coordinates have been measured on JD2456049. Field 1 comes before field 2 in each pair. RA and DEC are:

E1: 18:20:11.665, +03:17:26.152
E2: 18:20:08.522, +03:17:49.439 which is 23 arc seconds more Northernly

S1: 13:54:10.407, -19:06:52.553
S2: 13:54:09.741, -19:06:43.784 which is 9 arc seconds more Northernly

W1: 09:13:41.508, -10:49:04.877
W2: 09:13:39.970, -10:49:08.317 which is 4 arc seconds more Southernly

Analysis:

When tracking due East centre-of-field drifted North
When tracking due West centre-of-field drifted South
When tracking near the meridian centre-of-field drifted North

Now, what does this imply? I am thinking it means that our Polar axis points East of true North, and is not elevated enough.

————-

later:

In order to calculate the angles that the mount needs to be turned by we need a method to analyze such positional data as we have above. I am testing various least-squares approaches in order to determine the 3D rotation matrix. After a lot of work it turns out that accurate fits are difficult to get when the number of positions is small. I generated artificial examples with known rotations and 60 pairs of points and ended up with solutions that were only within +/-1 degree of the known answer.

For the three pairs of points found above, the solutions were very small numbers, easily 0 within the +/- 1, or more, error limit expected.

At least this is consistent with a situation where the polar axis is quite well aligned already, and that a better alignment will require delicate work with the adjustment screws indeed!

In a sequence of observations of Mars (using Sidereal tracking) we sought to learn if there is a periodic error in the tracking. We plot the pixel coordinates of Mars in the session covering several hours:

What is most evident is that Mars drifted relative to the frame – but this may be the actual motion of Mars, although it seems a lot (Mars moves in RA mostly, not DEC – i.e. Y). This can be checked against the position of the stars in the frame – more later.

It has become evident that the square aperture in front of the CCD chip can shift – or rather, that the CCD camera can shift relative to the mask. The mask is present to help the frame-transfer procedure by shading the part of the frame that holds the transferred image during readout. If the CCD was not half-shielded the ‘smearing effect’ would occur due to illumination during readout. The mask is a set of adjustable blades, apparently that are fixed wrt the telescope body. The CCD itself is held to the body by a thread and the correct position is indicated by two steel pins that should touch, visible from the outside. It has occurred that the CCD has ‘unwound’ and this caused ‘dark corners’ to appear in the images. The camera had indeed ‘unwound’ a bit and was rotated back into proper position.

Following that incident a ‘black bar’ has appeared in the side of the image – perhaps due to slippage of the camera wrt the blades, or the blades’ motion.

The issue is further discussed here.

Stuck Filter Wheel hindering further observations:

Two dome flats showing a stuck FW. A script was used to get these images. In between the images we used the manual Engineering Mode to ‘do the homes’ (i.e. to force each wheel and stage to traverse its range and find its home position). Apparently the “Large Rotary Stage” is still stuck after doing this.

We have learned this about timings:

Color filters – it takes from 15 to 45 seconds to change a color filter. Mainly it takes 20 s, with exceptions.

SKE – it takes a full minute to set the SKE.

An image takes 0.3 s to be downloaded and written to disk.

Dome takes about 2 minutes to open.

One circuit of dome takes about 2 minutes.

A Peltier-element cloud-sensor is installed.