• State Verified Answer
  • Locked Locked
  • Replies 9 replies
  • Subscribers 92 subscribers
  • Views 5150 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 285537
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

nRF9160, Sending messages via MQTT larger than 256 bytes

Stas Jis

We use nRF9160 on our own board.
The firmware "Serial lte modem" is installed on the chip with connection to an external MCU.
We need to publish the JSON messages larger than 256 bytes (up to 2000 bytes) to the broker.
We transmit data in "Data Mode" and receive confirmation to publish messages.
For the test we are sending 356 bytes, here is the AT command sequence:

2022-03-09T08:49:53.339Z INFO Modem port is opened
2022-03-09T08:49:54.456Z DEBUG modem >> AT
2022-03-09T08:49:54.471Z DEBUG modem << OK
2022-03-09T08:49:55.439Z DEBUG modem >> AT+CFUN?
2022-03-09T08:49:55.453Z DEBUG modem << +CFUN: 0
2022-03-09T08:49:55.462Z DEBUG modem << OK
2022-03-09T08:49:58.061Z INFO Updating CA certificate...
2022-03-09T08:49:58.063Z DEBUG modem >> AT%CMNG=0,321,0,"-----BEGIN CERTIFICATE-----

2022-03-09T08:49:58.343Z DEBUG modem >> -----END CERTIFICATE-----"
2022-03-09T08:49:58.499Z DEBUG modem << OK
2022-03-09T08:49:58.500Z INFO Updating client certificate...
2022-03-09T08:49:58.502Z DEBUG modem >> AT%CMNG=0,321,1,"-----BEGIN CERTIFICATE-----

2022-03-09T08:49:58.702Z DEBUG modem >> z6s4x54=
2022-03-09T08:49:58.715Z DEBUG modem >> -----END CERTIFICATE-----"
2022-03-09T08:50:00.457Z DEBUG modem << OK
2022-03-09T08:50:00.459Z INFO Updating private key...
2022-03-09T08:50:00.460Z DEBUG modem >> AT%CMNG=0,321,2,"-----BEGIN EC PRIVATE KEY-----

2022-03-09T08:50:00.512Z DEBUG modem >> -----END EC PRIVATE KEY-----"
2022-03-09T08:50:00.711Z DEBUG modem << OK
2022-03-09T08:50:00.712Z INFO Certificate update completed
2022-03-09T08:50:21.135Z DEBUG modem >> AT+CEREG=5
2022-03-09T08:50:21.148Z DEBUG modem << OK
2022-03-09T08:50:24.911Z DEBUG modem >> AT+CFUN=1
2022-03-09T08:50:24.952Z DEBUG modem << OK
2022-03-09T08:50:25.923Z DEBUG modem << +CEREG: 2,"026F","00332521",7
2022-03-09T08:50:28.862Z DEBUG modem << +CEREG: 5,"026F","00332521",7,,,"00011110","11100000"
2022-03-09T08:50:35.864Z DEBUG modem >> AT#XMQTTCON=1,"999876","","","a34k7wa09ujucc-ats.iot.us-east-1.amazonaws.com",8883,321
2022-03-09T08:50:36.869Z ERROR Error: 'AT#XMQTTCON=1,"999876","","","a34k7wa09ujucc-ats.iot.us-east-1.amazonaws.com",8883,321
' timed out
2022-03-09T08:50:38.506Z DEBUG modem << OK
2022-03-09T08:50:38.810Z DEBUG modem << #XMQTTEVT: 0,0
2022-03-09T08:50:57.167Z DEBUG modem >> AT#XMQTTPUB="Rigel/ToServer/v2/AR_TEST","",1
2022-03-09T08:51:08.472Z DEBUG modem >> {"deviceId":"","deviceType":"Collar","requestTime":0,"carrier":"CELLULAR","rssi":-70,"messages":[{"messageId":536875008,"messageCategory":1,"messageType":9,"recordedTime":0,"firmwareVersion":"collar-fw-0.1.3","bootVersion":"collar-boot-0.0.1","attachmentStatus":"Unknown","battery":0,"chargeStatus":0,"operationMode":0,"debugMode":0,"sos":0,"safeZone":0}]}
2022-03-09T08:51:09.258Z DEBUG modem << #XMQTTEVT: 3,0
2022-03-09T08:52:08.971Z DEBUG modem << #XMQTTEVT: 9,0

