How to send more than 119 byte payload over AT commands

I have a RAK811 development board I am interfacing with using AT commands over USB. I see in the RAK811_AT_Command_Manual_V1.0.pdf section 1.2 it says there is a 255 character limit for AT commands including the terminating characters.

The command to send data over lora is at+send=lora:#:<data>\r\n where # is a 1-digit port number. This takes 17 characters leaving 238 characters for the data which is in hex meaning an effective payload limit of 119 bytes.

At DR3 (SF7125K in USA) I should be able to send around 200 bytes. Is it possible to send payloads of over 119 bytes using AT commands?


This AT command is not support,

But you can send around 200 bytes by RUI port.

Thanks Nicholas,

Can you point me to some documentation on using RUI?


You can refer this web,
Hope help you!

119 bytes would be at the huge end of the LoRaWAN payload size. The average of my devices is around 16 bytes.

See for some info.

Can you break your payload down, use different ports to differentiate the different payloads, send smaller packets of the faster changing sensors & the occasional packet of slower changing items. Or byte pack the data to make it smaller?

Hi @atgpara

Despite this discussion was quite time ago, I’d like to mentioned that in changeLog:

I found such messages for currently latest version v3.0.0.14:

5.Fixed 2 ERROR prompts for AT instruction overlength (more than 255 characters, including AT instruction characters)

But unfortunately I can’t test it yet on the hardware I have due to

I’ve tested v3.0.0.14 firmware and it hasn’t fixed this issue. Very very sad.

Besides LoRaWAN there is also LoRaP2P mode!

Also it is not just the point of the average and usual cases. There is the standard that allows up to 255 payload, and it is good to try to meet it. I understand that there is RAM limitation on stm32L, but still, is not so huge.

I also confirm that the problem with >119 byte payload in AT+SEND RAK811 persist on v3.0.0.14 firmware

Are there any plans for a fix in a future firmware release, or is it an unfixable bug ?

The “bug” would be thinking such a huge payload was something appropriate to even try to send.

1 Like

Welcome to RAK forum Peter :slight_smile:

Are you sending via P2P or LoRaWAN? If LoRaWAN, what is your spreading factor?

Hi @carlrowan ,

I am using LoRaWAN with SF7, below there are images from RAK serial tool and Gateway GUI
Here the device joined and tried to send 118, 119 bytes (success) and then 120 bytes (fail)

@cstratton I understand that one shouldn’t push protocol limits in the first place, but there is no use in a device limitation beyond protocol standards in payload size, and near 100 bytes (119 from ~220 for SF7) is a significant difference. I just try to minimize breaking my data in chuncks and test/set my limits.

Are there plans for a fix in future precompiled firmware release, or should I only try with RUI ?
Thank you for the support

Thanks for the info @ptr321.

Can you try to send this payload?


This is 238 characters.

Hi @carlrowan , it is sent with success. However, that message is 238 characters → 119 bytes ( because 2 characters = 1 byte in hex ) . Am I understanding something wrong here ?

You are actually correct. 2 character will represent an ASCII byte.

These are not bugs since the limitations on the spreading factor follow the specs set by the LoRa Alliance.


It should be 242 but 4 characters was used by \r\n.

In LoRa P2P, there will be no restriction based on spreading factor because it doesn’t need to follow the standard. However, RUI firmware will limit your UART transmission to 256 bytes. At this point, you have no other way if you have a bigger payload but to slice it.

Got it, thank you very much @carlrowan

1 Like