Is it possible to identify and isolate GNSS chips using GPSTest Database?

[V. Kelly Bellis]

Qualcomm and Broadcom, for example, make several several different chips used by various OEMs for their smartphones, many of which are represented in the GPSTest Database. But the GPSTest Database only lists 'GNSS hardware model name' as the column heading with cell values that sometimes contain arcane identifiers, but often do not.

The thing that prompts the question is illustrated by the scenario in trying to find all instances in GPSTest Database of Qualcomm's Model number SM7250-AA, also known by the name Snapdragon 765. Doing a search of the GPSTest Database for SM7250 returns 0 results. Doing a search for SM72 returns 0 results. Doing a search of just the first 3 characters; i.e., SM7, returns only 10 results.

The Product Sheet for the Qualcomm Snapdragon 765 5G Mobile Platform boasts that the chip supports dual frequency; however, all evidence from users of this chip that have contribute to the GPSTest Database thus far indicates that the  Qualcomm Snapdragon 765 does not support dual frequency.

The interesting thing about the Qualcomm Snapdragon 765; it reportedly did support dual frequency, however only briefly, in the Samsung Galaxy A71 when it was first released. Apparently for a few weeks the A71 5g saw L5: A71 5G Dual Frequency GNSS

I've posted the question Why did SM-716U stop using L5?  over at XDA, but wondered if anybody here in the GPSTest group had any knowledge on the matter?

[Sean Barbeau]

Yes, unfortunately all we have to work on that's programmatically accessible via Android APIs is the "GNSS hardware model name". It looks like there are some patterns within this data (e.g., "SDM" or "SM" for Snapdragon model prefixes) but no standard. If someone wants to collaboratively work on deciphering what the common patterns are I'd certainly welcome the help. The script I have could certainly add another column and automatically parse out the model and map it to a more human-readable name.

Re: dual-frequency disappearing - I've been told that there are often contractual arrangements between Qualcomm and the device OEM that defines whether or not a specific feature, including L5/E5a, is available on a specific device, even if the chipset supports it. So for the A71 - it could be a bug that accidentally removed L5/E5a, or it could have been that the A71 was never intended to support L5/E5a per the contract with Qualcomm and someone messed up the initial config to accidentally allow it.

Sean

[V. Kelly Bellis]

getGnssHardwareModelName()

Returns the model name (including vendor and hardware/software version) of the GNSS hardware driver, or null if this information is not available.

As you point out, and as GPSTest database clearly illustrates, there appears to be no industry standard for the Android API to access and report on GNSS system on chip (SoC) details. Staring at the database, at least three GNSS SoC manufacturers can be recognized:

• Broadcom
• Qualcomm
• MediaTek

Nearly a quarter of the database records have the ' GNSS hardware model name ' field totally empty while also none of those 228 records (as of 20210601) indicate supporting dual frequency. These null records are rather interesting in and by themselves as they cover a wide range of time, platforms, manufacturers, and GPSTest versions.

As for potential patterns which might yield a value for a new record attribute ' GNSS SoC ' from a regex operation, there are these recognized nomenclatures:

• BCMnnnn
• SMnnn
• SDMnnn
• MTnnnn

There are more records than not having a recognizable GNSS SoC model identifier. Many have names that include bits like MTK_MNLD, SM_SAIPAN, SM_BITRA, SM_RENNELL, NICOBAR, SM_LAHAINA. And still others with only the value of 'qcomm;' and nothing else.

So why bother with this matter further? One reason to consider the addition of the new record attribute ' GNSS SoC ' would be in helping to identify those manufacturers that have turned on access to L5/E5a.

Another reason to consider the addition of the new record attribute ' GNSS SoC ' might be in formulating arguments as to why there is a need for industry-wide standards for GNSS SoC architectural identifiers.

Kind regards,

Kelly

[Robert Enger]

(At least on some of the older test results) weren't the accessible constellations limited by US Government (or other political) regulations?

Maybe that is why some of the records in the database look strange?

E.g. my ancient LG V20 appeared to list Beidou sats, when I was on vacation in Peru.  They "magically" disappeared once I returned to US soil.

--
You received this message because you are subscribed to the Google Groups "GPSTest" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gpstest_andro...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gpstest_android/1a7e006f-5fd1-43a7-9a0a-7f471e0417a7n%40googlegroups.com.