Earthshine blog

Tested a script while looking through the telescope. Script was set up to switch filters and take sequences of images.

Everything seems to be badly scrambled! Colours of filters do not match what is requested, and the sequences of images received are incorrect – for instance, when asking for 10 images at 2 seconds each I get about 3 images at 2 seconds and the rest are rushed through rapidly.

Shutter opens at strange times after a sequence.

It seems like the system is badly shaken up now. I think some of the above behaviour may explain some of the odd image-sequences we had at MLO, but the majority from MLO were good: now it all seems random.

My guess is that the LabView software has been jumbled somehow – it is easily done since the coding is not deterministic as text code is – it is all little coloured lines and boxes. It is easy to pick something up and drop it down in the wrong place. A test and a fix for this might be to restore an older version of the software – for instance something after Ingemar fixed the bad coding problems we found while at MLO and before the system was hit by lightning.

Another possibility is that hardware has been damaged in such a way as to scramble/ignore software instructions. Not sure how to test for this – we used a ‘sniffer cable’ to listen to the erroneous traffic to the mount, but I am not sure what to listen in on here?

Wonder if there is a way to ‘reset the hardware’? Perhaps the FW are ‘off by one’ – some latch is not clicking home?

—————

Inside the ‘breakout box’ there are lights to watch as a script runs. There is a light on a ‘hager’ relay and it evidently lights up when the two Thorlabs filter-wheel controllers are being adressed. They have displays that show numbers and I am guessing they show the position of the FW.

While running a sequence through the 5 filters I saw the numbers change. I think I caught a rythm corresponding to several passes through the 5 filters, but I swear there was an irregularity [hard to prove afterwards as there is lots of uncomfortable crouching and waiting to do]. Also strange is that the FW displays show two sets of numbers first, these then change to another set, then the hager light goes out and you can hear the shutter start working [its progress is uneven, however, despite being asked to take 10 identical images]. Here is a sequence:

FW2:5->5,6->1,2->3,4->2,3->4,
FW1:2->1,2->1,2->1,2->1,2->1,

where “A->B” means that the FW display first showed an A which then changed to a B, after 5 seconds or so. Notice how FW1 always goes “2->1”. FW2 seems to be cycling all numbers. Notice how the start position in one pair is always 1 higher than the end position in the previous set. There is a cryptic sentence deep inside Dave’s LabView code about how Thorlabs uses one set of indices and his code another – this could be it, I guess.

I think FW1 is the ND filter and is always set the same way – in the above test I was asking for the ‘AIR’ position and I think this is what we see. I will now run a test where I ask for one of the ND filters instead and we will see if the numbers change!

—————

OK, I did that, and it seems I am right. FW1 is the ND filter. I set it to ND2.0 and the sequence 2->1 above changed to 5->6.

Should run a sequence now of just changing the ND filters.

——————

Ok, did that too. This time I used a script that always set the ‘B’ filter, but cycled through the available ND grades – that is AIR, ND0.9, ND1.0, ND1.3, ND2.0. The typical sequence of readouts from the Thorlabs controllers was:

FW2:3->2,3->2,3->2,3->2,3->2, …
FW1:6->1,2->1,2->3,4->4,5->5, …

we see how the colour filterwheel (FW2) always sets the same filter and always seems to start at the one numbered one higher. Visual inspection during the cycling revealed that the colour of the light switched between the colour of the lamp and Green – i.e. the FW2 settings actually acquired were ‘Air’ and ‘V’ – not ‘B’ as I asked for.

FW1 meanwhile seems to have cycled irregularly – 1,1,3,4,5, … (2 is missing). It was not really easy to see whether various ND grades were inserted or not, but clearly AIR was one of them since I could see colours of the light.

Note that in a sequence “A->B” a sound – such as of a filter-wheel changing position – is heard before A, and before B.

Not sure what to make of this. It could be a signals problem where feedback from the actual position of the wheel is missed or missunderstood by the software so that new or wrong commands are sent.

Is the software that directs the FW giving absolute commands or relative ones, as in
“Go to the blue filter”
vs
“go to the filter after the one you are at, which I assume is the IRCUT filter, so that you will arrive at the B filter since it comes after IRCUT”?

