# az encoder 1 jumped 12aug19

#### 190913

azimuth encoder failures

# Pointing errors show the jump

Azimuth encoder 1 (dome side) is used to point the azimuth. It jumped by 1tooth on 12aug19.

### x102 runs show az error vs za.

x102 calibration runs in late august and early sep19 showed a linear azimuth error vs za. The problem was resolved on 11sep19.
• Page 1:
• top 2 frames show za error vs  za and azimuth
• bottom 2 frames show azimuth error vs za and azimuth
• Each color is a different receiver
• black: lbw, red: sbw,sbn, green: sbh, blue: cband
• The symbols are for different sources.
• The mean za error is -4.09 asecs
• The mean Az error is -22.55 asecs
• Looking at frame 3, you can see a linear ramp of  az error vs za.
• Page 2 Linear fit to az error vs  za
• A linear fit was done to az error vs za.
• the fit was:
• azErr=1.367 - 1.861 * za (asecs)
• At za=20 degrees the error is about -35 asecs,.
An azimuth encoder error will give an almost linear sky azimuth error vs za since:
•  skyAzimuthError(greatcircle)= sin(za)*AzEncoder error.

The sin function is almost linear in its argument for small values.

### Correcting the error.

The pointer, scriber mark:

• There is a scribe mark on a plate on the fixed part of the platform where the azimuth (gregorian side) equals 270 degrees.
• a retractable  pointer is mounted on the encoder platform (gregorian size).
• When the azimuth encoder reads 270 degrees, the pointer should align with the scribe mark.
• this was developed to recover the azimuth position whenever an encoder problem arose.
• If we have an encoder problem:
• move the pointer to the scribe mark and then reset the encoder to 270 degrees.
• We can probably reset the position to about 1/64". at the 60 foot radius of the scribe mark this is about 1.2 milliDeg, or about 4asecs.
• The system is calibrated using the pointing model.. the sequence is:
• before a new pointing model is made
• move the azimuth to 270 degrees (using no pointing model corrections)
• Make sure the pointer is aligned with the scribe mark
• If it is not aligned:
• move the pointer to the scribe mark
• reset the encoder to 270
• Take a picture of the pointer,scribe mark for later reference.
• Make the new pointing  model.
• If the pointer / scribeMark was not pointing at true 270 degrees, the pointing model will correct for it.

On 11sep19 at 14:00 osvaldo and adrian  checked the scribe mark/pointer and found that it was off
the pictures show before and after the adjustment

When repositioning the pointer,

• i moved the azimuth by .02 degrees to line up the pointer with the scribe mark (before the encoder was reset).
• a .02 degree encoder error at za=20deg  would be 24.6 arcseconds...
• The linear fit to the pointing errors gave 35 asecs.
• Being off by 10 asecs is a position error of 1/32"
• I don't have a picture of where the pointer was aligned before the last pointing model
• The position of the pointer will move a little if the dome is at a different za.

### When did the jump occur

Looking at the x102 data, the first bad az error point was on 12aug19. To verify this is used the azimuth encoder difference.

There are two encoders on the  azimuth arm

•  1 on the dome side,
•  1 on the ch side
• Their difference is used to measure the azimuth arm bending
• Only the dome side encoder is used for pointing.
•  (this is to measure azimuth arm bending.. only the dome enc is used for pointing).
• Page 1: 01-26aug19 az encoder difference
• Top: 10aug19 encoder difference
• The black dots show the azimuth encoder difference vs az for the entire day
• the red line is the average  for the day.
• There is lots of spread in the azimuth encoder difference,.
• It depends on the direction and velocity that the azimuth arm
• Bottom daily average 1-26 aug19
• The black traces are the daily averages for 1-11 aug19
• The green traces are the daily averages for 13-26 aug19
• the red trace is the daily average for 12aug19
• you can see that there was a jump in the 12aug19 data.
• note: i left out 27-31 aug19 since the vertex system was turned off when hurricane dorian passed by.
• Page 2: encoder difference for 12aug19
• Top: encoder difference for hr of day
• I've removed the daily average to make it a little clearer.
• You can see a jump between 0 and 1 hours
• Bottom: blowup 0 to 1 hours
• the red line shows the jump at 00:21:30 12aug19.
• The jump occurred at az=352.86 while the az was moving at -.42 deg/sec (slew rate)
• The jump is the expected .02 degrees.

### Summary:

• azimuth encoder 1 (dome side) jumped by 1 tooth (.25" or .02 degrees azimuth) on 12aug19 @ 00:21:30
• The jump occurred at az=352.66 while it was moving at -.42 degs/sec (slew rate).
• the encoder jump was corrected on 11sep19 at 14:00
• After correcting the encoder, we spun the azimuth 360 degrees to look for any problems in the  encoder rack gear.. none were found.
• There was only one jump during the month so it was not a repeatable  problem in the encoder rack gear
• between 12aug19 and 11sep19 (morning) there was an extra pointing error in azimuth:
• a linear ramp  0 to -24 arc seconds  going from za =0 to 20 degrees
• The x102 pointing actually showed an error of 0 to -35 arcseconds.
• I should have caught this error sooner.. my excuses are:
• during aug19 i didn't do a lot of sources that were tracked rise to set at high za (high or low dec)
• On 21 aug19 there were enough sources to say there was a problem.
• during the first part of sept, lots of 430,327 runs were done .
• 327 and 430 are not usually very reliable for pointing.
• Excuses aside, i think i should  plot the average azimuth encoder difference each day.
• This might show   a jump (like it did on 12aug19.

processing: x101/190911/azpnterr.pro