ZED-F9P-Integration Manual
UBX-18010802 - R02
3 Getting started Page 14 of 114
Advance Information
3.3 List of supported RTCM output messages
Message Description
RTCM 1005 Stationary RTK reference station ARP
RTCM 1074 GPS MSM4
RTCM 1077 GPS MSM7
RTCM 1084 GLONASS MSM4
RTCM 1087 GLONASS MSM7
RTCM 1094 Galileo MSM4
RTCM 1097 Galileo MSM7
RTCM 1124 BeiDou MSM4
RTCM 1127 BeiDou MSM7
RTCM 1230 GLONASS code-phase biases
Table 2: ZED-F9P supported output RTCM version 3.3 messages
The configuration of the RTCM 3x correction stream must be done according to the following rules:
• All observation messages must be broadcast at the same rate.
• The reference station ID field in the GPS, GLONASS, Galileo, BeiDou observation messages must
be consistent with the reference station ID field in the reference station message otherwise the
rover will not be able to compute its position.
• The RTCM 3x stream must contain the "GLONASS code-phase biases" message (type 1230)
or the "Receiver and Antenna Description" message (type 1033) otherwise the GLONASS
ambiguities can only be estimated as float, even in RTK fixed mode. If using a ZED-F9P as a base,
"GLONASS code-phase biases" message (type 1230) must be enabled to be output. For a ZED-
F9P being used as a rover if no RTCM 1230 message is received, or if the reference receiver type
reported in RTCM 1033 message is unknown to the ZED-F9P receiver, the ZED-F9P rover will
only be able to estimate GLONASS ambiguities as float, even in RTK fixed mode. This will result
in degraded performance, especially in challenging environments.
• The static reference station message (type 1005 or type 1006) does not need to be broadcast
at the same rate as the observation messages however the rover will not be able to compute its
position until it has received a valid reference station message.
• The RTCM 3x stream should only contain one type of observation messages per constellation.
When using a multi-constellation configuration, all constellations should use the same type of
observation messages. Mixing RTK and MSM messages will result in undefined rover behavior.
• If the receiver is configured to output RTCM messages on several ports, they must all have the
same RTCM configuration otherwise the MSM multiple message bit might not be set properly.
3.4 NTRIP - Networked Transport of RTCM via Internet Protocol
Networked Transport of RTCM via Internet Protocol, or NTRIP, is a standard protocol for streaming
differential data over the internet in accordance with specifications published by RTCM.
This is a convenient method used by many commercial service providers for distributing corrections.
There are three major parts to the NTRIP system: The NTRIP client, the NTRIP server, and the NTRIP
caster:
1. The NTRIP server is a PC or on-board computer running NTRIP server software communicating
directly with a GNSS reference station. The NTRIP server serves as the intermediary between the
GNSS receiver (NTRIP Source) streaming RTCM data and the NTRIP caster.
2. The NTRIP caster is a HTTP server which receives streaming RTCM data from one or more NTRIP
servers and in turn streams the RTCM data to one or more NTRIP clients via the internet.