Why does the wheel change position twice during a ‘set the FW-wheel’ command? Makes sense only if it always went to some home position, and then proceeded from there – but clearly it is not starting from the same position each time, given the readout above. Again, could it be that the intent is to send it to home each time but this goes wrong and it doesn’t actually arrive at home, but assumes it did for the next relative command?

NEXT time, we need ABSOLUTE ENCODERS. I want a little man inside the telescope with a cell phone calling us with the ACTUAL position of each FW!

Manually testing the shutters and FWs.

We disconnected the CCD camera so we could look through the telescope along the optical axis, at a lamp. We ran the camera, so that the internal shutter opened and closed regularly, and then manually changed the color and ND filters.

Strange behaviour was observed: Setting the color of the filter was not a simple affair – the colour would be a bit random, and the ND filter would reset – apparently by itself – after a few seconds.

We will try to run scripts next, to see if the command of the devices from the scripts are more consequential and whether the ND resets in the middle of a sequence. Our experience from masses of observations from MLO (before the lightning struck) is that stacks of images are all OK as long as the first image is all right.

Testing the system on a lamp-illuminated flat field. With a script, sequences of images are taken with commands to change filters. Kinetic sequences.

There is obviously some problem with either the shutter or the setting of the FW, because while some images are well exposed at more or less recognizable exposure times (we use a different lamp from the hohlraum we had on MLO) some are simply almost all black at those same exposure times.

To test if it is the shutter that is failing to open, or the FW that does not set, we must eliminate one thing at the time – first let us run a script with exposure times of varying lengths, and simply listen for how long the shutter is open.

If it seems the shutter is always open as long as we ask it to be, we move on to the FW – perhaps we can open the telescope box and simply look at whether it turns (pant a white spot on the side!).

As stated before, scripts can now be run and images gathered. We have solved a minor problem with disc-access that suddenly popped up. Still not sure what this is due to, but can now save images from automatic scripts. This clears the way for a row of lab tests that will start now.

It was possible to start a simple observing script today: Mount was not attached so nothing moved except shutters and FWs (and the SKE is still not working) – files were obtained but it turned out that something with the setup of permissions on the PXI has changed so images could not be written to the ‘NAS’ drive (a network drive in the instrument rack). Am seeking help from DMI IT department for this.

If that starts working we can run tests on bias fields at least, and later on flat fields (with a screen of some sort in the distance) and then focus tests and all this.

We managed to get actual images from the CCD camera today. Hans will tell the story of what was wrong.

So – testing all systems together, next!

‘de Kennis van nu’. The program will be available online, from the web-link http://www.wetenschap24.nl/programmas/de-kennis-van-nu.html

Our paper also made it to an online DMI news item.
http://bit.ly/1eBN5K2

Sloooowly the system is coming back to us: We now have LabView Engineering Mode control of Front shutter, Iris, Mount, Filter Wheels, and now also Focus stage.

We still need to get the SKE stages working.
We need to plug in the camera and see if it can be brought under LV control.

With these things running we are closer to getting some technical data from the system, such as bias frames, all-colour flat fields (for the first time), and we could study the shape of the PSF in different filters.

Important next steps are:

a) get the CCD working and under LV control
b) Try running simple scripts again without telescope mounted

Future, ambitious, steps are:

c) assemble the actual telescope in a testing facility and run pointing tests – perhaps test long sequences of observing scripts indoors and actually debug the system so it would work under field conditions.
d) See to the never-attempted integration with a weather station

Got the FWs moving today, using very basic LabView modules. Engineering Mode does not seem to want to talk to its ‘subVIs’ any more.

For reference:

in the VI ‘set DO line’ you can select port and line combinations. So far we know that:

port0/line22 operates the relays in the Breakout Box labelled RE2 and RE4.
port0/line23 – RE3 och RE5
port0/line20 controls the Thor FWs. The two relays adjacent to the Thor controllers come alive. The FW can be selected via the pushbuttons on the boxes.

If we can get the camera alive next we could at the very least do lab work on the CCD properties – make color flat fields, study the PSF in various filters, and so on.

Today Hans was able to operate the front shutter and the front iris using LabView. The licensing problem seems to have been cleared up (it seems to have been a typo in a form somewhere – perhaps it happened at MLO, or later at DMI). The CCD camera and the Magma no longer are listed with ‘yellow triangles’ in the system – we have yet to plug it in and see it operate.

