NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Software > ModificationRequest3C206

Changes | Index | Contents | Search | Statistics | Go

Correct OBSC_AZ, OBSC_EL in Antenna FITS file

Modification Request #3 (C2 2006)

• 1. Introduction
  • 1.1 Pointing Related keywords
  • Example:
  • Effects on Pointing
• 2. Design
• 3. Deployment Checklist
• 4. Test Plan
• Signatures

1. Introduction

1.1 Pointing Related keywords

There are two sets of Az,El coordinates that are recorded as a function of time in the Antenna FITS file table ANTPOSGR:

MNT_AZ  - Encoder Az indicated
MNT_EL  - Encoder El indicated
OBSC_AZ - Observed Az commanded
OBSC_EL - Observed El commanded

Also, there are four header parameters summarizing the scan:

SOBSC_AZ - Observed Az command at scan midpoint 
SOBSC_EL - Observed El command at scan midpoint 
SMNTC_AZ - Encoder Az command at scan midpoint 
SMNTC_EL - Encoder El command at scan midpoint

The (SOBSC_AZ, SOBSC_EL) values should be just the midpoint of (OBSC_AZ, OBSC_EL) arrays. And they appear to be correct to within a sample time. The (SMNTC_AZ, SMNTC_EL) values should be the midpoint of the (MNT_AZ, MNT_EL) arrays minus any errors in the servo. The (SMNTC_AZ, SMNTC_EL) appear to be incorrect by a significant amount (by as much as 3-4 arcsec). They can be directly compared to the Az,El commands in Antenna-AntennaManager-azElCommands.

The difference of (SOBSC_AZ, SOBSC_EL) and (SMNTC_AZ, SMNTC_EL) should be the contribution to pointing from the traditional pointing model, the local pointing corrections, the beam offsets, and the dynamic corrections. Since these parameters are used to determine pointing we could have an offset in the traditional pointing model. Moreover, if the error is not constant but is a function of Az,EL then we could be artificially degrading the accuracy of the pointing model.

I (Joe Brandt) looked into this issue a few months ago, and believe the difference is due to a 'time-shift' between the estimated commands at the mid-point of the scan (e.g. SOBSC_* and SMNT_*) and the actual values used to command the servo. The time shift of 300ms may be induced by the pipeline delay of commands going thru the antenna manager's velocity generator.

Example:

SDMJD   =     53783.8635532407 / MJD of scan midpoint
SOBSC_AZ=     300.000000000002 / Observed Az command at scan midpoint
SMNTC_AZ=     299.991264082683 / Encoder Az command at scan midpoint

The (az-related) columns from the data table are:

Note that SDMJD matches the timestamp of row 61, but the antenna OBSC (commanded values in observed az/el coordinates) passes the scan midpoint (exactly 300.0 deg) in row 58.

Effects on Pointing

The original problem was essentially the antenna was associating OBSC_AZ/EL values with the incorrect timestamp value. The position value intended for , was actually associated with . Stated another way:

where:

• is the astrometric position generating function to track a source in az/el coordinates
• is time
• are the positions generated and recorded in the OBSC_AZ/EL columns

This shift produced a reference source position which appeared to lead the true position of the source. In the case of a source in the South, where the sky moves from East towards the West, a the reference position would have been reported to be further West than the true position, as shown in the diagram below:

Since azimuth increases from East through South to West, to correct this the pointing reduction would produce an erroneous negative az1/az2 offset. When enabling the fix described in this MR, the reported reference position is shifted toward the East, removing the erroneous negative offset.

The same is true for sources in the North below the NCP. Here the sky moves West to East, but azimuth also increases from West through North toward East. Above the NCP, the effects are reversed, with azimuth corrections having an erroneous positive offset.

2. Design

To repair this problem, I have added a delay-line of the same duration as the velocity generator to keep all fields synchronized to the same timestamp.

To indicate the change, the antenna FITS file keyword FITSVER will be incremented to '2.8' to indicate the incorporation of this change.

3. Deployment Checklist

• Communication with Computing group needed? No.
• What documentation needs to be updated? Antenna FITS file specification.
• Training Needed? Is this being released to staff astronomers or everyone right now? No training required, community release.
• Notification Needed? TBD.

4. Test Plan

1. Setup the antenna to start a scan at 299.0, 15.0 with an az rate of 600min/min, and scanlength of 12 seconds. This should produce a scan which passes exactly 300.0 degrees six seconds into the scan. Take data with the telescope and archive the azElCommands.
   • Directly compare (SOBSC_AZ, SOBSC_EL) with (OBSC_AZ, OBSC_EL) in the Antenna manager FITS file.
   • Currently this is fine but we should check to make sure nothing has changed.
   • Verify that the OBSC_AZ field at the timstamp specified by SMJD is equal to the SOBSC_AZ value.
   • Verify that the first row value of OBSC_AZ is 299.0
2. Directly compare (SMNTC_AZ, SMNTC_EL) in the Antenna manager FITS file with the azElCommands in the archived file.

1. Astronomical tests:
   • Peak up with old and new versions on an astronomical source, and compare the different LPCs reported
   • Peak up with old and new versions, and then offset and track the half-power point of a bright source. This should look symmetric for the new version, asymmetric for the old version
   • These tests were briefly performed on Tueaday 7th March, but should be repeated.

Signatures

APPROVED: I acknowledge that my request is fully contained in this MR, and if the SDD delivers exactly what I specified, I will be happy.

ACCEPTED: I acknowledge that I have validated the completed code according to the acceptance tests, and I am happy with the results.

Written	- JoeBrandt - 23 Feb 2006
Checked	- RamonCreager - 23 Feb 2006
Approved by Sponsor	- DanaBalser - 14 Feb 2006
Approved by CCC	- RichardPrestage - 09 March 2006
Accepted/Delivered by Sponsor	- RichardPrestage - 09 March 2006

Symbols:

• Use %X% if MR is not complete (will display )
• Use %Y% if MR iscomplete (will display )

-- NicoleRadziwill - 14 Feb 2006

Attachment:	Action:	Size:	Date:	Who:	Comment:
Diagram1.png	action	1927	08 Mar 2006 - 15:14	JoeBrandt