Pergamon

Phys. Chem. Earth (A). Vol. 26, No. 6-8, pp. 645-648,2001 Q 200 1 Elsevier Science Ltd. All rights reserved 141%1895/01/$ - see front matter PII: S1464-1895(01)00114-4

A Binary Exchange Format for GPS Data

R Galas and W. Kiihler GFZ Potsdam, Division Kinematics & Dynamics of the Earth, Telegrafenberg A17, 14473 Potsdam, Germany Received 28 September 2000; accepted 20 January 2000

Abstract. Near real time monitoring of the quality of GPS data in a high rate & low latency GPS ground tracking network sets new requirements for data formats. At GFZ a compact binary exchange format for GPS data was developed for the level-l data products of the CHAMP mission. This new binary format preserves all the advantages of the widely accepted RINEX format, but avoids its limitations on the precision of the observables. It is receiver-independent, compact and can be easily extended to future observation types. A library for the GFZ-binex data handling, integrity checking and conversion from/to RINEX is available for public use. A more detailed description and up-to-date information on the development of this format standard can be found on the C&Z homepage 0 2001 Elsevier Science Ltd. All rights reserved httn://www.efz-notsdam,de/nbl/CHAMP/binex.htm.

1 Introduction The exchange of the GPS data between surveying agencies and scientific organisations operating different GPS receivers has became a time consuming procedure, since different receiver producers adopted their own format Consequently, a standards for internal data storage. number of authors proposed different standardised exchange formats for GPS geodetic data. Only one of these, RINEX, (proposed by W. Gurtner et al., 1990), received wide acceptance as an exchange format for geodetic GPS data. However, when preparing the CHAMP mission, it was found that RINEX does not meet all requirements for a GPS flight- and high rate ground data format. Three main flaws prevented the use of RINEX in the CHAMP mission and motivated the development of a binary exchange
Correspondence to: R. Galas

format for GPS data. These were: the limited precision of the observables (3 digits after the decimal point); the omission of some critical data, such as the channel numbers needed for monitoring the receiver performance; . signal to noise ratios converted to a scale other than that used internally by the receiver. Data products of the CHAMP mission are stored in the level-O and level-l archives of the Information System and Data Center. GFZ and JPL agreed to accept the Turbo Binary GPS data format for the level-O archive, to preserve the high accuracy of the observations, and to save hard disk space, the Turbo Binary data files are compressed with the tcomp utility (W. Kohler, 2001). For level-l GPS data a new format (described below) was proposed and accepted by the user institutions. UNAVCO also proposed its own BINEX format as a new standardised GPS data exchange format. Both standards preserve the full receiver accuracy, and both promise easy handling of the LEO GPS-data by Data Centers as well as having the potential for adding new data fields. In pursuit of similar goals, the IGS Low Earth Orbiter (LEO) Working Group recommended the development of a new format for the 1 Hz ground data and proposed the creation of a Format Subcommittee (LEO Working Group Draft Recommendations from 12 March 1999 Meeting at GFZ Potsdam).
l l

2 General remarks At an early point in the new formats development we realised at GFZ, that there are two basic requirements that the format must fultil. First, the format definition must be as simple as possible, to enable other software developers to write file-readers for their own applications, or to write converters to transform the data to other data formats (e.g. RINEX). Second, the philosophy and main structure of the RINEX format must be preserved. Moreover, the data

646

R. Galas and W. Kbhler. A Binary Exchange Format for GPS Data

should be stored as binary numbers in order to preserve the original accuracy of the measurements and to facilitate the combination of two or more parameters into one byte whenever possible and reasonable. During long years of application RINEX has proved its convenience over a long period of time and application and GPS users are already familiar with it. It was therefore decided to exclude some features from the new format definition, which may be helpful, but are not strictly needed. As a result, this new format may be defined as an extended or modified RINEX. To stress the similarity of the proposed format to RINEX, it has been named GFZ-BINEX (GFZ is added to distinguish from the earlier UNAVCO proposition). In accordance with the foregoing remarks, the new format
should:

be as receiver independent as RINEX; have basic similarities to RINEX; be binary; insofar as it possible, it should preserve all data from many different receiver types; be easily extendable. On the other hand, there are some features which the new format should not possess. For example, the new format
l l l l l

should not:
l

l l

