> For the complete documentation index, see [llms.txt](https://docs.rtkdata.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rtkdata.com/integration-hub/robotics/fixposition-vision-rtk-2.md). # Fixposition Vision-RTK 2 NTRIP Setup: Xsens XVN & PBx-A1 Connect the Fixposition Vision-RTK 2, Xsens Vision Navigator (XVN) or PBx-A1 to RTKdata: built-in NTRIP client, host, port 2101, AUTO and Position Automatic. The **Fixposition Vision-RTK 2** has an NTRIP client built into the sensor, so it connects to RTKdata without a robot computer in between. To set up NTRIP on a Vision-RTK 2, open its web interface, stop the Fusion under **Status** > **Fusion** with **Stop**, open **Configuration** > **GNSS**, set **Source** to **NTRIP client (auto)** in the **Correction data** card and enter your RTK credentials in **User** and **Password**, the RTKdata host for your region in **Host** (`rtk.rtkdata.com` for North America, `eu.rtkdata.com` for Europe or `aus.rtkdata.com` for Australia), `2101` in **Port** and `AUTO` in **Mountpoint**. Set **Position** to **Automatic**, click **Save and apply**, then start the Fusion again with **Start**. The sensor needs its own internet connection, in operation over Ethernet. One RTKdata data stream serves both internal GNSS receivers: Fixposition states that "A single RTK correction data stream is required. It is used for both GNSS receivers." The same steps apply to the **Xsens Vision Navigator (XVN)**, which Clearpath Robotics describes as the same sensor ("also known as the Movella XVN"), and to the **Fixposition PBx-A1**, see [Which Fixposition and Xsens sensors does this guide cover?](#which-fixposition-and-xsens-sensors-does-this-guide-cover) below. On Clearpath robots with OutdoorNav, follow the [Clearpath OutdoorNav](/integration-hub/robotics/clearpath-outdoornav.md) guide. The labels on this page follow the [Fixposition Vision-RTK 2 Integration Manual v2.3.1](https://docs.clearpathrobotics.com/assets/files/clearpath_robotics_031747-TDS2-264040833beadb5631ba90c93fd252ba.pdf) (the public edition hosted by Clearpath Robotics) and the [Vision-RTK 2 Quick Start Guide](https://docs.clearpathrobotics.com/assets/files/clearpath_robotics_031747-TDS3-e7cb7555b6ce37b17a0ef6a8de16974e.pdf), version 2024.04. Older sensor software shows host and port together in one field, **Address**; in that case, ask the manufacturer for a software update first. {% hint style="warning" %} **Give the sensor internet before you enter NTRIP.** At delivery, the Ethernet port of the Vision-RTK 2 runs as **dhcp-server** at `10.0.2.1`. In this state, the sensor has no route to the internet unless it is also connected to a Wi-Fi network, and the NTRIP client never connects to RTKdata. Set Ethernet to **dhcp-client** behind a router, or to **static-ip** with a gateway, as described in [How does the sensor get internet for RTK corrections?](#how-does-the-sensor-get-internet-for-rtk-corrections) below. {% endhint %} These are the values you enter, and the field names in bold match the **Correction data** card under **Configuration** > **GNSS**. Choose the server closest to your work area. All three servers share the same base station network; the difference is routing latency, see [NTRIP Server Settings](/get-started/network.md). {% tabs %} {% tab title="North America" %} * **Host (domain)** in **Host**: `rtk.rtkdata.com` * **Host (IP fallback):** `13.56.117.10`, only if the hostname does not resolve or does not connect * **Port:** `2101`, in **Port** * **Username / Password:** From *RTK Credentials* in your [account dashboard](https://rtkdata.com/my-account/rtk-credentials/), not your website login, in **User** and **Password** * **Mountpoint (ALL CAPS):** `AUTO` (recommended), or `AUTO_WGS84`, `AUTO_ITRF2020`, `AUTO_ITRF2014`, in **Mountpoint** {% endtab %} {% tab title="Europe" %} * **Host (domain)** in **Host**: `eu.rtkdata.com` * **Host (IP fallback):** `3.73.41.96`, only if the hostname does not resolve or does not connect * **Port:** `2101`, in **Port** * **Username / Password:** From *RTK Credentials* in your [account dashboard](https://rtkdata.com/my-account/rtk-credentials/), not your website login, in **User** and **Password** * **Mountpoint (ALL CAPS):** `AUTO` (recommended), or `AUTO_WGS84`, `AUTO_ITRF2020`, `AUTO_ITRF2014`, in **Mountpoint** {% endtab %} {% tab title="Australia" %} * **Host (domain)** in **Host**: `aus.rtkdata.com` * **Host (IP fallback):** `54.206.56.130`, only if the hostname does not resolve or does not connect * **Port:** `2101`, in **Port** * **Username / Password:** From *RTK Credentials* in your [account dashboard](https://rtkdata.com/my-account/rtk-credentials/), not your website login, in **User** and **Password** * **Mountpoint (ALL CAPS):** `AUTO` (recommended), or `AUTO_WGS84`, `AUTO_ITRF2020`, `AUTO_ITRF2014`, in **Mountpoint** {% endtab %} {% endtabs %} | Field in **Correction data** | Value | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Source** | **NTRIP client (auto)** | | **User** | Your RTKdata username from *RTK Credentials* in your [account dashboard](https://rtkdata.com/my-account/rtk-credentials/). It starts with `rtk` and is not your website login. | | **Password** | Your RTKdata password from *RTK Credentials*, not your website password | | **Host**, North America | `rtk.rtkdata.com`, IP fallback `13.56.117.10` | | **Host**, Europe | `eu.rtkdata.com`, IP fallback `3.73.41.96` | | **Host**, Australia | `aus.rtkdata.com`, IP fallback `54.206.56.130` | | **Port** | `2101` | | **Mountpoint** | `AUTO` (recommended), or `AUTO_ITRF2020`, `AUTO_ITRF2014`, `AUTO_WGS84`. Type it; do not pick a stream with **Sourcetable**. | | **Position** | **Automatic**, so the sensor sends its position to RTKdata | * Enter only the hostname in **Host**, without `http://` and without `:2101`. The port has its own field. Fixposition's own example shows a hostname in **Host**. * Mountpoint names are case sensitive: `AUTO` in capitals. * Enter the username and password without a space at the start or end. * One set of credentials allows one connection at a time. A second sensor or robot running at the same time needs its own data stream, see [Account & Credentials](/get-started/account-and-credentials.md#using-one-subscription-with-several-devices). ## Requirements * **Fixposition Vision-RTK 2, Xsens Vision Navigator (XVN) or Fixposition PBx-A1** with both GNSS antennas connected and a clear view of the sky * **GNSS antennas that Fixposition lists as compatible:** according to Fixposition, only active antennas (with a built-in LNA) are suitable, and Fixposition advises against antenna assemblies that combine GNSS, Wi-Fi and cellular antennas in one housing. See Fixposition's [antenna compatibility page](https://docs.fixposition.com/fd/which-gnss-antennas-are-compatible-with-the-vrtk-2). * **Internet for the sensor over Ethernet**, for example from a router on the robot, with outbound TCP on port `2101`. Fixposition describes Wi-Fi as suitable only as a service interface and asks for Ethernet in regular operation. * **A stable power supply:** for the Vision-RTK 2, Fixposition asks for a supply that delivers 10 W at 5 to 36 V and does not recommend powering it over the USB-C port during operation. The PBx-A1 quick start guide asks for a 9 to 36 V supply. * **A laptop with a browser and an Ethernet port** for the web interface * **RTKdata account** with active RTK credentials (username starts with `rtk`), with one data stream per sensor or robot that is connected at the same time * **RTKdata coverage** at your site: check the [coverage map](/get-started/coverage-map.md) before you go out. Fixposition recommends a base station closer than 15 km. {% hint style="info" %} Don't have an RTKdata.com account yet? [Start 30-day Free Trial](https://rtkdata.com/try-rtk-corrections-free-for-30-days/) or [View Pricing](https://rtkdata.com/pricing/) {% endhint %} ## Which Fixposition and Xsens sensors does this guide cover? This guide covers the Fixposition Vision-RTK 2, the Xsens Vision Navigator (XVN) and the Fixposition PBx-A1, which all take RTKdata corrections through the NTRIP client built into the sensor; Clearpath robots with OutdoorNav have their own guide. | Sensor | Where you set up NTRIP | What differs | | -------------------------------- | ----------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Fixposition Vision-RTK 2 | Web interface, **Configuration** > **GNSS** | The reference for the labels on this page. The sensor computes with two internal u-blox F9P GNSS receivers. Ethernet runs as **dhcp-server** at `10.0.2.1` at delivery. | | Xsens Vision Navigator (XVN) | Web interface, **Configuration** > **GNSS** > **Correction data** | Clearpath Robotics states that the Vision-RTK 2 "is also known as the Movella XVN (Xsens Vision Navigator)". Xsens describes the same built-in NTRIP client with **User**, **Password**, **Host**, **Port** and **Mountpoint** in its article [Using the NTRIP-X Base Station with Xsens MTi and XVN products](https://base.xsens.com/s/article/Using-the-NTRIP-X-Base-Station-with-Xsens-MTi-and-XVN-products), and calls the status page the **Status Dashboard**. | | Fixposition PBx-A1 | Web interface, **Configuration** > **GNSS** | The [PBx-A1 quick start guide](https://docs.fixposition.com/fd/pbx-a1) (28 April 2026) shows the same choice of correction source (NTRIP client, I/O port, TCP client) and the same **Correction stream** path dialog, but not the NTRIP field names, so the steps below use the Vision-RTK 2 labels. Ethernet runs as DHCP client at delivery. | | Clearpath robots with OutdoorNav | The XVN web interface, opened from OutdoorNav | See the [Clearpath OutdoorNav](/integration-hub/robotics/clearpath-outdoornav.md) guide | ## How does the sensor get internet for RTK corrections? The built-in NTRIP client reaches RTKdata only over the sensor's own internet connection, in operation over Ethernet: under **Configuration** > **Network**, set the **Ethernet** connection to **dhcp-client** behind a router, or to **static-ip** with **Gateway** and **DNS**, and check that **Default route** shows Ethernet. According to the Fixposition quick start guide, the Vision-RTK 2 reaches the internet only as a DHCP client or with a static IP. The factory setting **dhcp-server** is for a laptop plugged straight into the sensor. | Ethernet connection | Use it when | Internet for NTRIP | Web interface address | | ----------------------------------------------------- | ----------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------ | | **dhcp-server** (factory setting on the Vision-RTK 2) | A laptop is plugged straight into the sensor for setup | No. Without a Wi-Fi client connection, **Default route** is None | `http://10.0.2.1/` or `http://fp-xxxxxx.local/` | | **dhcp-client** (factory setting on the PBx-A1) | The sensor is connected to a router that assigns addresses, for example the router on the robot | Yes, if the router has internet | The address the router assigns, or `http://fp-xxxxxx.local/` | | **static-ip** | The network needs a fixed address | Only with **Gateway** set to the router and a working **DNS** | The address you set | * `fp-xxxxxx` stands for your sensor's name, which the web interface shows in its navigation bar. Behind a router, the addresses `10.0.1.1` and `10.0.2.1` no longer apply. * Make the change while the laptop is still connected straight to the sensor, then connect the sensor to the router and open the web interface at the address the router assigns. * For **static-ip**, click **Edit connection**, fill in **IP address**, **Netmask**, **Gateway** and **DNS**, click **Apply** and then **Connect**. Use **Set as default** for the connection the sensor should use after a restart. The form suggests `1.1.1.1`, `8.8.8.8` and `8.8.4.4` for **DNS**; if your network allows only its own DNS server, enter that one. * **Default route** on the **Configuration** > **Network** page shows the interface the NTRIP client uses. It must show Ethernet (or the Wi-Fi client), not None. * Ethernet with internet has priority over Wi-Fi, and according to Fixposition the sensor does not fall back to another route by itself. If a **static-ip** connection has no internet, for example a direct cable to the robot computer, leave **Gateway** empty; only then does the sensor use its Wi-Fi client connection for internet. * The **Internet** indicator in the navigation bar only shows whether the sensor can ping `8.8.8.8`. It says nothing about port `2101`: what counts for RTKdata is **connected** in the **Correction data** card. * **Recovery on the Vision-RTK 2:** if the sensor is no longer reachable after a network change, connect the laptop to its USB-C port and open `http://10.0.3.1`. Windows has to show the sensor as "USB Ethernet/RNDIS Gadget", not as a COM port. * **PBx-A1:** open the web interface at `http://.local/`, where the UID is your device's identifier, for example `xf-abc123`. Fixposition states that there is currently no recovery route for the PBx-A1 and that a forgotten static IP locks you out, so keep the DHCP client setting. ## How do you set up the built-in NTRIP client for RTKdata? To connect the built-in NTRIP client to RTKdata, open the sensor's web interface, give the sensor internet, stop the Fusion, set **Source** to **NTRIP client (auto)** under **Configuration** > **GNSS**, enter your RTKdata RTK credentials in **User** and **Password**, `rtk.rtkdata.com`, `eu.rtkdata.com` or `aus.rtkdata.com` in **Host**, `2101` in **Port** and `AUTO` in **Mountpoint**, set **Position** to **Automatic**, click **Save and apply**, check the fix outdoors and start the Fusion again. {% stepper %} {% step %} ### Open the web interface Connect a laptop to the sensor and open the web interface in a browser: * **Ethernet straight to the laptop** (Vision-RTK 2 at delivery): open `http://10.0.2.1/` or `http://fp-xxxxxx.local/`. * **Wi-Fi access point:** screw on the Wi-Fi antenna (without it, the quick start guide gives a range of only half a meter), join the network `fp-xxxxxx` with the default password from the Fixposition quick start guide and open `http://10.0.1.1/`. * **Behind a router:** open the address the router assigned to the sensor, or `http://fp-xxxxxx.local/`. * **PBx-A1:** open `http://.local/` from a computer in the same network. {% endstep %} {% step %} ### Give the sensor internet Open **Configuration** > **Network** and set the **Ethernet** connection to **dhcp-client** (behind a router) or **static-ip** with **Gateway** and **DNS**, as described in [How does the sensor get internet for RTK corrections?](#how-does-the-sensor-get-internet-for-rtk-corrections) above. Check that **Default route** shows Ethernet, not None. {% endstep %} {% step %} ### Stop the Fusion Open **Status** > **Fusion** and click **Stop**. While the Fusion is running, the web interface does not save changes, according to Fixposition's troubleshooting page. {% endstep %} {% step %} ### Choose the built-in NTRIP client Open **Configuration** > **GNSS**. On the page **GNSS Configuration**, in the card **Correction data**, set **Source** to **NTRIP client (auto)**. "(auto)" stands for the automatic choice of the NTRIP version, not for the position. The factory setting is **I/O port**, which leaves the built-in client off. {% endstep %} {% step %} ### Enter the RTKdata values Fill in each field on its own; Fixposition asks for all fields of the form to be filled in when you use NTRIP. 1. **User:** your RTKdata username from *RTK Credentials* (starts with `rtk`). 2. **Password:** your RTKdata password from *RTK Credentials*. 3. **Host:** the host for your region, for example `eu.rtkdata.com`. 4. **Port:** `2101`. 5. **Mountpoint:** type `AUTO` in capitals. Do not use **Enter path** for RTKdata; the separate fields keep the username and password apart from the host. Do not load the mountpoint with **Sourcetable** and **Use** either: type `AUTO`. {% endstep %} {% step %} ### Set Position to Automatic Set **Position** to **Automatic**. With **Automatic**, the client sends the best available position from the GNSS receivers and the Fusion engine to RTKdata. * **Manual** sends a fixed coordinate. While the robot moves, `AUTO` then gets no updated position and cannot hand off to a closer station. * **None** sends no position, and `AUTO` sends no corrections. {% hint style="info" %} **AUTO needs your position.** The `AUTO` mountpoint chooses the base station from the position the sensor sends. Fixposition notes that a closest-base-station service needs an initial single 3D GNSS position, so set up the connection outdoors. Without a position, the login works, but no corrections arrive, see [NTRIP & GGA Essentials](/integration-hub/ntrip-clients-and-field-software/ntrip-and-gga-essentials.md#what-happens-when-gga-is-not-sent) and [Why does a robot have to send its position as GGA?](/integration-hub/robotics.md#why-does-a-robot-have-to-send-its-position-as-gga) {% endhint %} {% endstep %} {% step %} ### Save and apply Click **Save and apply**. The **Correction data** card then shows **connected**. The client keeps trying to connect by itself and reconnects after 10 seconds without data, so use **Restart client** only if the connection hangs. **connected** means that the login worked; it does not yet show a fix. {% endstep %} {% step %} ### Check the fix outdoors Go outdoors with a clear view of the sky, open **Status** > **GNSS** and check the values in [How do you check that both GNSS receivers reach RTK Fixed?](#how-do-you-check-that-both-gnss-receivers-reach-rtk-fixed) below. On the XVN, Xsens calls this page the **Status Dashboard**. {% endstep %} {% step %} ### Start the Fusion Open **Status** > **Fusion** and click **Start**. Move the platform under **RTK fixed** in figure eights or a zigzag until the IMU has converged. Fixposition gives about 3 minutes for the first use. {% endstep %} {% endstepper %} ## How do you check that both GNSS receivers reach RTK Fixed? Open **Status** > **GNSS** outdoors: the **Correction data** table should show **connected** to RTKdata and the stability badge **Good** under **Evaluation** in the recent rows, and **Fix type** should show **RTK fixed** for both **GNSS 1** and **GNSS 2**, with a **Baseline** preferably below 15 km. | What you check | Where on **Status** > **GNSS** | Expected | | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Connection to RTKdata | **Correction data** | **connected** | | Stability of the stream | **Evaluation**, first badge, in the rows **Last 10 seconds** and **Last minute** | **Good**. The longer rows can still show **Warning** after a change of the NTRIP settings or an internet outage; Fixposition's PBx-A1 quick start guide shows **Warning** in **Last 15 minutes** and **Last 30 minutes** next to **RTK fixed** on both receivers | | Usability of the stream | **Evaluation**, second badge. Some sensor software shows a single **Stability** column instead of **Evaluation**, without a Usability badge; check **Good** there | **Complete** or **Incomplete**. Not a failure criterion, see the FAQ below | | Fix | **Receivers**, **Fix type** for **GNSS 1** and **GNSS 2** | **RTK fixed** on both receivers | | Distance to the base station | **Baseline**, for each receiver | Fixposition recommends a station closer than 15 km; beyond 25 km, **RTK fixed** becomes unlikely | | Antennas | **Antenna state and power**, for each receiver | **OK** and **On** | | Signals | **Signal levels** | Most signals above 42 dBHz, according to the quick start guide | * The Fusion initializes only when both receivers report **RTK fixed**. * The rows of the **Correction data** table appear only once the stream has run for a while, and a change of the NTRIP settings can cause artifacts. Do not judge the stream right after **Save and apply**. * Latency and stability values are reliable only when the sensor's system time is synchronized with NTP or GNSS. * If **RTK fixed** does not come within two minutes, the quick start guides advise moving away from obstructions, keeping USB3 connectors, lidars and unshielded cables away from the GNSS antennas, and checking that the base station is closer than 25 km. * Optional, on a Linux computer in the same network: `nc` on port `23010` of the sensor shows the correction stream that the sensor receives from the caster, as Fixposition's page [Debugging NTRIP connection](https://docs.fixposition.com/fd/debugging-ntrip-connection) describes: ```bash nc 23010 ``` * Do not test with u-center's **Receiver** > **NTRIP Client** and the same RTK credentials while the sensor is connected. That opens a second connection on the same data stream, and the two connections disconnect each other. {% hint style="info" %} **Which RTCM messages arrive.** RTKdata streams RTCM 3.2 with MSM4 messages (1074, 1084, 1094, 1114, 1124, 1134) and 1005, which covers the station position and MSM observations for GPS, GLONASS, Galileo and BeiDou that Fixposition lists as required. Fixposition also lists RTCM 1230. RTCM 1230 (GLONASS code-phase biases) comes from the base station, and most RTKdata base stations do not send it. Without it, a receiver from another manufacturer than the base station cannot fully resolve the GLONASS ambiguities, so GLONASS does not contribute to the fix. GPS, Galileo and BeiDou are not affected. {% endhint %} ## How do you use RTKdata with a sensor that has no internet? Set **Source** to **I/O port** and feed the RTCM corrections from an NTRIP client on another device into one of the sensor's I/O ports; that client also has to send a position to RTKdata, because in this mode the sensor sends none. * **I/O port** takes RTCM over the serial ports or the network ports of the sensor (TCP `21000` to `21004`, UDP `21010` and `21011`). The built-in NTRIP client is off in this mode. * **Position for the external client:** Fixposition names the output message `NMEA-GN-GGA_NTRIP` for a client that needs the sensor's position. Without a position, `AUTO` sends no corrections. * **One input per network port:** Fixposition states that a network port handles only one input stream correctly. Do not send wheel speed and corrections into the same port. * **Exactly one NTRIP client per data stream:** with **I/O port**, the built-in client is off. Do not leave **Source** on **NTRIP client (auto)** while an external client logs in with the same RTK credentials. * **TCP client** connects to a raw TCP source without user, password or mountpoint and is not used with RTKdata. **ROS 2.** Fixposition's ROS 2 driver `fixposition_driver_ros2` passes RTCM corrections from a ROS topic to the sensor: the topic is set with `corr_topic` in the driver's `config.yaml`, which comes with `/rtcm`. Fixposition's guide [How to send RTCM3 messages via ROS](https://docs.fixposition.com/fd/how-to-send-rtcm3-messages-rtk-corrections-via-ros) uses the ROS 2 package `ntrip_client` as the NTRIP client and sets **Source** to **I/O port**. * As the position source for `ntrip_client`, use the driver's `sensor_msgs/msg/NavSatFix` topic `/fixposition/gnss1` on the `fix` input of `ntrip_client`. According to the driver maintainer in [issue #106](https://github.com/fixposition/fixposition_driver/issues/106), this topic carries data only when the output message `NOV_B-BESTGNSSPOS_GNSS1` is enabled on the sensor port that the driver reads, under **Configuration** > **I/O**, **Output messages**. * The sensor outputs GNSS messages at about 5 Hz by default, and `ntrip_client` sends one GGA to RTKdata for each `NavSatFix` on `fix`, without a rate limit. For GGA at about 1 Hz, switch on the advanced view with the toggle in the header of **Output messages** and set the rate of `NOV_B-BESTGNSSPOS_GNSS1` to `5` on the sensor port that the driver reads: the sensor then outputs one of every five messages, and `/fixposition/gnss1` runs at about 1 Hz, also for other nodes that read it. See [GGA Rate Recommendation](/integration-hub/ntrip-clients-and-field-software/ntrip-and-gga-essentials.md#gga-rate-recommendation). * `ntrip_client` subscribes to `fix` as reliable, and a reliable subscription receives nothing from a best effort publisher. The driver publishes its topics with the QoS profile that `qos_type` in its `config.yaml` selects, and the shipped file selects a sensor data profile, which is best effort. Check with `ros2 topic info /fixposition/gnss1 --verbose` that the publisher shows `Reliability: RELIABLE` and that `ntrip_client` appears as a subscription. If the publisher shows best effort, `ntrip_client` receives no position and `AUTO` sends no corrections; the comment next to `qos_type` in `config.yaml` lists the profiles the driver accepts. See the QoS notes in the [ROS 2 NTRIP Client](/integration-hub/ntrip-clients-and-field-software/ros2-ntrip-client.md) guide. * Build the driver from its main branch as of August 2026 or use a release newer than 8.1.0: in release 8.1.0, every TCP read is capped at 8 bytes, which [pull request #115](https://github.com/fixposition/fixposition_driver/pull/115) fixed on the main branch. * For the `ntrip_client` parameters, such as host, port, mountpoint and the quoted username and password, use the parameter file in the [ROS 2 NTRIP Client](/integration-hub/ntrip-clients-and-field-software/ros2-ntrip-client.md) guide. That guide does not cover the Fixposition driver, and RTKdata has not tested this chain. ## Which RTKdata mountpoint fits the sensor's maps and waypoints? Use the RTKdata mountpoint `AUTO_WGS84` or `AUTO_ITRF2020` when the robot's maps and waypoints are in WGS 84, and `AUTO` when they are in your regional datum or were recorded on `AUTO`; keep one mountpoint for the whole project. | Mountpoint | Delivers | Use it when | | ------------------- | ---------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | | **`AUTO`** | **Recommended.** Your region's datum, see [Coordinate Systems & Datums](/get-started/coordinate-systems-and-datums.md) | Maps and waypoints are in the regional datum or were recorded on `AUTO` | | **`AUTO_ITRF2020`** | ITRF2020 at the current epoch | Maps and waypoints are in WGS 84 or ITRF2020 | | **`AUTO_ITRF2014`** | ITRF2014 at the current epoch | The project requires ITRF2014 | | **`AUTO_WGS84`** | WGS84(G2139) at the mid-year epoch | Maps and waypoints are in WGS 84 | * Fixposition states that the sensor's output is always in the datum of the correction service, and that it uses the WGS84 parameters for latitude, longitude and height. With `AUTO`, these outputs are therefore in your regional datum, for example NAD83(2011) in the USA, ETRS89 (realization ETRF2000) in Europe and GDA2020 in Australia, although the sensor treats them as WGS84. * A constant offset of 50 cm to 1 m against WGS 84 maps or waypoints is then a datum mismatch, not an accuracy problem, see [Why Your Coordinates May Be Offset](/get-started/coordinate-systems-and-datums.md#why-your-coordinates-may-be-offset). * Keep one mountpoint per project: maps recorded on `AUTO` and waypoints from a global mountpoint do not line up. More on this in [Which RTKdata mountpoint fits a robot's maps and waypoints?](/integration-hub/robotics.md#which-rtkdata-mountpoint-fits-a-robots-maps-and-waypoints) * Heights from RTKdata are ellipsoidal. For heights above sea level, apply a geoid model, see [Understanding Heights](/get-started/understanding-heights.md). ## Troubleshooting | Problem | Cause | Fix | | -------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Correction data** never shows **connected** | No internet for the sensor: Ethernet still on **dhcp-server**, **Default route** None, or outbound TCP on port `2101` blocked; or the hostname does not resolve | Set Ethernet to **dhcp-client** or **static-ip** with **Gateway**, check **Default route**, allow outbound TCP on port `2101`, then try the IP fallback for your region, see *If the hostname does not connect* below | | The **Internet** indicator in the navigation bar does not match the NTRIP status | The indicator only checks whether the sensor can ping `8.8.8.8` and does not test port `2101` | Go by **connected** in the **Correction data** card | | **connected**, but no corrections and no **RTK fixed** | **Position** is **None** or **Manual**, the mountpoint is not `AUTO` in capitals, or the sensor has no position of its own yet (indoors, in a hall) | Set **Position** to **Automatic**, type `AUTO`, and connect outdoors once the receivers have a position | | **NTRIP client (auto)** does not connect, although network, host and credentials are right | The automatic version choice does not work with the caster | As a second attempt, select **NTRIP client (v1)** or **NTRIP client (v2)**. Fixposition describes these options as a help when the automatic choice does not work with a particular caster | | Login rejected | The website login was used instead of the RTK credentials, or a space at the start or end; or the sensor does not accept a character in the password | Enter the username (starts with `rtk`) and the password from *RTK Credentials* in **User** and **Password**. If it is still rejected, contact | | Stability **Good**, but no **RTK fixed** | **Antenna state and power** not **OK** and **On**, an antenna that Fixposition does not list as compatible or a combination antenna with LTE or Wi-Fi, USB3 connectors, lidars or unshielded cables near the antennas, or a **Baseline** above 25 km | Check **Antenna state and power** and **Signal levels**, use compatible GNSS antennas, move cables and devices away from the antennas, and check the site on the [Coverage Map](/get-started/coverage-map.md) | | Fix keeps jumping between **RTK fixed**, **RTK float** and single, or corrections drop every few seconds | A second connection on the same data stream: an external client in an **I/O port** chain while the built-in client is still on, u-center's NTRIP client used for testing, or a second robot with the same credentials | Exactly one NTRIP client per data stream and one data stream per robot connected at the same time, see [How many data streams does a robot fleet need?](/integration-hub/robotics.md#how-many-data-streams-does-a-robot-fleet-need) | | Login fails after a configuration was restored with **System** > **Tools** > **Backup and restore** | According to Fixposition, a backup cannot read passwords from the sensor, so a backup file carries no NTRIP password unless one is added by hand | Enter **User** and **Password** on each sensor after the restore, with its own data stream for each robot connected at the same time | | Changes cannot be saved | The Fusion is running | **Status** > **Fusion** > **Stop**, make the changes, **Save and apply**, then **Start** | | The sensor restarts again and again, and the NTRIP connection drops each time | The power supply is too weak, or, with the I/O connector in use, its pin 3 is not wired as Fixposition requires for your hardware version | Use a stable 5 to 36 V supply that delivers 10 W (Vision-RTK 2), do not run the sensor from a laptop USB-C port, and check the I/O connector on Fixposition's [troubleshooting page](https://docs.fixposition.com/fd/troubleshooting) | | Web interface not reachable after the network change | The sensor has a new address: behind a router, `10.0.1.1` and `10.0.2.1` no longer apply | Open the address the router assigned or `http://fp-xxxxxx.local/`. On the Vision-RTK 2, use the USB-C recovery access at `http://10.0.3.1`. The PBx-A1 has no recovery route | | No corrections after a software update | The correction settings may no longer match the RTKdata values | Check **Configuration** > **GNSS**: **Source**, the five fields and **Position**, and enter the RTKdata values again. A factory reset is not a fix: it also clears the network configuration and the GNSS correction configuration | | The NTRIP settings show one **Address** field instead of **Host** and **Port** | Older sensor software | Ask the manufacturer for a software update; the labels on this page follow the current Fixposition manual. Fixposition's older screenshots show host and port together in this field | | Constant offset of 50 cm to 1 m against maps or waypoints | Datum mismatch between `AUTO` and the maps | Use `AUTO_WGS84` or `AUTO_ITRF2020` for WGS 84 maps, see [Which RTKdata mountpoint fits the sensor's maps and waypoints?](#which-rtkdata-mountpoint-fits-the-sensors-maps-and-waypoints) | | ROS 2: `ntrip_client` connects, but no corrections arrive | No position reaches RTKdata: `/fixposition/gnss1` carries no data, or the driver publishes it best effort while `ntrip_client` subscribes as reliable. In the second case, `ros2 topic echo` still shows data, because it adapts its QoS to the publisher, and the `ntrip_client` log shows `offering incompatible QoS` | Enable `NOV_B-BESTGNSSPOS_GNSS1` on the sensor port that the driver reads, and check with `ros2 topic info /fixposition/gnss1 --verbose` that the publisher shows `Reliability: RELIABLE`, see [How do you use RTKdata with a sensor that has no internet?](#how-do-you-use-rtkdata-with-a-sensor-that-has-no-internet) | ### If the hostname does not connect Keep the hostname for your region whenever it connects. Use the IP fallback only if **Correction data** stays without **connected** although the sensor has internet, for example because the network's DNS server does not resolve the hostname: enter the IP for your region in **Host** and keep port, credentials and mountpoint. | Region | Hostname (preferred) | IP fallback for **Host** | **Port** | **Mountpoint** | | ------------- | -------------------- | ------------------------ | -------- | -------------- | | North America | `rtk.rtkdata.com` | `13.56.117.10` | `2101` | `AUTO` | | Europe | `eu.rtkdata.com` | `3.73.41.96` | `2101` | `AUTO` | | Australia | `aus.rtkdata.com` | `54.206.56.130` | `2101` | `AUTO` | For connection problems that are not specific to Fixposition sensors, see [Common Connection Issues](/support/common-connection-issues.md) and [Troubleshooting & FAQ](/support/troubleshooting-and-faq.md). ## Frequently asked questions ### Does the Vision-RTK 2 need two RTKdata data streams for its two GNSS receivers? No. One RTKdata data stream per sensor is enough: Fixposition states that "A single RTK correction data stream is required. It is used for both GNSS receivers." The built-in NTRIP client holds one connection and passes the corrections to both receivers. You need a second data stream only for a second sensor or robot that is connected at the same time, see [Account & Credentials](/get-started/account-and-credentials.md#using-one-subscription-with-several-devices). ### Is the Xsens Vision Navigator the same as the Fixposition Vision-RTK 2? Yes, according to Clearpath Robotics, which states that the Fixposition Vision RTK 2 "is also known as the Movella XVN (Xsens Vision Navigator)". Xsens describes the same built-in NTRIP client under **Configuration** > **GNSS** > **Correction data**, with **User**, **Password**, **Host**, **Port** and **Mountpoint**. Use the RTKdata values on this page in the same fields, with **Position** set to **Automatic**. ### Why does Usability show Incomplete while both receivers are RTK fixed? **Usability** rates the presence and frequency of certain RTCM messages, according to Fixposition, so it can show **Incomplete** while both receivers report **RTK fixed**. Fixposition's own PBx-A1 quick start guide shows **Incomplete** next to **RTK fixed** on **GNSS 1** and **GNSS 2** in its example. What counts for the RTKdata setup is **connected**, the stability badge **Good** and **RTK fixed** on both receivers. ### Which NTRIP version should I select: auto, v1 or v2? Select **NTRIP client (auto)**, which chooses the NTRIP version automatically. RTKdata works with both NTRIP version 1 and version 2. Select **NTRIP client (v1)** or **NTRIP client (v2)** only as a second attempt if **NTRIP client (auto)** does not connect although network, host and credentials are right. ### Does GLONASS contribute to the RTK fix with RTKdata? In most cases, no. RTCM 1230 (GLONASS code-phase biases) comes from the base station, and most RTKdata base stations do not send it. Without it, a receiver from another manufacturer than the base station cannot fully resolve the GLONASS ambiguities, so GLONASS does not contribute to the fix. GPS, Galileo and BeiDou are not affected. ## Quick reference ``` Source: NTRIP client (auto) User: (from RTKdata dashboard, starts with "rtk") Password: (from RTKdata dashboard) Host: eu.rtkdata.com / rtk.rtkdata.com / aus.rtkdata.com Port: 2101 Mountpoint: AUTO Position: Automatic ``` 1. Open the web interface: `http://10.0.2.1/` or `http://fp-xxxxxx.local/` with the laptop straight on Ethernet, `http://.local/` on the PBx-A1. 2. **Configuration** > **Network**: set **Ethernet** to **dhcp-client** behind a router or **static-ip** with **Gateway** and **DNS**; **Default route** must show Ethernet. 3. **Status** > **Fusion** > **Stop**. 4. **Configuration** > **GNSS**, card **Correction data**: **Source** **NTRIP client (auto)**, **User** and **Password** from *RTK Credentials*, **Host** `rtk.rtkdata.com`, `eu.rtkdata.com` or `aus.rtkdata.com` (IP fallback `13.56.117.10`, `3.73.41.96` or `54.206.56.130`), **Port** `2101`, **Mountpoint** `AUTO`, **Position** **Automatic**, **Save and apply**. 5. Outdoors, **Status** > **GNSS**: **connected**, **Good**, **RTK fixed** on **GNSS 1** and **GNSS 2**, **Baseline** preferably below 15 km. 6. **Status** > **Fusion** > **Start**, then move the platform under **RTK fixed** in figure eights or a zigzag. 7. One data stream per sensor connected at the same time; keep maps, waypoints and mountpoint in one datum. ## Related Guides * [Clearpath OutdoorNav](/integration-hub/robotics/clearpath-outdoornav.md): RTKdata on Clearpath robots, whose XVN web interface opens from OutdoorNav * [Robotics](/integration-hub/robotics.md): how RTK corrections reach a robot, which robots have an RTKdata guide and how many data streams a fleet needs * [ROS 2 NTRIP Client](/integration-hub/ntrip-clients-and-field-software/ros2-ntrip-client.md): the `ntrip_client` parameter file and QoS notes for a setup with **I/O port** * [NTRIP & GGA Essentials](/integration-hub/ntrip-clients-and-field-software/ntrip-and-gga-essentials.md): why the caster needs the sensor's position before it sends corrections * [NTRIP Server Settings](/get-started/network.md): the regional hosts, IP fallbacks, port and mountpoints in one reference * [Account & Credentials](/get-started/account-and-credentials.md#using-one-subscription-with-several-devices): where to find your RTK credentials and why each robot connected at the same time needs its own data stream * [Coordinate Systems & Datums](/get-started/coordinate-systems-and-datums.md): which datum `AUTO` and its variants deliver in each region * [Understanding Heights](/get-started/understanding-heights.md): ellipsoidal and orthometric heights, and how to apply a geoid * [Coverage Map](/get-started/coverage-map.md): check the station coverage where the robot works * [Common Connection Issues](/support/common-connection-issues.md): what to check when corrections do not arrive or the fix stays on Float * [Troubleshooting & FAQ](/support/troubleshooting-and-faq.md): port 2101, firewalls and carrier restrictions * [Enterprise & Volume](/commercial/enterprise-and-volume.md): volume licensing for robot fleets ## Related Industry Solutions * [Robotics](https://rtkdata.com/robotics/) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.rtkdata.com/integration-hub/robotics/fixposition-vision-rtk-2.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.