Google maps integration does not set the radioType

[ztindall]

We are using the google maps integration and have noticed a high number of failures for our newer devices. After looking more into the failures, I don't believe the integration is passing the radioType property to the geolocate endpoint

The following request body returns a 404

{
	"carrier": "",
	"considerIp": false,
	"cellTowers": [{
		"cellId": 28094225,
		"locationAreaCode": 5648,
		"mobileCountryCode": 310,
		"mobileNetworkCode": 410
	}]
}

However, the following request body returns a valid geolocate result

{
	"carrier": "",
	"considerIp": false,
	"radioType": "lte",
	"cellTowers": [{
		"cellId": 28094225,
		"locationAreaCode": 5648,
		"mobileCountryCode": 310,
		"mobileNetworkCode": 410
	}]
}

The default value for radioType is "gsm"

How can we add an explicit radioType to the request that is made to google?

[rickkas7]

Unfortunately there is no good way to set the radio type in the built-in Google maps integration. The reason is that previously lte did not work well and leaving it out worked much better so it's not included.

There isn't anything particularly magical about the Google Maps integration. What I would do instead is use Logic to do the expansion of the tags and add in the radio type.

[rickkas7]

There's a workaround in this post that's easier than using Logic.

[ztindall]

Thanks @rickkas7, is it safe now to hardcode lte as the radioType for all devices? Seems like this may fix some of the broken geolocate calls and break some of the existing ones that work

[rickkas7]

It's hard to say for sure, which is why we don't just change it in the official integration.

In the United States, there are almost no 2G/3G devices left, so always specifying lte should be fine.

And even in other areas, it may be OK. The thing is that both Google and Apple geolocation work by building a database of cell ID and LAC based on phones which report both a GNSS location and cell information. Since so few phones connect by gsm now, it's not surprising that that data is becoming less available. It's quite possible that carriers are using the same CID and LAC for both RATs, so it may work even if the device is 2G/3G and asks for LTE, but it's hard to prove that it will always work.

Another option is to send up the actual RAT, either gsm or lte, from the device-side code by modifying the library and webhook. The reason we don't do that is that the connected tower info is retrieved from cellular_global_identity() in Device OS, which doesn't return the RAT.

[ztindall]

@rickkas7, just wanted to add some stats to this thread for others curious about the solution.

45% failure rate using gsm with the built-in integration

0% failure rate using lte with custom integration