include compression, since this is a task to be performed by another program, include data integrity checking (CRC), handle different types of endiness (big- or little-endian-formats) as there should be at least one hardware platfotm, which can read and write binary files without byte swapping (we prefer little endian, this means e.g. Intel).

3 Form& description Each GFZ-BINEX sections (Fig. 1). file comprises a header- and data-

File header

Header update (optional)

Fig. 1 General tile format As in RINEX, the ASCII header describes the global data and the record structure of the following data records in label: value. Each such string is the string form terminated by a new line character. The header has variable length and is terminated by the keyword string end of header. As in RINEX, the file-header appears not only at the beginning of the data file, but is repeated whenever the data block structure is changed. The header

section has an ASCII format in order to permit easy inspection of the file contents. The binary data section contains observables and other relevant information (e.g. Broadcast Ephemeris). Two main types of observables - integer and floating point are currently defined. Integer observables, such as signal to noise ratios (SNR), are stored as short integer (2 bytes) numbers. Floating point variables (phases, pseudo-ranges) are stored in double precision (IEEE 754) and have an additional flag byte (like RINEX LLI). The set of observables defined is easily extendable by following the rule that the storage format is to be derived from the observable name. The following naming rule has been adopted: The general pattern comprises three parts: XYn. X - the prefix portion, describes the type and scale containing L, P, C, D, S. Y - is composed of the observable detail, which may be omitted. n - is the suffix portion, 1 or 2 indicating the wavelength index. Where the prefixes correspond to: L - phases, measured in cycles; C, P - pseudoranges, in meters; D - Doppler frequency in HZ; S - signal to noise ratio (SNR) the units of which are receiver independent. Consist with RINEX, the usual observable names have been adopted to make them more easily extendable. The defined observation types and SNR-types are currently: Ll - phase measurements on the first frequency (C/A-phase in the Turbo Binary); - phase measurements on the second L2 frequency; - direct phase derived from Pl measurements LPl (Turbo Binary), - pseudorange using the CIA-code on the Cl first frequency; P 1, P2 - pseudoranges using the P-code; D 1, D2 - Doppler frequency on L 1 and L2, - SNR count for C/A code, SA Sl, s2 - SNR counts or signal strength for Ll and L2 P-code respectively. Two of them, LPl and SA, are new in comparison with RINEX 2.10. In order to distinguish between RINEX-scaled SNR values during conversion to/from RINEX (versions 2.0 and lower), and in order to preserve the original unchanged values (sometimes negative) negative values must also be admissible. The range -32758 to +32767 is reserved for the original SNR values. The value -32768 indicates that the SNR is not available. SNR numbers scaled according to the RINEX definition are mapped onto the range between -32767 and -32758. The data section is stored in binary little endian format. This means that in order to read or write the data on a computer with big endian format (Spare, etc.), the bytes of 2, 4 and g-byte values must be swapped. Single binary values may be read directly from BINEX-files on a little endian computer; however one must be careful that this
l l l l l l l

R. Galas and W. KGhler: A Binary Exchange Format for GPS Data

647

does not hold for C-structures (or similar constructs in any other language). This restriction is the result of the compilers requirement to align the data to 2, 4 or even 8 bytes (mainly for performance reasons). The binary format preserves the original accuracy of the observations, while keeping the file size compact and saving the CPU time required for read/write operations; however, data cannot be edited with ordinary file editors. We do not consider this to be a disadvantage of the proposed format, as large ASCII-files are not easily editable anyway. Therefore, for the users convenience the authors provide simple tools to permit file inspection. A more &tailed description of the GFZ-binex can be found under httn://www.rrfi-potsdam.de/pbl/CHAMP/binex.htm.

3.1 File header The file header begins with the string BNX (no termination byte), which serves as a file type indicator to allow readers to check for the correct file type. This is followed by a version- and spare bytes (Fig. 2). Both bytes are currently set to zero. Furthermore the header consists of an arbitrary number of records in an arbitrary

