RTCM 10403.2协议：差分GNSS全球导航卫星系统服务-版本3

需积分: 0 75 浏览量更新于2024-01-18 收藏 1.15MB PDF 举报

The document RTCM 10403.2 RTCM Paper 104-2013-SC104-STD RTCM STANDARD 10403.2 DIFFERENTIAL GNSS (GLOBAL NAVIGATION SATELLITE SYSTEMS) SERVICES – VERSION 3 was developed by the Radio Technical Commission for Maritime Services (RTCM) Special Committee No. 104 and released on February 1, 2013. It is an English-language protocol for global navigation satellite systems, copyrighted by RTCM and not for reproduction or redistribution. The document outlines standards and guidelines for differential GNSS services, specifically focusing on version 3 of the protocol. It provides technical specifications and procedures for the implementation of GNSS in maritime environments, ensuring accurate and reliable positioning and navigation for maritime applications. RTCM, based in Arlington, Virginia, is responsible for developing and maintaining technical standards for maritime services. The organization ensures that the protocols and standards for maritime navigation and communication are up to date and in line with technological advancements. The RTCM 10403.2 document is a testament to their commitment to providing reliable and accurate global navigation satellite system services for the maritime industry. In summary, RTCM 10403.2 RTCM Paper 104-2013-SC104-STD RTCM STANDARD 10403.2 DIFFERENTIAL GNSS (GLOBAL NAVIGATION SATELLITE SYSTEMS) SERVICES – VERSION 3 is an essential technical document for the implementation of GNSS in maritime environments, developed by RTCM to ensure reliable and accurate navigation and positioning services for the maritime industry.

RTCM 10403.2

 Marine – Hydrographic surveying, dredge operations, navigation in narrow

channels, buoy placement and auditing, even tidal height

 Air – Aerial surveying, landing system testing, calibration of other navigation

systems

 Land – Surveying, building and bridge construction, surface mining, agriculture,

road construction, asset location and management

It turns out that the RTK requirements for all these different applications don’t vary that

much. The broadcast link bandwidth and update rates are primarily determined by the

accuracy requirements and the signal blockage environment. Otherwise the required services

are similar for air, land and sea applications.

RTCM 10403.2

3 PRESENTATION LAYER

3.1 Introduction

3.1.1 Version 3 Database Architecture

Version 3 is written in a database format, loosely patterned after the NMEA 2000 standard.

Whereas the NMEA standard is written for a networked set of different electronic units, the

Differential GNSS Version 3 standard is written for a centralized distribution of data. For the

Version 3 broadcast, every bit counts in the frequently repeated messages, so while lining up on

byte boundaries is desirable, forcing each data field to occupy whole numbers of bytes is not

practical.

Also, the NMEA 2000 database has a wide disparity between Data Dictionary (DD) and Data

Field (DF) records. In the case of Version 3 broadcasts, there would be little difference. As a

consequence, rather than utilize both DF and DD tables, these are collapsed into one DF

definition. Rather than referring to “Parameter Groups”, this document will use the more

familiar term “Message Types”.

For messages whose lengths don't line up with byte boundaries, the reference station designer

should use zeros for undefined bits to fill out the last unfilled byte.

3.1.2 Message Groups

Message types contained in the current Version 3 standard (RTCM 10403.2) have been

structured in different groups. For proper operation of a particular service the provider needs to

transmit messages from each of several groups, as shown in Table 3.1-1. For example, to

provide RTK services the provider must transmit at least one message type from each of the

following groups: Observations, Station Coordinates, and Antenna Description. The different

message types in each group contain messages with similar information content.

In some cases the shorter ones contain the minimum needed to provide the service, while the

longer message types contain additional information for enhancing the performance of the

service. For example, Message Type 1001 contains the shortest version of a message for GPS

Observations, namely L1-only observables. For a broadcast link limited in throughput, use of

1001 might be appropriate. Message Type 1002 contains additional information that enhances

performance. If throughput is not limited and the additional information is available, it is

recommended to use the longer version of messages. Similarly Message Type 1003 provides

minimum data for L1/L2 operation, while Message Type 1004 provides the full data content.

The shorter observation messages save throughput, but contain less information. However, since

the additional information in the longer observation messages does not change very often, they

could be sent less often.

剩余254页未读，继续阅读

sayhi:

粉丝: 6
资源: 1

RTCM 10403.2协议：差分GNSS全球导航卫星系统服务-版本3

RTCM 2.3 / 3.2协议完整版

RTCM3.2标准协议英文版.pdf

RTCM3.3协议全

rtcm 10403.3

rtcm standard 10403.3, differential gnss(global navigation satellite systems

rtcm3.3 c10403.3_all.pdf

RTCM3.2中1005型数据用C语言详细解析，并给出详细示例

ZED-F9P数据格式

python 中ntripclient 收到的差分数据如何转换成rtcm3的格式输出

springboot 解析rtcm3数据d300044ce00080ededd6

最新资源