Options - go to homepage
Options logo

Options

TMM and TPSDK for Android, iOS and Windows

Overview

Trimble offers partners different ways to integrate Trimble positioning technology - based on the needs of the partner.

TMM

Trimble® Mobile Manager (TMM) and its websocket based output stream allows an easy and quick integration into any existing application. The RESTful API exposed by TMM offers further configuration options allowing a partner to fully focus on his application and reuse existing elements in TMM.

TPSDK

The Trimble Precision SDK (TPSDK) is an SDK giving full access to all receiver functions. Its a more granular and defined access compared TMM - but also requires additional work with regards to Bluetooth connectivity and configuration.

Platforms

Both integration strategies are available for all major operating system.

While websockets are supported by all major development languages TPSDK comes with a defined set of output targets:

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

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

For example, Bluetooth communication differs significantly between Android and iOS, requiring platform-specific adaptations.

Before starting your implementation, it’s worth considering the integration strategies provided by TMM and TPSDK. Depending on your application’s needs, a WebSocket-based approach may offer a more convenient and effective solution than direct SDK integration.


Options

Before deciding on an integration strategy, developers should evaluate the available integration methods:

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

For greater control, consider the RESTful API or Facade layer—a wrapper around the SDK that simplifies implementation by encapsulating common use cases.

For applications needing full control or access to advanced receiver features, you can extend the Facade with additional functionality or integrate the SDK directly.

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


Feature Overview

A non-exhaustive comparison is provided below:

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

Note: Mock locations are no longer recommended and have been removed from most parts of the documentation.

Many applications require precise positions but can work with the level of detail provided by Google Mock Locations (i.e., the location object).

You can enable mock locations in Trimble Mobile Manager (TMM) without any development effort—your application will behave as usual, but benefit from higher accuracy positions from Trimble GNSS receivers.

TMM also adds extra meta information to location.extras, accessible via standard Android techniques. Detailed information is available in the TMM developer documentation.

Downside:
With Android mock locations, it has become difficult to distinguish between a ‘Trimble’ position and a fused position from the Android OS. If your application does not parse location.extras, it cannot filter positions, resulting in a mix of sources. Some HTML5/JS frameworks also do not provide access to location.extras, which can further complicate position filtering.



WebSocket 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 main 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.

Essentially, 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. It also serves as a practical example of how to use 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 is to copy and paste 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 more.

TPSDK follows a component-oriented design based on interfaces. Each feature is tied to a specific interface, enabling modular and flexible functionality. For example, 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.