PointMan and Trimble Catalyst

Mar 13, 2020 | Uncategorized

By: Peter Srajer, CLS, P. Eng. and Benjamin Skogen, CPM

Summary

Trimble Catalyst is a software based GNSS receiver as opposed to the use of the dedicated processors and firmware programming that is on board a conventional hardware receiver. The Trimble Catalyst uses the DA1 antenna and processing power of a compatible mobile device to acquire, track and process GNSS signals. Catalyst is an on-demand, subscription user-based service. Using the service, any location-enabled Android field app can use various levels of positioning without the need for additional hardware or additional correction services (depending on location). The software is only available on Android based systems at this point, Apple iOS has technical limitations which preclude it’s use, primarily the lack of support for OTG (on the go) USB protocols and limitations on CPU and GPU coprocessing that are needed for continuous  signal processing and tracking. Windows OS would be sufficient technically but is not supported at this point due to its limited market penetration in this space.

The critical piece of the solution is the DA1 USB antenna that can acquire and track multi-frequency GNSS satellites and correction services. (GPS/GLO/GAL/QZSS/L-bands). The DA1 will perform the initial signal acquisitions (GNSS and Correction services) and transfer the signal tracking to the mobile device which then is used to compute the final positioning solution.

Catalyst allows worldwide access to Trimble’s correction services through Trimble Corrections Hub, which also bundles access to the Trimble VRS Now and Trimble RTX correction services (See Appendix A for Details). These correction services are the critical part of the solution and the availability of the higher accuracy solutions is dependant on subscribed access to these services and on your location. You do not need access to local network or cellular services, the Trimble correction services are available over a satellite link. It will also support the use of third-party correction services using the NTRIP protocol, these may require connectivity and third party subscriptions to those services.

Historical and Technical Basis

Software based receivers started as an idea in the mid 2000’s and have become possible due to the ability of the underlying off the shelf hardware to support the software algorithms needed for digital signal processing. GNSS signal acquisition and tracking is an extremely computationally intensive process and normally would require dedicated hardware and firmware specifically designed to handle the real time processing of large data flows and signal processing algorithms.

A standard GNSS receiver is a collection of dedicated hardware components, the core of which is an Application Specific Integrated Circuit (ASIC): this is often a very large proprietary chip on the GNSS boards at the heart of hardware based receivers. These boards typically host several other dedicated hardware components. Each manufacturer has one or more flagship GNSS boards (e.g., for Trimble there are popular boards like the BD970 with a large ASIC on it running their Maxwell technology). Or, an increasing number of third-party manufacturers use OEM boards produced by firms like Trimble; for example, Bluestar uses a board produced by Hemisphere, Leica uses boards produced by Novatel (now Hexagon)

The use of more efficient and faster linear algebraic mathematical libraries, calculus and matrix functions has allowed software to reach the point where they can compete with hardware-based solutions enough to process GNSS data.  Similar mathematical algorithms are used in powering AI and Machine learning systems and are considered one of the unsung engineering breakthroughs of the last decade.

The advantage of a software based receiver lies in its flexibility, it can be updated and enhanced on a ongoing basis and as new signals and services come up, it can be updated to use those where a hardware system is limited in its ability to upgrade without a expensive factory or laboratory process. Other advantages over the legacy dedicated hardware units, especially in flexibility, are that new constellations, signals, and advances in GNSS algorithms can be added with a simple software upgrade. This makes the marketing push over how many channels a receiver can handle irrelevant.

The limitation is processing power, and it’s likely that smartphone processing capabilities will advance fast enough (or even faster) than changes in GNSS technology. An Achilles heel in GNSS solutions is the antenna: there are physical limitations. If you are receiving garbage, rife with multipath, random or bias signal noise, you will process garbage. The GPS antenna in your smartphone is terrible as a surveying or engineering tool. A ground plane to mitigate multipath is essential, and antenna size is also a function of the nature of the signals, an all purpose antenna in a mobile device that receives cellular, WIFI, Bluetooth and GNSS signals is going to prioritize design on the cellular or WIFI signal structure primarily. Physical engineering limits, signal structure and frequency preclude the ability of an all-purpose antenna to support all purposes to the extent needed for high precision and high accuracy engineering solutions.

There are also Chu limits to consider (thresholds on how much signal  and the noise ratio certain sized elements can receive). A GNSS receiver paired with a tiny or poorly engineered antenna limits the accuracy and productivity that can be expected, this is the reasoning for the requirement of the dedicated Trimble DA1 antenna.