Next steps are to use same methods to get all devices running – Engineeering mode seems to be dead somehow, but all the ‘sub VIs’ are there and so far we have gotten the front shutter and iris VIs to work – can slew telescope from sub VI also.

Ingemar was here and looked at the LV code. We semeed to learn the following:

1) The NI Report Generation Toolkit license has run out and needs replacement.

2) The newest set of LV codes are on the NAS under ‘Earthshine Project/LabView Sou…/’

3) The Engineering mode refuses to run because of some error messages related to the AXIS – these are for the FWs, the SKE and the Dome. No matter what you want to do with the Engineering Mode it will always start by initializing all its sensors, and if one of them fails, nothing works! Since we have no dome there will indeed be a problem here!
Ingemar was able to turn off some of this (NB: set it back to as-was, later!) and indeed the code progressed to a further point (when it then ran into other problems). Front shutter was tested while the error-checking was turned off in Eng. Mod. but did not work.

Of the above 1) may not be important as long as scripts are not being read. But 3) seems pretty serious.

Questions:

Are the new licenses for the MAX correctly installed?

Can the code that refers to the dome be turned off?

Will things work again once the dome is turned off and the other AXIS cables are plugged in?

Why did front shutter also not work – it has no motor?

Added later: Some of the above is now clearer. See here. A number of the errors were related to wrong LV license number, and the new IP numbers for DMI must be set insid ethe LV code. For reasons we do not understand the COM-port numbers had changed.

Here is a list of non-lunar images taken at MLO. There are stars, clusters, galaxies, and planets and asteroids. Many are suitable for studies of extinction.

I wrote a program called moonraker in fortran, which processes all our data, seeking out the best for further reduction. Peter has written something similar in IDL.

It goes through all the images and throws out ones with

1) saturated BS (> 50,000 counts in the peak of the BS)

2) underexposed BS (<10,000 counts)

3) smeared images (heavy bleeding of photons in the Y-direction on the chip, reaching the bottom 20 pixel wide strips of the frame). A mean count level of more than 50 counts in this strip triggers a flag and the frame is rejected.

4) rough check if the moon is too close to the edges of the frame. This is not yet optimal, but throws out the worst cases.

5) checks that the temperature of the CCD is OK (an entry in the fits file header tells us if the temperature of the CCD has stabilised or not)

If all 100 slices in multiple exposure frames are OK, according to the above, they are bias subtracted (using the biases on either side of the exposure, averaged appropriately for each slice, and scaled to the superbias created by Henriette) and averaged, and written to disk.

6) The magnitude of the total light in the frame (i.e. apparent magnitude) is then compared to the expected V magnitude (using the JPL model, with corrections for the east and western sides of the moon, depending on which side is illuminated by BS), taking into account the airmass of the observation and the extinction for the particular filter. This isolates for removal exposures which have been taken with an incorrectly reported filter. Finally, after extinction correction, only those frames which fall within ~ 0.2 magnitudes of the correct magnitude using the JPL model are retained.

The list of the final set of good exposures using this method is attached (all100.doc — actually an ascii text file):

There are 534 good frames, spread from nights JD2455938 to JD2456104.

A summary is as follows:

Night, number of good frames in V, B, VE1, VE2, IRCUT, comments

JD2455938 2 2 0 5 0 fullish moon, some foggy frames
JD2455940 3 1 0 2 0 fullish moon
JD2455943 3 3 0 3 1 fullish moon
JD2455944 3 1 2 1 3
JD2455945 1 1 1 2 0
JD2456000 3 0 0 1 1
JD2456002 7 0 0 0 0 V band only
JD2456003 9 0 0 0 0 V band only
JD2456004 1 0 0 1 0
JD2456005 6 0 0 0 0 V band only
JD2456006 4 0 0 0 0 V band only
JD2456014 3 0 0 0 0 V band only
JD2456015 7 10 4 6 4 1/3 moon, lots of frames
JD2456016 11 10 9 11 11 “
JD2456017 7 11 0 11 2 “
JD2456028 5 5 0 9 0
JD2456029 0 0 0 6 2 2/3 moon, lots of scattered light
JD2456030 1 0 0 3 2
JD2456032 1 0 0 4 1
JD2456033 4 1 4 2 4
JD2456035 0 0 0 1 0
JD2456045 5 5 4 4 4
JD2456046 4 8 10 11 10
JD2456047 6 5 8 6 7 stars visible in some frames, useful for PSF
JD2456061 2 4 3 6 4
JD2456062 0 0 0 2 0
JD2456063 0 0 0 5 0
JD2456064 0 0 0 3 0
JD2456073 4 7 7 10 8 some eclipsing of moon – dome issues?
JD2456074 4 2 3 7 5 scattered light haze or fog?
JD2456075 8 7 8 7 8
JD2456076 9 1 0 2 0
JD2456089 3 2 1 1 0
JD2456091 2 1 5 0 4
JD2456092 0 0 3 0 5
JD2456093 0 0 1 0 5
JD2456104 5 7 5 1 5 some foggy frames, moon a bit close to bottom corner

