Location library - separating cloud and GNSS requests.

[Roman Veselskyi]

Hello,

I’m wondering if there is a way to separate CELL and Wi-Fi location data from GNSS location data in the Location library. Currently, we use nRF Cloud for location services, which works well. However, we believe using our own cloud as a proxy to nRF Cloud might improve both message transmission times and battery consumption.

Here’s our proposed approach:

1. The device collects cell tower and Wi-Fi data and sends it to our cloud.
2. Our cloud forwards this data to nRF Cloud and receives the location in response.
3. The location remains on our server, so there’s no need to send it back to the device.

The issue we have is that we don’t want to forward AGPS data. Is it possible to forward only CELL and Wi-Fi data and let the device request AGPS directly from nRF Cloud?

[Cole Hafner]

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

[Roman Veselskyi]

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:

1. Collect cell and Wi-Fi data
2. Send that data to nRF Cloud
3. Receive the location information from nRF Cloud
4. 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:

1. Trigger event
2. Collect cell and Wi-Fi data
3. Send data directly to our cloud
4. Receive confirmation that the data was delivered
5. 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. 

[Cole Hafner]

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

[Roman Veselskyi]

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?