Trimble Catalyst requires three components:

1. A location-enabled mobile app on an Android device
2. A subscription to the Catalyst service (Cost runs from $10/hour for on demand 1 cm – > Free for 2-3 metre) See below for cost details
3. A Trimble DA-1 antenna that plugs directly into an Android smartphone or tablet USB port ($350)

The field mobile device (Android based in this case) can run custom applications that leverage the Trimble SDK or can be setup to use  Android Location Sharing service by the mobile mapper software to directly stream positioning information. The use of the SDK would give a more flexible software solution and will expose more functionality and ability to access the precision and accuracy factors and well as items such as the expected satellites in view, ability to configure services etc.

The minimum hardware requirements are: (Source: Trimble.com)

• Android 5.0 or higher
• 64-bit CPU with at least 4x Arm® cores (6x or more Arm cores recommended)
• Maximum Core speed of at least 1.5 GHz
• 5 GB of RAM or higher

These requirements would include most any Android device from the past 3-4 years, testing by Trimble has been completed and verified on units including the Samsung Galaxy S5 and S6 units which indicates the minimum level of mobile devices expected. Essentially what Trimble has done is taken their core GNSS technology that runs on a dedicated hardware chip and created a software service that can run in an app on a smartphone or tablet. The user must select a monthly subscription based on the level of accuracy desired.

Accuracy Levels

There are four levels of software subscription to choose from, depending on what kind of work you are doing. The subscription prices go up with the levels of precision needed. A subscription gives the user the ability to access the Trimble Corrections Hub and access to the Trimble corrections services. In an online environment the Corrections Hub uses the Trimble RTX or VRS corrections over the internet, in offline mode this switches to the RTX or VRS satellite broadcast corrections using the DA1 antenna.

1. Meter provides code-processing using the correction data from Trimble’s RTX service. It tries to get code data from the RTX online service first, but if there is no internet connection it can get the data from the geostationary L-Band satellites that transmit RTX corrections. It can also use an SBAS solution if the other sources are not available. The DA1 antenna provides the L-Band satellite connectivity in cases of no network connection. The cost of this service is $40 per user per month
2. Sub-meter uses the same RTX code correction sources and in the same manner as the meter option, but the higher subscription rate unlocks the precision. With online code data, it tends to get 30cm-60cm, and with sat-based code data it is slightly less precise: 40cm-60cm. The cost of this service is $120 per user per month.
3. Decimeter uses RTK and/or Network RTK sources. If a user is in an area serviced by Trimble’s VRS Now networks (parts of the U.S. south and Midwest, most of western Europe, parts of Australia, etc.),(see coverage map later) corrections are delivered via internet connection and are included in the subscription. If you are in a non-VRS Now area, you can connect to local, regional, or state real-time networks (some are free, and others charge) or get RTK corrections from an I.P.-enabled base (Can be setup on a per project basis). This level of subscription unlocks the processing capability for decimeter precision. The cost of this service is $200 per user per month.
4. Precision level unlocks the processing of full-on RTK/Network RTK, in the range of 1-2cm within the decimeter solution above. It can use non-proprietary RTK formats, like RTCM-3.  It also supports RTCM-3 MSM (Multi-Service Message) for multiple constellations. This is essentially a higher-level processing solution than the Decimeter subscription; it uses the same correction sources and signals as the Decimeter level. The cost of this service is $350 per user per month.

As a subset of the Precision level, there is a Precision-on-Demand solution which provides the same level of accuracy and processing as the Precision subscription, but the on-demand subscription is based on a hourly usage (Positioning as a Service). This level costs $10/hour in 10 hour blocks and can be shared among any number of users.

Catalyst can feed live positions directly to the mock location apps within the mobile devices. They also offer a software development kit (SDK), which is freely available, and supports Catalyst. The GNSS Direct SDK (same SDK as for their R1 and R2 receivers) is available for third parties to use to integrate their software solutions with Catalyst. This SDK is most likely the best solution to integrate the Prostar solutions within the Trimble hardware ecosystem.  There is more to this partnership than the technical ability to have a robust high precision solution that has the advantage of easy configuration in the field. Trimble has significant worldwide presence and partnering with them is a great opportunity to leverage that presence as a trusted partner. Many large corporations in the engineering and surveying sectors have embedded interest with the Trimble ecosystem, this allows an easier introduction and transition into their survey and engineering departments and a level of comfort to the engineering groups that the solution is trusted.  This is a significantly less expensive solution initially than buying conventional hardware receivers, setting up VRS or other correction subscriptions and dealing with upgrades and configurations to the hardware.

