Location library - separating cloud and GNSS requests.

RE: Location library - separating cloud and GNSS requests.

Maximilian Deubel — Fri, 04 Apr 2025 08:18:43 GMT

Hi! I think enabling CONFIG_LOCATION_SERVICE_EXTERNAL is the correct approach. This will force you to implement the callbacks, but doesn't necessarily mean that you have to use a proxy for AGNSS. You can essentially copy the method_gnss_nrf_cloud_agnss_request function. Note that there are different versions for different backends. Please let me know if you need further assistance on this.

RE: Location library - separating cloud and GNSS requests.

Roman Veselskyi — Thu, 13 Feb 2025 16:35:27 GMT

Cole Hafner

Thank you for your response—I wasn’t aware of the Location History API.

I have a question regarding C2C. Is it possible to separate the CELL and Wi-Fi data so they go through the proxy, while allowing the GNSS portion to use a direct request?

I’m wondering if we can configure the library to collect only Wi-Fi and CELL data, and then, for example, respond to the library with:

location_cloud_location_ext_result_set(LOCATION_EVT_RESULT_UNKNOWN)

once the collection is done. However, doing this seems to require enabling CONFIG_LOCATION_SERVICE_EXTERNAL, which would then force all A-GPS requests through the proxy as well. Is that correct?

RE: Location library - separating cloud and GNSS requests.

Cole Hafner — Thu, 13 Feb 2025 15:54:55 GMT

That makes sense. You could use our C2C model in which you proxy requests from your devices to your servers to nRF Cloud. This would work well for your use case. Here is a guide for using the nRF Cloud API from your proxy server. The firmware would be custom.

An alternative is to use nRF Cloud location history API from your portal. nRF Cloud tracks your device's location history and makes it available via the location history API endpoint. This would sidestep the need to send this data to your servers.

Hope this helps!

Cole

RE: Location library - separating cloud and GNSS requests.

Roman Veselskyi — Thu, 13 Feb 2025 11:51:48 GMT

Hello,

Yes, we are using the location service library, and it is working correctly. The problem is that we want the fastest possible response from the device.

Currently, if we trigger the device to send location data, we must wait for it to:

Collect cell and Wi-Fi data
Send that data to nRF Cloud
Receive the location information from nRF Cloud
Then finally send the data to our own cloud

Only after all these steps are completed does the device receive confirmation that the data has been delivered and return to idle mode.

However, since the device itself does not need the location information (the user sees everything on the portal), we think we can simplify the process:

Trigger event
Collect cell and Wi-Fi data
Send data directly to our cloud
Receive confirmation that the data was delivered
Return to idle mode

By removing the step of waiting for the location data from nRF Cloud, we can speed up the overall response time. Especially on the NB-IoT network.

RE: Location library - separating cloud and GNSS requests.

Cole Hafner — Thu, 13 Feb 2025 00:52:05 GMT

Hello,

This could be done by creating custom firmware. Have you tested our location service library and found it to be inefficient?

Omitting the response in order to close the radios a bit earlier could yield longer battery life, but I suspect the differences to be negligible. What is your use case?

Thanks,

Cole