nRF9160 send larger MQTT payloads than 2048 bytes to save battery power (need to send 200KB)

[Johan]

Hi,

I want to optimize the transmission efficiency and thinking of sending larger packets than 2048 bytes of MQTT would help.

We have limited battery power, and looking at the MQTT traffic towards AWS I see that this is happening:

1) MQTT-packet is sent.

2) Waiting for response (several seconds)

3) Receiving an ACK.

4) goto 1 (is the fastest way I can do it now, send the next packet of max 2048 bytes).

If I can change the max mqtt packet size to for instance 16K, that would mean an improvement I'm guessing.

Changing it though, makes the example code crash, going somewhere into non program space. It doesn't seem to allow changing of that size, even though it's available in the menu <Project -> configure nRF SDK...etc -> searching for MQTT -> finding maximum MQTT PACKET SIZE set to 2048>

I tried 4096, 8192, 16384.

I get for bigger sizes, crash in the code.

For smaller increases like 4096, I get an error from the socket_write instead, so it's then in the modem software I'm guessing.

I really want to send bigger packages, to improve battery life.

Who can help with this? 

IS this bugs or crash by design, or fail by design, even though the MQTT PACKET SIZE is allowed to be changed by design?

Johan

[Martin Lesund]

Hi Johan,

It is a bug.

The TLS output buffer has a size of 2kB, and there is a bug that you do not get a notification that the messages are too big. (this will be fixed)

So the solution is to have shorter messages.

Best Regards,

Martin  L,.

[Johan]

Ok, looking forward to that bugfix.

Will you enable us to send larger packets later? Is there a limitation somewhere? Is there power to save to send more in a bigger chunk, than to send them separately?

So, how to get up speed when needing to send a large data buffer?

I'm thinking to split the big chunk of 300KB (example size), into like you suggest, smaller parts

* send part 1

* send part 2

...

* send part n

immediately after eachother.

There is no need to wait for the ACK for each part before sending the next I'm guessing.

[Johan]

Yes now using NCS v1.0.0 and mfw v1.0.0. Same performance.
I just finished creating a trace and I will send it to you over email.

[Johan]

Hi Martin,

Whats the way of fetching the max size of the TLS output buffer now from latest release 1.2?

Before you mentioned the 2048 bytes limitation, and we have used that. It looks like the source code uses MBED and there is a 16384 buffer there somewhere.

/Johan

[Martin Lesund]

Hi Johan,
Please check the "mfw_nrf9160_1.2.0_release_notes.txt" located inside the "mfw_nrf9160_1.2.0.zip":

[Johan]

Thanks.

I wonder still, what function call I can make to get this number fetched - so when it changes - I dont need to update my app, instead it fetches the current max size from the driver instead.

[Johan]

I would like a discussion on this one with Nordic. Why no contact on this?

[Martin Lesund]

Hi Johan,
sorry for the delay.
There is no way to read this number out.
The TLS buffer size is restricted around 2048bytes because of limited memory resources.

[Johan]

All right. Then we will hardcode it.

I read you have 3 simultaneous TLS sockets available at the same time in your modem implementation.

No change of setting up how many sockets I want to use, ie getting a larger TLS buffer for 1 single socket since that's all we use?

Future perhaps? Anyone you could take this to, as a request?

[Martin Lesund]

Reported internally as a feature request.

Just to mention, this would not be a quick fix, it would require some restructuring on the modem side etc. So this is not something that will change in the near future.

[Johan]

All right. Perhaps for future generations this will be useful when it's implemented, if ever.