How useful is util/cellular/cells for geolocation?

Hi,

suppose I read the CID and LAC from util/cellular/cells and figure out it is the Cell ID and Local Area Code - these values can be used in geolocation APIs if you can find one. Also the nearby cells information…
However I haven’t found an API that gives me even a vague area for that information, and I am wondering how accurate the values are.
For example I see the LAC always seems to be 65535 which seems suspicious to me (-1 in 16-bits?).

Are the values accurate, and has anyone found a geolocation API that works with the values from the MangOH?

-Camilo

A while back, a colleague looked at using a 3rd party service for cellular based location services. This was a while ago and I didn’t do the work myself, so I’m a bit hazy on the details… I believe the conclusion was that on wp76/77, it was only possible to get the information about the currently connected cell tower and not other adjacent towers due to limitations in the Qualcomm APIs. Without having multiple points of reference a location service won’t be able to provide a precise location. Have you looked at WiFi based location services? I have found that those work quite well.

Thanks @dfrey - I can add some info. I know the location won’t be as precise as GPS/GNSS and one cell tower will be even less precise than several. It is still useful and should essentially be ‘free’ information as the radio is already in use - compared to enabling wifi which will cost power.
On the MangOH yellow you do get adjacent cell info it seems, I can confirm with this example:

"cells": {
  "mcc": "234",
  "cid": 9,
  "mnc": "10",
  "rat": 4,
  "nb": [{"cid": 71,
          "lac": 65535,
          "rx": -79
          }],
  "rx": -70,
  "lac": 65535
  }, 

You can see an additional CID, LAC and RX value where the RX is not as favourable as the main one… Still I haven’t found a service to translate this to a location, frustratingly. I know android phones do this but they will largely use LTE instead of 2G. And I suppose it is different again for NBIoT if we get to use that…

Folks, I can’t give up on this yet. After a deep dive into this I have found that the device occasionally reported different types of numbers where location could be determined. The difference was RAT=1 instead of RAT=4.

Right now RAT=4 and in the Octave console the signal is reported as LTE (odd as we believed the MangOH was NBIoT with 2G fallback)

Is there anywere that documents the meaning of the RAT values and how to select them? I saw mention of cm radio rat LTE to force LTE for example

I would be interested to force RAT 1 somehow to be able to get working cell based geolocation.

As a wider issue I understand the 4G values reported for cellid can be larger than 16bit and I suspect that the path this data takes from the modem to the octave code is somewhere restricted to 16bit and thus overflowing and resulting in broken cellid based location - can anyone confirm this or suggest where to look for a diagnosis?

-Camilo

Let me get back to you on that.

@asyal interesting!
I have managed to force GSM mode using
cm radio rat GSM
Then the values can be looked up - I used a cloud action to query opencellid service which sometimes returns a location. I will try the google service next.

Side question - if I force GSM with the cm command, where is this persisted and can it be set from octave??

@jvermillard is this controllable via Octave?

if you use the AT!SELRAT at command or the cm radio rat it will be persisted

it’s not possible to do it remotely (it’s quite dangerous you could disconnect a remotely deployed device)

lac is not available in LTE so that’s why the returned value is max 16bits. The underlying legato api used is: https://docs.legato.io/19_11/le__mrc__interface_8h.html#a70ba0ca70367bc673a6bca1e246bb88f

Thanks @jvermillard, so to summarise, the info in the cells JSON structure is NOT useful for geolocation when LTE is in use, and doing anything other than leaving the cm radio rat AUTO is dangerous.

Looking at the signal strength reports it seems we manage to call different APIs to retrieve this for LTE vs UMTS and GSM. So could we get the TAC for LTE instead of trying to get the LAC which is unavailable? For example using the underlying Legato API:
https://docs.legato.io/19_11/le__mrc__interface_8h.html#a856dc7825b4fa8de095f26020e03f015

Is this a bug or a feature enhancement? Or should there be another way to get this really valuable data to support geolocation?

the format of cell neighbor in LTE is buggy for sure. I filled one on internal octave bug tracker. don’t hesitate to reach your FAE or the sales in charge of your account to escalate if it’s blocking you