az encoder 1 jumped 12aug19
190913
Other links
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.
Plots of pointing
error 12aug19-10sep19 (.ps) (.pdf)
- 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).
The plots show the
azimuth encoder difference for 1-26 aug19 (.ps) (.pdf)
- 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
<-
page up
home_~phil