{"id":7648,"date":"2021-04-05T13:33:16","date_gmt":"2021-04-05T13:33:16","guid":{"rendered":"https:\/\/www.use-snip.com\/kb\/?post_type=ht_kb&p=7648"},"modified":"2021-04-18T14:09:54","modified_gmt":"2021-04-18T14:09:54","slug":"using-rtcm2-with-ublox-gnss","status":"publish","type":"ht_kb","link":"https:\/\/www.use-snip.com\/kb\/knowledge-base\/using-rtcm2-with-ublox-gnss\/","title":{"rendered":"Using RTCM2 with uBlox GNSS"},"content":{"rendered":"

This article covers the basics of how to setup a uBlox chip set to utilize RTCM2.x style corrections<\/b>.<\/p>\n

In general the SNIP <\/b><\/span>knowledge base articles do not provide Vendor or Model\/Device specific setup instructions, preferring to point to documentation directly from the maker.\u00a0 But as uBlox is often used in conjunction with RTKLIB tools and the commercial products based based on that; we make an exception and group this article with others relating to the use of RTKLIB.<\/p>\n

[Aside<\/strong><\/em><\/span>: Beside the web sites maintained by each\u00a0 product developer, UNVACO offers very\u00a0 good setup instructions for survey grade GNSS devices.\u00a0 See:\u00a0 https:\/\/kb.unavco.org\/kb\/category\/gnss-and-related-equipment<\/a> and enter your equipment type into the search field.\u00a0 This is the best place on the web for detailed setup instructions for your Base Station]<\/p>\n

This article consists of both detailed instructions regarding how to set up a uBlox chip using u-Center to import and use RTCM2, and a variety of historical ‘asides’ with data on RTCM<\/a>, NMEA<\/a>, and GNSS in general that may be of interest to the reader.<\/p>\n

Background<\/h2>\n

Many of the various low cost L1-only uBlox chips, including the 6T and 8 series (as well as the latest F9P) can be used for traditional RTK navigation and positioning.\u00a0 These chips provide an output of the raw code and carrier tracking data (the “observables”) which can then be used by a external navigation filter such as the popular RTKLIB tools.\u00a0 It requires only modest effort to develop and deploy robust and accurate RTK and\/or SSR solutions in embedded products using these resources and a nearby Base Station. Many of the users of the Lite <\/i><\/b><\/span>model of the SNIP <\/b><\/span>NTRIP Caster do precisely that.\u00a0\u00a0 The newest uBlox offering (the F9P chip) now provides L2 tracking as well as multiple constellations and a built-in RTK navigation filter. \u00a0 A data stream from a nearby Base Station is still required (providing RTCM3 or SSR content, or both), but this serves to continue the industry trend of RTK becoming a low-cost commonplace commodity.<\/p>\n

However, there remains a number of users and use cases who wish to use RTCM2 “code” corrections rather than RTK or SSR style solutions.\u00a0 [Aside<\/i><\/strong><\/span>: Besides the RTCM2 message types 1,2,3,9, and 31, RTCM2 also provides a very early form of RTK which is no long recommended for use and is not considered further here.]<\/p>\n

The reasons for using RTCM 2.x vary, but often such users simply wish to hold sub-meter accuracy in a moving ground platform.\u00a0 The availability of SBAS\/WASS corrections is often further compromised in ground vehicles due to urban blockages, particularity at higher latitudes where geostationary transmissions are often blocked.\u00a0 The ~15 minute acquisition of the full ionospheric map is also problematic for real time vehicle applications.\u00a0 The largest remaining user segment for RTCM 2.x is found in coastal marine applications (harbor approach, etc.).\u00a0 Aside<\/strong><\/span><\/i>: During times of low solar activity, RTCM2 is frankly not that much better than SBAS, but during periods of higher actively, both RTCM2 and RTCM3 perform markedly better.<\/p>\n

For these users, RTCM 2.x represents a marginal accuracy improvement over SBAS, but nothing like the 100x improvement achieved with RTK.<\/p>\n

Equipment Used<\/strong>:\u00a0 In this article we have used an older uBlox 6T device with firmware 7.03 in the examples.\u00a0 Eight years ago we demonstrated using these devices with modified copies of RTKLIB to perform rapid cold start RTK Fix acquisition in a moving vehicle.\u00a0 The primary modifications to RTKLIB involved adaptive weighting of the Kalman filter based on the instantaneous SNR and Doppler values to detect and reject transitory multipath.\u00a0 In turn that work led to the creation of the SNIP<\/strong><\/span> NTRIP Caster.\u00a0\u00a0 Most of the screen shots shown below are taken from u-Center (revision 20.10), the software provided by uBlox to set up and monitor their chips.<\/p>\n

Overview<\/h2>\n

By default, the uBlox chip defaults to using SBAS\/WASS corrections signals when these are present.\u00a0 It must be expressly told to use RTCM2.<\/b>\u00a0 Some GNSS devices will automatically move between RTK, DGPS\/DGNSS, SBAS, and true autonomous modes depending on the available data they are given.\u00a0 This is not true for uBlox.\u00a0 [See caution about NMEA-183 $GGA sentence below as well]\u00a0\u00a0 Aside<\/i><\/strong><\/span>: In this document we will treat the term “DGPS” (differential GPS) and “DGNSS” (differential GNSS) as being equivalent.<\/p>\n

Beside being told to use RTCM2, various ports must be enabled and configured to receive the data (see next section).\u00a0 And the corrections data needs to contain ‘code’ DGPS messages (message types 1,2,3,9, and 31).<\/p>\n

Aside<\/em><\/strong><\/span>: For a list of the defined RTCM2 messages see this article<\/a>.<\/p>\n

It appears that uBlox is tolerant of other RTCM 2.x message types being present in the data stream (such as the retired RTK messages expressed in messages 18,19,20,21), correctly reading them in and then ignoring them.\u00a0 This has not been verified with all chip sets.\u00a0 Aside<\/em><\/strong><\/span>: This behavior is according to the RTCM 2.x specification and is generally true for other GNSS devices as well.<\/p>\n

It appears that uBlox is tolerant or decodes the improved antenna messages in RTCM 2.x, types (22,23).\u00a0 But it is not known if it makes any use of them.\u00a0 For code corrections use, this information is of almost no additional value.<\/p>\n

It appears that uBlox is tolerant of the presence of additional <cr><lf><\/strong> characters being present in the data stream.\u00a0 Again, this has not been verified with all chip sets.\u00a0 Aside<\/i><\/strong><\/span>: RTCM2 was originally developed for transmission over a serial communications link using a big-endian ordering.\u00a0 When converted to octets the 30 bit parity words are expressed in 5 octets. When then sent over TCP\/IP or a serial cable, some Base Stations will add additional <cr><lf> characters between each message frame.\u00a0 This is not in fact defined or allowed by the current RTCM standard, but is commonly seen.\u00a0 A well designed receiver device should be able to cope with either style.<\/p>\n

When DGPS data is present, the uBlox chip immediately decodes it and moves from “autonomous” to the “DGPS” mode of operation (the value of ‘1’ to the value of ‘2’ in NMEA). \u00a0\u00a0 Note that this may take ~3 seconds depending on how often the data stream is sending the messages of interest.\u00a0\u00a0 When the data is removed, the uBlox chip remains in the DPGS mode for 60 seconds.\u00a0 You will see that ‘age of DNSS’ indication in the $GGA sentence increasing during such times.\u00a0 After 60 seconds have elapsed without any new data, the uBlox chip reverts to the “autonomous” mode of operation.\u00a0\u00a0 [The timeout value can be set with UBX \u21d2 CFG (Config) \u21d2 NAV5 (Navigation 5) at the bottom of the dialog]\u00a0\u00a0 This can be verified with both u-Center and the NMEA $GGA or $GLL output sentences\u00a0 (see below).\u00a0 See How do you know it is working<\/i> below for a quick recap of key indications.\u00a0 \u00a0
\n<\/i><\/p>\n

Terminology Aside<\/strong><\/span>s<\/i>: The term “autonomous” indicates operation without external corrections, it is also called “single” in some GNSS tools.\u00a0 In the uCenter tool it is called “2D\/3D” and this is also where uBlox provides a fixed altitude operating mode. Some GNSS devices describe their mode as\u00a0 autonomous when they are in fact using SBAS\/WASS corrections information.\u00a0 Other devices will describe the same operating mode as “DGPS” (differential GPS\/GNSS) so the reader is advised to check. The NMEA-183 specification is very vague on this point, that part of the standard having been written before the deployment of SBAS\/WASS corrections.\u00a0\u00a0 Further the term “DGPS” is generally held to refer to the use of code corrections<\/em> only (which are then directly subtracted from the observed code measurements by the rover device, hence the name).\u00a0 By contrast the terms “RTK” or “NRTK” (network RTK)\u00a0 are used to refer to RTCM 3.x messages with code<\/em> and carrier<\/em> phase measurements where the rover device code and carrier measurements (the observations<\/em>) are combined with the measurements from the Base Station in a “double difference” navigation filter.\u00a0 To complicate this still further; the RTCM message set standard which defines all the RTK messages is still formally uses the term “Differential” in it’s title.<\/p>\n

 <\/p>\n

Process Steps<\/h2>\n

We presume in these instructions that a working copy of u-Center is connected to the device in question and that the serial port “UART1” is connected and available for use (to send the DGPS data stream in with).\u00a0\u00a0 We would recommend a baud rate of 19.2k or higher to ensure that no data is dropped.\u00a0\u00a0
\n<\/i><\/p>\n

Aside<\/i><\/strong><\/span>: The tool u-Center is now 15+ years old and the product of many different user demands (uBlox states that 100+ people have contributed to it).\u00a0 It is not particularly intuitive, with related functions spanning different dialog boxes and settings.\u00a0 The GUI uses a common interface for all the uBlox chips, even if a specific chip does not support a given feature.\u00a0 The primary GUI feedback to indicate that a given feature is not<\/strong> supported is a grayed out control.\u00a0 However, this also is used to indicate that the feature is simply disabled.\u00a0 The only way to tell one from the other is a detailed review of the specification sheet for the device you are using.\u00a0 The firmware revision is also very important, as some features are present only in later revisions.<\/p>\n

To see the firmware revision use the dialog in uCenter found at: UBX \u21d2 MON (Monitor) \u21d2 VER (Version) and press poll<\/em> for the data.<\/p>\n

\"\"<\/p>\n

Step #1 – Disable SBAS use.<\/h3>\n

Go to the dialog at UBX \u21d2 CFG (Config) \u21d2 SBAS (SBAS Settings). Select disabled <\/b>in the combo box.\u00a0 Send this message to the device (the send button is along the lower left side of the dialog).\u00a0\u00a0 Your dialog should look like the below:<\/p>\n

\"\"<\/p>\n

The device will now accept and use RTCM2 code corrections data when it is found to be present. But we must still set some other controls to ensure the data is processed, and then we must provide the data.
\n<\/i><\/p>\n

Aside<\/i><\/strong><\/span>: The u-Center GUI uses a combination of dialog styles; some of which can send data to the device such as this one, others which can only display data.\u00a0 Many dialogs also allow a periodic polling mode of use where the displayed data is automatically updated.\u00a0 Use the polling mode to watch data such as the DGPS corrections data change and evolve over time.<\/p>\n

Step #2 – Enable Uart1 for RTCM2 input<\/h3>\n

Go to the dialog at UBX \u21d2 CFG (Config) \u21d2 PRT (Ports).\u00a0 In the combo box, select “1- UART1” – this brings up the setting controls for this port.\u00a0 Besides the obvious baud rate and serial details (we recommend 19.2k or better), there are two combo boxes that control the supported “protocol” in and out.\u00a0 It appears that the design of the uBlox chip employs a sort of “directed pipe” style where (in this case) you must tell it at which port a given protocol will appear.\u00a0 There is also some (conflicting) evidence (not explored further here) that the RTCM2 input can only be present on one port at a time.<\/p>\n

Set the values as shown below, the critical detail is that RTCM2 be an input (Protocol in) on UART1 .\u00a0 Other values can also be made to work.\u00a0 In particular, you may want to send NMEA sentences back out to assist in data logging.\u00a0 Send this message to the device.<\/p>\n

\"\"<\/p>\n

Step #3 – Connect a suitable data Stream<\/h3>\n

Now would be the time to send RTCM2 correction to UART1 (matching the same baudrate etc., you set above).\u00a0 See the next section if the process of doing this needs further explanation.<\/p>\n

When data is being received on UART1, you can use the dialog found at: UBX \u21d2 MON (Monitor) \u21d2 IO (IO System) to observe data (measured in octets) arriving at the different ports (in this case the Rx bytes field for UART1).<\/p>\n

\"\"<\/p>\n

Aside<\/i><\/strong><\/span>: The dialog found at UBX \u21d2 MON (Monitor) \u21d2 RXBUF(RX Buffer) can be used to check the receiver buffer sizes.\u00a0 A similar buffer (TXBUF) exists for the transmit side.\u00a0 These are of value to detect and correct buffer overruns if the baud rate is set too low.<\/p>\n

Note that IO (IO System) dialog now shows a count of all bytes transferred.\u00a0 Ensure that data is being received from your DGPS source.<\/p>\n

This dialog shows data is being received.\u00a0 It does not<\/b> indicate that the bytes are meaningful.\u00a0 In other words; that they are correctly formed RTCM2 message content.\u00a0 We will use another dialog for that.<\/p>\n

Go to the dialog at UBX \u21d2 MON (Monitor) \u21d2 MSGPP (Message Parse and Process).\u00a0 This dialog shows the uBlox device’s ability to decode and classify the message content it sees on each port (Step #2 told it to expect RTCM2 content on this port).\u00a0\u00a0 As shown below, you should see a (growing) count of RTCM2 message content on UART1.\u00a0\u00a0 This dialog shows that the data received has been decoded as valid RTCM2 content.\u00a0 It does not<\/b> indicate that the RTCM2 message content is the correct type(s) to be used<\/strong> for DGPS.\u00a0\u00a0 Once again, we use another dialog for that.<\/p>\n

\"\"<\/p>\n

Aside<\/i><\/strong><\/span>: Keep in mind that anything the device does not understated will be classified as “UNKNOWN”\u00a0\u00a0 So as an example, if you were to send valid RTCM3 content to most uBlox chips (except the F9P), it would appear as UNKNOWN because it is not decoded.<\/p>\n

Go to the dialog at UBX \u21d2 NAV (Navigation) \u21d2 DGPS (DGPS Data).\u00a0 This dialog shows the actual decoded DGPS information.\u00a0 The data age will vary between ~0.5 and ~3 seconds.\u00a0 The PRC and RRC values for each reported satellite will updated as new messages arrive.\u00a0 The PRC (pseudo range correction) is the value that is used to adjust what the uBox chip has measured.\u00a0 The RRC (range rate connection) is a 1st order model used to propagate the correction value forward in time.<\/p>\n

\"\"<\/p>\n

The above does <\/b>indicate that theRTCM2 message content in the correct type(s) is input, parsed, and\u00a0 be used for DGPS in the uBlox device.\u00a0\u00a0\u00a0 If you see this data, the uBlox chip is being correctly feed.<\/strong><\/span>\u00a0 We can now examine the navigation output and the NMEA outputs in greater detail to learn how the corrections have changed (improved) the positional output (next step).<\/p>\n

Aside<\/strong><\/span>:<\/i> The above was done with a uBlox 6T device and it does not appear to decode RTCM2 message type 31 (code corrections for GLO satellites).\u00a0 It is not clear what message types newer designs will decode.\u00a0 Current adopted RTCM2 supports GPS+GLO, but there are some deployment with code corrections for other GNSS constellations using message type 59.<\/p>\n

Step #4 – Observe the Navigation details<\/h3>\n

There are two easy ways to determine if the uBlox chip is using the RTCM2 message content.\u00a0 One can look at the uCenter “NAV” solution dialogs, or one can look at the NMEA-183 messages being output.\u00a0 The second method is of particular value when uCenter is not connected to the device.<\/p>\n

\u00a0\u00a0\u00a0 In the uCenter navigation status dialogs<\/strong><\/h4>\n

Go to the dialog at UBX \u21d2 NAV (Navigation) \u21d2 SOL (Navigation Solution).\u00a0 This dialog shows general information about the current postilion estimate.<\/p>\n

Note the field marked “Fix Flags”\u00a0 and the value “DGPS” indicating that RTCM2 corrections are being employed.<\/p>\n

\"\"<\/p>\n

Go to the dialog at UBX \u21d2 NAV (Navigation) \u21d2 STATUS (Navigation Status). This dialog shows similar information about the general status of the navigation filter.<\/p>\n

Note the field marked “DGNSS Fix” and the value “Yes” indicating that RTCM2 corrections are being employed. The field “Diff Corrections Available” is also of note.<\/p>\n

\"\"<\/p>\n

\u00a0\u00a0\u00a0 In the NMEA-183 messages<\/strong><\/h4>\n

This information can also be visually decoded in the $GGA and $GLL sentences. Here we again use the uCenter tool to decode the message for us.<\/p>\n

Go to the dialog at NMEA \u21d2 GxGGA (Global Positioning Systems Fix Data) \u21d2 GPGGA.<\/p>\n

In the $GGA sentence<\/strong>, the data element “Status” will be “2<\/strong>” if DGPS is being actively used (see below).\u00a0 A value of 0 indicates no positional fix (GPS not working or no position is determined).\u00a0 A value of 1 indicates an autonomous mode of operation (no corrections present).<\/p>\n

Aside<\/strong><\/em><\/span>: The values 3 and 4 refer to float<\/em> and fixed<\/em> RTK modes (when the wavelength ambiguity is not resolved the device is said to be in a float<\/em> mode).\u00a0 Other values are not universally agreed upon and different device manufactures use different values for the same operating modes. This is a point of great confusion.\u00a0 Further, some device manufactures will decode and use SBAS\/WASS corrections and report in the NMEA sentences they are using a differential mode (i.e. 2), while other will report this as an autonomous mode (i.e. 1).<\/p>\n

Note that value for “Age of DGNSS Corrections” (here shown as 1.4 seconds). This value changes as the latency in\u00a0 the messages evolves.\u00a0 It is generally less than a few seconds.\u00a0 If it exceeds 60 seconds, the device will drop back to an autonomous mode (see prior comments regarding how to set this threshold).<\/p>\n

\"\"<\/p>\n

In a somewhat similar way the $GLL sentence<\/strong> can be used.<\/p>\n

Go to the dialog at NMEA \u21d2 GxGLL (Geographic Position – Lat\/Lon) \u21d2 GPGLL.<\/p>\n

Here the key inform is found in the “Mode Indicator” field where D=Differential operation.<\/p>\n

Note that “Status” has a different meaning that that used in the $GGA sentence.<\/p>\n

\"\"<\/p>\n

 <\/p>\n

Key Take away:
\n<\/strong><\/span>Any of these methods is sufficient to determine if
\nthe uBlox device is using the DGSS corrections.<\/strong><\/p>\n

 <\/p>\n

Connecting to SNIP for data streams<\/h2>\n

In order to send corrections data to the uBlox chip obtained from any NTRIP Caster<\/a> (such as SNIP<\/b><\/span>) an NTRIP Client is used.\u00a0 Here we have used a popular PC based tool from Lance Lefebure, download it here: http:\/\/lefebure.com\/software\/ntripclient\/<\/a> \u00a0 It is suggested this be download and run from the same PC that u-Center is run from.\u00a0\u00a0 A common USB to serial cable can then be used to send the data stream to the uBlox device over its uart1 port.<\/p>\n

It appears that the current version of the u-Center tool now has both and NTRIP Client<\/a> and an NTRIP Server<\/a> built into the tool.\u00a0 Presumably these could be used to acquire corrections and send them to the uBlox device under test.\u00a0 We often see others doing this on the RTK2go node<\/a>, but have not investigated the setup process further here.<\/p>\n

Connect the Lefebure NTRIP client to a Caster in the normal way, selecting an RTCM stream that contains nearby (<100km baseline or better) data to the device under test.\u00a0 Here we have used a Base Station provided by ESRI<\/a> which is located 50km away from the uBlox device.<\/p>\n

\"\"<\/p>\n

 <\/p>\n

The Lefebure tool, when connected and running, also displays the location in periodic NMEA sentences when available.<\/p>\n

Note also you can have SNIP<\/strong><\/span> record the NMEA data from the connected clients in various ways for post processing. See the AVL tab<\/a> for further details.<\/p>\n

 <\/p>\n

How do you know it is working<\/h2>\n

In this uBlox device a $GGA sentence with the mode set to 2<\/strong> (indicating DGPS) confirms that the corrections have been used.<\/p>\n

To recap the key check points from the above:<\/p>\n