Changes between Version 8 and Version 9 of NDF


Ignore:
Timestamp:
Jun 24, 2014, 5:48:37 PM (8 years ago)
Author:
stoecker
Comment:

Copied texts from proposal

Legend:

Unmodified
Added
Removed
Modified
  • NDF

    v8 v9  
    11This page is dedicated to the development of an RTCM3 Navigation data frames (NDF) message for the transport of raw GNSS messages.
     2= Preface =
     3
     4Many 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 this situations – a transport format for raw Navigation Data Frames (NDF).
     5
     6This 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.
     7
     8Like 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.
     9
     10A 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.
     11
     12= NDF message =
    213
    314== Message header ==
     
    1021||||
    1122||=TOTAL=|| || || 32 + Frames || ||
     23
     24The message allows grouping multiple frames into one block. These can be
     25* multiple signals for one satellite,
     26* multiple satellites for one time or,
     27* multiple frames for one signal,
     28* multiple satellite systems.
     29
     30Also combinations of these are possible. For realtime raw frame transport probably bullets one and two or a combination of these is most useful.
    1231
    1332== Frame Entry ==
     
    4665|| BDS || DF427 || similar to GPS, but with a 14 leap second difference ||
    4766
    48 == Frame Data ==
     67== Frame Data (implementation recommendation) ==
     68
     69While 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.
     70
     71* GPS
     72 * Old Style: 300 bits including the checksums
     73 * New Style: 300 bits including the CRC
     74* SBAS
     75 * 250 bits including CRC
     76* QZSS
     77 * 300 bits for GPS-compatible signals **Needs to be verified**
     78 * 250 bits for SBAS-compatible signal **Needs to be verified**
     79 * 2000 bits for LEX signal **Needs to be verified**
     80* Galileo
     81 * I/NAV 244 bits **Needs to be verified**
     82 * F/NAV 120 bits **Needs to be verified**
     83* Beidou:
     84 * 300 bits **Needs to be verified**
     85* GLONASS:
     86 * 85 bits
     87
     88Data 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.
     89
     90= NDF as ephemeris transport =
     91
     92RTCM3 already has a set of navigational data messages like 1019 (GPS), 1020 (GLONASS) or planned messages like 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.
     93
     94The 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 (e.g. for GPS C/A this would be subframes 1 to 3).
     95Advantages on this approach:
     96 * Receivers already must support the frame format, so data decoding is no longer special for RTCM messages, but can use already existing algorithms
     97 * No assumptions are taken about which data is required and which not
     98 * Changing data formats are handled easily
     99 * Unique structure for all satellite systems and signal types (even private services, ...)