NRF Cloud coap payload size limitation too small

[AdrianT]

Hi,

I am using NRF Cloud + coap comms to send data. However I have encountered payload size limitations that are not configurable via KConfig: sdk-nrf/subsys/net/lib/nrf_cloud/src/nrf_cloud_codec.c at main · nrfconnect/sdk-nrf

I have manually modified it to accomodate my payloads. I am also considering manually encoding my payload in cbor to avoid modifying SDK code. Is there a reason why this is limited to 64 bytes? There is no documentation pointing to the payload size limits for nrf cloud.

[Pete Skeggs]

Ah. If that is your need, then look instead at nrf_cloud_coap_bytes_send():
github.com/.../nrf_cloud_coap.h

[AdrianT]

nrf_cloud_coap_bytes_send works. Thanks.

Just a question, nrf_cloud_coap_message_send is also limited by 

MESSAGE_SEND_CBOR_MAX_SIZE (256). Is there a reason why?

I am mostly concerned about it since we are now using nrf_cloud_coap_bytes_send to send ideally more than 1500 bytes. Is there a limitation on the nrf cloud backend on the length of messages? Is there a reliability concern?

[Pete Skeggs]

The function nrf_cloud_coap_bytes_send() is not limited to 256 (that constant is not even used in the function).

As indicated in the modem firmware release notes (inside the zip file you download from nordicsemi.com), DTLS packets are limited in size to 1024 bytes each. So a single message cannot be larger than 1024.

The CoAP block transfer standard allows for sending much larger messages as a series of smaller ones. The nrf_cloud_coap_bytes_send() function should already do this if the buf_len parameter is > 1024. You are still limited to the size of a buffer you can allocate in RAM. 

[Achim Kraus]

> send ideally more than 1500 bytes

That will then be far, far away from "ideally" ;-).

In my experience, your application is either designed to exchange a few hundreds of bytes (400-700), then coap will perform brilliant. If in rare cases more data is required, but the majority of the traffic is small, then using coap blockwise helps to overcome that. e.g. SCADA usually use such 400-700 bytes messages, but in rare case a firmware image with 400k.

If you need to use the device on very low radio, then it works better if you even limit that to 200 bytes.

If you frequently transfer 10k or 100k or what ever, you anyway far out of "low power wan", at least not in the 10 years from battery category.

So, maybe you tell, what your application requires, then it would be easier to provide guidance.

[AdrianT]

The custom sensor generates datapoints that are quite large in size. We have already optimized the data to what is only necessary but it is still above the typical payload size.