Subject: [IGS-RTWG-12] Availability of 5 sites from JPL in RTWG format
From: "Ronald J. Muellerschoen" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Date: Wed, 31 Mar 2004 01:22:16 +0000

******************************************************************************
IGS-RTWG Mail      30 Mar 17:22:19 PST 2004      Message Number 12
******************************************************************************

Author: Ronald J. Muellerschoen

To the RTWG:  March 30, 2004

Dear IGS Colleagues:

Contributing to the IGS real-time network infrastructure, we are pleased
to announce the availability of our real-time data server.   The format
and serves as our model was put forth by Ken MacLeod of Natural
Resources Canada ( NRCan ) in mail message [IGS-RTWG-7] "Real-Time Message
Format Version 1.0"

Available Records Types and Real-Time Sites
-------------------------------------------
Record types 100 and 200 are now available for 5 stations:

AMC2    67   Alternative Master Clock, Colordo Springs, CO, US
DLF3    71   Delft University, Netherlands
GOLD    32   Goldstone, CA, US
MADR    33   Madrid Spain
TIDB    34   Tidbinbilla Australia

Issue of Data Station (IODS) and Record Type 100
------------------------------------------------
All IODS integers are currently set to 1.  Since type 100 has not well been
established other than in principal, the specification we will use follows:

typedef struct IGS_100_payload {
   unsigned char sta_rec_type;  /* station data format ?            */
                                /* default to 0                     */
   char IGS_UniqueID[8];        /* char name, with null terminator  */
                                /* only 4 char name currently       */
                                /* then null padded                 */
   char *data;                  /* other                            */
                                /* with null terminator             */
} IGS_100_payload;

Record Type 100 will be issused every 60 seconds, with a random initial
offset time per site.

The sta_rec_type is currently not used, and is defaulted to 0.

The IGS_UniqueID is null padded with 4 leading characters, for example
'gold\0\0\0\0'

And data is also currently set to 'station tracking normal\0' for all
stations.

We will keep the IODS numbers updated should there be a
station configuration change, and pass on to the user in the data portion
of the 100 type payload a string description of the change.

Record Type 000
---------------

To allow easy access to the data, we have added a rec_id 000, which
is a request for data flow.  The complete format of this request including
the IGS RTWG header follows:

  IGS RTWG header
  ---------------
/* data is packed as big endian */
typedef struct IGS_header {   /* 11 bytes                           */
   unsigned short rec_id;     /* 000, 100, 200, 300, or 400         */
                              /* if 000, this is a request for data */
                              /* if 100, station id information     */
                              /* if 200, gps observable data        */
                              /* if 300, gps ephemeris data         */
                              /* if 400, met data                   */
   unsigned short sta_id;     /* unique IGS sta_id, for 100, 200,   */
                              /* and 400                            */
                              /* if rec_id 000, then this is also 0 */
                              /* if rec_id 300, then this is also 0 */
   unsigned long  GPSTime;    /* secs past 6 Jan-1990               */
                              /* current time for 000, 100, 300     */
                              /* time of observables for 200, 400   */
   unsigned short num_bytes;  /* bytes in this message              */
   unsigned char IODS;        /* Issue of data station flag         */
                              /* not used for type 000              */
                              /* not used for type 300              */
} IGS_header;

   JPL defined request for data payload
   ------------------------------------
typedef struct IGS_000_payload {
   unsigned char num_requested;     /* number of stations requested    */
   unsigned char *requested;        /* IGS station ids        */
} IGS_000_payload;

For example, to request data from stations 32(gold) and 34(tidb),
the user would send a big endian packed structure that in perl looks like:

   $rec_id = 0;       $sta_id = 0;
   $GPSTime = 0;      $num_bytes = 14;
   $IODS = 0;         $num_requested = 2;
   $requested1 = 32;  $requested2 = 34;
   $message = pack( "nnNnCCCC", $rec_id, $sta_id, $GPSTime, $num_bytes,
                     $IODS, $num_requested, $requested1, $requested2 );

This message would be then be sent to the listening port and IP as described
below.  After about 2 minutes, the data server will timeout unless a new
request
for data is received.     It is recommended that UDP request for data be made
every 30 seconds. It is not necessary to repeat requests for a TCP
connnection; timeouts are determined instead by broken connections.

We can also configure the data server to send RTWG data format without
requiring the user to send Record Type 0.  However this method is
not preferred from our operations.

Protocol and Ports
-------------------

The data server supports requests for both TCP and UDP.  For both protocols,
3141 is the only listening port.   The reply port to the user is determined
either from accept or recvfrom, rspt.  It is of course recommended that
port 0 be the sending port, in which case the O/S will make an ephemeral
port assignment.

Available IPs and Listening Port
--------------------------------
Queries for data can be sent to 216.116.102.232 or 64.239.128.174 at port 3141.
(64.239.128.174 may be currently firewalled blocked, but has better Internet
connections.  If you are having problems using IP 216.116.102.232, we can
open up the firewall to 64.239.128.174 on a per IP basis.)

Summary
-------
The JPL data server supports both TCP and UDP protocols.  It has adopted
and extended the format first put forth by NRCan.   It aims to
be user friendly and minimizes bandwidth in that the user can request a subset
of the available sites.  It will additionally advertise the available
sites with record type 100.

We hope that this data server assists in setting standards for a common
mode of distributive data distribution.  We request that the data obtained
by the JPL
data server not be redistributed.

best regards,

ron m.