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.

[Carl Richard]

Hi!

I'm closing the socket like this, during the sleep cycle of PSM. 

int mqtt_close_sock(void) {
	int ret = close(client.transport.tcp.sock);
	if (ret < 0) {
		return -errno;
	}
	return 0;
}

So far it seems like the issue persists as the spikes continue even after I close the socket. 

[Didrik Rokhaug]

Hmm, that should be enough...

In the previous case, they used mqtt_abort().

Looking at what it does, I can not really see any reason why that should work while your mqtt_close_sock() does not, but it might be worth a try.

Anyway, I have asked the SDK and/or modem team to take a look as well.

[Carl Richard]

I'll try that out! Thanks. 

[Carl Richard]

Calling mqtt_abort() yields the same, strange behaviour as my previous function. It seems like the action of "closing" the socket actually initiates a transmission, waking the modem and triggering a full transmission cycle (including active time countdown). 

And as you can see the small peaks "restart" when something is transmitted. As mentioned earlier. 

[Didrik Rokhaug]

The modem team has some leads for what the spikes could be, but are not able to get enough information from the modem trace to confirm them.

If you can share your application source code, I can run the application on some internal testing HW to get more information out of the modem. However, I would have to compile against a modified version of the SDK, hence my need for the source code.

I can convert the case to private if that helps.

[Carl Richard]

Here's the code. Just notify my if you're wondering about anything!

Thanks :) 

6560.mqtt.zip

[Didrik Rokhaug]

Hi, and sorry for this taking some time.

I am having some problems setting up the test equipment. Hopefully, that will be sorted out soon.

I did try to run your application though, but the connection to the server timed out. I guess it was not running at the time?

Best regards,

Didrik

[Carl Richard]

Hi!

No problem! I haven't been testing the last days, so the server is offline. I will set it up again :) 

Best regards,
Carl R.

[Didrik Rokhaug]

I have been able to take a trace, and the modem team has looked at it.

However, they also commented that you should try to close the socket while it is not used.

Looking through the code I got from you, I could not find the mqtt_close_sock() function you posted earlier. Where did you call it?

[Carl Richard]

Ah, thanks! 

I chose to remove the function as it did more harm than good. Initiating the disconnection, both with my function and the one you purposed, led to the device entering RRC connected mode thus consuming quite a lot of power. It could be that I did not close it properly, or that the MQTT application did not like the way I did it.

I can experiment some more with that in the future.