MQTT with PSM

[spline_pete]

Using ncs v1.4.0, modem FW v1.2.3, SES v5.10d.  The code is based on the Asset Tracker, LTE with PSM, motion-activated GPS, using MQTT to send GPS location to backend.

prj.conf
CONFIG_LTE_PSM_REQ_RPTAU="00000110"
CONFIG_LTE_PSM_REQ_RAT="00000010"
CONFIG_MQTT_KEEPALIVE=600

After connecting (Sierra Wireless/Verizon):
AT+CEREG=5
AT+CEREG?
+CEREG: 5,1,"1510","00526401",7,,,"00000010","00010011"
Active Time: 000 = 2 sec; 2 x 2 sec = 4 sec
Periodic TAU: 000 = 10 min; 19 x 10 min = 190 min

The device occasionally needs to check if it has any messages from the server. Is it better to wake-up, connect to the Broker, poll, process, then disconnect? Or stay connected, poll, process, then sleep? I did see this post from about a year ago:

“You should have separate threads for the MQTT and GPS in your application, and both sockets should be read/polled
all the time to avoid any conflicts.”
https://devzone.nordicsemi.com/f/nordic-q-a/56641/mqtt-and-gps-concurrent-mode-on-thingy-91

Is this still the best practice? How often can/should you poll MQTT when using PSM? Or is it just managed in the background? Does this need to sync with the KeepAlive time?

[Didrik Rokhaug]

Hi,

When using PSM, you will wake up at regular intervals, to listen for incoming transmissions from the network. In addtion, you can transmit data at any time, but after transmitting, you must also listen for incoming transmissions.

Therefore, whenever you send a keepalive message, you will also listen for incoming messages.

When you poll() on a socket, the thread polling will sleep until there is an event on the socket, or the call to poll() times out.

Therefore, if you poll() with a timeout of that matches the MQTT keepalive (and there are no other threads running), the device will sleep until it receives some data, or must send an MQTT keepalive message.

If you instead disconnect from the broker, you will have to re-connect to the broker each time you want to check for incoming data. If you are using TLS, this becomes even more expensive as you will have to perform a new TLS handshake each time (this can be made a bit better with TLS session resumption and a persistent MQTT session, but it will still be an extra cost, and might not be supported by your server). In addition, you must either time the messages to the device so that they are only sent when the device is connected, or you must use retained messages.

(not to say that you won't have any such problems when staying connected and using PSM. Using QoS 1 or 2 is highly recommened if you want to make sure that the message actually is received by the device)

In the end, it comes down to how often are you sending data, and how often are you expecting to receive data.

If the periods between messages (both uplink and downlink) are long enough, it might be better to disconnect completely, to not have to pay the cost of keepalive messages. But, other than that, it would be best to stay connected the whole time.

With other words, you should test both, while meassuring the current consumption.

 

“You should have separate threads for the MQTT and GPS in your application, and both sockets should be read/polled
all the time to avoid any conflicts.”

 Yes, separate threads are a good idea (if you use the GPS driver, it has an internal thread that reads the GPS socket). The most important aspect is that all data sent from the modem to the application should be read in a timely fashion, to avoid running out of shared memory.

Please let me know if you have further questions.

Best regards,

Didrik