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.

One thought to “Reference Frame Implementation in CORS Network and RTK Service”

  1. Hi Tyan
    I am sorry for writing you like this, I was not able to identify your email address. Feel free to delete this comment. I am currently writing my masters thesis investigating the tilt compensation mode of the Trimble R10. I have without any luck asked questions directly to Trimble as well as the national distributer of my country. Below is a copy of my email to Trimble. If you provide me with your email I will be happy to send the attachments to the email. If you can help me unravel this black box I would be very happy.

    Thanks, Daniel


    I am having trouble interpreting some of the lines in the .jxl export
    from R10 observations. My questions are related to the
    part of the export. I have studied the
    JobXMLSchema-5.70.xsd, but not found the answers i was looking for. When
    measuring the traditional way as topo points I get something like this:


    What do this bivector tell? What are its units?

    When measuring tilt compensated points i get something like this:





    From what I can tell in JobXMLSchema-5.70.xsd the units are gon, is
    this correct? The three axes are obviously orthogonal to each other, but
    what are the orientations of the rotation axes for pitch, roll and yaw?
    I would think that yaw is rotation around a vertical, or z, axis,
    correct? My guess is that yaw = 0 means magnetic north? If so, is yaw =
    100 due east or west? What are the purpose of making it a negative
    number, all directions could be covered in the range 0 – 400. With yaw =
    0 what are the direction of the axes on which pitch and roll describe a

    I have also attached two pictures and two .txt’s. I am having trouble
    matching the numbers. tilt.txt shows deviceaxisorientation from the .jxl
    export and tilt.jpg is a picture taking of same observation in the
    controllers (tci41) point manager. The same story goes for topo.jpg and

    I am writing my master thesis in Surveying and Mapping at Aalborg
    University, Denmark. I would greatly appreciate any light shed on the above.



    Daniel Sondrup

Leave a Reply to Daniel Sondrup Cancel reply

Your email address will not be published. Required fields are marked *