Delivered-To: igs-rtwg@igscb.jpl.nasa.gov Message-Id: Date: Wed, 31 Mar 2004 01:22:16 +0000 To: igs-rtwg@igscb.jpl.nasa.gov From: "Ronald J. Muellerschoen" Subject: [IGS-RTWG-12] Availability of 5 sites from JPL in RTWG format Cc: robert.f.meyer@jpl.nasa.gov, Yoaz.Bar-Sever@jpl.nasa.gov, Kevin.J.Miller@jpl.nasa.gov Sender: owner-igs-rtwg Precedence: bulk ****************************************************************************** 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.