subscribing in Assert tracker v2

[Mustafa]

Hello,

I'm trying to send messages from the cloud (AWS-IoT ) to the device, so I modified the device so that it subscribes to a new topic and when I send messages from could, it seems that the device doesn't listen frequently to the cloud. sometimes it receives a message, sometimes not. and when I sent multi messages very fast, the device receive all messages after a random delay. 

I tried to check the code if there is any configuration I can use to force the device to listen to Cloud always. but without luck. This behavior is in Active and Passive mode as well. 

My question is: How can the device receive messages instantly from the cloud without delay. 

Thanks in advance.

[Albrecht Markus Schellenberger]

Mustafa said:

Actually I'm still wondering about the reason to close the TCP connection with server-side. It supposes to keep the connection alive because CONFIG_MQTT_KEEPALIVE = 1200. even I tried to reduce this time but it always closes the connection after 320 seconds ( any value above 320sec causes CLOUD_TIMEOUT event).

Thanks a lot for your feedback, Mustafa! That is a good and interesting observation. I wonder if maybe the NAT rules time-out, making the server not recognise the client anymore? I have to check this with our experts. I’ll be on vacation next week, but I asked my colleague Didrik Rokhaug to watch this ticket.

Regards,

Markus

[Didrik Rokhaug]

Hi,

Could you try to disable PSM, to see if that changes things?

Best regards,

Didrik

[Mustafa]

Hey Didrik, thanks for your reply. I did some experiments with two different network operators. I disabled PSM and changed Mqtt_keep alive to 400sec.

In the first operator ( KPN in NL ) the server doesn't receive any data after 300 sec even device shows that data is sent successfully.

The second operator ( T-Mobile in NL): the device gets a timeout after 320sec and then it tries to establish the connection again with the server and every 320sec it gets event Timeout and re-initializes connection with server-side.

Here below are the trace files per operator, hopefully, that you can find the problem. 

KPN 

trace-2021-10-13T21-39-09.599Z KPN.rar

T Mobile

trace-2021-10-13T21-20-33.087Z TMobile.rar

thanks in advance!

[Didrik Rokhaug]

The KPN trace looks better this time, but it doesn't look like it captured the device waking up. The trace ended only  a minute after the SUPL session completed. And the SUPL session ended just a couple of seconds after the last packet sent to the cloud. The whole trace lasts for only a bit less than 2 minutes.

The T Mobile trace on the other hand looks like have captured the issue. But, it looks like the device is still requesting PSM, even though the application doesn't request it. This is probably because the modem has the PSM settings stored. The easiest way to tell the modem not to use PSM is to flash the at_cmd sample, send AT+CPSMS=0 followed by AT+CFUN=0.

[Didrik Rokhaug]

Hi, have you been able to capture traces without PSM yet?

[Mustafa]

Hey Didrik, sorry for my late message. I was actually struggling with GPS timeout that sometimes tracker keeps searching for GPS fix for more than one hour and GPS timeout is already adjusted on 60 sec but that is for another issue. For now, I've tested the devices with/without PSM and I've noticed that without PSM the connection with the server still opens but the device sends an update message per 26 min instead of 60 min since the settings are adjusted to 3600 sec. Here below are the traces files 

trace-2021-10-24T07-58-11.071Z without psm.rar

trace-2021-10-24T14-09-26.958Z with psm.rar

[Didrik Rokhaug]

Here is what the modem team said:

With given information I am not able to comment anything very meaningful. TLS connection is established and UE sends 708 bytes to server. This is acked by the server, but nothing more really. Seems that server is not responding or data is lost somewhere in the path.

After twenty minutes there are weird TCP transmission to unseen segments. I think the log is not complete and some parts are missing. TCP segment from UE to server jumps from 185 to 3018 which is not possible.

At this point, I feel like the ticket has gone on long enough that it is time to take a tep back and try to get an overview of where we are. Could you try to sum up the problem you are seeing?

What are you trying to do, and what is happening?

What application FW are you suing, which SDK version is it based on, and what modem FW version are you using?

[Mustafa]

Hey Didrik, 

You are right this issue took a long time. here is the summarize of the problem when CONFIG_MQTT_KEEPALIVE is set for more than 300 sec then the server ( AWS IoT ) doesn't receive any message from the device, even though the device log shows that message is sent successfully. 

we tried with T-mobile and KPN in NL and both are almost the same except in the T-mobile network the device lost connection after 300 sec when CONFIG_MQTT_KEEPALIVE > 300 sec. but in the KPN network the device doesn't show any error. In both networks, the server doesn't receive anything after 300 sec 

our project is based on Low power consumption so we need to set CONFIG_MQTT_KEEPALIVE  to a max of AWS limit and that is 1200 sec. but it doesn't work when it is initialized for more than 300 sec.

we use

SDK = nrf 1.6.1,

modem version 1.3.0
Mqtt server: AWS Iot mqtt 

LTE-M network: KPN and T-mobile in NL 

app: asset_tracker_v2

[Mustafa]

one thing I forget to mention is that this problem occurs only when PSM is enabled
if PSM is disabled, the server receives always message from the device. 

[Didrik Rokhaug]

Thanks for the summary, and sorry for the slow response.

Have you tried to connect to other brokers (i.e. not AWS)?

E.g. if you run the mqtt_simple sample (with PSM), do you see the same problem where the client is disconnected from the broker after being in PSM for > 300s?

Attached is a slightly modified version of the mqtt_simple (from NCS v1.6.1) sample that connects to test.mosquitto.org with a keepalive period of 600s, and PSM. It will also print each time it calls mqtt_live, so it is easy to keep track of when it sends MQTT keepalive messages.

mqtt_simple.zip

On my end, it successfully sends a keepalive message after 10 minutes, so at least on my setup, it works as it should.

If it doesn't work, can you share the application and modem log?