Different approaches in making an asset tracker on nRF9160

[Torje]

Hello all developers,

We've made our asset tracking application based on the Nordic SDK. From working with this for a while now, I have some observations I would like to discuss here.

From SDK 2.2.0, these has been several improvements to the Location library. This handles almost everything, but we're not so "hands on" the code when using this. I feel like it provides less feedback on getting a fix (like satellite stats, timeout, assistance data handling, location methods etc). Its quite the black box.

Alternatively, we can use "the rest", like nrf_cloud lib extensions with multicell, agps etc to achieve the same result. This is a bit more work, but we have better control and more flexibility in adapting the system as we want to. I.e, The callback functions supported by the nrf_modem_gnss is a lot better than the one made available through he location lib.

The location library also has a great new feature in selecting accuracy of gnss fix. There seems to be no way in getting this without using this approach.

I have not been able to combine the location library with other approaches, like using location lib only for gnss, but handling fallback to cell location by multicell_location (Some config options couldn't be combined, cant remember which ones right now), or using the nrf_modem_gnss CB in combination with location lib (Would have to start gnss twice - seems like nonsense)

I guess what I'm wondering, is my understanding here correct? If someone would like to elaborate on my assumptions, this would be very welcomed.

Thank you all for any insight provided!

Kind regards,

Torje

[Simonr]

Hi Torje

I think you have got it correctly, as the location library provides a "full package" with a compact API and a location core that handles functionality independent of the location method used. Depending on your preference you might want a more "bare bones" library letting you decide exactly what is returned and not, and the GNSS interface API is part of the location library, so it can't be used "together" with it I'm afraid, nor is the location library designed to be combined with other approaches AFAIK.

I'm not sure I'm able to elaborate any better on the location library than what the documentation itself provides.

Best regards,

Simon

[Torje]

Hello Simon,

And thank you for replying, and for confirming my understanding.

Allow me to do a follow up question: Do you know of a method of choosing higher gnss accuracy without using the Location library? I've played with the though of selecting "continuous mode" and just let it run a bit after the first fix is produced, but perhaps there are some more elegant solutions to this?

Thanks again,

Torje

[Simonr]

Hi

Using the GNSS interface library by itself would be the way to go if you don't want the location library I think, as it uses the high GNSS accuracy by default, with the option to go to low acc. if relevant. The GNSS sample project uses the GNSS interface alone, so you can look at that for reference.

Best regards,

Simon

[Torje]

Hi again,

I was under the impression that the accuracy from gnss interface was "normal", and a "high accuracy" was implemented in the Location lib by letting it run for longer. If this is incorrect, then I'm very happy by using the GNSS interface already. 

Thank you for assisting me in this, and for clarifying on my initial request. Sometimes you can't see the wood for the trees.

Kind regards,

Torje

[Simonr]

There is just a "normal" and "low" accuracy specifically in the GNSS interface, that is true, but you can tweak (increase) its run time to achieve similar accuracy as to what the location library provides.

Best regards,

Simon