I’ve inspected all of these by eye and they look mostly pretty good! There are still a few bad frames here because the scattering of the halo is not selected for yet — but the number of frames with low alpha (i.e. haze or fog) is just a handful.

Some of these nights will be pretty useful for looking at colour changes in the ES over time. I am doing that next.

Clear. Moon up.
7-9 m/s from 160 deg.
14% RH rising
7 deg C.

I do not understand this image:

The image is not overexposed (3000 counts only) so the streaks are not ‘blooming’, which occurs when the pixels are saturated (starts near 60000 counts). A streak downwards would be due to readout while shutter was open (down corresponds to the readout direction). But UP is very strange – it could happen if the telescope was moving while the Moon was being imaged, but as far as I know this is not a situation we have seen before. It could also happen if the readout direction changed – but I do not think that is possible – and in this case readout would have had to occur in both directions then.

Very clear. High wind.

Shutter failed pretty miserably – 1 image stack of 16 was useful.

Later restarted telescope and was able to calibrate the mount – this means that the shutter started working again.

Google Sky helps find the calibration position.

Hazy – VYSOS line is yellow/white. Moon rises in clouds.

8 m/s from 180 deg
RH is 15%

clear, 40F, 15-20% RH rising, 6-8mph or 2-4 m/s from 220 degr.

Many ‘hung shutter’ frames but the ones that work are perfect.

clear, 35 F, 30% RH, 2 mph winds.

hazy
40 F
RH is 30% and rising
4-6 mph winds.

9 C/50 F, 8mph/3-4 m/s, 15% RH, clear but not v. so.

As of end of May 2012 we have about 25000 images labeled “MOON” – many of these contain 100 images each.

From these, after coadding all image-stacks, and by selecting only good data, we get 6871 single images (these are now either single observations or aligned 100-image bundles). These cover 55 separate nights from July 2011 to now.

Most of these 55 nights are observed in all filters.

None are science-grade SKE or ND images.

With an expected 200 good nights and a duty cycle of 20-25% we are not doing too badly!

Shutter all over the place today – dragging AND overexposure??

9-11 m/s from 120 deg. RH near 20%, 6 deg C. clarity 9/10.

Hazy or foggy – quite large halo on Moon in TV cam. Difference image showing structures.

15 m/s from 160 deg, steady. 6 degrees C. RH is 30%.

12-18 m/s from 140 deg. humid – RH is 70% and rising. T is 5 deg C. It is almost clear – but minutes ago small puffy clouds blew over …

Ups — more clouds. Closing down for a while now.

Observing again – must say there is some fog banks that come and go. Not one of the best nights.

Clear. 12 m/s from 150 deg. 48 deg F. 10% RH.

At 2456073.8ish the cables are in the frame.

Good data – butthe usual filter dragging and blanks. Especially V which is unusual.

18 m/s from 160 deg. RH 20%. 5 deg C. Clear.

Clear. 15 m/s from 140 deg. RH is 20%. 4 deg C.

Windy at 17 m/s from 160 deg. Clear. RH 50%. T near 4 C.

Focus problems – again!

Trying to determine if CCD is linear by observing pairs of stars at various exposure times. Finding that focus is bad !?Is it even possible to get ‘doughnut’ images for out-of-focus stars in a refractor?RH is 50%, T is about 44 F, wind is 6-8 mph- It seems clear.Later, osberving Moon: ..54.06.. T=37ish F, RH is down to 42%, wind 2-3 mph. seemed clear when the Moon rose.

