LR1110 chip: one solution for LoRa and GNSS tracking

LR1110 chip: one solution for LoRa and GNSS tracking

LR1110 chip: one solution for LoRa and GNSS tracking 2560 1707 Irnas

Authors: Luka Mustafa and Marko Sagadin

This year, Semtech, a leader in LoRa and RF technology, introduced another very capable LoRa transceiver to their list (like SX1261/2/8 family), the LR1110. With an extra set of localization features, we believe LR1110 will be the game changer in asset tracking.

At IRNAS we develop applied IoT solutions for clients worldwide and jointly with them create a vision of novel products to enable their respective industries. Ranging from electrical grid IoT systems empowering advanced real-time diagnostics of the infrastructure, monitoring penguins in Antarctica, to asset-tracking in Africa and Rhino tracker implants. IRNAS’ vision to create robust devices with up to 20-year lifespan leads us to be creative, innovate and look outside the limitations of present solutions.

We are actively pursuing the best in class solutions, and in this article you shall find a hands-on comparison of LR1110 GNSS positioning with Ublox ZOE-M8G, demonstrating a 10 fold increase in battery life and unlocking a range of new products. As Wienke Giezeman, CEO of TheThingsNetwork, very well put, this “pretty unique piece of silicon” is a game-changer. The LR1110 is the latest in a flurry of dual-mode silicon that appears to be enabling new use cases for the IoT sector at large.

At IRNAS, we ourselves have confirmed this hands-on and we invite you to set up a call with us to discuss integrating LR1110 into your IoT product.


Semtech LR1110 LoRaWAN transceiver with GNSS and WiFi scanning evaluation has shown promising results. To best share our hands-on experience at the first instance we organized this session to explore the capabilities of the solution and share our initial experience. 

  • Thomas Telkamp – Lacuna Space – enabling IoT to space connectivity with LoRaWAN
  • Orne Brocaar – Chirpstack LoRaWAN server with upcoming support for LR1110
  • Fabien Ferrero – RF and antenna expert, working with LR1110
  • Luka Mustafa – IRNAS – Applied IoT solution development with LR1110

WEBINAR: Hands-on experience with LR1110 LoRaWAN transceiver with GNSS and WiFi functionality

Semtech LR1110 LoRaWAN transceiver with GNSS and WiFi scanning evaluation has shown promising results. To best share our hands-on experience at the first instance we are organizing this session to explore the capabilities of the solution and share our initial experience. 

More Details

Semtech LR1110

The LR1110 is capable of GNSS scanning and Wi-Fi AP passive scanning, enabling indoor and outdoor localization alike at very low power consumption. This means that it is capable of communicating over LoraWan and it can be used to acquire position coordinates either through GNSS or Wi-fi signals. Crypto engine allows to keep LoRaWAN keys inside the device and secure joining and communication.

Particularly when combined with Zephyr RTOS and Nordic semiconductor nRF52, it has enormous potential to be an “all-in-one” solution.


LR1110 provides an interesting solution, particularly where low-power operation and device cost are most critical. A good example from our portfolio are animal and asset tracking systems, where a typical design consists of an MCU with LoRa transceiver and GNSS receiver chip. LR1110 combines both functions with an additional benefit WiFi positioning and thus:

  • Board complexity and BOM cost is decreased
  • Very low-power GNSS signal acquisition under clear sky conditions is possible
  • Extremely low power WiFi localization for outdoor urban and indoor applications

But how does LR1110 geolocate? And how does it differ from classic NMEA format messages over UART?

From MAC addresses/NAV messages to geo-location

By itself, LR1110 is not able to determine the location on-chip, however it can do data pre-processing and compression. Both Wi-fi and GNSS scan results are then sent to the LoRa Cloud geolocation server where they are resolved to the actual location. While this may not be suitable for all applications where the IoT device itself needs to know its own location, the vast majority of use-cases require it to be only known in the cloud, for which this solution is perfect and more power-efficient than traditional GNSS receivers.

Geolocation with Wi-fi

