Getting Started

RTK Positioning Principle

Ntrip Protocol

Definition
NTRIP (Networked Transport of RTCM via Internet Protocol) is an internet-based protocol specifically designed for the real-time transmission of differential GNSS (Global Navigation Satellite System) data. It is primarily used to transmit RTCM (Radio Technical Commission for Maritime Services) format differential correction data (e.g., for GPS, GLONASS, etc.) from a reference station to a rover (such as surveying equipment, drones, autonomous driving systems, etc.) to improve positioning accuracy (from meter-level to centimeter-level).

Components

• NTRIP Client: The terminal device (e.g., GNSS receiver) that receives the differential data.
• NTRIP Server: Stores and distributes differential data from reference stations.
• NTRIP Caster: The core intermediary server responsible for coordinating the connection between clients and servers, acting like a "router".
• Mount Point: A unique identifier for a data stream; clients subscribe to specific data sources (e.g., data from a particular reference station) through it.

Working Principle

• Based on the HTTP/HTTPS protocol, using long connections (Keep-Alive) to achieve real-time data transmission.
• The client sends an HTTP request to the Caster, specifying the target Mount Point. The Caster then continuously pushes the corresponding RTCM data stream to the client.
• Supports authentication (e.g., username/password) to ensure secure data access.

Characteristics

• Low Latency: Suitable for scenarios requiring high real-time performance (e.g., autonomous driving).
• Cross-Network Compatibility: Utilizes the HTTP protocol to penetrate firewalls, adapting to complex network environments.
• Flexibility: Supports unicast (point-to-point) and multicast (one-to-many) transmission modes.
• Standardized Data Format: Uses the RTCM SC-104 standard (commonly version RTCM 3.x), ensuring device compatibility.

Common CORS Service Providers and Positioning Accuracy

Please understand the coverage of the CORS service before purchasing the equipment, and make sure you can obtain a CORS account service; otherwise, you will not be able to get RTK positioning data after receiving the equipment.

Positioning Principle Overview and Flowchart

In a large area, multiple base stations (three or more) are evenly distributed to form a reference station network. They send data to a central server. The central server simulates a "virtual reference station" based on this data. The user, using a fixed CORS account, employs the 4G network and Ntrip protocol to broadcast the data from this "virtual reference station" in real-time to the rover. The rover performs real-time differential calculations to eliminate common errors, thereby achieving centimeter-level accuracy RTK positioning.

Advantages and Disadvantages of Network RTK

Network RTK has significant advantages, mainly reflected in utilizing widely distributed mobile communication base stations as reference stations, achieving seamless coverage, and using the built-in 4G module for efficient communication between the rover and the central server. Users do not need to build their own reference stations, reducing costs, and only need to pay communication fees. Meanwhile, due to the large number of reference stations, even if some are damaged, it does not affect the overall accuracy and reliability.

However, in the Network RTK model, network stability greatly impacts positioning accuracy. Stable network communication must be ensured to guarantee stable delivery of differential data, enabling ultra-high positioning accuracy.

Common Application Scenarios

• Surveying and Geographic Information Collection: Improving the accuracy of field measurements.
• Precision Agriculture: Autonomous driving of agricultural machinery and variable rate fertilization.
• UAV Navigation: Achieving centimeter-level positioning for aerial photography or inspection.
• Intelligent Transportation Systems: High-precision vehicle positioning and lane-level navigation.

NMEA Data Parsing

Modules output NMEA 0183 messages (e.g., RMC, GGA). Example GGA data:
$GNGGA,063924.000,3037.643956,N,10348.010829,E,5,34,0.46,507.909,M,-32.181,M,1.0,3335*76

Full NMEA 0183 Reference

Common Coordinate System Comparison

Modifying the Baud Rate

Note: If using an Arduino UNO, it is necessary to employ the configparam example routine within the library file. First, switch the module to I2C mode to configure the rover module's baud rate and modify it to 57600. Using boards with multiple hardware UART interfaces like the MEGA2560 or ESP32 does not require this baud rate modification step.

Wiring Diagram

• Connect the module to the Arduino according to the wiring diagram above.
• Move the selection switch on the sensor to the I2C side. (Note: Text says I2C, but wiring and context suggest UART preparation. Possibly means use I2C first for configuration).
• Open Arduino IDE, upload the code below to Arduino UNO.
• Open the Arduino IDE Serial Monitor, set the baud rate to 57600, and observe the serial print results.
• Note: Configuration mode only supports I2C mode. Running this example requires switching to I2C.

Parameter Configuration Example Code

  /*!
  * @file  configParam.ino
  * @brief config moudle param
  * @copyright Copyright (c) 2010 DFRobot Co.Ltd (http://www.dfrobot.com)
  * @license The MIT License (MIT)
  * @author ZhixinLiu([email protected])
  * @version V0.5.0
  * @date 2024-04-24
  * @url https://github.com/DFRobot/DFRobot_RTK_LoRa
  */

#include "DFRobot_RTK_LoRa.h"

// must use iic config parameter
DFRobot_RTK_LoRa_I2C rtk(&Wire ,DEVICE_ADDR);
void setup()
{
  Serial.begin(115200);
  while(!rtk.begin()){
    Serial.println("NO Deivces !");
    delay(1000);
  }
  Serial.println("Device connected !");

  /**
   * | Support Baud | UNO/ESP8266 | Leonardo/Mega2560 | ESP32 |  M0 |
   * | eBaud9600    |      √      |         √         |   √   |  √  |
   * | eBaud14400   |      √      |         √         |   √   |  √  |
   * | eBaud19200   |      √      |         √         |   √   |  √  |
   * | eBaud38400   |      √      |         √         |   √   |  √  |
   * | eBaud56000   |      √      |         √         |   √   |  √  |
   * | eBaud57600   |      √      |         √         |   √   |  √  |
   * | eBaud115200  |             |         √         |   √   |  √  |
   * | eBaud256000  |             |                   |   √   |  √  |
   * | eBaud512000  |             |                   |   √   |  √  |
   * | eBaud921600  |             |                   |   √   |  √  |
   */
  rtk.setModuleBaud(eBaud115200);

  Serial.print("module mode = ");
  Serial.println(rtk.getModule());

  Serial.print("moudle buad = ");
  Serial.println(rtk.getModuleBaud());
}

void loop()
{
  // Reserved interface, direct communication with gnss firmware, use with the original factory data manual
  Serial.println(rtk.transmitAT("$PQTMVERNO*58\r\n"));
  delay(2000);
}

Result

Usage Notes

• When using, powering solely through the Gravity interface may lead to insufficient power for the 4G module, causing communication failures. It is recommended to use the Type-C interface or the terminal block for additional power supply.

• Due to weak satellite signals indoors and severe obstruction affecting the antenna's satellite acquisition quality, it can only be used in relatively open outdoor areas.

• During the first power-on, since the 4G module initialization and GNSS antenna satellite acquisition require a process, it is necessary to wait a few minutes after powering on to obtain RTK positioning information.

• When switching the I2C/UART output mode, power off and then on again for the change to take effect.