NRF9151 location tracking sample interval

[Jacky1700]

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

[Øyvind]

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

[Jacky1700]

Hi Øyvind，

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 

[Jacky1700]

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

[Øyvind]

Can you please test with

# Enable power savings mode

CONFIG_LTE_PSM_REQ=n

[Jacky1700]

Hi Øyvind,

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. 

[Jacky1700]

Hi Øyvind, 

I'd like to discuss some more details about the AS-RAI here. 

On the nrf9151 AT spec, I have the same question as the person asked on the below link. 
(+) LTE-M Release assistance indication (RAI): How to indicate? - Nordic Q&A - Nordic DevZone - Nordic DevZone

But he was suggested to refer to the nrf_socket.h....do you have a sample to show the details, based on the nRF_cloud_multi_service sample? 

By the way, I got the information that the only the LTE-M network support AS-RAI, the NB-iot network doesn't support the AS-RAI. So what we can do if the network here is the NB-iot network only? 

Thanks and regards,

Jacky

[Øyvind]

Hi Jacky, 

Jacky1700 said:

I got the information that the only the LTE-M network support AS-RAI, the NB-iot network doesn't support the AS-RAI. So what we can do if the network here is the NB-iot network only? 

The nRF9151 supports both AS-RAI and CP-RAI, so RAI can be used also with NB-IoT. The application interface is the same for both. Do you mean that the network does not support RAI in NB-IoT?

Jacky1700 said:

But he was suggested to refer to the nrf_socket.h....do you have a sample to show the details, based on the nRF_cloud_multi_service sample? 

Currently, there's no RAI support in the nrf_cloud_multi_service sample. The sample uses MQTT and CoAP stacks from Zephyr. RAI support needs to be implemented on the socket level, so RAI support would have to be in the Zephyr protocol stack implementation. This has been forwarded as a feature request. 

That said, the UDP and modem_shell samples have RAI support. You can also test the AT command linked above in the AT Client.

Jacky1700 said:

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. 

From the GPS receiver chapter in the nRF9151 Datasheet it states:

GPS receiver operation is time multiplexed with the LTE modem, and GPS and QZSS position can be received while the LTE modem is in RRC Idle mode, power saving mode (PSM), or completely deactivated.

This means that you do not need to be in PSM, RRC idle is sufficient. You can use Signaling connection status notification +CSCON to determine when the device is RRC Connected or RRC idle.

Kind regards,
Øyvind