NRF9151 location tracking sample interval

With the NRF_CLOUD_MULTI_SERVICE sample, we'd like to set the GNSS location tracking sample interval to 2s or even 1s. 

But we found that the actual time will be about 25s (please refer to below LOG information for the details), even I set the 

CONFIG_LOCATION_TRACKING_SAMPLE_INTERVAL_SECONDS=1 
CONFIG_LTE_PSM_REQ_RAT="00000001"

We found that the time delay was mainly due to time duration of RRC Inactivity Timer from the LTE (NBIOT) net RRC connected process. This time duration is configured by the network, and the local device can’t set it. 

So, the request here is that: are there any methods to achieve our expectation to get the GNSS tracking sample data every 2s or even every 1s, without adding an extra GNSS module? The FAE here told us about the AS-RAI technology, but we can't make sure the network can support it everywhere (as our product will be sold all over the worlds).

As suggested by the AI, per the nrf9151 AT command document, the establishment of an RRC connection is usually triggered by the "activation of a PDP context" (since RRC needs to allocate radio resources for data transmission); conversely, deactivating a PDP context (AT+CGACT=0,<cid>) will prompt the network to release the corresponding RRC resources (such as the "indirect RRC connection release" scheme we discussed earlier). I tried this solution but failed. 

LOG information