Passive Wi-fi scan looks for broadcast packets from WiFi access points and extracts MAC addresses and their corresponding RSSI values. This data is then sent over LoRaWAN to geolocation server, which does all the computing and finally outputs position. This approach is preferred in closed areas with no open sky, like urban outdoor environments, offices or storage facilities. Given that the WiFi positioning power-consumption is significantly lower then GNSS, this can be attempted first in a majority of use-cases.

Geolocation with GNSS

GNSS receiver works in two modes.

In assisted scan mode, the user has to provide an Almanac file with the position of the satellites in the sky, assistance position (in range +/- 150 km) and the current time in GPS time format. All this information helps LR1110 to minimize satellite search time and optimize the time and energy needed to obtain information about the position.

Almanac file is around 2kB big, but it is saved in the flash memory of LR1110, so only seldom updates are required. The Almanac expires after 3 months, but it should be updated every month for optimal performance. Fresh Almanacs are provided by Lora Cloud server every two weeks and can be sent to the device over LoRaWAN. An additional piece of information the device requires is precise time, either by the RTC on board of the device or provided via the network.

In autonomous scan mode, chip searches for the strongest signals in the sky. No assistance information is needed, but power consumption is larger than in the assisted scan mode.

After completing either one of the scans, LR1110 outputs NAV message, which is a binary payload containing satellite IDs and their data. This message, along with the timestamp of when the scan was done, has to be sent to the geolocation server for final computation. Only then we can receive coordinates.

Setup at IRNAS

At IRNAS we develop products where LoRa and GNSS technologies are combined and have been pushing the limits of the low-power operation of thus-far available technologies. LR1110, however, provides a leap forward in low-power operation. Let’s see what we can do with it.

Evaluation setup

As the first step, we have prepared an evaluation setup using Nucleo-478RG and LR1110 evaluation board based on drivers developed by Lacuna Space team. A Python test script that communicates with LR1110 via UART to sync time and gather statistical information has been prepared. Alternatively, a solution with onboard RTC has been used for standalone operation with NodeRed integration to LoRa Edge, available on IRNAS GitHub along with a range of other projects.

In the test setup, LR1110 makes an assisted GNSS scan and sends NAV message, along with some extra data over LoRaWan to TTN. A Node-Red instance listens to the traffic, parses the messages and prepares the HTTP post request to Lora Cloud geolocation server. Resolved coordinates are then received and saved into an Influxdb database. With visualization tool Grafana, this data is then queried and mapped.

To have a better look into the operation of LR1110, a series of raw data examples at all stages of the process has been prepared. The raw payload example shown below is returned from LR1110 (its length is subject to the number of satellites found).


This payload then needs to be sent via LoRaWAN or other means to a server that performs the request to the LoRa Edge solver and returns the actual location. Example below in Python can be used for this purpose.

There are a few specific fields here that must be understood in more detail:

  • gpstime – time when the fix has been acquired if provided externally to the solver. Time configured in the LR1110 is contained within the raw payload.
  • help_position – coarse position of the device to aid the solver.
  • gnss_capture_time_accuracy – requires a bit more thought, as if this value is <16 then the field gpstime is used as the time of fix. You can, for example, use the time acquired from the gateway or other means to override the time in payload.
  • gnss_assist_position – rough position estimate of where the device is.
