Relation between coordinates parameters of the 30m telescope
SL, 06/2013.
Important preliminary remark: for now this page is a sand box where I gather various informations about coordinates variables generated by the 30m telescope control system, which may be useful for the implementation of a new instrument into the system
I gathered these information from various documents, Wiki pages (in particular https://mrtlx1.iram.es/mainWiki/AntennaMountDrive?highlight=%28CategoryNcs%29), and email exchanges with specialists of the 30m telescope. Ideally I would like that this page contains the list of the various coordinates values delivered by the telescope, with their descriptions and the relations between them. It would good also to centralizes here links to related documents and wiki pages.
Table of the coordinates parameters generated by the New Control System of the 30m telescope
In particular I list the variables from the antMD.trace category, that are also broadcast on the local network by the Elvin server. The correspondence with the parameters in the IMBFITS files recorded at the end of each scan, and the time stamp information and possibly units of these parameters are also displayed.
ATTENTION! The TimeStamp attribute in the table below gives the time when the message is generated inside the slow loop. So it is important to realize that this means TimeStamp is not the value of the time at which the parameters below (eg coordinates) are referring to; this temporal reference information is given by the MJD parameter, which is listed at a line of the table below.
antMD.trace. parameter name 
IMBFITS parameter name 
units 
Description 
time of validity of the value 

SITELONG 
rad or deg ? 
Telescope longitude 
static 

SITELAT 
rad or deg ? 
Telescope latitude 
static 

RXHORI 
radians ? 
Nasmyth offset in Pointing Model 
static 

RXVERT 
radians ? 
Nasmyth offset in Pointing Model 
static 

RXHORICO 
radians ? 
Nasmyth offset in Pako (user defined) 
static 

RXVERTCO 
radians ? 
Nasmyth offset in Pako (user defined) 
static 

P1 .. P6 
radians ? 
Pointing Model parameters 
static 

CTYPE1 
string 
Source coordinate system for BASELONG (e.g. AZ, RA, etc.) 
static 

CTYPE2 
string 
Source coordinate system for BASELAT (e.g. EL, DEC, etc.) 
static 

SYSTEMOF 
string 
System in which offsets (LONGOFF/LATOFF) are reported 
static 

LONGOBJ 
rad or deg ? 
Longitude of the source in the chosen coordinate system (RA or AZ etc.) 
predicted value at TimeStamp + 2s 

LATOBJ 
rad or deg ? 
Latitude of the source in the chosen coordinate system (DEC or EL etc.) 
predicted value at TimeStamp + 2s 
timeStamp 

seconds ? 
time at which the antMD message is sent 

slowRate 

Hz 
Frequency at which the coordinates data are generated 

LST 
LST 
seconds ? 
Local Sideral Time 
predicted value at TimeStamp + 2s 
MJD 
MJD 
days 
Modified Julian Day 
predicted value at TimeStamp + 2s 
paralact 
PARANGLE 
rad or deg ? 
Paralactic angle [VALUES ARE VISIBLY WRONG, would be good to go in the code, find how they are calculated and correct the mistake] 
? 
basisLat 
BASELONG 
radians ? 
Actual longitude in the chosen coordinate system (RA or AZ etc.) 
predicted value at TimeStamp + 2s 
basisLong 
BASELAT 
radians ? 
Actual latitude in the chosen coordinate system (DEC or EL etc.) 
predicted value at TimeStamp + 2s 
xOffset 
LONGOFF 
radians ? 
Scan pattern longitude offset from the source in SYSTEMOF (RA or AZ etc.) 
predicted value at TimeStamp + 2s 
yOffset 
LATOFF 
radians ? 
Scan pattern latitude offset from the source in SYSTEMOF (DEC or EL etc.) 
predicted value at TimeStamp + 2s 
actualAz 
CAZIMUTH 
radians ? 
"Commanded" azimuth (isn't it rather the wished azimuth before pointing model and refraction corrections ?) 
TimeStamp1s/slowRate 
actualEl 
CELEVATION 
radians ? 
"Commanded" elevation (isn't it rather the wished elevation before pointing model and refraction corrections ?) 
TimeStamp1s/slowRate 
trackAz 
AZIMUTH 
radians ? 
Real azimuth in the encoder reference 
TimeStamp1s/slowRate 
trackEl 
ELEVATION 
radians ? 
Real elevation in the encoder reference 
TimeStamp1s/slowRate 
SigTrAz 
TRACKING_AZ 
radians ? 
Azimuth RMS tracking error (sampling with fastRate = 128 Hz) 
TimeStamp1s/slowRate 
SigTrEl 
TRACKING_EL 
radians ? 
Elevation RMS tracking error (sampling with fastRate = 128 Hz) 
TimeStamp1s/slowRate 
MaxTrAz 

radians ? 
Azimuth Max tracking error (sampling with fastRate = 128 Hz) 
TimeStamp1s/slowRate 
MaxTrEl 

radians ? 
Elevation Max tracking error (sampling with fastRate = 128 Hz) 
TimeStamp1s/slowRate 
MinTrAz 

radians ? 
Azimuth Min tracking error (sampling with fastRate = 128 Hz) 
TimeStamp1s/slowRate 
MinTrEl 

radians ? 
Elevation Min tracking error (sampling with fastRate = 128 Hz) 
TimeStamp1s/slowRate 
Relation between the various coordinates variables
For simplicity I note Rot the rotation matrix which allows to switch from one coordinate system to another one, without specifying which are these coordinate system (to know this look at the values inside CTYPE1, CTYPE2 and SYSTEMOF) ==> this means that I do not distinguish between a rotation and its inverse operation, but the reader can figure out which is the direction of the rotation from the context. Note that Rot may use the paralactic angle, but since the value is wrong it can be recalculated using Az, El, and the Site Latitude.
I note PM the corrections from the pointing model applied to the wished coordinates, to build the commanded coordinates that will allow to point in the sky real coordinates that are as close as possible to the wished coordinates.
Also I don't write the transformation from one unit system to another (ex: rad to deg, etc.).
With this conventions we should have (TO BE CHECKED ON A FITS FILE AND/OR 30m EXPERTS [AS/WB/HU/RZ...]):
 [BASELONG; BASELAT] = [LONGOBJ; LATOBJ] + [LONGOFF; LATOFF]
[BASELONG; BASELAT](T2s) = Rot[CAZIMUTH; CELEVATION](T+1s/slowRate) ; Attention! The relation given here is what I think was the intention of people who created this set of coordinates, however as reported in the GISMONCSInterfaceandFITSFormatv0.5.pdf document, the experience of tracking errors with GISMO prior to 2012 indicates that some corrections are missing in [CAZIMUTH; CELEVATION], in particular the inclinometer corrections, and possibly other corrections...
[AZIMUTH; ELEVATION] = PM([CAZIMUTH;CELEVATION]) + [TRACKING_AZ; TRACKING_EL] ; As indicated also in GISMONCSInterfaceandFITSFormatv0.5.pdf they seem to be encoder values, not coordinates in the sky
Taking into account the remarks above and calling AZ and EL the real Azimuth in the sky and the real Elevation in the sky: [AZ; EL](T) = Rot[BASELONG; BASELAT](T2s) + [TRACKING_AZ; TRACKING_EL](T+1s/slowRate)