NTRIP statistics (ntrip_stats)
Objectives
Ensure all required RTCM3 messages are provided, and multi-constellation corrections are supported.
Identify delays or disconnections in the correction stream during the recording.
Provide an overview of the RTK fix quality achieved by the GNSS receivers and the information they used to achieve it.
Evaluate if the selected correction stream is sufficient for accurate global localization.
Explanation
The NTRIP statistics file allows the user to evaluate the performance of the received RTCM3 messages, including the available message types for the selected NTRIP caster, communication delays, GNSS performance (i.e., GNSS fix quality and signals tracked), and the processing of the RTCM3 messages by each GNSS receiver.
The first plot of the NTRIP file presents the delay in all the RTCM3 messages received (i.e., all message types), calculated as the difference between the message timestamp and the receive time.
The second plot presents the delay for an MSM GPS message type (e.g., RTCM3-TYPE1073). This plot allows the user to determine whether the delay is observed in one message type alone or the overall RTCM3 message stream. For reference, the average message frequency for most NTRIP casters is about 1 Hz (i.e., a delay of 1 second is expected between two messages of the same type under ideal conditions).
The third plot presents the relationship between each message's timestamp (i.e., when the message was generated) and the received time. Under ideal conditions, the slope of the line should be always 1.
Higher delays can be explained mainly by three factors:
The selected NTRIP caster is far from the rover (e.g., further than 40km).
The sensor is experiencing constant Internet outages.
The Internet connection is slow, causing delays in downloading the corresponding messages.
Small inconsistencies in the delay between RTCM3 messages are expected. However, if the delay is constantly higher than 2 seconds, then it is worth investigating.
Fig. 1: RTCM3 message delay.
The fourth plot presents the RTCM3 message types received by the sensor. In this example, the received RTCM3 messages were:
RTCM type 1005: Stationary RTK reference station ARP.
RTCM type 1074: GPS MSM4.
RTCM type 1087: GLONASS MSM7.
RTCM type 1094: Galileo MSM4.
RTCM type 1124: BeiDou MSM4.
RTCM type 1230: GLONASS code-phase biases.
As shown in Fig. 2, this particular NTRIP caster is streaming one RTCM3 message type per satellite constellation in addition to the reference position of the base station. Therefore, with the available RTCM3 messages, the RTK processor can achieve an RTK-fixed status with data from every satellite constellation.
Fig. 2: Received RTCM3 message types.
The Vision-RTK2 requires some of the following RTCM3 message types for proper operation (for more information, refer to Section 5.5.1 of the Integration Manual):
Fig. 3: List of required RTCM3 input messages.
For proper operation, the sensor must receive one message type from each GNSS constellation.
The following plots present the GNSS fix type achieved and the number of signals each GNSS receiver tracked, used, and corrected. The latter indicates how many satellite signals are healthy enough (e.g., good quality signal with enough signal power) and contain corresponding RTCM3 messages to be corrected. Suppose RTCM3 messages are received, but no signals are corrected. In that case, it can indicate that the correction data does not contain the necessary RTCM3 messages or the quality of the raw GNSS measurements is not good enough (e.g., due to electromagnetic interference or multipathing).
Fig. 4: GNSS receiver performance.
For the Fusion engine to initialize, the sensor must achieve an RTK-fixed state on both GNSS receivers. The available GNSS fix types are:
Fix type | Description |
|---|---|
Unknown | The receiver has no satellite signals. |
No fix | The receiver does not have enough satellite signals. |
Dead reckoning | No satellite signals are available, but dead reckoning is enabled. |
Time | The receiver has received time information only. |
Single 2D | Autonomous GNSS fix with very few available satellite signals. |
Single 3D | Autonomous GNSS fix, typically in situations with no correction data or in outages. |
Single 3D - DR | Autonomous GNSS fix with dead reckoning. |
RTK float | RTK with ambiguities not fully solved. |
RTK fixed | RTK with ambiguities fully solved. |
Similarly, the last plot indicates how many RTCM3 messages were processed by each GNSS receiver. Ideally, the receiver should process most RTCM3 messages, and no messages should display an error. Assuming the sensor receives one message type per GNSS constellation, the plot should report at least six messages per second, and no messages should fail to be processed.
Fig. 5: RTCM3 messages processed by each GNSS receiver.
It is important to consider that the reporting period of the GNSS receiver is 1Hz, which can cause the messages to have a delay and accumulate on the next epoch, as shown in Fig. 6:
Fig 6: Reporting delays on the GNSS receiver.
Expected results
The RTCM3 message stream should have an average delay of 1 second (i.e., the average message frequency for most NTRIP casters is about 1 Hz.). Delays over 2 seconds can hint at Internet connectivity issues, an unstable correction source or the selected basestation being too far away (we recommend the basestation be closer to 15km from the rover).
It is expected to see minor inconsistencies in the message receipt time vs the header time, in the order of ±0.5s. Higher inconsistencies can hint at connectivity issues.
The sensor must receive one message type from each GNSS constellation. In other words, the receivers must process six messages per second (one for each constellation, one for basestation position, and one for phase correction).
The receiver should process most RTCM3 messages, and no messages should display an error.
For the Fusion engine to initialize, the sensor must achieve an RTK-fixed state on both GNSS receivers.
Under open-sky conditions, each GNSS receiver should use, on average, 40 corrected GNSS signals.
If no RTCM3 markers are plotted, this indicates that the correction stream presented no MSM GPS messages. The Vision-RTK2 requires MSM-type messages. Thus, try connecting to a different basestation or use a different correction service provider.
Examples
Disconnections to the NTRIP correction stream can be seen as significant delays in the receipt time of the RTCM3 messages (i.e., more than 3 seconds) or lack of messages for an extended time, as shown in Fig. 7.
Fig. 7: Recurrent disconnections to the correction stream.
If no MSM GPS message types (e.g., RTCM3-TYPE1073) are in the correction stream, the file will skip plots 2 and 3, as shown in Fig. 8. Even though the GNSS receivers might be able to obtain an RTK-fixed status with legacy GPS messages, it is highly encouraged to switch to a correction stream with MSM multi-constellation messages for the best positioning performance and signal availability.
Fig. 8: File without MSM GPS message types.
In addition, as shown in Fig. 9, the user can observe that the number of signals with corrections used by the Fusion engine drops significantly when no MSM messages are employed.
Fig. 9: GNSS signal availability when no MSM-type messages are provided.
Example HTML:
Further analysis
If the GNSS receivers experience issues obtaining an RTK fixed status or the estimated baseline is wrong under RTK fixed conditions, verify that the selected basestation is less than 15 km from the rover. The sensor might experience degraded performance if the selected RTK basestation is slightly far away (> 15 km). The sensor will experience degraded performance and difficulties computing an RTK-fixed solution if the basestation is excessively far away (> 25 km). In this case, please choose a different NTRIP mountpoint or re-connect to the VRS service.
If RTCM3 messages are missing for multi-constellation support, attempt connecting to another basestation or switch to a different correction service provider.
If the sensor experiences multiple disconnections from the correction stream, verify that the device's network configuration is correct and that Internet coverage is always available.
If access to a different correction service provider is required, contact support@fixposition.com. We partner with multiple providers and can help you select the ideal one for your operation.