Reference Frame Implementation in CORS Network and RTK Service

With the recent discussions on a new Australian datum (GDA2020), I have come across several queries regarding datum implementation in CORS network system and RTK service.

The basic principle to keep in mind is that RTK, or more descriptively, carrier-phase double-differencing, is a relative positioning technique. Unlike DGPS or PPP, it does not solve directly for coordinate but instead compute the vector (baseline) between the reference point (base station or CORS) and the unknown point. This vector is then applied to the known, accurately surveyed coordinate of the reference point to produce the coordinate of the unknown point (see Hofmann-Wellenhof, Lichtenegger, Collins, GPS Theory & Practice, Section 8.3 for further details).

For an RTK service, the measurements (or observables) made at the reference station are transmitted to the rover receiver occupying the unknown point. The rover uses the observables from the reference station along with its own observables to compute the vector between the reference station and itself. Known accurate coordinate of the reference station is also sent in the transmission stream which the rover then uses to compute its own accurate coordinate.

So what happens when CORS network operators switch from GDA94 to GDA2020? Quite simply, the reference coordinate sent in the stream will change. And that’s about it. The observables remain the same. The computed vector remains the same. But because the reference coordinate has changed, the computed coordinate at the rover will change too.

So if my service provider offers parallel streams, one in GDA94 and another in GDA2020, can I tell which is which?

It depends. Out-of-band, the operator can always provide relevant metadata about the streams – including reference frame – through various mechanisms. It can be specified on their website or reflected in the stream’s name (for example, Bathurst-RTCM3-GDA2020).

In-band – that is, from the content of the stream itself – it depends on the message format used. Let’s look at RTCM 3 which is the most widely used international standard for CORS network and RTK service. The RTCM standard specifies the reference coordinates in Earth-Centre-Earth-Fixed (ECEF) coordinates with the option to specify their ITRF realisation year. This implies that the reference frame is ITRF but regional CORS network operators often use their local datums directly. For example, in Australia, CORSnet-NSW and GPSnet currently transmit GDA94 coordinate in their RTCM streams. Anyone using their RTK services will produce coordinates in GDA94 which is the intended purpose.

When the operators migrate to GDA2020, the GDA94 coordinates will be replaced with GDA2020 coordinates and the X, Y, Z values transmitted in the RTCM stream will change. Additionally, an operator may choose to keep the current stream (and GDA94 coordinate) and create a new ‘GDA2020 stream’ with a different set of coordinate values transmitted. The observables for these streams are identical, only their coordinate values differ.

Alternatively, an operator could employ a strict implementation of the RTCM standard and transmit the reference coordinate in ITRF. RTCM supports the transmission of transformation parameters which can then be used by the rover to automatically transform the computed coordinate from ITRF to the desired datum. This will require network operators to include the appropriate Coordinate Transformation Messages in their streams.

As of Version 3.2, the RTCM standard is yet to support dynamic datum however this support is planned in the future.

BeiDou, China’s own GPS

While the United States’ GPS is used in pretty much all vehicle navigation systems and smartphones, and Russia’s GLONASS is making inroads, not many are aware that China has been busy launching its own global navigation satellite system called BeiDou. Over the past three years or so, China has significantly expanded BeiDou and there are now more than 10 BeiDou satellites orbiting. (more…)

RTKLIB on Raspberry Pi

High accuracy GNSS positioning has always been associated with expensive commercial solutions. So I was pretty thrilled when I first heard about RTKLIB. Developed for the past seven years by Tomoji Takasu, RTKLIB is a free open source software for GNSS data processing. It has an impressive list of features, decoding of multiple formats (including the latest RTCM 3.2), NTRIP support, multiple constellations support, post processing and real-time processing ranging from single point positioning to RTK to PPP.

A great thing about RTKLIB is that it is highly portable. It is written in standard C and can be compiled on many different operating systems and platforms, including the hugely popular Raspberry Pi. Run the free RTKLIB on a fifty bucks Raspberry Pi connected to a low cost GNSS board (such as the u-blox LEA-xT series), now you have access to centimetre level positioning without the thousands of dollars price tag. (more…)

Trimble CMRx bandwidth test

CMRx is the latest version of Trimble’s proprietary format for distribution of GNSS correction data to their rover hardware. A while back I did a quick test to measure the average bandwidth used by CMRx. Here’s a plot of bytes transferred per second for a two constellations (GPS and GLONASS), two frequencies (L1 and L2) stream over 10 day average.

CMRx bandwidth in bytes/sec
CMRx bandwidth in bytes/sec

The average figure is 171 bytes/sec. That is about thirty percent less compared to RTCM 3.0.

RTCM 3.2 support in Trimble Pivot 3.1

Since RTCM released Version 3.2 of their DGNSS Services Standard in February 2013, I have been wondering when GNSS hardware and software makers will add support for it in their products.

Trimble recently released Version 3.1 of their Trimble Pivot software and first on the list of new features is support for Multiple Signal Messages (MSM) as specified in RTCM 3.2. The MSM is intended to convey GNSS observations in a universal manner as more constellations and signals become available. It is a replacement for the older RTCM 3 messages (Message Type 1001-1004 and 1009-1012). Currently there are seven types of MSM, ranging from MSM1 for delivering compact GNSS pseudoranges to MSM7 which provides full GNSS pseudoranges, phaseranges, phaserange rate and CNR at high resolution.

Pivot supports MSM3-7 as its output format and its new RTCM3 decoder is capable of decoding MSM4-7. The next thing to look forward to is, of course, support for these new messages in GNSS receivers to make the end-to-end connection happens!