-- MicheleDeLaPena - 04 Jan 2007

---

Table of Contents

---

Characterization of the Pointing Control System (PCS) Mount Polynomials

As part of an on-going effort to understand fully the nature of the Telescope Control System (TCS) components, the polynomials generated for the azimuth and elevation axes of the mount are being analyzed in detail. The dataset consists of the operating system timestamp, and the second order polynomial coefficients and associated MJD (TAI) for an LBC Blue observing run done on 25/26 December 2006 (lbcb.20061226.060241). The specific focus of the analysis was looking for glitches in the functions which could account for "jumps" seen in the acquired images. I note that no glitches were found that would account for the jumps. Since this analysis is based upon one dataset, it does not cover the full parameter space (extremes in elevation, varying pressure, etc.) which should be done for a full parameterization of the PCS polynomials.

PCS Update Cycles

The PCS contains three update threads: slow, medium, and fast. The slow thread runs approximately every 60s and is used to compute the refraction constants, based upon updated weather information, and a new precession matrix; this thread is implemented in the AtmosphereUpdater class of PCS. The medium thread runs approximately every 5s and is used to update the sky patch matrices (approximation to the transformations between astrometric and observed locations for a limited region of sky) and re-evaluate the pointing model; this thread is implemented in the SkyPatchUpdater class. Finally, the fast thread runs approximately every 50ms and is used to compute the position demands for the mount; this thread is implemented in the TrajectoryGenerator class. All timestamps associated with the demands (i.e., polynomials) as seen external to the PCS are in MJD seconds using the TAI timescale.

It should be noted the update cycles in PCS are not driven by interrupts. Rather the cycles are infinite "while" loops running inside independent threads; the loops run continuously. The timing of the update is controlled by checking the current time against the computed "end time" for the given cycle. If the current time is less than the "end time", the execution will sleep for one machine tic and recheck the time. The goal is to get within 1ms of the 50ms timing; once this is achieved, the loop continues. If the current time is greater than or equal to the "end time", the loop immediately continues.

Analysis

Operating System Timestamps

Since any subsystem may be sharing its server with other subsystems, there can be significant load on the server. Although the TCS is not a real-time system, there is a need for the PCS to generate the mount polynomials in a timely manner. If the mount control system processing unit (MCSPU) does not receive any valid polynomials from the PCS for one minute, the MCSPU will issue a "hold". As stated above, the PCS fast loop executes on an approximate 50ms cycle. Part of this analysis included examination of the operating system timestamp for every transit through the loop. The Figure below shows the results of this analysis. A simple point-by-point difference of the operating system timestamps was done and plotted against sample number. As can be seen in the plot, the loop executes approximately every 50ms with random deviations as would be expected given the implementation of the timing loop.

Polynomial MJD (TAI) Timestamps

A similar analysis as done for the operating system timestamps was done for the MJD (TAI) timestamps associated with each polynomial. It was anticipated these timestamps would exhibit similar behaviour to the operating system timestamps. However, this was not the case! The Figure below shows the results of the point-by-point difference in MJD (TAI) timestamps.

There are four main issues that can be observed in this graph.

1. There are four apparently random instances in this dataset where the timestamps and associated polynomial coefficients are identical; the corresponding operating system timestamps verify that the identical timestamps and associated polynomial coefficients are generated by consecutive update cycles.
2. The thick dark line in the middle of the graph is the approximate 50ms update time. While the median value of all the differences is 5.011177062988281e-02, close examination of the region reveals the data are quantized with five distinct update times represented: 0.05011081, 0.05011177, 0.05011272, 0.04924774, and 0.04924869. There is a periodicity with respect to the occurrence of the values.
3. There are instances where the pointing kernel acts as though it has missed a 50ms cycle, and the MJD (TAI) timestamp is on the order of 100ms different from the previous value. However, the corresponding operating system timestamps verify that the polynomials/timestamps are actually generated by consecutive 50ms update cycles.
4. For the instances where the MJD (TAI) timestamps are on the order of double the expected 50ms cycle, the actual values are quantized: 0.09935951, 0.09936046, 0.10022354, and 0.10022449.

Position Coefficients

The polynomial position coefficients were examined for discontinuities.

Elevation

The first of the three figures below shows the elevation position coefficients as a function of MJD (TAI) (s). The data were fit with a 5th degree polynomial, and the residuals are displayed in the lower graph.

• Fit to the elevation position coefficients and the associated residuals.
  

The zoomed view of the residuals of the elevation position coefficient fit reveals interesting details.

• The rectangle encapsulates data values which correspond to the five second, sky patch update cycle.
• The small "steps" correspond to the 50ms trajectory update.
• It is not known what is causing the "sawtooth" nature of the position values.

• Zoomed view of the elevation position coefficient fit residuals.
  

Azimuth

The first figure below shows the azimuth position coefficients as a function of MJD (TAI) (s). The data were fit with a 5th degree polynomial, and the zoomed residuals are displayed in the second figure.

