Delivered-To: igs-rtwg@igscb.jpl.nasa.gov Message-ID: <5ACEEE96F4F9D41190790002A528B51E56BDCE@s0-ott-x11.nrcan.gc.ca> From: "MacLeod, Ken" To: "'igs-rtwg@igscb.jpl.nasa.gov'" Subject: [IGS-RTWG-5] Request for Comment Date: Tue, 28 Oct 2003 15:13:55 -0500 Sender: owner-igs-rtwg Precedence: bulk ****************************************************************************** IGS-RTWG Mail 28 Oct 12:53:41 PST 2003 Message Number 5 ****************************************************************************** Author: Ken MacLeod, ken.macleod@nrcan.gc.ca Dear IGS Colleagues: To facilitate development of the RT-IGS we are requesting your comments concerning the proposed Message Protocol and the Data Format. The text below provides a very brief description of the proposed real-time messaging protocol and data record format. Later other documents will describe other aspects of the system for example, how to send data to a data centre/relay and how to request data from a data centre/relay. In order to get started with a real-time network as a minimum we need to specify the following: 1) Messaging protocol 2) Data Formats 3) Service standard Messaging Protocol At the last IGS workshop have agreed to a message interchange header format that would allow various real-time data servers to interchange data. So for example the Relay developed by NRCan could exchange data with the software developed by BKG or JPL. I'm not sure how well supported this header format is but it has been specified and is known. The following, lists the proposed message exchange protocol: 1) All RT messages must be encapsulated in the RT-IGS header mentioned above and discussed at the last IGS Work shop. 2) The real-time interchange of data is via UPD sockets. 3) All data is sent to the specified IP on the same port i.e. station, observation, eph and met data. Data Formats To facilitate orderly development every station contributing data to the RT-IGS will be assigned a unique numeric ID as well as the conventional IGS 4 character ID. It is assumed that the IGS Central Bureau will add this information to the station log and they will provide a list of all real-time stations containing information such as the numeric and character ID's etc. All the data exchanged in real-time should have a standard format (notice it is should have not must have). We propose record types for: Station Information, GPS Observations, GPS Ephemeris and Station Mets. These records are as described below in a C structure. /*************************************************************************** rtigs_records.h - description ------------------- begin : Wed Aug 27 2003 copyright : (C) 2003 by Ken MacLeod email : ken.macleod@nrcan.gc.ca. ***************************************************************************/ /*************************************************************************** * * * This program is free software; you can redistribute it and/or modify * * it under the terms of the GNU General Public License as published by * * the Free Software Foundation; either version 2 of the License, or * * (at your option) any later version. * * * ***************************************************************************/ #ifndef _RTIGS_T #define _RTIGS_T /*************************************************************************** ************************************** * RT-IGS record structures * * General: * * Every record will have a defined number. We propose the following: * 1) Station record number 100; * 2) Observation record number 200; * 3) Ephemeris record number 300; * 4) Meteorological record number 400; * * Every station will have a unique number. We propose the following: * * 1-99 reserved for JPL * 100-199 reserved for NRCan * 200-299 reserved for NGS * 300-399 reserved for ESOC * 400-499 reserved for GFZ * 500-599 reserved for BKG * 600-699 reserved for GEOSCIENCE AUS. * 700-799 others * etc * The number of bytes in each record will include the header as well as the data content * * All records will be related to a station configuration indicated by the Issue of Data Station(IODS) * This will enable the user to identify the equipment and software that was used to derive the data * * Each record header will contain the GPS Time in seconds which is continuous from ((6 Jan-1980)) * * The data payload of each record will consist of observations. Only a pointer is provided and the * developer will have to allocate the required memory. * * * All record data in network byte order, ie IA32 users will have to swap bytes ;-) **************************************************************************** ************************************* * Developed by Ken MacLeod Aug. 27/2003 * **************************************************************************** *************************************/ #define MAXSTA 256 #define MAXSOC 336 /* 16 * 21 = 336*/ #define MAXEPH 864 /* 12 * 72 = 960*/ #define MAXMETS 6 /*************************************************************************** ************************** * Structure name : RTIGSS_T * * Purpose: * * Encapsulate the station information that is critical for real-time users * * Users should use this record is to link data to a specific station configuration. * The station log should be transmitted by station operator every hour and upon update. * If the stations record Issue of Data Station(IODS) and the IODS on the observation * record do not match then the data cannot be used * * * This record is not intended to replace the IGS Station log but it is seen as a subset * of the log and contains information that is critical for real-time users. * *Version: 1.0 * *By Ken MacLeod Aug. 27/2003 *Changes: **************************************************************************** *************************/ typedef struct rtigs_station { unsigned short rec_id; /*100 indicates station record*/ unsigned short sta_id; /* unique number assigned to each station. Uniquely */ /* linked to an IGS Station log by the station record*/ unsigned long GPSTime; /* time of issue, GPS time is seconds from the beginning of GPS (6 Jan-1980)*/ unsigned short num_bytes; /* total number of bytes in the message*/ unsigned char IODS; /* a flag indicating the current station config this */ /* will change every time the sta config changes*/ unsigned char sta_rec_type; /* could be various station data formats*/ char IGS_UniqueID[8]; /* IGS ID eg NRC1 will use IGS 4 character standard*/ unsigned char *data; }RTIGSS_T; /*************************************************************************** ************************** * Structure name : RTIGSO_T * * Purpose : GPS Observations * Currently the JPL Soc format is used to compress the observation data. * See JPL's website for a description of the SOC compression routine *Version: 1.0 * *By Ken MacLeod Aug. 27/2003 *Changes: **************************************************************************** **************************/ typedef struct rtigs_obs { unsigned short rec_id; /*200 indicates rt-igs gps observation*/ unsigned short sta_id; /* unique number assigned to each station. Uniquely linked to an */ /* IGS Station log by the station record*/ unsigned long GPSTime; /* time of issue, GPS time is seconds from the beginning of GPS (6 Jan-1980)*/ unsigned short num_bytes; /* total number of bytes in the message*/ unsigned char IODS; /* a flag indicating the current station config that derived the observations*/ /* this will change every time the sta config changes*/ unsigned char num_obs; /* number of GPS Observations in data block*/ unsigned short GPSMilli; /* time of observation in Milliseconds past the second*/ short StaClock; /* approximate station clock solution in tens of metres*/ unsigned char* /* SOC formatted data*/ } RTIGSO_T; /*********************************************************************** * Structure name : RTIGSE_T * * Purpose : SV Ephemeris in Broadcast format parity removed * *Version: 1.0 * *By Ken MacLeod Aug. 27/2003 *Changes: ***********************************************************************/ typedef struct rtigs_ephemeris { unsigned short rec_id; /* 300 indicates rt-igs eph*/ unsigned short sta_id; /* unique number assigned to each station*/ unsigned long GPSTime; /* time of issue, GPS time is seconds from the beginning of GPS (6 Jan-1980)*/ unsigned short num_bytes; /* total number of bytes in the message*/ unsigned char IODS; /* a flag indicating the current station config that */ /* derived the observations this will change every time the sta config changes*/ unsigned char num_eph; /* number or eph records in data block;*/ unsigned char *data; /* Broadcast eph format with the parity bits removed 3 subframes = 72 bytes per eph*/ } RTIGSE_T; /*********************************************************************** * Structure name : RTIGSM_T * * Purpose : Station Meteorological observations * *Version: 1.0 * *By Ken MacLeod Aug. 27/2003 *Changes: ***********************************************************************/ typedef struct rtigs_mets { unsigned short rec_id; /* 400 indicates rt-igs eph*/ unsigned short sta_id; /* unique number assigned to each station*/ unsigned long GPSTime; /* time of issue, GPS time is seconds from the beginning of GPS (6 Jan-1980)*/ unsigned short num_bytes; /* total number of bytes in the message*/ unsigned char IODS; /* a flag indicating the current station config that derived */ /* the observations this will change every time the sta config changes*/ unsigned char numobs; /* if only temp, press, rel humidity then 3 */ long mets[3]; /* temp(Deg C), press (mb), rel humid(%), */ /* zenith Wet(metres), Zenith Dry(metres), Zenith Total(metre) */ /* and each scaled by 1000 so 1000.123 mb = 1000123*/ /* if the zenith observations are not present only enter 3 in the number of obs.*/ } RTIGSM_T; #endif The RTIGSS_T (Station record type) contains the RT-IGS numeric station ID and an Issue Of Data Station (IODS) key/flag that is used to link station observations to a specific hardware and software configuration. For example, when a GPS receiver is replaced the Issue of data station (IODS) is changed (increased by one) and the IGS station log is updated. A change in the IODS serves as notice to the consumer of the data that they should consult the IGS station log. The RTIGSO_T (Observation record type) contains a link to the station via the RT-IGS identifier and IODS. We are currently using/proposing JPL SOC data compression routine. This routine compresses the data to 21 bytes per satellite and the accuracy of the observations is maintained. The SOC compression routine is defined on JPL's web site. NRCan has C++ code that converts AOA TBIN and Ashtech MBEN data to SOC. This code can be made available to all RT-IGS participants. The RTIGSE_T (Ephemeris record type) also contains the RT-IGS identifier and the IODS that links the data to the station and configuration. The ephemeris format that is proposed is the broadcast format with the parity bits removed. To facilitate adoption of this format there are C++/C functions that translate Ashtech SNV formats to the proposed RT-IGS format. Again this code can be made available to all RT-IGS participants. Lastly, the RTIGSM_T (Meteorological recode type) also contains the RT-IGS identifier and the IODS. The currently proposed met. record type only contains the station temperature, pressure and relative humidity(scaled by 1000 to fit a short). Service Standard The frequency of the issue of the data is up to the station operator but in general the following is recommended: 1) Station records issued once per hour and upon update. 2) Observation records every second on the GPS second 3) Ephemeris records upon update 4) Met data every 5 minutes. If you have comments or suggestions changes please contact either Mark Caissy or Ken MacLeod Best Regards Ken