Professionals have used dual-frequency positioning receivers (SatNavs) for many years. But they are expensive. Recently, much lower-cost dual-frequency receivers have become available, such as the u-blox ZED-F9P. This receiver can operate as a regular positioning receiver, with or without RTK, or as a source of RTK corrections (RTK base station). Dual-frequency operation means that the receiver has more signals to play with, so you get a better position fix. It also means that the receiver can deduce the ionospheric corrections without the need for SBAS (also known as DGPS). The ZED-F9P receives all four constellations of satellites which are currently flying, so it has a large number of signals available. This is also an advantage for RTK, because it means the algorithm can converge in one or two seconds if you are close to the RTK base station or if you are using a Virtual Reference Station (VRS).

First, some notes on support software for the ZED-F9P. U-blox only provide Windows versions of u-center and the drivers. However, u-center works well under Crossover for Mac, so I expect it would also work under Wine. One notable thing which doesn’t work under Crossover is the firmware installer. (You are going to need the firmware installer if you brick the ZED-F9P. I have had a lot of problems with bricking the Ardusimple RTK2B, although I have not had similar problems with the u-blox C099-F9P evaluation board. I went for the RTK2B because I found the bluetooth interface on the C099-F9P had a very long delay.) The driver for the USB port of the ZED-F9P is only available for Windows 10. But for those using previous versions of Windows, the ZED-F9P works fine with the older USB driver, the one with version number 1.2.0.8, if you change the USB PID from 01A9 to 01A8. You cannot do this through the ‘old’ configuration interface, but you can do it through the ‘new’ configuration interface. You will need to make sure that certain other u-blox drivers are not installed because they interfere with the operation of the 1.2.0.8 driver. Given that you can’t connect to the USB port, you will need to connect to the UART port to change the USB PID. You can do this through a USB-serial interface chip such as those made by FTDI or Prolific. Both of the boards I mentioned have FTDI chips on them, but note that u-blox have changed the USB VID and PID of the FTDI chips on the C099-F9P and they will only work with the dedicated driver (Windows-only) provided by u-blox. On Mac OS, no driver is needed for the USB port of the ZED-F9P because the OS recognises it as a USB modem and provides a generic driver.

RTK is a technique for obtaining positions accurate to one centimetre, or a few centimetres. It uses a second, fixed receiver, preferably within 20km, to provide correction signals to the moving receiver. RTK brings some practical problems. The software for doing RTK can be complex, and difficult to configure. This is avoided if you use the ZED-F9P because the RTK processing is done by the receiver and you get a corrected position in real-time. But running the RTK in the receiver, creates a new problem. Where can you find a real-time stream of correction signals from a receiver not too far away? There are subscription services which have access to a large number of reference stations (RTK base stations) and some of these services synthesise a station in the user’s vicinity (VRS). But these services are expensive. In Europe, there is the EUREF Permanent Network which makes real-time streams available from a limited selection of reference stations. Some countries are more generous than others, in the number of stations available. Registration for this service is free. The quality of these correction signals is monitored, and there is a warning on the site information page, under Data Provided, if a particular station has a position error. There is also http://www.rtk2go.com/ which is worldwide, but the streams are of unknown quality. Anyone can sign up to provide a stream. The streams on rtk2go are free to use, without registration.

Another possibility is to set up your own RTK base station. There is a cost to this, but it is much less expensive than it used to be. You need somewhere to put the aerial where there is a reasonably clear view of the sky. You can follow the recipe developed by the French Centipede project https://centipede.fr/ https://docs.centipede.fr/ (Use an online translation service!) This does not require much technical knowledge. Unless you are taking part in the Centipede project, you will not be able to use their server to broadcast your corrections, and it may be convenient to use rtk2go. If you are not following the recipe, a key thing to know is how to find the position of your base station to within a couple of centimetres. In short, you record the RTCM data from your base station, convert the RTCM to RINEX v2 using rtklib, and submit the RINEX file to an online processing service, which will give you the position. In more detail:

Put the ZED-F9P into time mode, and choose the fixed-mode option. Set it to produce MSM7 messages (not MSM4), with no NMEA or UBX. Set the position in latitude longitude and height to approximate values, obtained by the receiver without corrections. The height should be the height above the ellipsoid, not the height above the EGM2008 geoid (“sea level”). Record the messages using u-center. Record preferably for a minimum of six hours, and keep the recording period within one UTC day. Convert the RTCM messages to RINEX v2 using rtklib http://www.rtklib.com/ https://github.com/tomojitakasu/RTKLIB Keep only the GPS observations, and only at an interval of 30 seconds. I found the command line version of rtklib was not well-behaved, so I suggest using the Windows version. The GFZRNX RINEX toolbox https://semisys.gfz-potsdam.de/semisys/scripts/download/index.php may also be useful. The naming convention for RINEX files is described in the GFZRNX manual. Submit the RINEX file to one or more of these online services provided by national mapping agencies. They are all free and all will process files from locations worldwide. https://www.ngs.noaa.gov/OPUS/ https://www.ga.gov.au/scientific-topics/positioning-navigation/geodesy/auspos http://rgp.ign.fr/SERVICES/calcul_online.php They will return a report giving you the position.

When I tried this, I did not get good results. Some of the timestamps in the u-blox RTCM messages are whole seconds, and some of the timestamps are one millisecond after a whole second. None of the three online services mentioned above were happy with this. As the RINEX file is plain text, I used a text editor to change all the timestamps to whole seconds. The results were not satisfactory. Based on an earlier version of the Centipede documents, there is a solution to this. I have not yet had time to try it. The full recommendations from Centipede are - Leave the receiver in normal positioning mode and set it to produce binary data messages RAWX and SFRBX. Centipede has a configuration file for this (for receiver firmware v1.13). Record for an entire UTC day. Use a modified version of rtklib http://rtkexplorer.com/downloads/rtklib-code/ (latest version) which can handle all the data produced by the ZED-F9P, raw or RTCM MSM7. Use the receiver-specific option -TADJ=1 to adjust the timestamps. Then submit the RINEX v2 file to the online processing service.

Once you have a good position, enter it into the ZED-F9P, preferably in XYZ format. Be sure to retain plenty of decimal places, 3 or 4 decimals for metres and 8 decimals for degrees. If you need to convert between ITRS and ETRS, there is a tool here http://epncb.oma.be/_productsservices/coord_trans/index.php You will need to specify the epoch (date of the observation). This is, in effect, the date on which the ITRS position is to be valid. You can change the format of the epoch: Y-M-D is the most convenient. If you use ITRS, you will need to update the position from time to time because the ITRS position is continuously shifting. Tools for converting between XYZ (ECEF) and LLH can be found here https://www.ngs.noaa.gov/NCAT/ https://www.ngs.noaa.gov/cgi-bin/xyz_getgp.prl https://www.ngs.noaa.gov/cgi-bin/xyz_getxyz.prl If I was setting up an RTK base station in Europe, I would use ETRS so that the position of the receiver did not need regular updates.