• Fit to the azimuth position coefficients and the zoomed residuals.
  

The zoomed view of the residuals of the azimuth position coefficient fit reveals interesting details.

• The rectangle encapsulates data values which correspond to the five second, sky patch update cycle. However, the five second cycle is not obvious in this data.
• The small "steps" correspond to the 50ms trajectory update.
• It is not known what is causing the "sawtooth" nature of the position values.

Velocity Coefficients

The polynomial velocity coefficients were also examined for discontinuities.

Elevation

The first figure below shows the elevation velocity coefficients as a function of MJD (TAI) (s). The data were fit with a 4th degree polynomial, and the residuals are displayed in the second figure.

• Fit to the elevation velocity coefficients and residuals.
  

The zoomed view of the residuals of the elevation velocity coefficient fit reveals interesting details.

• The small "steps" correspond to the 50ms trajectory update.
• It is not known what is causing the "sawtooth" nature of the velocity values.

• Zoomed version of residuals of the fit to the elevation velocity coefficients.
  

As a consistency check, the elevation position coefficients were used to compute "manually" the velocity values. This was done simply by computing Position(i+1) - Position(i) (e.g., the rise) and dividing by Time(i+1) - Time(i) (e.g., the run) for 1 <= i <= No_Values_In_Array. The next graphic shows the results. The data displayed in yellow are the point-to-point computed values; the blue curve represents the velocities as they are computed by the pointing kernel. The results are as expected; the pointing kernel velocity values are within the noisier manually computed velocity value envelope.

• Comparison of "manually" computed elevation velocities versus the pointing kernel generated velocities.
  

Azimuth

The first figure below shows the azimuth velocity coefficients as a function of MJD (TAI) (s). The data were fit with a 4th degree polynomial, and the zoomed residuals are displayed in the second figure.

• Fit to the azimuth velocity coefficients and the zoomed residuals.
  

The zoomed view of the residuals of the azimuth velocity coefficient fit reveals interesting details.

• The small "steps" correspond to the 50ms trajectory update.
• It is not known what is causing the "sawtooth" nature of the velocity values.

As for the consistency check, the azimuth position coefficients were used to compute "manually" the velocity values. This was done as for the elevation values by computing the rise / run for 1 <= i <= No_Values_In_Array; the following figure shows the results. The data displayed in green are the point-to-point computed values; the blue curve represents the velocities as they are computed by the pointing kernel. The results are as expected; the pointing kernel velocity values are within the noisier manually computed velocity value envelope. It is interesting to note the pointing kernel values distinctly reside to one side of the computed distribution.

• Comparison of "manually" computed azimuth velocities versus the pointing kernel generated velocities.
  

Acceleration Coefficients

Finally, the polynomial acceleration coefficients were also examined for discontinuities.

Elevation

The first figure below shows the elevation acceleration coefficients as a function of MJD (TAI) (s). The data were fit with a cubic, and the residuals are displayed in the second figure. The zoomed view of the residuals of the elevation acceleration coefficient fit did not reveal any interesting details, and the data are not shown here.

• Fit to the elevation acceleration coefficients and residuals.
  

Similar to the consistency check done for the velocity values, the elevation velocity coefficients were used to compute "manually" the acceleration values. This was done simply by computing Velocity(i+1) - Velocity(i) (e.g., the rise) and dividing by Time(i+1) - Time(i) (e.g., the run) for 1 <= i <= No_Values_In_Array. The next graphic shows the results. The data displayed in yellow are the point-to-point computed values; the blue curve represents the acceleration values as they are computed by the pointing kernel.

• Comparison of "manually" computed elevation acceleration coefficients versus the pointing kernel generated accelerations.
  

The results are not as expected! The acceleration values as provided by the pointing kernel do not agree with the manually computed values. The curves are the same order of magnitude, but the values are clearly different. Moreover, the curves are not different by a simple scale factor.

Azimuth

The first figure below shows the azimuth acceleration coefficients as a function of MJD (TAI) (s). The data were fit with a cubic, and the residuals are displayed in the second figure. The zoomed view of the residuals of the azimuth acceleration coefficient fit did not reveal any interesting details, and the data are not shown here.

• Fit to azimuth acceleration coefficients and residuals.
  

Similar to the consistency check done for the velocity values, the azimuth velocity coefficients were used to compute "manually" the acceleration values. This was done as for the elevation values by computing the rise / run for 1 <= i <= No_Values_In_Array; the following figure shows the results. The data displayed in yellow are the point-to-point computed values; the blue curve represents the acceleration values as they are computed by the pointing kernel.

• Comparison of "manually" computed azimuth acceleration coefficients versus the pointing kernel generated accelerations.
  

The results are not as expected! The acceleration values as provided by the pointing kernel do not agree with the manually computed values. The curves are the same order of magnitude, but the values are clearly different. Moreover, the curves are not different by a simple scale factor.