Embedded Files
From the start (June 2020) I had trouble with the mechanical stability of my az encoder mounting. The encoder shaft was inserted into a cup, which was then placed over the az nut. Either the cup did not make good contact with the nut or the encoder shaft was slipping relative to the cup.
To make sure that this error did not affect the initial meridian altitude measurements, I auto-guided on the target stars as they passed through their maximum altitude and then recovered the maximum altitude value by fitting a curve to the altitude data.
Below are examples of the 'transit' datasets that were created by tracking on one, or a few, stars. In the upper two plots, two stars were alternately tracked. In the lower left plot, three stars were alternately tracked. In the lower right, three stars were tracked, but only one has good enough data to determine a maximum altitude.
The individual stars tracks were isolated, and curves were fitted to find the maximum altitudes. The times of maximum altitudes were also recorded - something Tycho was not able to do because of the poor clock technology of his era - but which allowed me later to determine the Earth rotation rate.
My az stability measurement technique was to center a local target (a nearby water tower) and record the az.
Below: Here is a plot of the az repeatability for the month of October 2020. The scatter is about 0.1 degree, small enough to put stars in or near the camera FOV, but much larger than the encoder resolution, 0.009 degrees.
Because meridian altitudes change very slowly, these small errors did not contaminate the altitude measures, but they still bothered me. I wanted to be able to put any target star close to the center of the camera FOV.
I eventually traced the problem to the cup/nut connection where I had put shims to increase the friction fit, but I later found that some of these shims had worked loose. I then bonded the cup to the nut with a flexible caulking and that has held well.
Page updated
Google Sites
Report abuse