Options - go to homepage
Options logo

Options

TPSDK for Android and iOS

Overview

The Trimble® Precision SDK (TPSDK) is available in different versions tailored to specific operating systems.

The default outputs are:

  • Objective-C for iOS
  • Java for Android
  • C# for Android

While all versions share the same core functionality, the platform-specific technologies result in differences in their interfaces.

For instance, Bluetooth communication varies significantly between Android and iOS, requiring platform-specific adaptations.

Before diving into implementation, it’s worth evaluating the integration strategies provided by TMM and TPSDK. Depending on your application’s needs, a web socket-based approach may offer a more convenient and effective solution compared to direct SDK integration.


Options

Before utilizing any of the TPSDK APIs, developers should evaluate the available integration methods:

For applications that only require basic positioning, WebSockets can be a simple and effective solutions.

For greater control, developers should consider the Facade layer, a wrapper around the SDK that simplifies implementation by encapsulating common use cases.

For applications requiring full control or access to less common receiver features, extending the facade with additional functionality—or directly integrating the SDK—is recommended.

Each approach has its own advantages and trade-offs, making it important to choose the one that best aligns with your application’s requirements.


Feature overview

A none-extensive overview can be found in the following comparison

Integration WebSocket server TPSDK
Supports Trimble receivers yes yes
Position access localhost ws and json API
Position meta data Check documentation Check documentation
Complexity low med-high
Access to all features no yes
Allows datum transformation yes, via TMM yes, via the API and/or TMM
Allows going static no, just 1Hz snapshot positions yes
Allows undulation values yes yes
Allows tilted measurements no yes

 


Mock locations

WebSocket example

WebSocket example

Not recommended anymore and hence removed from most parts of the documentation

Many applications are in need of precise positions - but can happily live with the information detail level as provided via the Google Mock locations aka the corresponding the location object.

To overwrite mock locations you can enable the corresponding feature in Trimble Mobile Manager (TMM). This approach requires no development effort on your part - your application behaves just as it normally would, and can benefit from receiving higher accuracy positions from the Trimble GNSS receivers.

TMM also adds additional meta information to the location.extras - accessible via known Android techniques. Detailed information on the available data can be found in the TMM developer documentation.

Downside: The problem with Android mock locations is that it has become hard to differentiate between a ‘Trimble’ position and a fused position as provided by the Android OS. If an application does not parse location.extras its not possible to filter - meaning an application receives a mix of positions. Also some HTML5/ JS frameworks don’t provide access to location.extras which can result in futher position mixes.



Web socket server

WebSockets provide data that is functionally identical to TMM’s mock location output, including location extras, but with the added convenience of combining them into a single object.

The key advantage of WebSockets is that they offer a cross-platform solution for delivering precise position data. They can be consumed by any HTTP client, making them technology-agnostic - unlike the platform-specific Java or Objective-C facades.

Configuration is straightforward and can be performed via the TMM UI or, starting with TMM v2024.X, through the RESTful API provided by TMM. Once configured, the WebSocket stream delivers position data in the specified format.

Additionally, progressive web apps often face challenges with mock location access because they cannot filter by location provider. For such apps, the WebSocket server is an ideal solution, offering a JSON-based output stream where the data source is explicitly defined.



TPSDK and the Facade

Facade

The term facade is frequently used in the context of TPSDK.

In essence, the facade is a wrapper layer around various TPSDK components. It simplifies integration by exposing commonly used functions, such as Bluetooth connectivity and initiating an NTRIP survey. Additionally, it serves as a practical example of how to utilize the interfaces provided by TPSDK.

The facade is provided as source code for Android and as a component for iOS, making it easy to integrate into your project. The typical approach involves copying and pasting the facade into your solution, allowing for seamless updates when new TPSDK versions are released.

For customization, enhancements to the facade are best implemented in a derived class. This ensures that updates to the original facade can still be easily applied using a drag-and-drop process.

 

TPSDK

TPSDK, along with its core components - the Sensor Software Interface (SSI) and the Licensing Software Interface (LSI)—forms the foundation of all SDK-related functionality.

The SSI provides access to a wide range of GNSS receiver features, from configuring the receiver’s internal UHF radio to performing tilted measurements and beyond.

TPSDK follows a component-oriented design based on interfaces. Each feature is tied to a specific interface, enabling modular and flexible functionality. For instance, the ability to start an RTK survey depends on the presence and properties of the corresponding ISsiStartRtkSurvey interface. The availability of such interfaces is determined dynamically at runtime.

For more information, refer to the TPSDK documentation.