RTCM2ASC rel 1.0

This document describes the design and use of the DOS program RTCM2ASC.
The program converts the binary RTCM format into an ASCII format that can be read by mathematical tools like Matlab^TM.
RTCM2ASC operates in a batch processing mode where the RTCM messages are read from a binary file and converted to ASCII format.

Input: Binary file containing RTCM messages
Output: Text files for each message type in ASCII format

Release 1.0 currently supports message types 1, 2, 3, 6, 16, 18 and 19 but can be easily modified to include other types and functionalities should the need present itself.

Input file

Some restrictions apply to the input file:

Filename must be "rtcmout.bin"
Each RTCM message must be on a seperate line. This means the binary sequence must be terminated by a "carriage return" and a "line feed" char (CrLf)
Use the "6-of-8" bitpacking method (described below under The RTCM standard)
Otherwise follow the RTCM standard as described in the official documentation¹

When using the Z-12 receiver from Ashtech to generate RTCM corrections it is possible to define the terminating symbols as either CrLf, Cr or none². The program can be easily rewritten to use any other termination string, but it will require substantial extra code to allow for unterminated messages.

An example of a valid input file can be found here: rtcmout.bin

Output files

The text files generated by the program will be named mtype1.txt, mtype2.txt and so forth and placed in the same directory as the program and input file resides.
This means a seperate file will be generated for each message type. If a supported message type is not found in the input file the corresponding text file will be empty.
By use of command line arguments it is possible to determine exactly which part of the RTCM data that should be stored in the output files. Hence the exact structure of the output depends entirely on these arguments.
Each line (or row) in the output file corresponds to a single RTCM message and each column represents a particular piece of data from this message.
If the number of satellites change within the file so will the number of columns, and special care must be taken when using the data in programs such as Matlab that require a constant number of columns and rows.

An example of some output files can be found here: mtype1.txt, mtype2.txt and mtype3.txt

Note: These output files were generated from the above input file using the "-default" command line argument.

The RTCM standard

The message format is illustrated in figure 1.1:

Fig 1.1: The thirty-bit GPS word
Each message consists of two or more thirty-bit words. The first two words of any message contains the header information which is common to all message types.
Of the thirty bits, 24 carry the data and 6 are used for parity. The parity algorithm used is identical to the one used in standard GPS data transmission³. This means that for each word to be decoded correctly bits 29 and 30 from the previous word must be known, which poses some initialization problems.
When these thirty-bit words must be represented in an eight-bit environment a special "6 of 8" format must be used. Each byte contains 6 bits from the GPS word, setting the remaining 2 bits "marking" and "spacing" respectively (1 and 0) as shown in figure 1.2:

Fig 1.2: The five byte representation using the "6 of 8" format
The RTCM standard specifies that the bits must be ordered according to the "Most Significant Bit First Rule" whereas the ANSI X3.15-1976 standard requires the bits to be arranged according to the "Least Significant Bit First Rule". This results in a "byte roll" where the order of the bits within the byte is reversed.
As a result of the "6 of 8" format each GPS word takes up 5 bytes which means the entire message must have a size which is a whole multiple of five.

Program design

A simplified structure of the program is shown in figure 1.3. Basically the program consists of two loops. The first (outer) loop reads one line in the input file at a time, and starts right after the input/output files have been opened for reading/writing.
Each line of input corresponds to an RTCM message, and by reading the header information it is possible to determine how many bytes to decode in each message. Also, the message type is encoded in the header and from this information it is possible to call the correct function to decode a particular message. Should it prove necessary to extend the program's capability with other message types, this modular structure ensures that this task will require a minimum effort.

Fig 1.3: The program structure
The second (inner) loop performs the actual decoding of the message by assembling five bytes into a GPS word and converting the binary format into ASCII.
Some error checks and warnings are built into the program. If the length of a given message is not a multiple of five an error message is produced. This often happens when some transmission errors have occured during the creation of the input file from the RTCM output of the receiver, and some part of the message has been lost.
If the program encounters a message type which is not currently supported a warning is issued on the screen stating the type of message and line number. This as well arises as a consequence of partly received messages. As the decoding depends of the parity of the previous message, a transmission error will also affect subsequent data. A hint of this might be that messages are reported as there bitreversed counterparts (e.g. 1 -> 63, 2 -> 62, 18 -> 46 and so on ...) a result of incorrect parity removal.

