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

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

  • Hi 

    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

  • 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

Related