at ..62.8 clear, 3 deg C, 2 m/s from 250 deg. RH 40-55%.at ..63.11 T lower, still clear, low wind, RH 60%This is a really strange night – the relative exposure times are very unusual.The factors are:B 20V 22VE1 20VE2 18IRCUT 20Especially B is very strange indeed.A lot of shutter hang going on, though.

3 m/s from 220 deg, 4 deg C, RH 35% and rising.
Zenith clear but Moon rose behind clouds.

When observing resumed there was a slighthaze – VYSOS cloud line sloooowly moving upwards as dawn approached – but at least no obscuring clouds, as was the case at Moonrise!

Clear
T about 4 C
RH down to 15% from a high hours earlier.
3 m/s winds

12.8 degrees C in dome at start – 45 F outside on MLO mast
9 m/s increasing at start. At xxx.86 the wind is 16 ms or 20 mph. Steady from South.
RH 15%
clear

Exposure factors for the filters are very good this night:

B 34.0
V 11.8
VE1 2.6
VE2 10.0
iIRCUT 2.6

These are factors, note xposure times. The exposure time is some number times the above. A typical IRCUT exposure time may be 0.008 s. The code we have – script_builder_MOON.pro – scales a table like the above one appropriately for the lunar phase.

Later: The above factors seem inadequate on another night with the Moon rising – B is overexposed while VE1, VE2 and IRCUT are at 12000. Hmmm.

A bit later still: Hmmm – the above problem was due to hanging shutter – but a very consistently hanging shutter! So the table is OK. B is perhaps a bit high but now V and VE2 are just right.

12.9 C in dome at start (6045.75..)
RH 25%
0 wind
clear
Moon setting

Near ..45.86.. one of the cables from the MLO tower gets in the image.

Moon rising in a cloud.
50% RH.
Temp=35 F.
11 mph winds.

Extraordinary night – followed the Moon from moonrise until dawn. Clearest night we have had yet. Halo almost non-existent on DS.

This shows that we may be able to get very good data very close to the Sun – but in that case extreme refraction would have to be handled. Will look into whether this can be achieved from the JPL ephemeris. Exposure time also needs to compensate for the strong extinction through 5-10 airmasses. Not sure how to do that without stopping and starting scripts.

As of March 18 2012 we have 78.000 images of the Moon, of which 51.510 are relevant for data-reduction with the current techniques at hand.

Distribution across lunar phases is seen here:

Hazy – ring around the Moon.

On JD2455993 I tried to do lamp flats since the night was cloudy and humid. Started the LAMPTEST script, the system started slewing towards the hohlraum lamp – and kept going towards the floor. KS stopped it before it hit anything.

Why on earth are we back to the ‘old ways’? This is the sort of behavior we had before the ‘dont send commands during slewing’ problem was solved by Ingemar.

Because the system has been well behaved for a long time I did not have the cable sniffer running so we have no record of what went on.

Any ideas of automatic operations while the system still does this must be ruled out!

Will now reboot everything, calibrate (on another night), and see if the problem reappears.

We can only hope that someone had been moving the telescope about by hand, as that would explain what happened.

T=7,4 C in dome, RH=70%.

Moon in clouds. RH 85%. No observing.

A slight haze at MLO.

Trying to observe Moon. Many thin clouds, but it may clear up later and then we will not waste time on setup. T=7.4 C. RH near 40%, varying.

Shutter works irregularly at first, then regularly – as if it has some dirt or oil in it that needs to be rubbed around until it is warm? Now and then there is ‘dragging’ but, as always, mainly in one filter – when a new filter is chosen the dragging may go away, or reappear in another filter.

Dome needed a fresh ‘find home’ – wonder why? I left it in a working condition? Dome now follows telescope.

Moon in frame but not well centred. Why? It is just a few days since I calibrated the mount on a target in the same part of the sky? ‘Slow creep’ of alignment seems to be a feature of this system.

More clouds now. Shutting down. Need a cloud sensor up and running!

Ring around the Moon! No observations! Doing lampflats instead. T=7.3 C in dome.

Trying to observe M41. Temperature in dome 6.4 C at start. Very light haze.

Shutter giving problems: So far, all shots are bias frames – except one that is 0’s in one third … as if the camera died?

At one point, when this happened, some LabView panels having to do with Andor configuration and Shutdown moved to the front on the logmein display: I think this means they had been activated – I had done nothing to cause this – so perhaps it means that the system did it having sensed something was wrong?

