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]

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]

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.

[xuan0802]

I tested under opensky, 4 sattelites are used but a fix can not be obtained for too long time. Is there any solution to overcome this problem ?

[xuan0802]

At least any workaround solution is highly appreciated, we are developing a tracker product :(

[Hakon]

What hardware are you using? Is it a DK or a custom board?

[xuan0802]

we are developing our own tracker product. So it should be our custom board. But actually, we also tested with your dev kit too. At some time frames during a day, we can not get a fix for hours. This is unacceptable for the outdoor environment. We would like to have some features such as AGPS and some configuration parameters that we can change to reduce the GPS fix time during the difficult time frames.