How to reduce power consumption in mqtt_simple project with small keep alive

[Nikunj]

Hello, Nordic community,

I built and successfully run mqtt_simple project on our MQTT broker using v1.1.0 firmware and NCS.

I edited CONFIG_SERIAL=n in spm and mqtt_simple example.

 

Case 1: I configured and uploaded code on a device with 60 seconds keep-alive. After a successful connection with the MQTT broker, device is ideal(no transmission of messages) for 15 seconds. after 15 seconds I transmitted a message to the device from broker but the message is not received by device instantly it was received after 20-40 seconds. current consumption in this situation was

connecting current : 55-60mA

after connection ideal state (No transmission of messages): 20-25mA

current consumption during message transmission: 35-45mA

Case 2: I configured and uploaded code on a device with 5 seconds keep-alive. After a successful connection with the MQTT broker, device is ideal(no transmission of messages) for 15 seconds. after 15 seconds I transmitted a message to the device from broker and the message received by device instantly. current consumption in this situation was

connecting current : 55-60mA

after connection ideal state (No transmission of messages): 45-50mA

current consumption during message transmission: 45-50mA

how can I achieve the current consumption to 20-25mA with 5 seconds keep-alive?

Thanks,

Nikunj

[Didrik Rokhaug]

Hi.

One possible reason for not seeing a drop in the current consumption is that the device does not enter RRC idle mode. How long it takes to enter RRC idle depends on the network, but 5 seconds might not be enough time to be released from the network.

You can see if your device enters RRC idle by using the +CSCON AT command to subscribe to connection status notifications.

Best regards,

Didrik

[Nikunj]

Thanks for reply Didrik,

I am using vodafone ireland SIM for connection.

I need faster message transfer from server to device for that I used 5 seconds.

Is there any other alternative for faster message transfer?

Thanks,

Nikunj

[Nikunj]

Hello Nordic Community,

I found the issue during just next to manufacturing phase. Is there any alternative for faster message transfer(from broker to device) with lower power consumption?

any suggestion regarding this would be helpful. I am just using default mqtt_simple code with 5 seconds keep alive period on own mqtt broker. The reason behind 5 second is faster messages are transfer, any other alternative I can also try.

How can I suppose to reduce current consumption?

Thanks,

Nikunj

[Didrik Rokhaug]

Hi, and sorry for not being able to reply faster.

Did you try to subscribe to +CSCON notifications?

Did the show that the device enters RRC idle mode?

If not, and with data transmission every 5 seconds, I am not really aware of how you can lower the power consumption.

At least not if you want to maintain a low latency on downlink packages (from a server to the device).

Why do you send data to the device frequently, and why do you need low latency?

[Nikunj]

Hello Didrik Rokhhaug,

The reason behind low latency is that there is sensitive switch connected with device which needs to be trigger quick once user commands from server.

The user can send command any time from server that's why send data is frequent. 

Thanks,

Nikunj

[Didrik Rokhaug]

In order to reduce the latency, you must stay in RRC connected mode. However, that means that you are listening on the radio, which means higher power consumption.

Most of the power saving features in the network are ways for the device to turn off the radio for longer periods of time. However, this naturally increases the expected latency.

[Nikunj]

hello Didrik,

Could we solve this issue by edrx?

[Didrik Rokhaug]

With eDRX, you will also turn off the radio for a longer interval than normal (though not as long as with PSM).

The smallest "eDRX interval" that you can configure is 5.12 seconds.

If that (or longer) is acceptable, then yes, you can use eDRX, but then it does not make sense to send keep-alive messages every 5 seconds.