Problem with AGPS function

[xuan0802]

Hi Nordic guys,

We just integrated the AGPS function using SUPL library with the GPS driver to accelerate the GPS fix time.

We tested our code with near windows environment when there are less than 3 satellites. 

We saw that the connection to SUPL server is ok and some assistance data have been downloaded and injected into GPS receiver.

But we still can not get the first fix. 

According to my understandings, with the support of AGPS, the first fix can be obtained with less than 3 satellites.

Here, from our log we can see and use 3 satellites but can not obtain the first fix.

I am not clear about the problem here, can anyone tell me what problem is?

Thanks you very much, 

[Stian Røed Hafskjold]

Hi, because of summer vacations there will be some delays in the response time here on Devzone. I will have a look at this on Monday next week. Hope that's ok. Sorry for the inconvenience.

[xuan0802]

Did you take a look at it ?

[xuan0802]

Hi Stian, Did you take a look at it, we really need this function because the first fix is so slow

[Stian Røed Hafskjold]

Hi. I'm looking into your issue now.

I just have one question. What measures do you take in order to ensure that the GPS is not activated while the radio is active? The reason why I ask is because the GPS and radio cannot coexsist, so the GPS has to be turned on after the radio is turned off. So if you connect to the network to download AGPS data, you will have to wait to turn on the GPS. For example if you are using PSM mode: First you subscribe to the AT+CSCON notification, this will tell you when the RRC connection is released, which usually happens after 5-60 seconds. Then you have to wait until the active timer (T3324) runs out (eDRX mode) before it enters PSM. This timer value can be found in the AT%XMONITOR response <active time>. Now you can start the GPS, after PSM has been entered.

I have also asked the modem team for more GPS specifications, which may clear things up.

[xuan0802]

Hi Stian, 

Currently, We do not run GPS and LTE concurrently.

 We use the same measure as in the GPS example, but the difference is we are using GPS driver instead of directly opening the GPS socket. The there is AGPS request event, we turn on LTE using AT command similar to the GPS example. After, the SUPL session is finished, we turn off LTE and start GPS again.

I see that, when I turn on LTE, the GPS driver is blocked. After turning off LTE, the GPS driver starting searching again. Am I right? 

I attached our code, you can take a look.

agps.rar

[Stian Røed Hafskjold]

I got some feed back from the GPS experts:

Generally, 4 satellites are required to get a fix, so 3 is not sufficient. Note that some windows quite efficiently block GPS signals because they have some sort of metallic film.

It also depends on how the minimal 4 satellites are positioned in the sky. If they are close to each other, near the horizon, have weak, lossy signal, more satellites may be required. There could be some special case where 3 satellites could be sufficient, but that's not typical use. There are 4 unknowns in the equation system that needs to be solved (x, y, z position and receiver clock bias), so 4 satellites are generally required. With increasing number of satellites, the accuracy usually also increases.

In addition to having strong enough signal from at least 4 satellites, the receiver needs to know the ephmeris data and accurate timing information for each satellite. Ephemeris can be received using A-GPS or downloaded from the satellites, which may take a while. Timing information is sent from satellites every 6 seconds if I recall correctly, so with A-GPS and fairly clear sky view the expected TTFF is typicall RRC inactivity time + 5 seconds or so.

Note that A-GPS doesn't affect the number of satellites required, as it only provides a faster way to acquire ephemeris/other assistance data and not accurate enough timing information to correct the receiver's clock bias.

As mentioned in, the satellites' position also plays a part here and affects the accuracy. The receiver requires a certain estimated accuracy before calling it a fix. There's a new option in the GPS sample that can be used to output NMEA strings: https://github.com/nrfconnect/sdk-nrf/blob/master/samples/nrf9160/gps/Kconfig#L9

Using the NMEA strings, it's possible to read out for example signal strength, satellite position and lots of other information that can help debug the issues. There are tools available to assist with this, like VisualGPS and others.