Changes between Version 20 and Version 21 of NDF

Timestamp:

Jan 16, 2017, 1:03:37 PM (7 years ago)

Author:

JamesTCurran

Comment:

--

NDF

@@ -8 +8 @@
 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 it, or they can be preliminary converted into [e.g. already standardized MT 1019, 1020 etc] ephemeris structures for further processing archiving.
+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 archiving.
 
 = NDF message =
@@ -82 +82 @@
  * 85 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.
+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.
 
 = NDF as ephemeris transport =
@@ -91 +91 @@
 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
+ * 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