[00:00:09.507,781] [0m<inf> application: Enter main_application_thread_fn

[0m

[00:00:09.509,521] [1;31m<err> location: nRF Cloud A-GNSS request failed, error: -13[0m

[00:00:09.509,552] [0m<inf> nrf_cloud_pgps: Searching for prediction[0m

[00:00:09.509,674] [0m<inf> nrf_cloud_pgps: GPS unit needs ephemerides. Injecting 32.[0m

[00:00:11.009,185] [0m<inf> application: Temperature is 22 degrees C[0m

[00:00:15.460,235] [0m<inf> cloud_connection: Connected to nRF Cloud[0m

[00:00:21.559,753] [0m<inf> message_queue: Enter message_queue_thread_fn

[0m

+CSCON: 0

[00:00:44.997,192] [0m<inf> cloud_connection: RRC disconnected. Connected duration: 39088 ms[0m

[00:00:49.636,352] [0m<inf> location: Method specific timeout expired[0m

[00:00:49.636,871] [1;31m<err> location: Location acquisition failed and fallbacks are also done[0m

[00:00:50.646,972] [0m<inf> nrf_cloud_pgps: Not time to find next prediction yet.[0m

[00:01:18.748,413] [0m<inf> location: LOCATION_REQ_MODE_ALL: all methods done[0m

[00:01:18.748,535] [0m<inf> application: Location Updated: 22.541052 N 113.952046 W, accuracy: 9.9 m, Method: GNSS[0m

[00:01:18.748,535] [0m<inf> application: GNSS Position Update! Sending to nRF Cloud...[0m

[00:01:18.783,599] [0m<inf> message_queue: Enter message_queue_thread_fn

[0m

+CSCON: 1

[00:01:20.790,893] [0m<inf> cloud_connection: RRC connected[0m

+CSCON: 0

[00:01:43.875,335] [0m<inf> cloud_connection: RRC disconnected. Connected duration: 23085 ms[0m

[00:01:45.268,981] [0m<inf> location: LOCATION_REQ_MODE_ALL: all methods done[0m

[00:01:45.269,073] [0m<inf> application: Location Updated: 22.541190 N 113.951808 W, accuracy: 30.6 m, Method: GNSS[0m

[00:01:45.269,104] [0m<inf> application: GNSS Position Update! Sending to nRF Cloud...[0m

[00:01:45.279,937] [0m<inf> message_queue: Enter message_queue_thread_fn

[0m

+CSCON: 1

[00:01:45.751,342] [0m<inf> cloud_connection: RRC connected[0m

+CSCON: 0

[00:02:22.825,744] [0m<inf> cloud_connection: RRC disconnected. Connected duration: 37074 ms[0m

[00:02:26.245,117] [0m<inf> location: LOCATION_REQ_MODE_ALL: all methods done[0m

[00:02:26.245,178] [0m<inf> application: Location Updated: 22.540957 N 113.952130 W, accuracy: 15.7 m, Method: GNSS[0m

[00:02:26.245,239] [0m<inf> application: GNSS Position Update! Sending to nRF Cloud...[0m

[00:02:26.249,511] [0m<inf> message_queue: Enter message_queue_thread_fn

[0m

+CSCON: 1

[00:02:26.712,188] [0m<inf> cloud_connection: RRC connected[0m

+CSCON: 0

[00:02:48.788,879] [0m<inf> cloud_connection: RRC disconnected. Connected duration: 22076 ms[0m

[00:02:50.122,894] [0m<inf> location: LOCATION_REQ_MODE_ALL: all methods done[0m

[00:02:50.123,016] [0m<inf> application: Location Updated: 22.541361 N 113.951314 W, accuracy: 8.1 m, Method: GNSS[0m

[00:02:50.123,016] [0m<inf> application: GNSS Position Update! Sending to nRF Cloud...[0m

[00:02:50.127,349] [0m<inf> message_queue: Enter message_queue_thread_fn

[0m

Parents
  • Hello, 

    The general answer to this is that under optimal conditions, GNSS is capable of acquiring a position fix in approximately one second. The actual interval primarily depends on the speed at which the RRC (Radio Resource Control) connection can be established, data transmitted to the network, and the connection subsequently released. An update interval of a few seconds is likely feasible, subject to network performance. However, such frequent updates generate significant signaling traffic on the network side. Therefore, a recommended interval of around 10 seconds is generally advised to balance performance and network efficiency.

    I've forwarded to our team for more information and will update you within 4 business days.

    Kind regards,
    Øyvind

  • Hi 

    Thanks a lot for your answers!

    We'd like to get the interval as small as possible. If 1s is NOT achievable, we may have to go back to consider about 5s or 10s per your suggestion.


    Looking forward to getting your further solutions later!

    Regards,
    Jacky 

  • Hi Jacky, our experts provided the following feedback to your setup:

    RAI (Release Assistance Indication) is currently the only mechanism available to expedite the release of the RRC (Radio Resource Control) connection, which is otherwise managed by the network. For GNSS tracking intervals in the range of 1–2 seconds, it is likely necessary to utilize an external GNSS solution to meet performance requirements.

    It is also worth questioning the use of PSM (Power Saving Mode) in this context. If the device is transmitting location data to the network every few seconds, the benefits of PSM are significantly diminished. Furthermore, the configuration parameter CONFIG_LTE_PSM_REQ_RAT pertains to the requested PSM Active-Time—specifically, the duration during which the device remains available to receive paging messages from the network following RRC release, before entering PSM. There is no configurable parameter for the RRC Inactivity Timer, as this is entirely controlled by the network. Consequently, RAI remains the only viable method for reducing the RRC release delay.

    With RAI enabled, a tracking interval of approximately 5 seconds may be achievable, depending on network conditions. However, due to the substantial signaling overhead this imposes on the network, a 10-second interval is generally recommended to maintain a balance between responsiveness and network efficiency.

    Could you please test without PSM disabled on your side and provide feedback on the results?

    Thanks!

    Kind regards,
    Øyvind

  • Hi Øyvind,

    Current status already has the PMS enabled. Below is part of the prj.conf contents. 

    # Enable LTE Connectivity using Connection Manager
    CONFIG_NET_IPV4=y
    CONFIG_NET_IPV6=y
    CONFIG_NET_IPV6_NBR_CACHE=n
    CONFIG_NET_IPV6_MLD=n
    CONFIG_NET_CONNECTION_MANAGER=y
    CONFIG_NRF_MODEM_LIB_NET_IF=y
    CONFIG_NRF_MODEM_LIB_NET_IF_AUTO_DOWN=y
    CONFIG_NRF_MODEM_LIB_NET_IF_DOWN_DEFAULT_LTE_DISCONNECT=y

    # Enable power savings mode
    CONFIG_LTE_PSM_REQ=y
    # Set the PSM Requested Active Time to 20 seconds
    CONFIG_LTE_PSM_REQ_RAT="00000001"

    # Modem library
    CONFIG_NRF_MODEM_LIB=y

    # AT commands interface
    CONFIG_UART_INTERRUPT_DRIVEN=y
    CONFIG_AT_HOST_LIBRARY=y

  • Can you please test with

    # Enable power savings mode
    CONFIG_LTE_PSM_REQ=n
  • Hi ,

    I set CONFIG_LTE_PSM_REQ=n this afternoon per your suggestion and I got the below feedback. 

    +CSCON: 0
    [00:04:14.612,213] [0m<inf> location: Method specific timeout expired[0m
    [00:04:14.612,243] [1;33m<wrn> location: GNSS timed out possibly due to too short GNSS time windows[0m
    [00:04:14.612,731] [1;31m<err> location: Location acquisition failed and fallbacks are also done[0m

    I remember that GNSS need to work on the LTE power saving time duration, so if we disable the PSM mode, it seems that GNSS module will have no opportunity to work normally. 

Reply
  • Hi ,

    I set CONFIG_LTE_PSM_REQ=n this afternoon per your suggestion and I got the below feedback. 

    +CSCON: 0
    [00:04:14.612,213] [0m<inf> location: Method specific timeout expired[0m
    [00:04:14.612,243] [1;33m<wrn> location: GNSS timed out possibly due to too short GNSS time windows[0m
    [00:04:14.612,731] [1;31m<err> location: Location acquisition failed and fallbacks are also done[0m

    I remember that GNSS need to work on the LTE power saving time duration, so if we disable the PSM mode, it seems that GNSS module will have no opportunity to work normally. 

Children
No Data
Related