Regular current spikes on modified MQTT simple

RE: Regular current spikes on modified MQTT simple

Carl Richard — Wed, 24 Jun 2020 13:49:30 GMT

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.

RE: Regular current spikes on modified MQTT simple

Didrik Rokhaug — Wed, 24 Jun 2020 11:50:01 GMT

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?

RE: Regular current spikes on modified MQTT simple

Carl Richard — Tue, 09 Jun 2020 15:50:18 GMT

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.

RE: Regular current spikes on modified MQTT simple

Didrik Rokhaug — Tue, 09 Jun 2020 14:25:04 GMT

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

RE: Regular current spikes on modified MQTT simple

Carl Richard — Fri, 29 May 2020 14:12:29 GMT

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

Thanks :)

devzone.nordicsemi.com/.../6560.mqtt.zip

RE: Regular current spikes on modified MQTT simple

Didrik Rokhaug — Fri, 29 May 2020 12:20:58 GMT

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.

RE: Regular current spikes on modified MQTT simple

Carl Richard — Wed, 27 May 2020 07:06:35 GMT

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.

RE: Regular current spikes on modified MQTT simple

Carl Richard — Wed, 27 May 2020 06:10:18 GMT

I'll try that out! Thanks.

RE: Regular current spikes on modified MQTT simple

Didrik Rokhaug — Tue, 26 May 2020 14:15:40 GMT

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.

RE: Regular current spikes on modified MQTT simple

Carl Richard — Tue, 26 May 2020 13:15:27 GMT

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.

RE: Regular current spikes on modified MQTT simple

Didrik Rokhaug — Tue, 26 May 2020 09:31:58 GMT

I have not been able to get any more explanations about the previous case.

Were you able to remove the current spikes by closing the socket?

RE: Regular current spikes on modified MQTT simple

Carl Richard — Wed, 20 May 2020 14:47:45 GMT

No worries! And thank you! Now I can take a look at least.

BR,
CR

RE: Regular current spikes on modified MQTT simple

Didrik Rokhaug — Wed, 20 May 2020 14:25:51 GMT

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

RE: Regular current spikes on modified MQTT simple

Carl Richard — Wed, 20 May 2020 07:27:21 GMT

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

RE: Regular current spikes on modified MQTT simple

Carl Richard — Thu, 14 May 2020 14:39:38 GMT

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.

RE: Regular current spikes on modified MQTT simple

Carl Richard — Thu, 14 May 2020 14:32:45 GMT

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

Csv:
devzone.nordicsemi.com/.../mqtt_5F00_peaks_5F00_current.csv

Trace:

devzone.nordicsemi.com/.../mqtt_5F00_peaks_5F00_trace.bin

RE: Regular current spikes on modified MQTT simple

Carl Richard — Thu, 14 May 2020 12:37:34 GMT

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:
devzone.nordicsemi.com/.../0005.merged.hex

Non serial:
devzone.nordicsemi.com/.../7827.merged.hex

RE: Regular current spikes on modified MQTT simple

Stian Røed Hafskjold — Thu, 14 May 2020 10:10:09 GMT

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.

RE: Regular current spikes on modified MQTT simple

Carl Richard — Thu, 14 May 2020 09:52:53 GMT

I also did a small analysis of the peaks in python. It seems like the duration between spikes increases every second spike and that it initially only increases with 0.25s, before suddenly increasing with 1s between every spike. (see the crude plot below).

RE: Regular current spikes on modified MQTT simple

Carl Richard — Thu, 14 May 2020 09:46:57 GMT

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.

RE: Regular current spikes on modified MQTT simple

Stian Røed Hafskjold — Thu, 14 May 2020 09:05:10 GMT

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.