GPS

[pemar13]

Hi!

We have been experimenting with the nRF9160's GPS using both one of our own custom board and the Development Kit v 0.8.5 (with similar results).

We run the gps sample app in ncs version 0.4.0 using the FW 0.7.0-29.alpha.

We manage to "lock" the GPS and get valid PVT data after typically 2-4 minutes when we are outdoors. When we are indoors at an open window things work less well and often not at all.

These results are not really to our satisfaction. Since the antenna of the latest DK is supposed to be matched and the antenna on our custom board is pretty well matched, it is unclear why performance isn't better, but we hope things will improve. Do you have any comments on this?

Furthermore, the GPS API isn't extensively documented. Although it certainly is possible to figure out how to use it using the nrf_socket.h file and the gps sample, some more documentation would be welcome. Is this planned?

One detail in the code is not clear. In the GPS sample’s main.c, procedure print_satellite_stats, line 163, the counter in_fix is incremented when NRF_GNSS_PVT_FLAG_FIX_VALID_BIT is set in pvt_data->pvt.sv[i].flags. Looking at nrf_socket.h line 177, it would seem that NRF_GNSS_SV_FLAG_USED_IN_FIX should be tested instead. Do you have any comments on this?

Finalyly, the latest FW 0.7.0-29.alpha does not support GPS and NB-IoT concurrently. For when is this important functionality planned?

Best regards,

Per

[firmwareguru]

Hi Per, I am curious as to what you are using as your GPS performance baseline.  Can you please elaborate on what makes you think 2-4 minutes is a poor lock time? Since this is a new GPS device we are talking about, it is extremely important to refer performance data to a "known good" GPS receiver of similar class and capability in exactly the same conditions (location, time of day, etc).  

It is harder to do that than we might think - the lock time depends on a few factors, including if the receiver is starting up in a so-called "cold start" condition where it has no almanac nor ephemeris data, nor any notion of time.  It must spend its time blindly searching all PRN codes, and then when it does find and lock to signals is must download the ephemeris for each satellite.

To make an apples-apples comparison, both devices should either have been locked and tracking for a day before running this test (e.g. power cycling then measuring time to first fix (TTFF)), or both devices "factory reset" to come up in cold start.

If there is a discrepancy, it could be that the nRF is not saving downloaded almanac and/or ephemeris, or that the RTC is not running/working/being used.  All of these things need to happen to get a chance at fast TTFF. 

I would also like to add that NB-IoT is not a "roaming" technology therefore it is not necessarily targeted at mobile applications.  I might envision a deployment of statically located devices in a building, or around a city using NB-IoT, where the position of the device would be determined just once at installation which might not necessarily be a coordinate but an asset, e.g. 'smart meter 62'.  That said, using an even lower power technology like NB-IoT to locate assets within a cell tower radius using GPS could be useful.

[pemar13]

Hi Evan

First off, many thanks for your comments. We need a well-working GPS and input from experts is more than welcome.

Unfortunately, we currently don't have any possibility to benchmark other modules under identical conditions, which, as you point out, is necessary for any stringent performance comparisons. However, our feelings are based on our previous experience with u-blox modules, which have been performing quite well.

As you mention, it is important to understand what is going on at startup before assessing performance, but this isn't easy given that the true operation of the nRF9160 GPS is "hidden" under the API and the documentation is quite limited. Hence this ticket.

We certainly expect a longer lock time for the first cold start, but we have assumed that storing the almanac and other important data would result in faster subsequent startups, even after a reboot. Whether or not the RTC is running/used in the demo app I cannot say.

I hope that Nordic will be able to give us some tips on how to improve things.

Best regards,

Per

[firmwareguru]

Your gut feel that it is not performing well against the uBlox is good info.  I too am interested in using nRF9160 in a project.  

I would like to know what is the GPS IP used in this device.  And I agree that exposing more of the GPS engine operation through APIs would be well received!