import requests
import json
URL = ""
payload = "010106D9430816a202a82aeb61df9b2d5031d5367d072aa05209c0c7ae7651d5b8e7203c09a3caba8ea4bf8c8c16558652c17787636a776c44f9294cd5a54356ff4900"
gpstime = 1271763033
help_position = [46.452761, 15.641854]
json_dict = {
        "payload": payload,
        "gnss_capture_time": gpstime,
        "gnss_capture_time_accuracy": 15,   
        "gnss_assist_position" : help_position 
headers = {
        "Ocp-Apim-Subscription-Key": AUTH_TOKEN
response =, json=json_dict, headers=headers).json()

An example of a resolved response from LoRa Edge solver.

  "result": {
    "accuracy": 4.0,
    "capture_time_gps": 1271763033.13784,
    "capture_time_utc": 1587727815.13784,
    "ecef": [
    "gdop": 4.1,
    "llh": [
  "warnings": []

Performance evaluation of LR1110 and Ublox ZOE-M8G

Energy consumption

The performance has been compared against the u-blox ZOE-M8G that we most commonly use in our solutions. Such comparison is use-case specific and may not apply to everyone; however, it should suffice for feasibility purposes.

On average, the ZOE-M8G consumes 45 mA at 1.8 V from start-up to first GPS fix.
First cold fix takes about 30 – 60 seconds in standard scenarios, depending on the conditions (open field, nearby buildings etc.). To support hot-fixes, it is then put to sleep at 15 uA at 1.8 V. Assuming a fix is acquired every hour, the time to fix is typically in the 10-second range. Note, however, that the device receives the exact time and position using such a method and no external services are required.

On the other hand, LR1110 is able to get NAV message in 4.5 seconds at 6 mA (note that this is rather worse-case and better with up-to-date almanac) at 3.6V with potential to increase power efficiency even further.

Location accuracy and power consumption

Hands-on testing is the best strategy to compare different technologies in a real environment. The set-up consists of the internals of the Smart Parks Lion tracker system with passive GNSS antenna and LNA and LR1110 evaluation board with a passive GPS antenna with LNA. The fairest comparison would be to use both devices with the exact same antenna configuration; however, that was not practical at this point, meaning we need to take antenna-wise advantage of LR1110 into consideration in this case. As a next step at IRNAS, we aim to design a solution with active switching between the two GNSS solutions with the same antenna.

The figure below shows the signal levels of LR1110 eval kit antenna (left) and custom IRNAS board (right) solutions used when both connected to the Ublox u-center for evaluation, rather comparable signal levels are observed. See our post about antenna tuning for potted devices for more details. Note that this is not a very accurate method to compare and is only shown as a guideline. As a next step at IRNAS, we aim to design a solution with active switching between the two GNSS solutions with the same antenna.

LR1110 signal levels

Custom board signal levels

Below we can see locations taken with ZOE-M8G and LR1110 in 1 min, 30 min and 4-hour intervals. Important to note with this setup is that GPS fixes of ZOE-M8G are deemed valid when epe<50, and should we set this value lower, the fix would get significantly more accurate – at the expense of additional power consumed. Such configuration has been chosen as it is the default power optimal used across our projects. Blue dots represent recorded positions, green dot represents the actual position, and red represents the average position.

We calculated the average distance from the actual position, the maximum distance from the actual position and the average time to fix.

Average error is computed as an average position of all the points. Maximum error is the maximal deviation from the actual position over the time of data capture, and the process is random. Avg time to fix is computed for all the data points in a given data set. Avg power per fix is calculated from Avg time to fix and power consumption of the device.

The key difference is, however, that ZOE-M8G can be configured to produce more accurate fixes vs. LR1110 running at constant performance. This is very important to keep in mind when determining the application.

Judging just from Average error, we can see that both chips perform similarly, distance is around 25 to 30 meters, a bit on the higher side for LR1110 chip.

There are, of course, some fixes that span further than that: u-blox’s chip reported one distance that was 131 meters away from the actual position. But this is nothing compared to 818 meters from LR1110. Given the solver is cloud-based and Semtech has a good roadmap on improving it, we expect a continuous increase in performance. A histogram plot of positions has been constructed to get a better insight into the position errors. Both solutions similarly taper off in terms of fix precision to about 100m accuracy with very few outliers after that, ZOE-M8G being at advantage in precision better than 25m. Note that the histograms below have the last bin at 200 grouping all the values > 200.

The most important step, however, is to understand when the fix is accurate or not, and thus an investigation has been made with hdop and gdop metrics provided by the two solutions. Preliminary results shown below are not very encouraging, as for either solution we were not able to clearly determine the relationship of the fix to the error, observing greater errors reported when the actual error is small and vice-versa. Further investigation is required at this point, but it is beyond this current post.

LoRaWAN energy consumption

While the GNSS position acquisition power consumption depends on the fix time, the consumption for communicating that results depends on the payload size. Our standard payload for u-blox GNSS devices is 10 bytes, including the gnss position, time of the fix and fix quality information. This could be optimized down to 5 bytes if so required.

LR1110 NAV message, however, is of variable length subject to NbSvMax setting configuring the maximum number of satellites to be sent. A typical 8 satellite payload is 32 bytes, with extra fields enabled it can be of 67-bytes length, 5 satellite payload is 44 bytes. Note that a 51-byte user payload length is recommended for general compatibility with all networks and spread factors. All calculations include the 12-byte LoRaWAN header in addition to user bytes.

Using TTN airtime calculator EU868/BW125kHz, the following results are obtained. See Qoitech blog on spread factor power consumption relationship. Transceiver assumed is SX1262 at 20dBm/84mA/3.3V for the calculation, no RX window power consumption has been accounted for. Ballpark, the results show that payload increase from 10 bytes to 51 bytes about doubles the power consumption.

Evaluating the combined use-case of power consumption and data transmission yields interesting results. While the LR1110 data transmission will take about 45% more energy, the per fix power consumption is very low, and this offsets the results significantly. ZOE-M8G is more power optimal solution only in the 1 min interval use-case at SF12, although that is not a realistic use-case for EU868 band, at least as it violates the duty-cycle interval.

Use-case Lacuna Space overview

Our colleagues at Lacuna space are leading the IoT to space revolution with LoRaWAN to space connectivity, and LR1110 is an enabler in this story. They have done amazing work already that we build upon and demonstrated LR1110 to space connectivity.

The low-power WiFi/GNSS acquisition increases the battery life of asset tracking and other solutions in this scenario. More importantly, due to an all-in-one chip design and very competitive pricing, the overall solution significantly decreases the cost by at least a half. This is an opportunity for existing products, but more importantly, it unlocks new use-cases where geolocation and IoT to space connectivity have not yet been possible.

Use-case OpenCollar overview

Smart Parks is a Dutch social enterprise based in Utrecht. A Smart Park is a nature reserve that uses smart sensor technology to collect information for the improvement of nature protection and management. Together we have been creating OpenCollar GPS trackers that use the latest u-blox GPS technology to acquire the precise location of an animal and transmit it via LoRaWAN. The past year has proven significant benefits of this solution in terms of tracking resolution and battery life.

Rhino tracker

OpenCollar Rhino GPS tracker can be taken as an example. With a Saft LS14250 battery, rated at 1200 mAh capacity, the following parameters can be estimated.

Given that the typical lifespan of the Rhino horn implant is 2 years, translating the above results into practice would mean that the fix interval can be decreased from 4 hours to 10 minutes, which would be a massive improvement at a very little cost. Here are a few ballpark projections we have made.

Rhino tracking

  • Single SAFT LS12520 battery with 1200 mAh capacity (note that discharge currents significantly affect available capacity)
  • Current system: estimated 1200 fixes
    • hot-fix 30s at 45 mA at 1.8 V = 675 uWh per fix (assume about 60 % of battery available due to current rating)
  • LR1110 projection: estimated 40000 fixes
  • fix at 4.5s at 6 mA at 3.6 V = 27uWh per fix (assume about 90 % of battery available due to current rating)

Small animal tracking concepts

  • 30g weight solution with 10-year tracking lifespan without charging
  • <3g weight solution
    • best in class trackers currently deliver 144 fixes per charge
    • with 20mAh 1g cell, LR1110 can deliver about 1000 fixes + LoRaWAN messages

Sea animal tracking

  • 1.65s fix time enables GPS position to be acquired as soon as the animal reaches the surface, even if only very briefly (requires good GNSS signal)

Final thoughts

LR1110 is very promising for a wide array of solutions, provided good sky view and accurate time is available (either at the device or on the receiving side prior to the solver). For applications where greater accuracy is required or the actual time and position to be acquired at the device itself, traditional GNSS receivers remain the default choice. However, LR1110 is the only one offering integrated WiFi passive scanning, unlocking a range of new positioning applications in urban environments or with dedicated beacons.

From what we could experience in this evaluation, we are happy to say LR1110 will become a standard part of our designs and we look forward to creating new applied solutions with it.

Set up a call with IRNAS to discuss integrating LR1110 into your IoT application, create an evaluation setup and accelerate the creating of a next-generation product.

To kick things off and best share our hands-on experience, we are organizing a webinar session with some of the best and most relevant experts in the field to share their knowledge with us. We would like to invite you to further explore the capabilities of LR1110 and share your thoughts with us!