Feb 10 2006

February 10, 2006

Problems problems!

Well, the weather had been crappy for the past week or so, but I finally had a chance to get outside on the night of February 9/10. The moon was past first quarter and thus dominated the evening sky. One nice thing about being in the city is that moonlit nights aren't really a problem; the sky just isn't that much brighter under, say, a first quarter moon than it is on a moonless night. Still, with the moon nicely placed I decided to spend much of the evening photographing what had been the target of my first telescopic astrophotograph back in 1968 (I'd taken a few star trail pix by that time as well). The Meade "AutoStar Suite" makes it pretty easy to take pictures of solar system targets and its a good thing. The MaxIM DL software would not take an image with an exposure time of less than 0.06 seconds, which is too long, at least for the moon and Saturn, the two solar system objects I'd tried so far. So I used Meade's software and exposure times of a few thousandths of a second and combined roughly 50 frames for each resulting image. The seeing was typically terrible; the image on the screen bobbed and wiggled constantly. The field of view with the DSI camera is only about 5 arcminutes on a side when using prime focus (3190mm focal length - 9.6x7.5 micron pixels - 508x489 pixel array). Hence its like using a high-powered eyepiece at all times. I did the best I could to focus, then hit "expose" and watched as the software did its thing. Interestingly enough, the newest version of "Envision", the imaging part of Meade's AutoStar Suite, uses a version of the Drizzle technique which I'd used a number of times while at STScI. I wasn't using that, however. I just picked a bright feature near the limb, drew a box around it, and had the software use that as a fiducial mark to shift and stack images. I took a lot of images of the moon that evening, as well as a few of Saturn. Despite the really terrible seeing, the moon images came out pretty nicely. Well, at least until I got a closer look at them; more on that in a bit.

Given that the seeing was so bad I decided to use the rest of the evening trying out a new bit of software. Cyanogen Software, makers of the Maxim DL imaging package I was using, also produce something called MaxPoint, which builds a six parameter model that corrects for all sorts of mount maladies, including non-perpendicular axis, declination cone errors and the like. The first thing I needed to do, however, was to get the mount fairly accurately polar aligned. So I re-initialized the mount by turning the electronics off, then back on and sent the mount into its "locate switches" routine. As usual it sensed each switch and came to a parked position. The hand control indicated a nearby alignment star (Aldebaran) so I hit "OK" and the scope began slewing. Then stopped almost immediately. No matter what I did I could not get it to budge in right ascension. I could not figure out what was wrong, but suspected the safety limit switches. I tried several times, turning things off and on, re-setting the switch positions, still no movement. That put an abrupt end to the evening's festivities.

I took everything apart and put the 'scope in its case, but brought the equatorial head and mount electronics up to my study to have a look. I got onto the Cloudy Nights Forum and began searching for anything regarding "switches" and "CGE Mounts". Sure enough, I came across an article describing the exact symptoms I was observing. I read through the entire thread - looked like I was going to have to return the mount to California for repairs at first (see the earlier article about how I almost had to send the optical telescope assembly back two days after I'd bought it). But as I read on it seems this person found the problem and fixed it! He had described how to fix it so I decided to try it myself. The right ascension axel has two shallow "trenches" carved into it, essentially making one section slightly smaller in diameter than the rest. There is a pair of spring loaded roller switches that ride on the polar axel as the scope is turned in RA, and when one of these regions (each running about half the circumference of the axel) is encountered it causes one or the other switch to engage. There is a switch point at either end of the travel range for the RA axel - preventing the motors from driving the scope into the mount, and another point at the center of that range (meridian) that switches the logic from one side to the other. The switches themselves were mounted in a manner that allows their orientation to be adjusted; the trick was to adjust them so that they engage and disengage when they are supposed to. WARNING! BE VERY CAREFUL!!! I'm sure playing with this will void your warranty. Also note that improper orientation of these switches could cause one or another of the switches to not engage when they should, which could result in serious damage to your RA gears and motors. Be very careful and be sure you know what you're doing before trying this! I immediately saw that one of the switches was such that once set could not be unset. So I just loosened one screw and slightly turned the switch in its holder and heard it "click". I tried the hand paddle and voila! It turned. In fact it would turn without stopping when it got to what should have been the end of its travel and ran the mounting bracket for the scope directly into the pier! It turns out that the positioning of that switch is VERY sensitive. It took perhaps twenty minutes of fiddling around until I found a spot where the switch would disengage once set, yet would ALWAYS engage (stop) before allowing the mount to run into itself. Still, its something I'm very careful about as I now do not trust the switch to be a reliable safety feature.

So, lets review all that was wrong with this scope (so far): 1) One of the secondary mirror collimation screws had stripped threads, 2) The secondary mirror housing was loose and had rotated out of its properly aligned orientation, 3) The hand controller was fried, and now 4) the RA limit switches were not properly adjusted. From most of what I had read Celestron was supposed to have pretty decent quality control (at least better than its main competitor). If so then this one clearly was built on a Monday or Friday! So far the optics have seemed excellent - but I've yet to have a really steady night to give them a really good test. I'm almost afraid to know the answer.

This shows the four 5/64-inch hex bolts (allen wrench) that need to be removed in order to get to the polar axel limit switches. Once the four screws are loosened you'll need to rotate the axel to get the dec axis/counterweight shaft out of the way. The switch is located near the upper right screw (see image at right).

1) indicates the spring-loaded rollers riding on the outside of the polar axis. There are trenches milled into the outer axel in which these rollers ride. As the trench gets deeper or more shallow it causes one or the other switches to engage; you'll hear an audible "click" when that happens. 2) indicates the screw that secures the switch housing to the mount. Loosening this screw allows you to reorient/reposition the switches.

Anyway, with the limit switch problem solved I decided to look through the images of the moon that I'd taken. Gassendi is a really interesting large (110km) crater that happened to be near the terminator that night. The first image I'd taken included Gassendi, so I loaded up Maxim DL and read the appropriate file. It looked pretty good. It was a combination of 50 or so 0.002-second images which had been aligned and stacked in Meade's "Envision" package. When I looked a little closer, however, I noticed a problem. It had alternating rows of pixels that looked as though they were shifted several pixels. It turns out that the DSI is read out in an interlaced mode, and it seems that when taking a series of short exposures the alternating rows of pixels don't line up.

The solution was to use MaxIM's "deinterlace" function. Deinterlace produces two images; one based on the even numbered rows and the other based on the odd numbered rows of the original image. Deinterlace interpolates across the missing rows; then using Combine to shift and then add the two images back together results in the improvement shown below.


Here's a "before" and "after" pair showing the interlaced readout problem (left) and the same image after applying the remedy described. The images are of part of the rim of the lunar crater "Clavius" and very nicely illustrate the typically crappy seeing.

So after solving that issue I went back to the moon images I'd taken that night and cleaned them up. All of the images below have been processed, as described above, to remove the interlaced readout problem. They've also been lightly processed using the maximum entropy deconvolution command in MaxIm.