Earthshine blog

In a potential upgrade of what we currently have, we might consider going to linux and freeware, for our command system.

Some devices can be operated via the indiserver concept. Devices for which drivers have been written can be commanded from essentially the linux command line. This means that scripting systems are easier to set up – for us at least.

I have been able to control our SXV-H9 CCD camera using this system. Here is a link to how it is done:

There exist indiserver drivers for gphoto2 – that means that Canon DSLR cameras, for instance, can be operated in this way.

A TrueTech filterwheel is being tested. LX200 telescopes can be controlled – i.e. mounts such as ours.

Following the power surge and the consequent failure of the system, I installed SOLIS in case the software and drivers had been hurt by the power surge. This was apparently not a good idea – during construction of the system it was realized that ‘drivers’ from SOLIS and ‘drivers’ from the SDK are not the same and that only drivers from the latter must be present.

I therefore today de-installed (using the Windows 7 Control Panel) the Andor SOLIS package – as well as the unwisely installed Andor SDK package (both, apparently, with their provided drivers).

I then tried to run the ‘setup.exe’ present in the Andor SDK zip file – the setup offered to install itself into

C:\Program Files\ANDOR SOLIS\Drivers

which is supposedly not right – the SDK should install into

C:\Program Files\National Instruments\LabVIEW 2009\user.lib\Andor Tools

according to Ahmad. So I rebooted the system. Actually, it seems I chose ‘shutdown’ so it is not coming back up – must ask Ben to physically reboot.

RH 10%
T 37 F
wind ~20 mph
Moon rising in thin clouds. Later v. nice data (past 2456035.1 for example).
Azimuth near 90.0 degrees.
Dawn started at 5:10 HST.

Note 1: File with actual rising is B frame at 2456035.0738666 – could possibly show halo of BS against the mountain, as the BS rises, despite clouds on horizon – air between mountain-side and telescope probably quite clear.
Note 2: Rose only a few minutes after ephemeris time so we almost caught it rising from sea. Other nights have been 20 m delayed due to slope of Hawaii.
Note 3: started tracking at altitude -4 degrees – so the KS allows this, at that azimuth at least.

Note 4: Changed SHUTTERCLOSINGTIME in the Andor ini file from 20 ms to 100 ms to see if this helps for the ‘dragging problem’. Later changed this back to 20 ms since I got the usual amount of ‘dragged’ frames.

We may have located a significant bug in the control software: A command was being sent during slewing, which is not allowed. It was sent due to some timeouts in the software.

Bug was found by Ingemar Lundström after some information from Howard Hedlund of Astro-Physics in Illinois.

Multiple meridian flips were tested after fixing the software – both from Engineering Mode and from scripts. No problems.

It is still an issue that Kill Switches should not be reached – we fear that some loss of calibration takes place then too, although the amount of de-calibration may not be total.

Interpolation enabled. GOTOMOON centers better now. SETIMAGEREF tested.

MOON.csv – uses the GOTOMOON and MOVEMOONTOREF script commands to take lots of images in all filters. Takes 11 images at a time through B,V,VE1,VE2, and IRCUT filters, then loops back. 100 times.

The present version of GOTOMOON does not put the Moon in the center of the image field. We understand why that is, now: Ingemar Lundström spotted that there is a table-lookup based on ‘nearest previous neighbor’ rather than an actual interpolation. As the table is spaced at 2-minute intervals the Moon will slide from image-edge to image-center at 2-minute intrvals, which is what we see. This will be fixed in a later version of GOTOMOON.

DOMEAZ placed in a script appears to work well – i.e. no crazy round-trips, and works well in the East at azimuths like 75 degrees.

DITHERMOON.csv – takes ‘dithered’ images of the Moon – i.e. Moon moves about in two nested Releaux triangles. All filters. Takes about an hour to go through all filters at all dithered positions.

LOOPING.csv and FFdusk.csv – a pair of scripts that are used to start and do flat-fields at DUSK (i.e. not dawn). LOOPING.csv is started before dusk and takes B-band images on the NAS – the user checks if the exposure level is such that the event has begun. When the level is right (i.e. not saturated and in the 50000s) then a Normal Shutdown is performed, System_Data_Table.csv is edited and FFdusk.csv is placed instead of LOOPING.csv. Then that is started in the MASTER CONTROLLER and that should now run through the dusk event for about 20-30 minutes extending the exposure times in such a way that well-exposed images are obtained all the way until full darkness. Tricky to do due to the ‘bump’ during dusk and also if there are any clouds, watch out.Well, the ‘bump’ is NOT visible here. Typical. But usually there is a ‘bump’ on the dusk part of the bottom curve for illumination (at 6PM). That bump can cause you to make a false start so that later the light is too high and all the images end up over-exposed. The nump lasts about 15-20 minutes. Good example on the dawn shoulder! Might be clouds low on the horizon or whatnot.

ALTAIR.csv, JUPITER.csv and all STARNAME.csv scripts – have the coordinates of the star in the script, so only start these scripts if that object is above the horizon! Loops through all filters with (somewhat) appropriate exposure times.

MOVEMOONTOREF is a command to place the center of gravity of the Moon’s illuminated disc in the center of the image. Has been tested with GOTOMOON which must preceed it.

Seems to work.

A few test cases for making sure we are talking about the same thing when we set up the cusp angles and KE offset.

The agreed convention is to measure angles positive East of North. Blade starting position (at least conceptually) is with the KE covering the East side of the lunar disc and pointing North-South. After the angle is set the blade is positioned in offset (positive only by convention – the KE has to be advanced from disc center enough to over the bright parts and a little more of the DS. Note that the blade is FIRST rotated so that the BS is covered.

JD2466871 November 5 2011: The Moon is bright on the WEST side (the side towards DEcreasing RA). The phase is over half, i.e. more than half the Moon is bright. Judging from the display in ‘skychart’ the Cusp Angle is -195 degrees, i.e. to cover the BS the blade is rotated by negative 195 degrees. A solution would also be to rotate it by +165 degrees. Since the BS is still vissible the blade is now advanced at right angle to its edge by about 3/4 lunar radii – i.e. by 0.19 degrees.

JD2455866 October 31 2011: The Moon is less than half and is bright in the West side.
Judging by the display on skychart the blade should be rotated -186 or +174 degrees. The blade should be advanced although the DS is more than half the disc, since we want to get away from the cusps, so advance by 1/4 lunar radius or 0.12 degrees.

Remember – the blade advancement is always positive – never negative. It pushes FORWARD from its starting position at disc center and covers MORE of the disc. As the example on JD2455866 shows the advancement is always at least 1/8 degree and can reach as much as almost 1/4 degree.

One of the scripts uses the MEDIAN ADJUST command – it adjusts the key word for exosure time so that a better guess is used, based on the previous exposure time and attained flux level. It seems to work in the DOMEFLAT_COMMANDED.csv script, except for B and VE2 filters, where the exposure times suggested is 180 seconds. This is the limit (to avoid wasting too much time) and the corresponding images are underexposed. This is basically because the CCD camera is RED-sensitive, not BLUE-sensitive, and because the paint on the inside of the dome at MLO is not very reflective at red wavelengths. The V, VE1 and IRCUT images are properly exposed to about 51000 counts as they should be.

Setting the SKE: can only be done from the System_Data_Table – not in a script (the command suggesting that you can do it from a script is not for this purposes).

How to avoid ‘Camera Flatlining’: See the entry under Observing log for JD2455831.