What is a NTRIP Caster: Network Transport of RTCM data over IP (NTRIP) is a protocol used to transport RTK correction data over the Internet. The correction data is moved in a way similar to that of streaming audio. Essentially a client connects to some device serving the stream and requests a copy of that data. Transporting RTK correction data over the Internet is an alternative to using radios to transport the data. The GNSS receivers don’t know or care how the correction data gets to them, so we can transport it in any way as long as the bytes are in the same order when they get to the rover.
Terms: The NTRIP software components were named poorly, causing confusion about which pieces wait for connections, and which ones initiate requests.
In this scenario, the Caster will commonly live in a data center since it just moves data. Each base station is has a serial connection to a NTRIP Server, which encapsulates the data into TCP/IP packets and sends them to the caster.
If you manage a NTRIP Caster, you will need to ensure that your firewall allows TCP packets in to the caster software on whatever port number it is listening on. Both the NTRIP Server(s) and NTRIP Client(s) will connect to your Caster on its public IP at that port number.
If you manage a NTRIP Server, you do not need to do anything special on your firewall. A NTRIP Server functions as a TCP/IP client, meaning that it initiates the connection to the Caster. You will need to know the IP address and port number of the Caster, and also the mount point (stream) and password to send data in to that mount point.
In this scenario, the Caster will commonly live in an office or home, physically close the the base station. There has to be a serial connection between the RTK Base Station and the computer, which means you are limited to the maximum distance your cables can carry the serial data.
NTRIP Clients will need to connect to the caster, which means you will need to have: — A reliable computer with at least one serial port. — A reliable Internet connection. — A static IP address from your Internet provider (so the public IP address doesn’t change). — Configure your firewall to allow TCP port forwarding to the internal IP address of the computer running the Caster software. — The Caster should also have a manually assigned IP address on the internal network so that the firewall is always forwarding the incoming data to the correct device.
An NTRIP Caster is the real server element in the overall NTRIP system. SNIP is an NTRIP Caster. Go to SNIP download page
An NTRIP Caster takes data from one or more data stream sources (Base Stations referred to as NTRIP Servers) and provides this data to one or more end users (often called rovers), the NTRIP Clients. If you need to send data to more than one client at a time, or have more than one data stream, you will need a Caster.
NTRIP Servers are typically GNSS reference stations of various quality levels with a thin layer of software to connect to and push data out to a Caster over an internet connection using HTTP. These days, most GNSS devices intended for use as reference station have the NTRIP server functionality built directly into them. Many lower cost GNSS devices do not provide this ability, but can use SNIP to connect directly with either serial or TCP/IP links.
Typically the NTRIP Clients are GNSS rover devices in the field with a thin layer of software to connect to the Caster and to feed the resulting data stream directly into the GNSS device by way of a serial port. In more advanced GNSS devices, this software is built directly into the rover.
Need an NTRIP Client? Here is a list of popular software.
Сервер NTRIP представляет собой широковещательный интернет-сервер, управляющий проверкой подлинности и паролями для источников дифференциальной коррекции, таких как сети VRS, и транслирующий поправки из выбранного вами источника.
Настройте параметры NTRIP при создании GNSS контакта для Интернет канала передачи данных. При запуске съемки устанавливается соединение с NTRIP-сервером. Дополнительно появляется таблица, в которой отображаются доступные источники поправок с сервера, называемые «точка доступа». Это могут быть одиночные станции или сетевые источники (например, VRS). Тип данных базовой станции, предоставляемых каждой точкой доступа, отображается в таблице источников. Для определения ближайшего источника нажмите заголовок Расстояние отсюда для сортировки этого столбца. Базовые данные из выбранной точки доступа передаются через Trimble Access на подключенный приемник GNSS.
Если для соединения с отдельной точкой доступа требуется аутентификация, которая не была настроена в контактах GNSS, в программном обеспечении Trimble Access отображается экран, где вы можете ввести имя пользователя и пароль.
Версии протокола NTRIP
Когда ПО Trimble Access соединяется с сервером NTRIP, оно проверяет, поддерживает ли сервер протокол NTRIP версии 2.0, и, если это так, программное обеспечение ведет обмен данными с использованием протоколов версии 2.0. Если это не так, Trimble Access ведет обмен данными с использованием протоколов NTRIP версии 1.0.
Чтобы программное обеспечение всегда использовало NTRIP версии 1.0, установите флажок Использовать NTRIP v1.0 при настройке параметров NTRIP в GNSS контакте.
NTRIP версии 2 включает усовершенствования по сравнению с оригинальным стандартом. Trimble Access поддерживает следующие функции NTRIP версии 2:
Функция NTRIP 2.0
Преимущества по сравнению с версией 1.0
Полная совместимость с HTTP
Устранены проблемы с прокси-серверами.
Поддерживаются виртуальные хосты с использованием «хост-директивы».
RTK2go® is a community NTRIP Caster created to allow you to publish your GNSS correction streams for others to use with their NTRIP Clients. It is built using the same Pro edition of the SNIP Caster you can find on the use-SNIP.com site. Why do we do this?, because many of the RTK2go users here end up operating a SNIP network of their own. You can also download and evaluate your own copy of SNIP® from here. It is one part of the overall simple NTRIP™ project created by SubCarrier Systems Corp. (SCSC).
RTK2go: 500+ Public Base Stations, 30,000+ Users, 160,000,000+ Sessions, Professional Grade, and Free to use
Send your Base Station data to RTK2go ® if you do not wish to run your own NTRIP Caster. Please download your own copy of SNIP ® if you want to run your own NTRIP Caster.
Current average connection rates on this node:
100,000 connections per day, 400
500+ public data streams, with 5
Devices connecting with a URL use: rtk2go.com:2101
Devices connecting directly use: 3.23.52.207:2101
Current Status: Operational Running SNIP NTRIP Caster Rev 3.03 Today (Dec 6th) the Caster will be reset a few times as we bring up a new feature to support ‘region specific’ Caster tables.
It is now very strongly recommended that all data consumers (Rover devices) provide a valid email address in the user account name field when accessing the Caster. Please change your connection details to add a suitable email as the user name. When the SNIP Caster detects a user name that is a valid email and there is a reoccurring problem with the connection, you will be mailed an email informing you what the problem is and how to correct it. Should your IP be blocked after further bad connections, you will receive an email to notify you. You will receive at most one email per every 3 hours if the problem continues. We will not send you spam or use this email in any other way. With millions of bad connections now occurring every month, we have implemented this to better manage the service for all. Data providers (Base Stations, NTRIP Servers) should still use the registration information you received when you registered the Base. Please start doing this now, at the end of 2021 this will become required to use the RTK2go Caster.
Attention All Base Station Data Providers: Please Register before use (⇐ click here)
Having a prior registration is required for all data providers (Base Station owners) so that we have a valid email on record to contact you when your Base Station is not working. The process is quick, free, painless, and we will not send you spam. With millions of bad connections now occurring every month, we implemented this to better manage the service for all. Data consumers (NTRIP Clients) do not need to register but should provide an email in the user name field as per the above note.
RTK2go: This Caster accepts data from any valid NTRIP source including other SNIP nodes, the Simple NTRIP Caster, in the PUSH-Out mode, as well as from any other NTRIP Server software. It is not a web site. It is using a SNIP NTRIP Caster as a software service you can freely use (SaS). If terms like Caster, Client or NTRIP are unfamiliar to you, just click on these links for further explanations.
But if these terms are familiar to you, you probably want to know how to log on, see the below.
This is a simple “static page” web site as all the interesting things take place using the normal NTRIP protocol layers hosted on the same machine.
Terms of Use: By sending your data stream to this Caster you affirm that: a) You have the right to do so, and b) You consent to allow others to freely use your data, and c) The caster owner / operator shall be held harmless for any faults or loss – real or perceived. The caster owner / operator (SCSC) reserves the right to remove or block any party for abuse.
Useful details….
On SNIP
The RTK2go Caster is implemented with the SNIP NTRIP Caster using the same software you can purchase from our SNIP web site. It is running on an AWS 2-core Windows VM machine with a reliable internet connection. There are several thousand SNIP Caster deployments running both public and private NTRIP Caster networks all over the world. Over the past few years, SNIP has lowered the cost of professional grade NTRIP Caster ownership for GNSS professionals everywhere.
Worried about the lack of an available static IP at your planned site? No problem, we can help your setup a DDNS connection and register a proper name for your Caster to overcome this, just ask our support staff for details.
Do not have a dedicated server machine? No worries, SNIP works on common Windows 7, 8 and 10 machines as well as all Windows servers and various low cost virtual machines. The machine running this web site and also the RTK2go Caster with 400+ active Base Stations is just 2-core small Amazon AWS VM with an average
25% load utilization. The prior machine running the same web site and the RTK2go Caster with 300+ active Base Stations was a common Win7 box (4-core i5) with an average 12
15% load utilization.
Suggestions:
Are always welcome, please send them to support [at] use-snip.com We use your comments to help make SNIP the best NTRIP Caster in the world. Want to run your own copy, that’s why we are here.
SNIP® and RTK2go® are registered trademarks of SubCarrier Systems Corp. (SCSC). simple NTRIP™, PFAT™, and Simple NTRIP over IP™ are trademarks of SubCarrier Systems Corp. (SCSC).
If you wish to support RTK2go as a public service, please consider making a donation
BKG’s Open Source NTRIP Caster Running Under Docker
This repository contains the BKG NTRIP caster set up to run under docker.
To summarise: A GNSS receiver receives signals from GNSS satellites such as GPS and uses them to calculate its position. The signals are distorted by obstacles such as the ionosphere, which causes errors in the calculated position. The base station and the rover are both GNSS receivers. The base station is fixed in one spot and knows its position very precisely. Its observations of the satellite signals can be used to work out the distortion of the signals and thus correct the errors. A rover within a few kilometres of a base station can use these corrections to calculate its position accurate to 2cm. The NTRIP protocol provides the means for the base station to send data to the rover via the Internet. It does this via an intermediate server called an NTRIP caster.
I should also say at the beginning that you don’t necessarily need your own NTRIP caster. There are a number already available. Use your favourite seach engine to find them.
BKG’s caster software is free and open source. It implements NTRIP Version 1. NTRIP is now at Version 2. BKG offers a version 2 caster, but it’s not free or open source. If you are going to use the free caster, you need to check that your base station and rover can use a Version 1 service.
Docker provides a ready-made predictable environment in which you can build and run software. The steps to build and run a docker application are the same regardless of your operating system.
When docker runs an application, it creates a stripped-down Linux environment within whichever operating system your computer is actually running. This irons out most of the gotchas and makes success much more likely.
Each docker application is encapsulated in its own environment, which also reduces problems caused by hidden interactions. Two applications can only communicate through well understood interfaces.
This does mean that to put a solution together you may have to learn a few new skills, which is a cost, but most people find that the benefits of using docker far outweigh this. In particular, you need to understand how to use a UNIX command window. You can learn the basics of that using my dockerised learn package.
This document explains what NTRIP is, how to set up a suitable environment for your caster, how to build and run it and how to manage it once it’s running.
If you do need to run your own caster, read on.
Once you’ve downloaded the caster (see how below) and before you install it, you need to set up a couple of configuration files. They are called sourcetable.dat and ntripcaster.conf. The distribution includes an example of each file.
BKG’s original build and installation instructions are here They include some manual steps, to be followed once the software is built. Docker uses completely automated builds, so I’ve reworked the process so that you start by producing a couple of configuration files and the rest of the process is automatic.
There’s a copy of BKG’s documentation here. It may make more sense if you look at the example configuration files while you are reading it.
The important part is this:
«Go to the configuration directory and rename «sourcetable.dat.dist» and «ntripcaster.conf.dist» to «sourcetable.dat» and «ntripcaster.conf». Edit both files according to your needs. For details about «sourcetable.dat» see file «NtripSourcetable.doc». In the configuration file «ntripcaster.conf» you have to specify the name of the machine the server is running on (no IP adress!!) and you can adapt other settings, like the listening ports, the server limits and the access control.»
BKG’s instructions say: «Whatever the content of your «sourcetable.dat» finally might be, it is recommended to include the following line in that configuration file: CAS;rtcm-ntrip.org;2101;NtripInfoCaster;BKG;0;DEU;50.12;8.69;http://www.rtcm-ntrip.org/home».
That line is already in the example source table file so you can just leave it.
Apart from that first line, sourcetable.dat defines your mountpoints. You need one for each base station. I have one base station. It’s on the roof of my shed in Leatherhead in the UK. I call my mountpoint «uk_leatherhead».
Each line of sourcetable.dat is a list of fields separate by semicolons. Mine looks like this:
Field 1 of the second line is «STR» which says that it’s defining a mountpoint.
Field 2 «uk_leatherhead» is the name of my mountpoint.
Field 3 «Leatherhead» is the nearest town to my base station.
RTCM 3.0 means that the NTRIP connection is carrying RTCM version 3 messages, which is what my base station produces.
GBR is the three-letter code for the UK. You can find the two and three letter code for your country here.
«51.29;-0.32» gives the longitude and latitude of my base station. If you don’t have that information, you can use «0.00;0.00».
This file also lives in the directory conf (ntripcaster/ntripcaster/conf). You need to edit it to suit your needs.
The file defines all sorts of things, including the user names and password used to access the system.
All base stations use the same password. There’s no facility to specify a user name. (My base station software insists on supplying one, but for this caster ignores it, so it doesn’t matter what user name I use.)
There is a set of usernames and passords for each mountpoint which a rover needs to supply when it connects.
The lines you need to change are scattered through the file:
The last few lines of the file specify the user names and passwords for the rovers. You need one line for each of the mountpoints you specified in sourcetable.dat. In this file, the mountpoint names must start with «/» (but not in sourcetable.dat). For example:
creates user names «user1» and «user2» which a rover can use to connect to that mountpoint.
You can create a public mountpoint with no user name or password. Any rover can connect to that mountpoint:
Quick Instructions For Building and Running the Caster
These instructions are for readers who are familiar with concepts such as docker, remote management of computers, domain names, virtual private servers and so on. If you are not one of those people, continue to the next section.
The caster must run on a server machine on the public Internet. (I run mine on a Digital Ocean Droplet.) The server must have an Internet domain name, so you need to buy one of those and assign it to your server. (If you don’t understand all of that, read the more detailed explanation below.) When your configure your caster you have to put the same name in your configuration file.
I’m going to assume that you control your server via a sudo user rather than logging in as root, so I’m going to use the sudo command wherever necessary.
Log in to your server via a command window and install git and docker:
Installing docker ceates a UNIX group called «docker». To run the docker command, you need your user (the one you are logged in as on the server) to be in that group. In this example, the user is called «gps»:
The Docker service needs to be set up to run whenever your server machine starts up:
Download the caster:
That creates a directory called ntripcaster. Inside that is another directory with the same name plus a couple of other files. Inside the lower ntripcaster directory is the conf directory, where you create your configuration files:
Edit your configuration files sourcetable.dat and ntripcaster.conf as explained above.
Move back to the top level of the project and build your docker image:
The build will take a little while and at the end you should see something like this:
Running the Caster
Onc you’ve built the caster, run it like so:
«>/dev/null» connects the docker command’s standard output channel to a special file that just discards anything written to it. «2>&1» connects the standard error channel to whatever the standard output channel is connected to. That means that the docker image will run quietly, without sending anything to the console. The «&» at the end of the command runs it in the background, so you get another prompt and you can issue more commands. The caster will survive you ending the ssh session that you used to start it. It will run until something goes wrong and it dies, or until it’s forcibly shut down.
To view the running caster:
That produces a list of running docker containers, something like this:
So docker is running one container. Its container ID is fb90a0a44e14.
The container is running the image ntripcaster which we built earlier.
You need to know that container ID for various control purposes, as we wil see later.
For a quick check that the caster is working, if you have curl installed on your server, you can use it to fetch the caster’s home page:
(That’s http, NOT https.)
That request should produce a copy of the source table. This shows that the caster is running and that it’s found its configuration files.
Back on your local computer, if it’s got curl installed you can run a similar test to check that things are working across the Internet:
That should produce the same result as before. If the first test worked and this one doesn’t, the most likely explanation is that you haven’t arranged with your VPS provider to open up port 2101 to tcp traffic.
Stopping the Caster
The caster will run until you stop it or reboot the server machine.
To stop the container you need to find its container ID using docker ps as shown earlier. Given that, stop it like so:
Start the caster again as before:
The caster creates a log file as it runs, which you can use to debug problems. To see the log you have to know the ID of the container, in this example «fb90a0a44e14».
(By the way, BKG’s original installation instructions are slightly misleading. they say that to run the caster you should change directory to /usr/local/ntripcaster/bin and run the program from there. It will then pick up the configuration files from /usr/local/ntripcaster/conf and write a log file in /usr/local/ntripcaster/logs. Not quite. When the server starts up it creates a log file in the current drectory, whatever that is. So the docker image changes directory to /usr/local/ntripcaster/logs and runs the caster software from there, and the log ends up in the right place.)
If you connect a base station, the source value will increase by one. If you connect a rover, the client value will increase by one.
Use ctrl/c to stop the tail command.
There are a lot of acronyms in this field. I’ll start by unpicking some of them.
A Global Navigation Satellite System (GNSS) is a network of satellites that allows a receiver on the Earth to find its position accurately. The first and best-known was the Global Positioning System (GPS), originally created by the American military for missile guidance. GNSS systems now include the European Galileo, the Russian GLONASS and the Chinese Baidou. Each has its own network of satellites (known as a «constellation»). Many satellite navigation receivers are capable of picking up signals from all these systems and making use of any of them.
A moving receiver (for example a hand-held device, or in a car, a boat or an aircraft) that can see enough satellites can find its position reasonably accurately, typically to within three or four metres.
If the receiver knows that it’s in a fixed position it can do better by repeatedly finding its position and averaging the results. Most receiver have some kind of «fixed» mode, where they assume that they are stationary. The result depends on the device and on how long you leave it taking averages. You can achieve maybe 1m accuracy this way.
The Radio Technical Commission for Maritime Services (RTCM) produced a standard protocol for sending satellite observation data over a radio link. so a base station from one manufacturer can send observations to a rover from another manufactuer. This is called the RTCM protocol. It’s currently at version 3.
RTCM over radio is used for all sorts of purposes including the control of drones. The drone contains a GNSS rover which sends position information to its flight controller. The base station sits on the ground in a fixed position, sending GNSS data to the rover, which it uses to find its position more accurately. The two are connected via Long Range (LoRa) radio, which works over a few kilometres. The operator can pre-program the drone to follow a path around a site, avoiding obstacles.
This setup probably works well when the base station is in a prominent position and the rover is high in the air, so the two have line of site between them. If the rover is closer to the ground, for example in a hand-held tracker, obstacles such as buildings, trees and hedges can interfere with the radio connection and make it very flaky.
To provide a better alternative to RTCM over a radio link, the Bundesamt für Kartographieund Geodäsie (BKG) defined the Network Transport of Rtcm via Internet Protocol (NTRIP) which replaces the radio link with an HTTP connection over the Internet.
This requires the base station and the rover to be connected to the Internet and to be able to communicate with each other. To achieve that, one of the devices involved must have a published Internet location, ie a fixed IP address and a domain name. That’s the purpose of the caster. A caster takes NTRIP traffic from one or more base stations and routes it to one or more rovers. Having the intermediate caster means that neither the base station nor the rover need any fancy kind of Internet connection.
This is how it all works:
The base station sends data encoded in NTRIP format to a nearby rover via a caster. It sends its position and its recent readings («observations») of signals from the satellites that it can see. Knowing the base station’s position, it’s possible to work out what the signals ought to look like, and therefore what errors the distortion has introduced. If the moving rover is close to the base station, it sees the same satellites and suffers the same distortions, so it can use the base station’s observations to correct the errors in its own observations.
If the rover is within about 10 Km of the base station and the base station knows its position perfectly, the rover can find its position within 2 cm. Up to 20 Kilometres away it can produce 4 cm accuracy, and so on.
All this assumes that base station knows its position very accurately. If its notion of its position is wrong, the rover’s calculated position will be wrong by the same amount. Imagine you have rover close to a base station and and you move it around a site, measuring the positions of various features and draw a map. Each position on the map should be accurate to 2 cm. However, if the base station’s notion of its position is half a metre to the North of where it really is, your whole map will be shifted by half a metre to the North.
So getting everything to work properly mainly involves figuring out the position of the base station accurately.
Getting a Domain and Server
To run the caster, you need a server with a well-known name. You can achieve that by buying an Internet domain. Strictly you don’t buy a domain. You rent it from a domain registrar, so you have to pay regularly to keep it going.
You can obtain a domain from various domain registrars such as namecheap or ionos. There are many others. I mention those two because I know that their initial registration fees and their subsequent renewal fees are both reasonable. When choosing a registrar, always check the renewal fees. Beware of introductory offers that cost you a lot more later.
Once you have your domain name, you need a computer on the Internet that answers to it. You can rent a Virtual Private Server (VPS) rather than running your own machine. You may be able to find a VPS supplier that can also handle your domain registration.
You don’t need much computer power or network bandwidth to run an NTRIP caster, which is why you can use these cheap servers.
When you rent the VPS you can choose what operating system it runs. These instruction assume that you are running Linux rather than Microsoft Windows on your VPS. It’s more secure and more reliable.
Once you’ve hired your domain and your VPS, you need to configure the VPS to answer to the domain name. How to do that varies according to the two suppliers. Your VPS supplier’s tech support people should be able to explain how to do it, particilarly if you rent your domain from one of the better-known domain registrars such as Ionos or namecheap.
Each network service on a computer runs on a numbered port, for example, a web server will usually run its http service on port 80 and its https service on port 443. The NTRIP caster runs on port 2101. For security reasons many VPS suppliers stop access to ports by default. You have to ensure that port 2101 is open for tcp access. You may need to ask the tech support people how to do this.
Connecting to Your VPS
Once your VPS is set up and responding to your domain name, you need to connect to it from whatever computer you normally use. These instructions assume that you are running MS Windows on your local machine (because most people do) and that your VPS is running the Linux operation system (because that’s also what most people do). If you are running Windows on your VPS, the procedure to connect will be similar but different. You need to consult your VPS supplier about that. The docker commands will be the same.
There are various ways to connect to your VPS. The ssh command is probably the most common. Your Windows machine can’t do that out of the box, you need to install some software. My suggestion is git for windows. Once you’ve installed that, go to your start menu and run Git Bash. That starts a command window and you can run ssh in that.
To connect to your VPS you need your user name and your domain name. If your user name is «user» and your domain is «my.domain.name», connect like so:
If you didn’t create keys, you will be asked for your password when you connect to your VPS. That means you can connect to it from any computer, but so can anybody else who can guess your password. If you created a key pair, your VPS should be set up so that it’s only possible to connect from a computer that holds a copy of the private key. (So now would be a very good time to make a backup copy of your key pair on a memory stick.)
Logging in with a key pair means that you don’t have to remember yet another password. That’s not just convenient, it’s also much more secure. Your VPS supplier should have arranged that it’s not possible for anybody to log in over the network using a password.
To see why, once you are connected to your VPS, try this:
It shows the recent log of attempted logins. If you haven’t tried this before, the result is quite scary. This is what I got:
The line that says «Accepted publickey for root» is me connecting using my key. The rest show other people all round the world trying every few seconds to connect to my VPS by guessing user names and passwords. Ths will have started as soon as my domain was created and announced. One tried connecting as the user root, another tried as the user rabbtmq, another as fsc, and so on. Those user names are standard and exist on lots of servers. The hackers run software that guesses a password, tries to connect, guesses another password, tries to connect and so on. You can see which IP address they are coming in from, but they are probably using somebody else’s computer that they’ve already compromised.
If you allow connection by user name and password, it’s just a question of time before somebody makes a correct guess and gets in. That would be bad. They can use your VPS for all sorts of nefarious purposes, for which you could be blamed.
Prevent this by configuring your VPS to refuse logins over the network using a password. Consult your VPS supplier about how to do that. Keep a safe copy of your keys, otherwise you could lock yourself out as well as the hackers.
That’s the security sermon over. Now let’s build an NTRIP caster.
More on Installing the Caster
There’s a user called root that has special privileges. You need them to install things. Your VPS supplier may set things up so that you log in using another user that doesn’t have those privileges, but can get them.
If so, you get the extra privileges by putting «sudo» at the start of any command. Forcing you to use sudo is safer because those privileges also allow you to make disastrous mistakes. Having to start each dangerous command with «sudo» is a reminder to be careful. Using docker makes things even safer, because it automates all of the dangerous operations.
You don’t need to add «sudo» to the start of each command if you are logged in as the root user, because you already have the right privileges, but it does no harm. So you can copy and paste shown earlier into your git bash window whichever user you are logged in as, for example:
Concerning pasting, you can’t use the usual Windows shortcut ctrl/v to paste within the ssh window. Right click and a small menu appears with a paste option.)
To fetch the caster project, you did this:
which created a directory called ntripcaster
Then you need to edit your configuration files. If you are not familiar with Linux, use the editor nano, for example:
While you are in nano, move around the file using the arrow keys. The mouse doesn’t work. When you have finished editing the file, use ctrl/o to write your changes and ctrl/x to exit.
Once you’ve created those two configuration files, the instructions tell you to use docker to build your caster. The Dockerfile in the top level directory of your project looks something like this:
The directives in the Dockerfile automate a build and deploy process which is similar to the steps described by BKG’s original installation instructions. Tit runs in two stages. The first stage installs the software needed to build the executable program, and then builds it. That’s done just once when you run the the «docker build» command. That material is then all cleared away. When you run the server using «docker run» that invokes just the second stage, which takes the built executable program and runs it.
The first FROM directive defines which version of Linux docker will run the build stage, in this case Ubuntu 18.4. Check the website for Linux distribution you are using and choose the latest stable version. For Ubuntu, that’s this page. Choose the LTS version.
The top level directory of your project contains the Dockerfile and a directory ntripcaster. The COPY copies the contents of that directory into a workspace.
WORKDIR sets the current directory to that workspace.
The version of Linux that docker creates is very minimal and it doesn’t contain any software build tools. The first RUN installs what’s needed. The second one uses them to configure the caster for this Linux environment and the third one uses the make tool to build and install the caster.
The second FROM directive starts the second stage. Again it specifies which version of Ubuntu to use.
the COPY directive fetches the executable program produced by the build stage.
When the caster runs, it accepts network connections on port 2101. The EXPOSE allows the rest of the system to access that port.
The next directive WORKDIR sets the working directory when the docker image is run. When the program starts running it creates a log file in the current directory. The workdir sets that to /usr/local/ntripcaster/logs.
The CMD directive runs a command when the docker image is started. In this case the container will run the caster with the WORKDIR as the current directory. The container runs until that program terminates. Normally it runs indefinitely.
To build your docker image, you move to the top level directory of the project and run:
Note the «.» which means «the current directory». Docker looks in the given directory for a file called Dockerfile and obeys the directives in it.
You can run the image like so:
The «docker run» ties up your git bash window. You can start another and use ssh to connect to your server machine as before.
Killing the docker container stops the service:
When the container stops, the Linux image that was running and any files in it are destroyed, The advantage of that is that you don’t have to do any tidying yourself. The disadvantage is that if something goes wrong and the caster crashes, the container dies and all evidence vanishes with it.
You can set up the docker image so that things like the server log file survive. Read the docker manual to find out how.
Whenever you change anything in the project, you need to run the docker build again. That will produce a new image.
When you started the docker image earlier, it tied up your git bash window. To avoid that, start the image using this magic:
«>/dev/null» connects the command’s standard output channel to a special file that just discards anything written to it.
«2>&1» connects the standard error channel to whatever the standard output channel is connected to. That means that the docker image will run quietly.
The «&» at the end of the command runs it in the background, so you can issue more commands.in that window.
The caster will run until something goes wrong and it dies, or until it’s shut down.
If you run «docker ps» again, you will see that the container ID is different. Running a docker image creates a new container.
The docker container is a complete separate Linux environment and if you know its container ID you can run commands in it. For example, if the container id is f473f0749fd0, this will run the ps command in the container, which shows you what programs are running there:
The running programs include the ps that you are running to see this output.
More potential confusion:
is a docker command that lists the running containers.
is a linux command that lists the running programs. The two commands do similar jobs and one is named after the other.
You can configure your server machine to run a command whenever it starts. Unfortunately, how to do that depends on what version of Linux you are running. (Not to be confused with the version that you specified in the Dockerfile. That’s what runnin within the container.)
I’m running Ubuntu on my VPS, and a Google search led me to https://askubuntu.com/questions/814/how-to-run-scripts-on-start-up. The relevent part is «The upstart system will execute all scripts from which it finds a configuration in directory /etc/init. These scripts will run during system startup (or in response to certain events, e.g., a shutdown request) and so are the place to run commands that do not interact with the user; all servers are started using this mechanism.»
Configuring Your Base Station and Rover
Configuring your base station and your rover depends on what you are using. Read the manuals. You will need to supply the information that you set up in the ntripserver.conf configuration file. Both will need the server URL, port (2101), and mountpoint name. The base station should use the encoder password (and any user name). The rover will need the user name and password for the mountpoint that it’s going to use.
When any of your devices connect to the caster, you should see some activity in the caster’s log on your VPS.
Tweaks to The Original Source Code From BKG
The caster is free software originally written in C by BKG and distributed by them. I would have preferred to use that as my starting point, but when the time came, I couldn’t find it. Instead I used a copy on github: https://github.com/nunojpg/ntripcaster.
There are a huge number of ready-made projects out there written in C and C++ that you can download, build and run. The procedure tends to be:
If you can automate the whole process, including any configuration tweaks, you can use docker to build the project and run the result. This section may be useful if you want to do that.
The software is built using the make command. There is a file called makefile in each directory that tells make what to do.
The configure command runs another command automake which creates each makefile from a template called makefile.in and the settings in makefile.am.
To automate the manual configuration step, I edited Makefile.am and Makefile.in in the conf directory. The etc_DATA setting controls the files that are copied from that directory when the software is installed. The original contains:
so only those two files are copied.
In my version that becomes
Now when docker runs «make install», it copies four files from the conf directory rather than two.
So you just have to create ntripcaster.conf and sourcetable.dat and then run docker. It runs configure, which runs automake to create the makefiles, then it runs make to build and install the software.
Actually, what’s supposed to happen is that the template Makefile.in is edited by automake based on the settings in Makefile.am, so it should only be necessary to change makefile.am. I think what’s happened is that somebody has run configure and then committed the result, so I’ve inherited a Makefile.in that is not the original version. Ah well, that’s the fun world of open-source software for you.
Commercial NTRIP services
A number of GNSS devices can send and receive NTRIP corrections, notable manufacturers include Emlid; U-Blox; Trimble and Leica.
There are also a number of sources of NTRIP correction data. Trimble and Leica both provide these across the world for their own devices and others, but their services are expensive (hundreds of dollars per month). For somebody like a sureveyor working in the Oil and Gas sector, this makes a lot of sense: wherever you are in the world, your rover will receive some sort of correction data, making it more accurate than it would be otherwise. In places like Western Europe, it wlll be accurate to within a few centimetres.
There are free NTRIP services such as the International GNSS Service (IGS). and rtk2go.com, provided by snip.com, a company that makes and sells commercial NTRIP software. The free services are very limited, with just a few base stations scattered over large distances. For example, my nearest IGS mountpoint is at Herstmonceaux. If I lived in Brighton or Eastbourne, that would be great, but I don’t. I’m about 60 Km away. The corrections are useful at that distance, but running my own base station is better.
The rtk2go.com NTRIP service allows you to connect your own base station and share its corrections with other people. Unfortunately, a lot of the base station owners (in the UK at least) seem to switch them off when they are not using them. All the ones near me are only on occasionally. Also, the service is only free now while it’s in beta test. The owners say that they plan to charge for it eventually.
In the past, GNSS devices that could produce NTRIP corrections were expensive, but recently that’s changed.
In 2019, U-Blox launched the ZED-F9P, a dual-band chip which can be used in a base station or rover. As a rover it can find its position to within half a metre witout a correction source. With suitable corrections, to 2cm.
Sparkfun sell a version of the U-Blox chip mounted on a circuit board. It can be connected to a Raspberry Pi to produce an complete base station. No electronics knowledge or soldering needed.