Command line parameters

To control exactly which part of the data should be saved to file a whole array of command line arguments can be used when calling the program. Each type of data is set by a specific flag. Table 1.1 shows the complete list of data accessible from the currently supported message types. Also shown is the flag to use and the type of message in which the data is located.

Name	Message	Flag
PREAMBLE	All	`-pre`
FRAME ID/MSG TYPE	All	`-mtype`
REFERENCE STATION ID	All	`-refid`
MODIFIED Z-COUNT	All	`-zcount`
SEQUENCE NO.	All	`-seqno`
NO. OF DATA WORDS	All	`-length`
STATION HEALTH	All	`-health`
SCALE FACTOR	1,2	`-factor`
UDRE	1,2	`-udre`
SATELLITE ID	1,2,18,19	`-prn`
PSEUDORANGE CORRECTION	1	`-prc`
RANGE-RATE CORRECTION	1	`-rrc`
ISSUE OF DATA	1,2	`-iod`
DELTA PSEUDORANGE CORRECTION	2	`-dprc`
DELTA RANGE-RATE CORRECTION	2	`-drrc`
ECEF POSITION	3	`-xyz`
GPS SPECIAL MESSAGE	16	`-msg`
FREQUENCY INDICATOR	18,19	`-freq`
GNSS TIME OF MEASUREMENT	18,19	`-extime`
MULTIPLE MESSAGE INDICATOR	18,19	`-multi`
C/A-CODE / P-CODE INDICATOR	18,19	`-pca`
GPS/GLONASS SATELLITE INDICATOR	18,19	`-gpsglo`
DATA QUALITY	18,19	`-dqual`
CUMULATIVE LOSS OF CONTINUITY INDICATOR	18	`-cslip`
CARRIER PHASE	18	`-phase`
SMOOTHING INTERVAL	19	`-smooth`
MULTIPATH ERROR	19	`-mpe`
PSEUDORANGE	19	`-pr`

Table 1.1: An overview of the command-line arguments available
If no arguments are used a special help screen is displayed containing the same information as in table 1.1.
To avoid incorrect parity removal of the first message the previous (and unknown) parity bits 29 and 30 can be set directly using the flag "-pXY" where "X" and "Y" is either 0 or 1. E.g. "rtcm2asc.exe -p01" sets bit 29 to "0" and bit 30 to "1".
A special "-default" flag is offered to include only the data which is of general interest:

Modified Z-Count
Satellite ID number
Pseudorange corrections
Range-rate corrections
Delta Pseudorange corrections
Delta Range-rate corrections
Uncorrected Pseudranges
Uncorrected Carrier Phases
ECEF Position
Special GPS message

To Do's

During use it has become evident that some minor improvements would greatly increase the usability of this program. Because of time constraints these have not been incorporated into this first release but are listed here for future reference.

Make GUI and build it into a Windows application. This would make the program easier to use and command-line arguments could be removed.
Option to specify a given time period (mod. z-count) for which data should be stored
Option to pinpoint single satellites (sat. ID's) for which data should be stored.
Option to pipe RTCM messages into the program using the serial port. This would effectively make the program able to run in real-time mode.

Also, one could consider improving on the effects of partly received or damaged messages (if at all possible!?)

Bibliography

1. RTCM Special Commitee No. 104 (1998). RTCM Recommended Standards For Differential GNSS Service, Version 2.2

2. Ashtech (1995). Z-12 Manual, 2nd Edition

3. U.S. Coast Guard (1995). Global Positioning System Standard Positioning Service Signal Specification, 2nd Edition

Download

The program can be downloaded as a Win32 executable or as C source code. The source code has been successfully compiled using Visual C++ 6.