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?
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?
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 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
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.