Abandoned M41 – then tried the hohlraum source. No images at all recorded now.

Rebooted everything.

Mount re-calibrated after Ben’s fix of the Kill Switch ring. Can now reach -30 degrees declination.

Ran scripts to observe Saturn and Mars. Strange problems with script not writing to disc. Rebooted and all was OK.

T 4C outside, 6.7 inside. 10 m/s, 40% RH. Clear.

Observing asteroid EROS since it is close to Earth. Trying for a movie of the Moon rising behind the flank of Mauna Loa.

45% RH (rising), some indication of clouds, T near 3 C outside, winds 4 m/s 220 deg.

T fell to -3 degrees C outside. Inside the dome it was as low as 2.7 degrees C. About 30% of images were all right. RH very low. Wind near 8m/s.

Hit kill switch again at Alt 75 degrees near meridian. Mount calibration may be lost now – but seems to be less than a few pixels.

Moon observing with script Moonb.csv, which – wait for it – AUTOMATICALLY adjusts the dome position! Whohoo! AND the exposure time!

T near 4 C in dome so many dragged frames. RH v. low. Winds near 5 mph. Halo around Moon seems large.

Good to listen to the shutters etc via a Skype call from the telescope. Shutter is LOUD, when it works.

Mount is re-calibrated following yesterdays chrash into the kill-switch.

Image still jumps, but not as much as before – it seems to be at only the 5-10 pixel level now.

Testing focus and testing the script MOONb.csv that should automatically set exposure time (software sets it automatically as it builds the script).

T 4 deg C, wind 5 m/s, RH 20%. Almost Full Moon. Slewing went well. Moon nicely centred.

Here is a histogram showing the distribution of our observations across Sun-Earth-Moon angle (i.e. lunar phase on 0 to 180 degree interval). The huge spike near angle 50 is from the tau Tauri observations.

At sundown T=8.8 wind dropping, 10-14 m/s, RH about 20%. 2 hours later outside T was 5 degeres C while dome T was still 7.

Shutter failing often – and ‘open while reading out’ occurring. Again we see sets of images failing. Of course not related to the physical filter itself – but then why e.g. all VE1 images failing while adjacent images OK?

No clouds. halo starting to reach DS edge towards sky.

Noted that an antenna gets in the way of the Moon during some Moonsets.

Catching the setting crescent Moon. T=8.4 C in the dome. Got some nice Moon images – almost no scattered light!

Then observed Uranus, but images were either saturated or misfired. T=4.7 C now.

Now M41. Getting very few frames. T=4 C and the wind is strong at gusting to 16/17 m/s.

A skycam image showing where there is fog on the mountain. The navigation beacons are hazed out (in the NNW) so there’s fog at ground level. Close up please!

Dec 10 2011 Lunar Eclipse.Observed with Chris. Fairly clear skies. Temperature was sub 30 degrees F so plenty of shutter stick. Of 1500 images about 2-300 were useable.Made animated GIF of the eclipse.Image position wuite stable, but not perfect – clearly the fix by Ingemar which now enables interpolation helped a lot, but table may still be to coarse – otherwise slight ‘jitter’ in position may be due to ssome mount issue.

Clear, but 80% RH and T=5.6 C in dome.

Halo enormous – no sign of DS despite phase. Exposures of the BS only in the 1000’s – must update exposure time – heavy clouds??

Shutter clearly open during readout – dragging downwards.

Also sticking so that saturation in stripe downwards happens – i.e. shutter started to close, then stuck open for a long time. T now at 5.2 C.

T now at 4.9 C.

Experimenting with SETIMAGEREF and MOVEMOONTOREF because it seems the mount calibratio I did earlier tonight was not quite right. Noticing that when Moon is half out of the image frame downwards I get a reflecting coming in from the upper side of the frame – like was saw during the tau Tauri occultations in July – then it was left to right. So, something in the optical train is causing reflections onto the CCD when the source is not well centered.

More and more clouds now. T now 4.8 C.

I have obtained 100 dark frames with random exposure times in the interval 10-200 sec. This will allow me to determine with certainty if there is any substantial dark current.

The telescope performed as it should and all images were saved without trouble.

Extremely wet and cloudy these days! Wanted to observe Moon.