But from the server side, we always receive messages with a maximum length of 256 bytes (truncated):
{"deviceId":"","deviceType":"Collar","requestTime":0,"carrier":"CELLULAR","rssi":-70,"messages":[{"messageId":536875008,"messageCategory":1,"messageType":9,"recordedTime":0,"firmwareVersion":"collar-fw-0.1.3","bootVersion":"collar-boot-0.0.1","attachmentSt

There are no problems when transmitting a message via UART, we record everything that we transmit via "Logic" App, and clearly saw that the message via UART was completely gone.
Plus, we also saw the same problem when we subscribe to the topic. If we wait to receive messages larger than 256 bytes, it comes truncated and after we receive event for a read error and a disconnect.
2022-03-08T15:29:20.381Z DEBUG modem >> AT#XMQTTSUB="Rigel/ToServer/v2/AR_TEST",0
2022-03-08T15:29:21.134Z DEBUG modem << OK
2022-03-08T15:29:21.612Z DEBUG modem << #XMQTTEVT: 7,0
2022-03-08T15:29:24.096Z DEBUG modem << Rigel/ToServer/v2/AR_TEST
2022-03-08T15:29:31.789Z DEBUG modem << {"deviceId":"","deviceType":"Collar","requestTime":0,"carrier":"CELLULAR","rssi":-70,"messages":[{"messageId":536875008,"messageCategory":1,"messageType":9,"recordedTime":0,"firmwareVersion":"collar-fw-0.1.3","bootVersion":"collar-boot-0.0.1","attachmentSt#XMQTTEVT: 2,0#XMQTTMSG: 29,256Rigel/ToServer/v2/Operational{"deviceId":"","deviceType":"Collar","requestTime":0,"carrier":"CELLULAR","rssi":-70,"messages":[{"messageId":536875008,"messageCategory":1,"messageType":9,"recordedTime":0,"firmwareVersion":"collar-fw-0.1.3","bootVersion":"collar-boot-0.0.1","attachmentSt
2022-03-08T15:29:44.526Z DEBUG modem << #XMQTTEVT: 2,0
2022-03-08T15:29:44.689Z DEBUG modem << #XMQTTEVT: 2,-122
2022-03-08T15:29:44.700Z DEBUG modem << #XMQTTEVT: 1,-113

  • 0

    There is a hardcoded limit in the source code. You can increase that to suit your needs.

  • 0 in reply to Markus Tacker (he/him)

    Markus,
    We are working with SDK 1.8 where this configuration is not defined.

    #define MQTT_MAX_TOPIC_LEN	128
#define MQTT_MAX_CID_LEN	64
#define MQTT_MESSAGE_BUFFER_LEN	NET_IPV4_MTU

    Need to upgrade to a different SDK version? Or just adding "MQTT_MAX_PUB_LEN" fixes the situation.

  • 0 in reply to Stas Jis

    Looking at the source, `MQTT_MESSAGE_BUFFER_LEN` needs to be set to a larger value. 

    #define MQTT_MESSAGE_BUFFER_LEN	2000

  • 0 in reply to Markus Tacker (he/him)

    Markus,

    I changed the value to "#define MQTT_MESSAGE_BUFFER_LEN 2048" and flash the board.
    However, this had a different effect, the messages still do not arrive in their entirety, but only in chunks (of an even smaller size), with data loss.
    Original JSON:

    {"deviceId":"","deviceType":"Collar","requestTime":0,"carrier":"CELLULAR","rssi":-70,"messages":[{"messageId":536875008,"messageCategory":1,"messageType":9,"recordedTime":0,"firmwareVersion":"collar-fw-0.1.3","bootVersion":"collar-boot-0.0.1","attachmentStatus":"Unknown","battery":0,"chargeStatus":0,"operationMode":0,"debugMode":0,"sos":0,"safeZone":0}]}


    Result on the server:
    1 Message:
{"deviceId":"","deviceType":"Collar","requestTime":0,"carrier":"CELLULAR","rssi":-70,"messages":[{"messageId":536875008,

2 Message
1","attachmentStatus":"Unknown","battery":0,"chargeStatus":0,"operationMode":0,"debugMode":0,"sos":0,"safeZone":0}]}


  • 0 in reply to Stas Jis

    Hi,

    The SLM should also output log over RTT. Could you provide that log as well, so that we can see more of what the application is doing, and where the split happens?

    Best regards,

    Didrik

Related
Terms of service