Golioth Location General Availability

Today we are excited to announce general availability of Golioth Location! Golioth Location is a comprehensive device positioning service, presenting a consistent interface for tracking device location via both traditional mechanisms, such as GNSS, and more sophisticated techniques, such as network-based positioning. The service has been in private access since its initial launch in December 2024.

What Makes a Great Location Service?

In our blog post launching Golioth Location, we outlined why we found it necessary to build a location service. The points presented primarily focused on why providing an integrated network-based positioning service, rather than forcing users to bring their own, dramatically simplified initial setup and ongoing management. We also detailed why network-based positioning is a good fit for connected devices, especially those that are bandwidth and power constrained. These points hold true today: network-based positioning can extend battery life, alleviate time-to-first-fix (TTFF) delays, and drive down the cost of hardware.

However, we also received great feedback from customers in the private access program, ultimately driving us to rethink what an ideal location service could look like. As we have so many times since introducing the product in May of 2024, we found ourselves looking to Golioth Pipelines to provide a flexible and robust foundation for Golioth Location. With the wide variety of use cases for location services, ranging from active asset tracking to infrequent device check-ins for product analytics, it is critical to enable users to configure location resolution and storage to fit their use case.

For example, some use cases require that historical device location is persisted, whereas others only need the most recent device location. Some products need devices to be made aware of their location rather than just delivering it to a data store. The most significant difference in use cases is whether using GNSS is an option, and whether it can be used together with network-based positioning. Doing so provides the right trade-off of accuracy and performance, all while offering a consistent interface.

Golioth Location: Then and Now

In the private access iteration of Golioth Location, devices:

• Submitted network information to a dedicated API endpoint
• This information resolved a position (lat, long, accuracy)
• It was returned in the response to the device making the request
• The position would also be stored in Golioth Location, making it possible to visualize a fleet on a map in the Golioth console.

If it was necessary to store the device location in a timeseries data store, or route it to any external destination, the device would need to stream the position back to Golioth so that it could subsequently be routed to the desired destination via Pipelines.

Besides the obvious unnecessary round-trip this incurred, we also found that many products did not require the device itself to be aware of its location. Returning the position to the device at all was extraneous. For use cases where it did seem necessary for the device know its location, the logic in the device firmware could be offloaded to the cloud. For example, in a geofence application, the fence could be configured on the cloud, and the device would only need to be notified when its position moved outside of the fence.

The other major takeaway from customer feedback was the desire to use network-based positioning as a supplemental solution alongside GNSS. In private access, combining location obtained via GNSS with network-based positioning was messy, and the former would not show up in the Golioth Location map visualization. This was especially frustrating when multiple fleets existed in the same project, with some devices using GNSS and others using network-based positioning.

To address these concerns and more, we have removed the device-facing Golioth Location API endpoint, and instead introduced a Pipelines location transformer and location destination. The former is used to translate network information into a position, while the latter stores the most recent location for a device, regardless of how it was obtained. These can be combined with any other Pipeline transformers and destinations. For example, if you need to store the historical location for a device, you can add a step to send positions to LightDB Stream via the lightdb-stream destination. If you need to return data to a device, you can add a step to set the current position in LightDB State via the lightdb-state destination, allowing the device to fetch its own location. You can even combine all of these into a single Pipeline, which addresses a wide range of use cases.

filter:
  path: "*"
  content_type: application/cbor
steps:
  - name: convert-to-json
    transformer:
      type: cbor-to-json
      version: v1
  - name: resolve-position
    transformer:
      type: location
      version: v1
  - name: store-location
    destination:
      type: location
      version: v1
  - name: stream-location
    destination:
      type: lightdb-stream
      version: v1
  - name: set-state
    destination:
      type: lightdb-state
      version: v1

You can supplement the Pipeline above, with one that omits the location transformer and instead delivers data directly to the destinations after converting to JSON. This would allow for positions obtained via GNSS to appear in each destination in the same manner as those obtained via network-based positioning.

filter:
  path: "*"
  content_type: application/cbor
steps:
  - name: convert-to-json
    transformer:
      type: cbor-to-json
      version: v1
  - name: store-location
    destination:
      type: location
      version: v1
  - name: stream-location
    destination:
      type: lightdb-stream
      version: v1
  - name: set-state
    destination:
      type: lightdb-state
      version: v1

Lastly, because the existing device-facing location API has been removed in favor of existing data streaming capabilities, customers do not need to update their Golioth Firmware SDK versions to start utilizing these features. Nevertheless, we have introduced new net_info functionality in the most recent version of the SDK to make using network-based positioning simple and straightforward.

info = golioth_net_info_create();

struct golioth_wifi_scan_result golioth_result = {
    .mac = {result->mac[0],
            result->mac[1],
            result->mac[2],
            result->mac[3],
            result->mac[4],
            result->mac[5]},
    .rssi = result->rssi,
};

status = golioth_net_info_wifi_append(info, &golioth_result);
if (status != GOLIOTH_OK)
{
    LOG_ERR("Failed to append Wi-Fi access point");
    return -1;
}

status = golioth_net_info_finish(info);
if (status != GOLIOTH_OK)
{
    if (status == GOLIOTH_ERR_NULL)
    {
        LOG_WRN("No network information data provided");
        return 0;
    }

    LOG_ERR("Failed to encode network information data");
    return -1;
}

err = golioth_stream_set_sync(client,
                              "loc/net",
                              GOLIOTH_CONTENT_TYPE_CBOR,
                              golioth_net_info_get_buf(info),
                              golioth_net_info_get_buf_len(info),
                              SYNC_TIMEOUT_S);
if (err != GOLIOTH_OK)
{
    LOG_ERR("Failed to stream network data: %d", err);
    return -1;
}

Getting Started

Ready to get started? Go the the Location section in the console to activate Golioth Location, then check out the examples in the documentation to start tracking your devices. To learn more about network-based positioning pricing, take a look at the Golioth pricing page. If you have any questions or feedback, reach out to us on the forum!