GPS/LTE application freezes after approx. 1h

[visu]

Hi, I am using nRF Connect SDK 1.5.1 with the nRF9160 Modem Firmware 1.3.0

I have implemented an application on the thingy91 with the gps driver (continuous mode) and the lte link controller (LTE-M).

I send approx. every 5th position-data (together with some stuff like RSRP, cell-id etc) over udp to a server.

Now I have this issue that after about 40min to 1h20 the applications seem to freeze.

normally the output looks like this:

.....
D: NMEA: Position fix
I: connected to udp server
I: GPS position successfully sent to cloud
I: disconnected from server
+CSCON: 1
I: LTE_LC_EVT_RRC_UPDATE
I: LTE is in RRC Connected Mode
D: Waiting for time window to operate
I: GPS_EVT_OPERATION_BLOCKED
I: UPTIME IS: 4834163
+CSCON: 0
I: LTE_LC_EVT_RRC_UPDATE
I: LTE is in RRC Idle Mode
D: GPS has time window to operate
I: GPS_EVT_OPERATION_UNBLOCKED
.....

but the very last output I get is:

.....
D: NMEA: Position fix
I: connected to udp server
I: GPS position successfully sent to cloud
I: disconnected from server

It looks like the udp-socket thing worked, but it doesn't connect with RRC connected?
Is there a way to see where the applications get stuck? I tried it in the debug-mode in segger embedded studio, but I only see it is hanging around cpu_idle..
Are there any options I can turn on to see more in the uart output?
thanks in advance,

Visu

[Håkon Alseth]

Hi,

  

D: NMEA: Position fix
I: connected to udp server
I: GPS position successfully sent to cloud
I: disconnected from server

These prints seems to come from your application. Have you based this upon a application present in NCS? If so, which one?

It looks like the udp-socket thing worked, but it doesn't connect with RRC connected?
Is there a way to see where the applications get stuck? I tried it in the debug-mode in segger embedded studio, but I only see it is hanging around cpu_idle..
Are there any options I can turn on to see more in the uart output?

 You could force all logging to be info/debug:

CONFIG_LOG=y
CONFIG_LOG_MINIMAL=y
CONFIG_LOG_DEFAULT_LEVEL=4 # You can set this lower
CONFIG_LOG_OVERRIDE_LEVEL=4

 

This will produce quite alot of logging.

 

What you can also try is to increase the heap size given to modemlib:

CONFIG_NRF_MODEM_LIB_HEAP_SIZE=2048

 

Kind regards,

Håkon

[visu]

Hi Håkon,

thanks for your reply.

I am using the A-GPS Sample (but with SUPL), combined with the udp-sample.

With CONFIG_LOG_OVERRIDE_LEVEL=4 it really creates a lot of log, that I can't do much with..

I'll try to increase the heap and give it a try.

I also have another question:

right now I am sending like this:

        server_connect(); //connects like in udp-sample
        
        int err = send(client_fd, buf, sizeof(buf), 0);
        if (err < 0) {
                printk("Failed to transmit UDP packet, %d\n", errno);
                return;
        }
        LOG_INF("GPS position successfully sent to cloud");
        server_disconnect(); //disconnects like in udp-sample

In this way the RRC changes faster to RRC idle.

But I think it would be better to just leave the socket open. so I have to give the RAI indication.
How is this done? I saw in Case 270301 that this can be done with nrf_setsockopt(), but that didn't work for me.

[Håkon Alseth]

Hi,

 

visu said:

right now I am sending like this:

You should close the socket when err < 0, if not; you will get into a scenario where you're not allowed to allocate more sockets.

Does your log have any "failed to transmit" prints?

 

visu said:

But I think it would be better to just leave the socket open. so I have to give the RAI indication.
How is this done? I saw in Case 270301 that this can be done with nrf_setsockopt(), but that didn't work for me.

Closing the socket after you're done is usually the recommended fashion.

As mentioned in the case you linked to, RAI support needs to be verified on a network level, ie: you cannot (at this time atleast) read the support dynamically in firmware.

visu said:

I'll try to increase the heap and give it a try.

Please let me know if this helps on stability!

 

Kind regards,

Håkon

  

[visu]

Håkon Alseth said:

Does your log have any "failed to transmit" prints?

No it doesn't.

Increasing the heap size didn't help.

I tried it yesterday with NB-IoT and it ran without problems (7h). So I guess it can't be a bug in my application?

I may try to get modem trace logs today when running with LTE-M, maybe you can have a look then

[Håkon Alseth]

Hi,

 

visu said:

I tried it yesterday with NB-IoT and it ran without problems (7h). So I guess it can't be a bug in my application?

Have you checked the signal strength for LTE M in your area?

If you keep the socket open, and the LTE network changes (mobility in LTE-M, where you can be handed over to a new cell tower), this can be problematic in the application.

You can try to add AT host library to your application and issue "AT+CEREG=5" to see if there's anything network-wise that happens:

# AT host library
CONFIG_AT_HOST_LIBRARY=y
CONFIG_UART_INTERRUPT_DRIVEN=y

  

Kind regards,

Håkon