Crowdsourcing GNSS features of Android devices

Can’t I just look at the specs?

Mobile device manufacturers have been notoriously vague about GNSS features in official specifications. For example, if you go to Samsung’s website and look up specs for the Samsung Galaxy S21, you’ll see:

Model variants have different chipsets

Unfortunately OEMs ship different model variants in different countries, which can include different chipsets. For example, the S21 variants in the U.S., Canada, Korea, Chinese and Japanese normally get Qualcomm Snapdragon chipsets while Europe and other areas around the globe get Samsung Exynos chipsets. The Snapdragon 888 specs say it is capable of dual-frequency, but the Exynos 2100 specs don’t even list the GNSS capabilities!

OEMs sometimes add GNSS receiver hardware

Some devices (Xiaomi Mi 8, Samsung Galaxy S9, S9+, S10, S10+, Note10 Exynos variants) have packed in additional GNSS receiver hardware, in particular the Broadcom 4775 series that supports dual-frequency GNSS. And the presence of this additional hardware isn’t listed on any device spec sheet, so you’ll need to rely on Internet tear-down videos for your exact model to figure out what’s inside.

Devices have other limitations

Unfortunately even if you can confirm that a device has a dual-frequency receiver like a Snapdragon 888, it doesn’t mean the device will actually use L5 and E5a signals. Several devices (Samsung Galaxy S10, Samsung Galaxy S20 FE 5G, Google Pixel 4a 5G) include chipsets that support dual-frequency, but for some reason the signals don’t show up in GNSS testing apps. Presumably this is due to other hardware limitations on the device, such as the lack of a 2nd GNSS antenna and RF frontend for the L5/E5a carrier frequency, or licensing/purchasing contract limitations between the chipset vendor and device OEM.

Regional limitations

As the S21 specs say, “Galileo and BeiDou coverage may be limited”. But what does that mean? “G” in GNSS stands for “Global”, right? Well, for years the FCC restricted use of Galileo for devices in the United States, and even after the FCC lifted the ban many devices were never updated to allow it. The same restriction still seems to apply to BeiDou in the U.S. What about other countries? Do they force OEMs to limit which GNSS constellations can be used? 🤷

Software changes matter

Several devices have launched with GNSS features that changed with later software updates. The Google Pixel 4 and 4XL initially launched without L5 and E5a support, but a software update later added the capability. Conversely, some users have reported that entire GNSS constellations have disappeared after firmware updates due to bugs.

GNSS aficionado trying to figure out what features an Android device supports

Introducing the GPSTest Database

The latest feature in GPSTest sets out to solve this problem by providing a simple way for users to contribute device information to a centralized, publicly-available database.

  1. On the Status screen, wait for a GNSS fix (location)
  2. On the top Action bar, tap the “Share” icon
  3. Go to the “Device” tab and tap the upload to cloud icon