contrary to other proposals, it is thought to be sufficient to store the GPS-second as a 4 byte long word This means, the wrap around will occur 136.19 years after the start of GPS, i.e. sometime in 2116 A.D. Fractional parts of a second (time tag, clock offset) are stored as 4 byte fixed point data (long integer, divided by 231, thus having a resolution of 4.6* lO-10 seconds). The last byte in the epoch header represents either the number of satellites being observed at that epoch or an event flag. When positive, it shows for how many satellites data is stored in the current epoch body. A negative value indicates that the byte is an event flag. The event flag is defined as in RINEX, with one additional value (-7) indicating that the Broadcast Ephemeris parameters for a GPS satellite follows. Values from 0 to -127 allow for future extensions, e.g. An Almanac frame, and are currently not defined.

3.2.2 Epoch body. Each epoch body (Fig. 4) starts with a string of characters containing SV PR Numbers. Recognising that the channel number and the anti-spoofing (A-S) flag are both small, they are packed into one byte. Bits O-5 of this byte are reserved for channel number (set to 0 if not available),

Fig. 2 File header order. Every such record has a label (as in RINEX) and a value part. For easy parsing, 20 bytes for each label plus 1 termination character I:are used. The value part, which is also an ASCII string, has variable length and is terminated with a new line-character. Most labels resemble the labels of RINEX 2.10.
Channel numbers (Stringof unsignedcharacters)

Floatingpointobsewations 3.2 Data section Observations and associated information are stored in the data section, which (as in RINEX) has the structure of epoch-records. Each epoch-record consists of an epoch header and an epoch body. This facilitates concatenation or the splitting of two BINEX-files. However, compression of these records is more complicated than for track records. Fig. 4. Epoch body bit 6 indicates whether the A-S flag is known or unknown, and the MSB bit is set if the A-S is on. This channel string is followed by a set of SNR-numbers. Following these there is a set of floating point single observations. Both SNR- and single observations must appear in exactly the same order as defined in the file header strings labelled: # / TYPES OF OBSERV and # / TYPES SNR COUNT respectively. First all observations of the first satellite, then all observations of the second satellite etc. are stored.

3.2.1 Epoch header The epoch header (Fig. 3) carries information on the time tag, the clock offset and the number of satellites tracked.

3.2.2.1 Floating point single observation. Each single floating point observation (Fig.5) is associated

Fig. 3 Structure of an epoch-record. The time tag is split into an integer and a fractional part. Gf course, we use GPS time as time scale. However, Fig. 5 Single floating point observation.

648

R. Galas and W. Kiihler: A Binary Exchange Format for GPS Data

with a flag byte having the following meaning: bit 0 set : Observation invalid, no lock, bit 1 set : Loss of lock between previous and current observation (bit 0 in RINEX) bit 2 set : Inverse wavelength factor (bit 1 in RINEX) bit 3 set : Observation under Anti-Spoofing (bit 2 in RINEX) bits 5-7 : Spare bits, must be 0.
l l l l l

4. Software tools. To support potential users of CHAMP level-l GPS data products, a C-library of software functions for easy handling of GFZ-BINEX data has been developed and tested under the Linux and Solaris operating systems. Among other features, the library contains functions for the creation of data statistics, extraction of Broadcast Ephemeris, reading or writing of file headers and epoch headers, extraction of observations, byte swapping, data decimation, conversion to and from RINEX. The next library version will contain an efficient compression tool called bcomp (similar to tcomp compressing software), which is currently under development.

3.2.2.2 Broadcast Ephemeris Data Structure. To indicate that the Broadcast Ephemeris section follows, the event flag in the epoch-header must be set to -7.

5. Concluding

remark

Fig. 6 Broadcast Ephemeris data section. Time of transmission is accepted as the epoch of the observation. The first two bytes of the data section contain the SV PR Number. The parameters from the Subframe 1, 2 and 3 are stored in this section. The units and length of binary numbers are adopted according to the definition in the Interface Control Document GPS-200.

The proposed format has been used successfully in such the GFZ GPS High Rate Ground Tracking Networks as the GFZ Sub-Network for the CHAMP mission and the GFZ volcano deformation monitoring GPS array in Mexico.
References
Gurmer, et. al., Receiver Independent Exchange Format Version 2, Commision VIII, International Coordination of Space Techniques for Geodesy and Geodynamics, Vol. III, September-October 1990. Kiihler , W.. Compression algorithms for Turbo Binary GPS data, GFZ Scientific Technical Report, (in preparation), 2001.

Acknowledgement: The authors thank the reviewers and Peter Wilson for attentive and critical reading of the manuscript.