Station Software Methodology

All station code is kept under SCCS revision control. Realtime code unique to the station is kept in one SCCS area. Real-time code which must be changed when VLBA code is changed is kept in another area. Offline code is kept is an separate area, but if offline programs use functions in real-time modules, those modules are kept in the Realtime SCCS area. Finally the code which is unmodified from the VLBA is kept under SCCS control at the AOC in Socorro. A complete copy of a recent version of the VLBA code is kept online. The are four major code types distinguished.
Station unique
Code which was written in Green Bank and has no use at the VLBA.
VLBA changed
Code which is slightly modified from the VLBA code due to differences in the station hardware from VLBA antenna hardware. This code must be examined each time the latest version of VLBA code is retrieved.
VLBA unchanged
Low level functions for VLBA hardware control and for the operator interface package, SCREENS. These modules are completely replaced each time a new release of the VLBA software is retrieved.
modules to read and write the files for interfacing to other mission elements. A majority of these modules contain phase residual and log processing utilities.
NAIF toolkit
Only the offline program ORBITCO is written in fortran, to allow easier linking to the JPL Navigation Ancillary Information Format (NAIF) subroutines, which are written in fortran. The NAIF package has been updated very rarely (once in 4 years).
The use of SCCS allows the software for any date and time to be completely re-created, using the correct "makefile". In addition to SCCS, three complete versions of the station realtime code are kept:
Test version of the software. The new version of the code are first run during non-critical tracking passes.
Reliable version of the software. This version is also kept on the station realtime hard drive.
Obsolete version, kept for diagnostic comparisons with code.

VxWorks coding style

Instead of developing our own coding style, we mostly adopted the coding style proscribed in the VxWorks Programmers Guide. In addition, we adopted a standard set of SCCS macros and module description conventions. Some coding conventions are given below: A number of coding conventions are used, including also always adding a comment at every closing }. A few
Each module contains a leading set of comments containing SCCS keywords (ie %M%, version %R%.%L%). The module should have a one line description and a line indicating the module type (offline/realtime). There is a HISTORY section listing the latest changes first. If the history section gets excessive, older entries are removed. Finally, the preamble ends with a short description of the functions in the module.
2 space indenting for code in {}
The capitalization style recommended in the VxWorks programmers guide is adopted. All words in a variable name are capitalized, except for the first word (ie angularDistance).
comments at }
All closing } should have a comment indicating the intended opening { it matches.
comment alignment
It is preferred that comments all start in the same column or columns.
defined parameters in the code are all capitalized (ie TWOPI).
A short example is listed below:
/* File %M%, version %R%.%L%, released  %E% at %U% 
   retrieved by SCCS %D% at %T%     

%% function to calculate the angular distance between to angular coords

:: GBES-C realtime/Offline
  970626 GIL fix comments
  960719 GIL handle case of round off for arcCos (1.+EPSILON)
  940921 GIL initial version
Take any two pairs of angular coordinates and calculate the exact
angular distance between them.  (inputs can be az,el pairs, ra,dec pairs
or glat,glon pairs, but can not mix az,el and ra,dec etc).

#include "math.h"
#include "MATHCNST.H"   /* Mathematical constants. */

double angularDistance( double raA, double decA, double raB, double decB) 
/*  *    *    *    *    *    *    *    *    *    *    *    *    *    *    *  */
/* calculate the angular distance between two points                         */
/* INPUT raA, decA are the location of point A (radians)                     */
/* INPUT raB, decB are the location of point B (radians)                     */
/* OUTPUT angular distance between them (radians) is returned                */
/*  *    *    *    *    *    *    *    *    *    *    *    *    *    *    *  */
{ double dRa = raA - raB, cosDistance, distance;
  double cosA = cos( PIOVR2 - decA), cosB = cos( PIOVR2 - decB);
  double sinA = sin( PIOVR2 - decA), sinB = sin( PIOVR2 - decB);

  cosDistance = (cosA*cosB) + ( sinA*sinB*cos( dRa));

  if (cosDistance < -1.)               /* handle precision problems */
    distance = PI;
  else if ( cosDistance > 1.)
    distance = 0.;
    distance = acos( cosDistance);     /* normal calculation */

  if (distance < 0.)                   /* if negative distance */
    distance = -distance;              /* convert to positive */
} /* end of angularDistance */

VLBA Code Style

The VLBA coding style for supporting hardware modules was also adopted. This style is not clearly documented but generally consisted of creating a single software module for SETting all hardware states and another software module for GETting all hardware states for any individual hardware device. (ie getfmt.c and setfmt.c for getting and setting the formatter status).

These communication functions utilized some other modules which perform utility calculations, such as conversion from ascii strings to hardware units etc (ie string str2mode converts string "VLBA1:1" to bits in a 16 bit word). The same set and get functions are used by higher level operator "SCREENS", by the OBSERVE system, and the monitor functions.

Return to the Station Software Guide. The National Radio Astronomy Observatory (NRAO) is a facillity of the National Science Foundation operated under cooperative agreement by Associated Universities, Inc.
Last update: 97 July 1