[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[IGS-RTWG-5] Request for Comment
******************************************************************************
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