Check the pointing after the nov05 azimuth encoder failure
28jan06
The azimuth encoder failed on 14nov05. It was
reset using the index. A source was tracked after the fix and the azimuth
error had an offset of a few arcseconds. With a single source it is difficult
to separate out a model/source offset from an offset in the current position
of the encoder.
The pointing/calibration data from 20nov05
through feb06 was used to check the azimuth encoder offset. Only feeds
above 1 Ghz were used (lband and above).
The plots show the pointing
errors for the calibration data taken nov05-feb06 (.ps) (.pdf):
-
Fig 1 Pnt error by src: The colors/symbols show different
sources. This includes the data from all the recievers.
-
1st plot: Za error versus za.
-
2nd plot: Za error versus az.
-
3rd plot: Az error versus za.
-
4th plot: Az eror versus az.
-
Fig 2 Pnt error by receiver: The colors/symbols show different receivers.
These plots are ordered a little different than the first set: first by
za and then by az.
-
1st plot: Za error versus za.
-
2nd plot: Az error versus za.
-
3rd plot: Za error versus az.
-
4th plot: Az eror versus az.
The pointing errors are:
Axis |
mean offset [Asecs] |
rms [Asecs] |
Za |
-.05 |
5.7 |
Az |
.83 |
7.3 |
Conclusions:
-
There is no offset in the azimuth encoder.
-
It is interesting to note the structure in the azimuth error as a function
of azimuth. These are great circle errors so it is probably not an azimuth
encoder runout of the rack gear. These features have been present for awhile
(see model
15). The pointing model can not fit these variations. Hopefully
the azimuth encoder table would fix this.
processing: x101/050124/chkpnt.pro
home_~phil