Using the GPSTest “Share” menu you can now contribute your device GNSS features to the GPSTest Database
The GPSTest Database (https://bit.ly/gpstest-device-database), implemented as a Google Sheet, contains crowd-sourced Android device GNSS capabilities

Key features

Here are some of the most interesting device features that you’ll find in the database:

  • Device manufacturer, model number, and name — Along with the GNSS hardware model name (see below), this identifies your specific device model.
  • GNSS hardware model name — This field is the best way to see the exact GNSS hardware in-use in the device. You’ll see something like qcom,SDM845,MPSS.AT.4.0.c2.1–00545-SDM845_GEN_PACK-2 for Qualcomm chipsets (SDM845 is the Snapdragon 845), and Broadcom, BCM4775, GLL ver. 108.20.22 478864 if additional Broadcom GNSS hardware exists. So no more waiting for teardown videos to discover the packed-in BCM4775! Also, some devices include a version number within this field that can be used to track GNSS changes across software updates. For example, based on this field and Android software build number (see below) it looks like dual-frequency GNSS was enabled for the Xiaomi Mi 10T Lite after a software update. Similarly, the Google Pixel 5 got Carrier phase support (see below) following a software update.
  • Supported GNSS — The GNSS constellations that the device supports. Examples includes GPS, Galileo, GLONASS, QZSS, BEIDOU, and IRNSS.
  • Supported SBAS — The SBAS constellations that the device supports. Examples include WAAS, EGNOS, and GAGAN.
  • Supported GNSS and SBAS carrier frequencies (CFs) — The specific GNSS signal bands that are supported by the device. Examples include B1, B2a, E1, E5a, L1, and L5.
  • Dual-frequency support — This column explicitly shows SUPPORTED if the device is receiving L5 , B2a, or E5a signals or NOT_SUPPORTED if no L5 , B2a, or E5a signals are observed.
  • Raw measurements SUPPORTED if the device APIs return valid GnssMeasurement pseudorange data, and UNSUPPORTED if it does not. Apps can use these raw measurements to calculate a location using innovative techniques that might be more accurate than the one your device OEM has implemented.
  • Carrier phase via getAccumulatedDeltaRangeMeters()— Carrier phase measurements are a more accurate way of determining your location from satellite signals than pseudorange alone by leveraging information from the radio waves that carry GNSS data (see this Google I/O presentation and this InsideGNSS article for details). If a device supports carrier phase measurements via GnssMeasurement.getAccumulatedDeltaRangeMeters() this field will be set to SUPPORTED, and UNSUPPORTED if it does not. If the device hasn’t reported measurement data at the time of submission, this value may be shown as UNKNOWN.
  • User location country code —GPSTest doesn’t send your latitude and longitude to the database for privacy reasons. However, as mentioned earlier, due to the regional device differences in GNSS availability it is useful to know from which country a user is reporting data. Therefore, the on-device Android Geocoding API is used to determine the country where the device is located at the time of submission. The resulting country code (e.g., US, JP) is sent to the database. If the device doesn’t support the Android Geocoding API, then this field is left blank.
  • Various software version numbers — Android version (e.g., 11), Android software build number (e.g., G955USQS8DTJ3) and code name (e.g., REL for production release) can all be used to track capability changes across software updates, as mentioned above. However, from data I’ve seen so far, it seems like GNSS hardware model name is the best indicator for when capabilities may have changed from a software update. These fields can also indicate if the user is running an official OEM ROM or a custom ROM on their device.

Caveats

The main caveat to data in the GPSTest Database is that Android doesn’t provide an API that explicitly indicates which GNSS and SBAS are supported by a device. As a result, GPSTest can only report on what it observes from the live environment (with some emerging exceptions — see below). GPSTest tries to maximize results by forcing the user to wait for a first fix before they can submit data. But, there are certainly cases where available SBAS or other data could be influenced by the user’s position and the time of day. Ultimately, each record reflects that individual user’s experience with their particular device in that location — there is no 100% guarantee that your experience will be the same.

  • Android 11 added an API for GNSSAntennaInfo, which indicates the number of GNSS antennas and their carrier frequencies, which should be an explicit indicator of dual-frequency support. However, as of March 2021 the data coming from this API seems to be bad for all devices reporting it. Google has indicated that this should be fixed in future updates, at least for the Pixel 5.
  • Android S developer preview hints that explicit APIs for support of raw pseudorange measurements and navigation messages are coming.

Tips & tricks

To submit data to the GPSTest Database, in the app first switch to the main “Status” screen. Before submitting, go outside and wait for a GNSS fix. On devices that do support dual-frequency, make sure you wait for the L5/E5a signals to show up before submitting the information (some dual-frequency devices will show L1-only for a few seconds before locking on L5). Then tap the upload button (the “cloud with an arrow” icon) and you should immediately see a new record appear at the bottom of the sheet.

Closing thoughts

I’m excited to launch this new feature and I hope it brings some much-needed transparency to the Android industry for device GNSS features. I also hope that it will encourage OEMs to publish more detailed and accurate information about device variants, and allow consumers, enthusiasts, and GNSS professionals to make more informed decisions. Oh, and if you’re wondering — looking at GPSTest Database it seems the S21 (Snapdragon and Exynos variants) does not support dual-frequency, while the S21+ and Ultra (Snapdragon and Exynos variants) do. 🤷

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store