Testing the Diffuser. it sits in the ND filter wheel – that is, in the collimated beam. Being situated there it removes any spatial information originating in the flat screen itself, the front objective and the first lens of the collimating system. Flat fields taken this way have a central brightening that looks spherical or parabolic in shape.

Perhaps, if that darkening could be understood and subtracted by some fitting procedure, we can use the diffuser to get good high spatial frequency information about the FF? It seems to remove the huge gradients that otherwise characterize the FFs we have been getting from sky, dome and lamp in the past.

The difference between darkest corner and centre is about 10%. What is the origin of the circular feature, and what does its position off-center tell us?

We fit a second-order surface to the image above and subtract it. Add the mean back in, and normalize. The result is here:

While extremely similar in appearance to the other ‘superflats’ we find that the central red patch is about 1% above the rest.

On the July 26 2011 occasion of observing the star tau Tauri being occulted by the Moon we followed the Moon from just after Moonrise until Sun rose some hours later. During that time we tracked the star at sidereal rate so the Moon drifted through the frame.

Determining the radius and image-plane coordinates of the lunar disc we plot these:
We note that the radius increases slightly as the Moon rises – probably an effect of differential refraction decreasing as airmass approached 1. At most the radius estimate increased by about 1.5 pixels during the sequence. The standard deviation about the line is 1 pixel, telling us what the precision is of the method used to estimate lunar disc properties (it works by fitting a circle to points on the edge of the lunar disc).

We also see that the Moon did not follow a straight line across the image plane. The deviation is up to 5 or 6 pixels – about half an arc minute. This may be a refraction effect or a tracking effect or indeed an orbital effect – the mount we have does not track the Moon in declination.

In summary we see that the effect of differential refraction across the field is not more than half an arc minute at large air masses, consistent with physical estimates.

Observing Moon. Temperature in the 7-5 degrees C range (falling). Shutter sticking now and then. Weather very similar to previous days – clouds and rain into the late afternoon and then just at sunset the skies clear.

Dome ‘nudge’ working well and Dome Match also, although some work is needed on the table of pointings.

Halo around the Moon.

Getting the setting Moon in clear skies.

Plenty of ‘filter stick’ and it comes in sets – when we change filters the shutter ‘unsticks’ and we are good for one set of images, then we change filter and there is the chance that we get good data or bad data.

We also see a periodic shifting of the Moon inside the frame. Either the JPL table of Moon positions is slightly bad, or the interpolation is done.

Question: Is the table of Moon positions interpolated or do we go for ‘nearest neighbour’?

See the telescope and the Moon!

Strange ‘dragging’ on at least the VE1 images – and yes, readout drag is up-down, not right-left.

Many frame dropouts. Temp. is between 4 and 5 degrees C.

B and V perform well at this very almost new moon, but VE1 and VE2 seem to need boosting relative to the bluer bands.

Wait, the VE2 is fine – it is the VE1 that is too low, as if it, in particular, wants to stick.

Noting that the external view of the VYSOS-20 position is the best for detecting the coming of Dawn.

VERY little scattered light from the BS tonight – even at very high airmass.

4-5 degrees C. Less thin cloud than previous nights. Shutter misses quite a few images. Towards dawn shutter working better. Sky noticeably brighter by 5:25 on all-sky camera, but not in CCD images.

Getting multi-band images of crescent Moon. Bands of thin clouds rolling past – vissible mainly as increased halo around Moon and in the eq. diff. images. T between 6 and 7 degrees C. Not very many failed frames.

Dawn started 5:45. by 5:55 sky-level was 445 – normally 397.

Time Level
6:00 505
6:02 530
6:04 930 – bias pattern starts to be seen
6:11 Earthshine side weaker than patterns in bias. Stopped.

Sky flats in the morning. Stopped when trailed stars were seen. VE1 flats ‘blotchy’ and strange.

Lots of thin cirrus! 9 degrees C. Taking lunar images. Will follow the Moon up in case it clears before dawn.

Can confirm that GOTOMOON script command works – goes right to the Moon. [Added later:] but, weirdly, seems to drift slightly. Since the table is OK it must be the calibration that goes slightly off – polar axis alignment issue?

DOMEAZ was supposed to put the dome where the telescope is pointing – and it worked for a while, and then started sending the dome off to strange places. Perhaps some homing is needed on the dome before using the command?

