Location library - separating cloud and GNSS requests.

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?


Parents
  • 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

  • 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. 

Reply
  • 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. 

Children
No Data
Related