Information and documentation on the SDK are located at: https://developer.trimble.com/catalyst/

The SDK supports both Xamarin (C#) and Java environments or would allow the use of either to bridge to another development language.  Detailed information, the SDK and examples are located at the Trimble site. The SDK is located at: (You will need a Trimble ID – free) to access: https://community.trimble.com/community/developer/geospatial-developers/trimble-precision-sdk-for-trimble-catalyst

Appendix A – Coverage Maps for each Service Level

Source: Trimble Website  – Valid as of Dec 12, 2019

Figure 2- Meter Precision Coverage Map

Figure 3- – Sub- Meter Precision Coverage Map

Figure 4 – Deci-Meter Precision Coverage Map

Figure 5- Centimeter Precision Coverage Map

Trimble RTX and VRSNow

Coverage for the Precision and the Precision-on-Demand subscription levels are the same, the difference is in how the subscription is charged.  Coverage areas for the other subscriptions are similar as well, it is only the processing to retrieve the higher level of precision that changes the cost, the physical coverage area is the same.  The higher levels of precision shown in Western Canada and Southern Ontario are due to the recent acquisition of the Can-Net VRS network and are considered very reliable and robust.

Figure 6 – RTX Coverage Detail – North America

Figure 7 – VRS Coverage Detail – North America

VRS service coverage corresponds to the higher accuracy 1 cm level of subscription availability, RTX is Trimble’s decimeter and better level of service.

PointMan Now Supports Geoidal Models

Mar 12, 2020 | Uncategorized

By: Peter Srajer, CLS, P. Eng. and Benjamin Skogen, CPM

Synopsis of Issue

The survey and engineering worlds have various methods of determining the height of a point on the ground surface. In the same manner as horizontal coordinates having different datums, so do vertical coordinates. There are three surfaces we are concerned with in this case (Figure 1) Topographic surfaces are what we ordinarily see as the ground and it is that surface that we normally wish to have the elevation of a point on. The two others (Geoid and Ellipsoid) are the base or the datum from which we are measuring the height from. We need a consistent and industry standard way of referencing the topographic height value. To do that, we need to have, as our datum, the surface shown as the Geoid. Any elevation measured from this Geoid datum or surface is also known as the Orthometric height or Mean Sea Level (MSL). Technically there are many different Geoid surfaces, but the Geoid surface we are interested in is defined by actual sea level stations, survey level stations and, more predominantly, gravity measurements. These inputs are combined and adjusted to create a Geoid surface. This Geoid surface, however, is not static. As better gravity measurements arise, the Geoid surface gets updated. This is done by government agencies. In the case of the US, the US National Geodetic Survey (NGS) completes the work, but it is usually several years between updates to the surfaces. The Geoid surface is also called a Geoidal model as it is not truly a physical surface all the time. MSL means something physical on the coast but it varies physically from the actual mean sea level in the mountains where gravity measurements vary. Several presently used Geoid models are called Geoid12, Geoid18, and EGM96. The number indicates the year that it was finalized and published by the relevant agencies.

Technical Description

Figure 1: The Ellipsoidal height (h), Orthometric height (H) and Geoid height (N)
Reference: Natural Resources Canada – Retrieved Sept 30, 2019

Orthometric height (H), often referred as Mean Sea Level Height, can be obtained by subtracting the Geoid height (N), which we obtained from the Geoid model (i.e. Geoid18), from the GNSS ellipsoidal height (h): H = h – N. A Geoid height (N) is positive (+) when the Geoid is above the ellipsoid and negative (-) when it is below (as shown on the right and left sides of Figure 1). Hybrid Geoid models such as Geoid12b/18, EGM96 etc. are created by constraining a gravimetric Geoid model to published heights which used GNSS observations on leveled benchmarks. The Geoid 12b and Geoid18 hybrid models are used in the US; whereas the CGVD28, CGVD2013, CGVD2013a model are used in Canada. A model called EGM96 is used as a global reference if the localized models are unavailable.

The North American-Pacific Geopotential Datum of 2022 (NAPGD2022) is scheduled to replace both the Canadian and US models in 2022, which will replace all existing US and Canadian Geoid models at that time.

The relationship between horizontal and vertical GNSS parameters is that WGS84 parameters approximate the Earth by an ellipsoid, which is basically a flattened and deformed sphere. EGM96 is a complex model based on the gravitational force of the Earth, (which is not constant), that defines what “sea level” or up and down means. This smooth but irregular shape is called the “Geoid“. WGS84 is the ellipsoid that best fits that EGM96 Geoid, and this fit has been updated as more accurate measurements of the Geoid have been carried out over the years. It is the EGM Geoid that has redefined the WGS84 ellipsoid over the years. In a similar manner, the local to North America NAD83 parameters are used in conjunction with the localized Geoid12b,18, CGVDxxxx Geoid models. To get the correct Geoidal undulation values from the various Geoid models, you must have the horizontal coordinates in the correct NAD83 datum. The correct horizontal datum coordinates are required as the Geoidal model files are gridded in those specific horizontal datums.

GEOID18 is intended for use with coordinates in the North American Datum of 1983 (2011). NAD83 (2011) is from epoch 2010.00 and it provides Orthometric heights consistent with the North American Vertical Datum of 1988 (NAVD 88).

The Canadian models can be referenced to NAD83(CSRS) epochs (1997.0, 2002.0, 2010.0), depending on which Geoidal model is used. Even though the CGVD2013a Geoid model is now associated to an epoch (2011.0), Natural Resources Canada (NRCan) considered the current Geoid model as static. The epoch of 2011.0 was selected as it represents approximately the middle of the gravity measurements time span used in CGG2013a.

The use of epochs is done to ensure that tectonic plate movements and similar temporal displacements are accounted for. If needed to ensure very high precision measurements that are between epochs, a velocity grid is available. This is needed to ensure the correct horizontal position and epoch to get a correct, highly precise Geoid model. In most cases, unless a very high accuracy is needed, the use of standard NAD83 (CSRS) for Canada, NAD83 (2011) for US or WGS84 for EGM96 are enough.

The PointMan Solution

PointMan uses the output CGGA portion of NMEA string (NMEA-0183 messages: Overview) as the data input. In that data string, there are two height values; one is the Orthometric height (H) and the other is the Geoidal height (N). While this may seem to solve our problem: finding the Orthometric height, the problem lies in that this Orthometric height is not generally based on an accurate Geoidal model. In the Bluestar GPS, the Geoidal height and thus the Orthometric height is based on a generic inclined plane; essentially a low-resolution approximation that is of limited use for surveying. The correct procedure is to revert that NMEA Orthometric height to the GNSS Ellipsoidal height (h) by adding the NMEA Geoidal height (N) to the NMEA Orthometric height. This results in an Ellipsoidal height; from this point we subtract the correct accurate Geoidal height (N) that we derive from one of the appropriate hybrid Geoidal surfaces (i.e. Geoid18) to get a final accurate Orthometric height (H).

The essential problem is to find the Geoidal height (N) from the appropriate Geoidal model.  The Geoidal models are freely available from the various government agencies (links below). There are various formats and some files are available from proprietary sources (Trimble GGF files).  In all cases, the solution is to convert to a common format (BIN from the Geoid18 models) and load this surface in the program.  We may need to subdivide the Geoidal grid if it becomes too unwieldy to load and search the full set. The next process is to convert the GPS (from NMEA string) horizontal coordinates to the appropriate horizontal datum temporarily (see explanation above) and search with the hybrid Geoid model at those horizontal coordinates for the corresponding Geoidal height (N). This is the value we are looking for. The problem arises in that the hybrid Geoidal model is not a continuous surface, it only has values at regular grid points. These points can be spaced up to 100 km apart in the case of the EGM96 model. An interpolation scheme must be used to get the correct Geoidal value; something like a bi or tri-cubic interpolation is normally used. Other schemes that may need to be considered in future work would be to use the GDAL libraries to rasterize the Geoidal surfaces. This way, a continuous surface is created which solves the interpolation problem. This also transfers the processing needed for interpolation to a one-time process done on the initial back end load off the local computer.

UI Implementation

PointMan has a drop down inside the Diff Menu to select between preconfigured Geoids

The user can choose from None (Default), EGM96, 12A, 12B and GEOID18

These Geoids are hosted on our database server and made available via configuration on a per-client basis with access permissions included. Once the user selects a Geoid to use, PointMan will cache the information and use it to perform conversions locally on the device. This way, conversions can be performed in offline mode as well when no cell service or WiFi is available. The following screenshot shows what the user sees in PointMan when they have a Geoid selected in the settings page. This view is real-time which gives the user confidence that they are collecting on the desired Geoid.

The next screenshot shows what attributes are saved during data collection. Once a feature is collected, the user can tap on the feature and then tap Details. Note that the Geoid and Elevation (Orthometric) is captured.

Shown below is an accuracy map for Geoid12B. The map and additional information can be found at https://www.ngs.noaa.gov/GEOID/GEOID12B/GEOID12B_FAQ.shtml. At the 95% confidence level, the map indicates an accuracy of around 4-5 cm in our location, which is about 0.16 feet, therefore the 0.12 is accuracy is within the error tolerance. If CDOT and ProStar were to run a full analysis, we would, of course, take a larger series of measurements with each instrument and, thus, get a statistical measure. Since we only used three units for this test, it is simply considered a difference measurement.

CDOT Case Study – Cross-Comparison & Verification of Accuracy

To account for the various GPS receivers on the market, we performed a difference measurement between each of the popular receivers that PointMan supports. Most surveyors are familiar with the Trimble R10 and trust it. Because of this, our study sets the Trimble as the standard and we indicate the Emlid and Bluestar differences from it. As a real-world test of PointMan implementing Geoid models, Colorado Department of Transportation surveyors used the following three GPS receivers in conjunction with both NTRIP and Base/Rover corrections to test Geoid12B inside the PointMan mobile application against known Trimble-collected monuments:

1. BlueStarGPS SafeRTK (Mesa County NTRIP)
2. Emlid Reach RS2 (Mesa County NTRIP & LoRa Radio Base – 868 MHz)
3. Trimble R10 w/ TSC3 (Mesa County NTRIP) as a baseline for comparisonThe following image shows the locations of four control points as well as the location of the base station used for testing these three systems.

Maximum elevation variance between the three receivers was 0.12 feet vertically, which CDOT verified to be within tolerance on their project sites. Note that the testing only included the Geoid12B (CONUS) model with no vertical calibrations performed on any of the receivers to ensure that the data from each unit was comparable.

Figure 1: CDOT surveyors using an Emlid Reach RS2 base and rover on a project site (12/10/2019)

Conclusion

Despite a small sample size, these results showed that elevation differences were minimal when using the same Geoid with no vertical calibration. As a reminder, the goal of this study was two-fold: (1) using PointMan Geoids, verify that accurate elevations could be collected using less expensive equipment, while being comparable to more expensive Trimble units and (2) to determine if more cost-effective GPS receivers could, in fact, be utilized by CDOT to meet project accuracy requirements. During our testing, this study confirms both items in question. Both the Emlid and the BlueStar receivers performed within the 95% confidence level set forth by NOAA and were also comparable to Trimble with respect to project tolerances. In addition, both CDOT surveyors on the project verbally indicated that the data collected using the Emlid and BlueStar receivers was acceptable for CDOT projects. The surveyors were also impressed with how easily all three GPS receivers connected to PointMan and how reliably they held an NTRIP correction signal. It was noted that PointMan correctly calculated Geoidal height for every point collected. In conclusion, we believe our implementation of Geoids in the PointMan mobile application will give users on CDOT and other projects the ability to acquire accurate vertical data while utilizing our low-cost solution.

Links

Further Explanation – Geoid models: https://geodesy.noaa.gov/GEOID/

United States Geoid Models (Geoid18): https://www.ngs.noaa.gov/GEOID/GEOID18/Geoid18_tech_details.shtml

Canadian Geoid Models: https://webapp.geod.nrcan.gc.ca/geod/data-donnees/Geoid.php?locale=en

EGM 96 models: https://earth-info.nga.mil/GandG/wgs84/gravitymod/egm96/egm96.html

EGM 96 and EGM 2008: https://www.usna.edu/Users/oceano/pguth/md_help/html/egm96.htm

Proprietary Geoid Models – useful for Second phase loading of GGF Models: https://www.trimble.com/globalTRLTAB.asp?Nav=Collection-71

Link to test results for Canadian Geoid models: http://webapp.geod.nrcan.gc.ca/geod/tools-outils/gpsh.php?locale=en