Custom AGPS: Which data is required for the AGPS?

[Jan Erik]

Hi,

I'm currently implementing AGPS on 9160, nrf connect master branch.

Right before every GPS search we are connecting to our own server via CoAP.
To minimize data usage and power consumption I want to avoid using the SUPL library.
Instead I'm returning approximate coordinates and a timestamp from our server to the device, and I'm trying to feed it to the AGPS.

As there is no documentation for the gps driver I've been digging around in the code.
I've found a few data structures that I can send to the driver, but they all have quite a lot of extra data that I'm not sure is required or not.

The struct called nrf_gnss_agps_data_location_t seems to be the one I need, but it doesn't just have latitude+longitude, it has orientations and uncertainty etc.
Are all of those data points in the same struct necessary?
For instance, can I just use 0x00 or 0xff for some data points I don't have?

Also, should I load the AGPS with all the different types of structs as well?
Does some of the structs make other structs irrelevant?
For instance, should I load the agps with ephemeris, almanac and location, or would just location be enough?

---------

Bonus questions:
Do you have any examples of, or documentation regarding using AGPS through the GPS driver without the SUPL library?
What is the data usage and power consumption cost of using the SUPL library?
Am I crazy for rolling my own solution instead of just using it?

[Simon]

Currently, a huge portion of the support team (including many of the experts on nRF9160) is on summer vacation, and you may experience delayed answers. My apologies for that.

I will try to provide you with an answer within this week.

Best regards,

Simon

[Jan Erik]

Hi, any updates here?

[Simon]

I am currently looking into this and will prioritize it in the next days. The GPS experts in the support team are currently on vacation, so I'll have to do some investigations myself.

Best regards,

Simon

[Simon]

I am not totally sure about this, as I don't know much about AGPS.

Couldn't you just test it out and see if it works? Try using only using type=NRF_GNSS_AGPS_LOCATION and using this struct with all fields set to NULL except for these and run nrf_sendto()?

I've asked internally about this, and hopefully, someone with more knowledge about this can shed some light on your questions.

Best regards,

Simon

[Jan Erik]

Hi, it seems like nrf_sendto() is successful but I'm not noticing a huge TTFF improvement.

In any case it would be great to know which extra pieces of information would increase our GPS performance, and which pieces we can leave out. I have no problem waiting for someone more knowledgeable about AGPS by the way.

Also, are those struct values Nordic specific or based on some external convention?
For example the UTC time one has some weird polynomial values that I can't quite figure out, so even though I have a timestamp I'm not able to feed it to the agps. If it's not Nordic specific I might be able to find some docs about it elsewhere.

And one more thing: I can't find any official google documentation about their SUPL server, does that exist?

[Didrik Rokhaug]

Hi, we are still waiting for answers to Simon's questions internally, but I'll try to add my knowledge here as well.

When it comes to what data is necessary, the answer is the more, the better.

However, the data has different longevity, so not all the data is necessary every time.

E.g. the almanac is valid for weeks (I don't remember the exact number at the moment) but can be used for months with less performance gain. In addition, it is not strictly necessary, so the GPS should be able to get a fix even if it is missing.

Meanwhile, the ephemeris is only valid for a couple of hours, before it must be refreshed.

So, I would say that if you fill out what you can, that should help you a bit. However, this is mostly (somewhat qualified) speculation on my part. It might be that the whole struct must be filled (correctly) for you to get any benefit.

When it comes to the data format, I have seen any specifications, though I would assume it is closely related to the format used by the satellites. The format of the structs is probably specific to the nRF9160, but the data inside should be fairly standard.

I do not believe that any of the structs make any of the other redundant.

If you haven't already, you should take a look at the A-GPS related files in the nrf_cloud library (nrf/subsys/net/lib/nrf_cloud), which shows how that library handles requesting and downloading A-GPS data from nRF Cloud.

Best regards,

Didrik