Testing the combination

GOTOMOON
MOVEMOONTOREF

to see if it keeps the Moon centered. At least the MOVEMOONTOREF does not send the telescope anywhere crazy.

Nice screendump of what the Front Camera Saw earlier today. The Pleiades!

9 Degrees C. Some thin cloud from the start – then more and more.

Lots of Moon observations in ‘dither’ mode, through all filters.

Day started with CCD flatlining. Reboot. Then all OK, Still have to set sub-degree offsets on pointing to put Moon in middle. Why? Will test the MOVETOREF command.

FW apparently OK – no noticeable ‘sticks’.

Various things failed and none of the planned observations could be obtained:

Telescope did maverick meridian flip that we cut short as it neared the floor.

The camera flatlined for none of the known reasons.

Then some part of the FW or rotary stage system got stuck. There is an issue with the large rotary stage acknowledged by several parties. I additionally think the FW can get stuck at times – witness the failed VE1 observations on JD 2455849.

PXI is at the moment unreachable over the internet following an iBoot power cycle that failed to re-boot the machine.

More ‘dithered’ observations of the Moon. VE1 filter images kept being ‘bias frames’. How does the shutter know that the VE1 filter is in? Or is something else going on?

Pointing with absolute coordinates is awkward – from night to night the mount calibration seems to go slightly off so that new offsets have to be tested in a time-consuming manner. If the polar axis alignment is not good, would it cause this problem?

CCD seemed to show new startling ‘saturation’ modes.

here

Apparently managed to ‘unstick’ the previously stuck filter-wheel stage that caused blocking of the FOV by the edge of the aperture of the stage that holds the SKEs. This was done from the Engineering Mode by ‘finding the homes’. The Large Rotary Stage did not reset in such a way that the green light indicating success ever lit up. The Little Rotary Stage rotated, cleared the blockage, and its light lit up.

A selection of Skycam shots to show what you can see. From top left : a hazy night, a very hazy night (ice crystals?), a very clear night, water on the sky cam and the laser star, the skycam on a wet afternoon and the crescent moon on a bright sky just before sunset.

Skyflats, Moon and Altair.

Skyflats started too late and are not well exposed – I started at 6:13, Sunset was close to 6:20 so should perhaps start closer to 6:00 next time.

Moon was run through various settings of SKEs and the KEDFs as well as the NDs – but images appear strange – as if the devices did not set right or the input data was wrong.

Altair was imaged through variable cloudiness allowing us to see both very clear PSFs and the misty PSFs.

The NAS was acting up – images were not being received on it. Had to reboot.

Rain on MLO. Moon up.

Tested setting the SKE from a script – this failed. The values for cusp offset and cusp angle were taken from the System_Dataxxx.csv master spreadsheet rather than the script itself (“protocol”).

We actually have no, documented, proof that the setting of the SKE or KEDFs works, right?

Ben has created a map of where the dome should be for a range of telescope pointings. Map works well so far! We are adding data points to it as we go along, and also mapping out the edges of the dome slit at various positions:

A better resolution version is available here:

http://www.astro.utu.fi/~cflynn/dome_pointing_plot.ps

Testing the Focus Search tab in the Eng. Mode. Works nicely – but how do you reset the scale on the graph?

Also tried to ‘open’ and ‘close’ the Front Iris (elsewhere labelled as 30mm and Open). This produced no effect what so ever on diffraction spikes or flux levels. Does the Iris work? In which position is it stuck?

May have learned this important lesson:

The ‘flatlining’ of the CCD camera may be entirely due to the ‘running of two instances of LabView’. This occurs easily, it appears, if you close the VI for imaging while the Engineering Mode (EM) runs – or something like that: the danger is that an instance of Labview is started without you knowing it.
The danger is present when closing VIs. So, to guard against this, have the Task Manager running so that you can see whether you have more than one ‘instance of LabView’ running.

Also, you must have iBoot channel 5 ON when using any of the EM modes for controlling Filter Wheel, front Flap, Rear Flap, Side Flap, underside Flap or any other wonderful device on this telescope!

Sept 24 2011: Observed Jupiter with Chris. Did approx. 2000 0.1s V-band exposures. Used a script that contained direct GOTO RA/DEC command, called JUPITER.csv. Co-added the images on ‘woof’. Chris later analyzed the resulting profile.