This page is dedicated to the development of an RTCM3 Navigation data frames (NDF) message for the transport of raw GNSS messages.

Preface

Many users need all the information contained in the data transmission by the satellite in an unmodified form. Lots of receivers and services already support output of raw frames, but there exists no standard. This message tries to solve these situations – a transport format for raw Navigation Data Frames (NDF).

This message is in line with lately introduced MSM observation messages. MSM messages are generic and Message Type numbers are reserved for up to 16 GNSS systems. Similarly, NDF data messages are also claimed as generic, i.e. their high level structure is the very same for each GNSS and Signal.

Like in case of MSM description, first we describe generic NDF message structure. Then for each available GNSS we specify signals containing binary data and provide recommendations for data framing.

A GNSS application can use NDF data as is, or it can first convert it into [e.g. already standardized MT 1019, 1020 etc] ephemeris structures for further processing.

NDF message

Message header

Data field	DF NUMBER	DATA TYPE	NO. OF BITS	NOTES
Message Number	DF002	uint12	12	99 (pre-standard number) 4075 (proprietary number for this purpose)
Reference Station ID	DF003	uint12	12	stream identification
Reserved field		uint2	2	reserved bits, maybe used to separate different type 4075 message, always 0 for NDF
Frame Count (FC)		uint6	6	Number of frame entries to follow
Frame Entry			depends on FC and frame size	frame data according to following table
TOTAL			30 + Frames

The message allows grouping multiple frames into one block. These can be

• multiple signals for one satellite,
• multiple satellites for one time or,
• multiple frames for one signal,
• multiple satellite systems.

Also combinations of these are possible. For realtime raw frame transport probably bullets one and two or a combination of these is most useful. The provider of a data stream can decide which grouping to use.

Consumers of NDF data must not assume any special form of grouping and handle each frame individually as if it has been transmitted in a separate RTCM block. The grouping is a space saving mechanism and has no further meaning.

Frame Entry

Data field	DF NUMBER	DATA TYPE	NO. OF BITS	NOTES
Satellite system		uint5	4	0 == GPS, 1 == GLONASS, 2 == Galileo, 3 = SBAS, 4 = QZSS, 5 = BDS, 6 = IRNSS
Satellite number		uint6	6	Satellite ID, index from MSM satellite mask bit field (0..63, see DF394)
Extended Sat Info		uint4	4	Specific for each GNSS system, Frequency number+7 for GLONASS
Signal Type		uint5	5	Signal type specification, index from MSM signal mask bit field (0..31, see DF395)
Epoch Time		uint30	30	Epoch time, specific for the satellite system always 30 bits (see table below)
Continuous Tracking		bit(1)	1	Tracking this satellite frame data was continuous (1 = continuous, 0 not continuous or unset)
Frame Data Size (N)		uint12	12	Number of bits to follow
Frame Data			N	Bit data from satellite (see data section below)
TOTAL			48 + N

Layout of a frame block always follows this structure, so unknown satellite systems or satellites can be skipped in messages with more than one frame.

Epoch Time (accuracy in milli seconds, equal to MSM)

Satellite system	DF NUMBER(s)	NOTES
GPS	DF004	in milliseconds (0..604799.999 s)
GLONASS	DF416 (3 bit) + DF034 (27 bit)	Like for MSM, Day of week (0 == Sunday, 6 == Saturday, 7 == unknown) + time of day in ms (0..86400.999 s)
Galileo	DF248	equals GPS
SBAS		equals GPS
QZSS	DF428	equals GPS
BDS	DF427	similar to GPS, but with a 14 leap second difference
IRNSS		equals GPS

Frame Data (implementation recommendation)

While the format general has variable bit length support, to reduce confusion about the data contents the standard should define the bits sizes and data to be transferred for all existing satellite systems. Data should always include checksums and other non-informational parts of the transmission. Data must be ready usable (i.e. inverted bits and similar transport mechanism have to be removed).

• GPS
  • Old Style LNAV: 300 bits including the checksums
  • CNAV-Style: 300 bits including the CRC
• SBAS
  • 250 bits including CRC
• QZSS
  • 300 bits for GPS-compatible signals
    • See GPS for specification
  • 250 bits for SBAS-compatible signal
    • See SBAS for specification
  • 2000 bits for LEX signal
• Galileo
  • F/NAV 244 bits
  • I/NAV 2*120 bits
• Beidou:
  • BDS-2 D1 and D2: 300 bits
    • NOTE: interleaving removed, ICD style data stream
• GLONASS:
  • FDMA: 85 bits
  • CDMA: 300 bits (200 or 400 for anomalous strings)
• IRNSS:
  • 292 bits

Data senders need to decide whether data with bad checksum is transferred or not. While generally data with a bad checksum may be discarded, in disturbed environments even such data may be useful, in particular when parts of the message are common to multiple satellites, or when a portion of the data is already known.

Implementers can freely choose how to group data into a single message. Possibilities (used by proprietary formats already) include:

• One Frame per message (easy, but bandwidth wasting)
• Time based per satellite system (all simultaneous transmissions of a single satellite system in one block until maximum block size reached)
• ...

NDF as ephemeris transport

RTCM3 already has a set of navigational data messages like 1019 (GPS), 1020 (GLONASS), 1042 (BDS), 1044 (QZSS) 1045, 1046 (Galileo). With the additional satellite systems more and more navigation messages become necessary and also the existing system navigation messages are changing and thus additional formats are required.

The above message structure allows to use this message also as a replacement or enhancement of existing ephemeris messages simply by filling the message not with the real-time stream, but with all frames necessary to for an ephemeris set. Advantages of this approach:

• Receivers already must support the frame format, so data decoding is no longer special for RTCM messages, but can use already existing algorithms
• No assumptions are taken about which data is required and which not, or what the future use of certain reserved/spare bits might be
• Changing data formats are handled easily
• Unique structure for all satellite systems and signal types (even private services, ...)
• New signals, adhering to an existing GNSS standard, but containing different data (e.g. new augmentation signals or pseudolites) can directly employ this standard

Implementation

• For ephemeris usage set "Message Number" field to 100 (pre-standard number).
• For ephemeris usage set "Reserved field" to 1.
• Only one satellite is allowed per message.
• Complete matching and valid frames for one ephemeris set must be included in correct order:
  • GPS old style : Subframes 1 to 3
  • GLONASS : Frame 1-5
  • IRNSS : Subframes 1 and 2
  • SBAS : Message 9