Regular current spikes on modified MQTT simple

[Carl Richard]

Hello!

H.W: nRF9160 DK v8.5
MWF: 1.1
NCS: tag 1.2
SIM: Telenor NB-IoT

I'm using a modified version of the MQTT simple example for an application that periodically uploads data to a privately hosted broker. The MQTT functionality have been moved to a separate file and modified so that the main loop of the original example is run as a separate thread, handling the MQTT operations.  

In addition I'm using PSM and an upload timing scheme similar to the one in the udp_with_psm example. The MQTT keepalive is set to the PSM TAU period (~300 seconds) in order to avoid unnecessary wake up during the sleep cycle. 

When looking at the power consumption of the example in a power analyser I see that the application consistently has power spikes of ~8mA every ~6 seconds. Do you have any suggestions to how I can avoid these? I have confirmed that it is related to the MQTT operation as the spikes aren't present otherwise, but I struggle to find out exactly what is causing them. 

EDIT: The intervals seems to be of increasing length between each TAU. From what I can see it starts with very short intervals (~600 ms), and then it increases gradually all the way up to ~12s. This seems to reset every time the modem wakes up and transmits. (it's a bit hard to make out the actual intervals during the transmission as it's cluttered with paging spikes)

Attached is a snapshot from the power analyser. The red graph is the MQTT current, the green one is the current of a CoAP application with the same configuration for comparison. 



Do tell if I should provide any more information or code. 

Thanks in advance.

-- Carl Richard

[Stian Røed Hafskjold]

The only thing I can think of right now is that the if you are doing a DNS query the DNS timer may be running for a while after the DNS resolution has finished. So if you are using host names in your code try to use plain IP addresses instead. However, if there is a timer running I would expect to see a more consistent interval between the spikes.

What is the resolution on the power analyzer? And are you able to zoom in to one of the spikes? The current profile of the spike might tell us what to look for next.

[Carl Richard]

Thanks for the answer! I'm using a plain IP address defined like this: 

CONFIG_MQTT_BROKER_HOSTNAME="--.---.---.--". Is that enough to avoid DNS resolution?

I'm using an OTII ARC. It has a sample rate in this range at 4 ksps, with a sample resolution of +/- 50nA. A detailed picture of a spike is attached below.

[Stian Røed Hafskjold]

Yes, I think that should be enough to avoid DNS resolution.

OK, so it looks to me that the "event" is 5 ms long, and based on the current I would guess that this is the CPU waking up to do some stuff. 5ms is quite a long time though... so I'm not sure...

Could you post a hex file that I can run on a PCA10090 DK, with Telia, Telenor or iBasis SIM? I can try to do some debugging here.

If you can also provide a modem trace, together with a csv or something from the current measurement (running at the same time) we could try to align them and see if we can get some info out from the trace.

[Carl Richard]

Here are the hex files. One with serial logging and one without (low power)

It connects to my own broker(that should be running). LED1 will light when it's connected, and it will transmit every 5 minutes after that. 

It is configured for NB-IoT so you should use a SIM that support both that and PSM. (I've been using Telenor)

I will do the trace and send you that along with a csv too!
Serial:
0005.merged.hex

Non serial:
7827.merged.hex

[Carl Richard]

Here! I think I've done it correctly. The application was running with double power consumption, but the peaks were still very visible. 

Csv:
mqtt_peaks_current.csv

Trace:

mqtt_peaks_trace.bin

[Carl Richard]

I can also add that I suspect it could have something to do with the TCP connection. It could be that the TCP socket have increasing timeouts when waiting for a handshake(or the likes of it). Will run a test now to see if the intervals actually reach a maximum at some point.

[Carl Richard]

Any updates on this? I haven't been able to pinpoint the issue myself yet. 

[Didrik Rokhaug]

Hi, Stian is unfortunately a bit busy with other tasks at the moment, and have asked me if I can look into your case.

I have had a case earlier that looks a lot like this. At the time, we found that if the socket used by the MQTT library is closed, then the spikes disappear.

I do not remember if we found the root cause of the wakeup or not, but I will ask some of my collegues which were also involved with the case on Friday.

Best regards,

Didrik