Hello,
I’m having problems running the LoRa ABP/OTAA examples using Arduino IDE. The library should allow up to 255 bytes of payload data, but it fails if 11 bytes or more are sent.
LoRaMac.cpp LoRaMacQueryTxPossible() fails with LORAMAC_STATUS_LENGTH_ERROR. I can’t debug this any further. Any suggestions ?
Russ…
Hi @colombo9, welcome to rak forum 
May I know the modifications you did on the example code? Like buffer size, payload packaging, etc?
At SF12, I was able to send only up to 40bytes to TTN. I am just trying to check the limit at SF12.
Then changing to SF7, I can successfully send 232bytes. I am failing at 248 bytes though. I tested at 16bytes increment.
Also, large payload is not ideal for Lorawan. Just take it into consideration. Our friends from TTN forum already had a great discussion on this topic https://www.thethingsnetwork.org/forum/t/limitations-data-rate-packet-size-30-seconds-uplink-and-10-messages-downlink-per-day-fair-access-policy-guidelines/1300.
The internal buffer in Arduino is set to 16 bytes, so use a #define SERIAL_TX_BUFFER_SIZE 64 (as an example) at the top of your sketch to make it larger. This takes space from memory so don’t just make it some number without figuring out what you actually need.
As @carlrowan says, working to the max is not a good design strategy with LoRaWAN and if you are starting out hoping to send 256 bytes, LoRaWAN may not be a good fit for your application. You can check out what you can & cannot send as data sizes using this:
https://avbentem.github.io/airtime-calculator/ttn/eu868/222
In the US, you can send 11 bytes at SF10. In the EU you can, in theory, send 51 bytes at SF12. However LoRa Alliance members are required to actively block anyone regularly sending at SF11 or 12 - for 51 bytes it’s 2.7 seconds of airtime which is a huge block on a channel, which along with some cross-talk, can really make a mess of the airwaves for that duration, resulting in lost uplinks all round.
Tell us your application, maybe we can suggest a way.
1 Like
Thanks to everyone for the great info. I’m using the Arduino RAK LoRaWan ABP example for US915 and 12 byte GPS location payload. Literally, just changing the send_lora_frame() routine from ‘Hello!’ sent every 5 minutes.
I’ve tried multiple DR_x values with no success. The error occurs within the LoRaMac library before the message is ever sent to TTN.
Try sending a short message at DR3 (SF7) and see what DR or SF is seen at the gateway.
As Nick says, 11 bytes would be the limit for you at DR0 (SF10), but you should be able to do a bit more at the remaining, faster data rates. Do consider if you cannot chop a byte off that packet somehow though - you probably don’t need the full position, just the local part.
Arduino transmit buffer size really should not matter much. All that controls is how much a sketch can write ahead of the UART and return immediately. If something longer is sent, the method call simply blocks until the UART ISR has drained all but the last [buffersize] bytes. Many embedded systems wouldn’t have a UART transmit buffer at all.
Chris, Here’s the info from an 11-byte payload using DR_3. It’s not using SF7 as expected.
{
“time”: “2020-12-11T16:29:41.919643179Z”,
“frequency”: 903.9,
“modulation”: “LORA”,
“data_rate”: “SF10BW125”,
“coding_rate”: “4/5”,
“gateways”: [
{
“gtw_id”: “eui-58a0cbfffe8024cd”,
“timestamp”: 2476404860,
“time”: “2020-12-11T16:29:41.131788015Z”,
“channel”: 0,
“rssi”: -48,
“snr”: 11.5
},
{
“gtw_id”: “eui-b827ebfffe9912bf”,
“timestamp”: 3337236940,
“time”: “”,
“channel”: 0,
“rssi”: -67,
“snr”: 12.8
}
]
}
At least now we know the problem: until you get off DR_0 you won’t be allowed more than 11 bytes.
I can’t find the source code the library you seem to be using, but looking at comparable things, see if adding a call to this helps:
void lmh_datarate_set(uint8_t data_rate, uint8_t enable_adr);
eg probably
lmh_datarate_set(3, 0); //DR3 = SF7, disable ADR so it does not change
Hi @cstratton,
@colombo9 is using the example code of WisBlock.
Hi @colombo9,
The section you need to modify is the macro definition related to this line. You need to set LORAWAN_ADR_OFF. I assume you have LORAWAN_ADR_ON which is the default on the example.
Can you modify this line as well? By default this is LORAWAN_DATARATE DR_0
Now reporting SF7 and 11 byte payload works, but 12 byte payload still fails.
{
“time”: “2020-12-11T19:29:59.755669007Z”,
“frequency”: 904.5,
“modulation”: “LORA”,
“data_rate”: “SF7BW125”,
“coding_rate”: “4/5”,
“gateways”: [
{
“gtw_id”: “eui-b827ebfffe9912bf”,
“timestamp”: 1270224395,
“time”: “”,
“channel”: 3,
“rssi”: -61,
“snr”: 10.5
},
{
“gtw_id”: “eui-58a0cbfffe8024cd”,
“timestamp”: 409394915,
“time”: “2020-12-11T19:29:58.968888998Z”,
“channel”: 0,
“rssi”: -45,
“snr”: 11
}
]
}
No difference. Still fails with 12 byte payload.
I believe we’re dealing with a bug somewhere in the LoRaMac library.
It’s the LoRaWAN library source I was looking for, rather than the example sketch.
From the install instructions it looks like it’s using this:
https://github.com/beegee-tokyo/SX126x-Arduino/blob/master/src/mac/region/RegionUS915.h#L225
Which should be scaling the payload limit by the datarate
static const uint8_t MaxPayloadOfDatarateUS915[] = {11, 53, 125, 242, 242, 0, 0, 0, 53, 129, 242, 242, 242, 242, 0, 0};
Enforcement would be here:
I wonder if the issue might be here where it is possibly (?) running a check against a default data rate rather than on one actually in effect?
cstratton - You’re exactly right about the library using the default index:
C:…\Arduino\libraries\SX126x-Arduino\src\mac\region\RegionUS915.h(225): static const uint8_t MaxPayloadOfDatarateUS915[] = {11, 53, 125, 242, 242, 0, 0, 0, 53, 129, 242, 242, 242, 242, 0, 0};
Changing index 0 value from 11 to anything greater proves this.
Making changes previously suggested (i.e. force DR_3, LORAWAN_ADR_OFF, etc) made no difference.
We still don’t have an answer WHY the library is using index 0. Who do we need to contact ?
Thanks, Russ…
You could lodge an issue on GitHub - although that segment of code is from Semtech so you may want to look at the original repro to see if this issue has been raised and if they have made a fix.
The test I’ve done above is for EU868. I can’t confirm the issue yet with US915.
@colombo9, have you tried turning off the ADR then set a different DR? Because if the ADR is on, the DR will be set to the default DR0.
The packets are being transmitted at DR3 though.
Seemingly some part of the code is still using DR0 for the check, even though the actual transmission is at DR3.
Adding some debug code in the library would be good, unfortunately that’s tricky in Arduino unless the support to make printf() works it may require passing in a function pointer to an Arduino-C++ logging method. I guess in theory one could debug the project with an stlink and gdb…
Unfortunately this seems to be based on an old version of the Semtech code, and without any continuity of git history. I’m looking at this, Semtech’s code, and another board vendor’s and they’re all different. Generally speaking though, it looks like ADR is the emphasized path and non-ADR does not get as much attention. How exactly the requested non-ADR datarate is supposed to be preserved and applied seems a bit different in different versions I don’t have the hardware to debug this one (at least unless I fake the radio in order to use an nRF MCU without one), but would suggest trying to follow the logic through it and see how the wrong datarate gets used for the maximum length lookup.
Filing an issue on the GitHub - beegee-tokyo/SX126x-Arduino: Arduino library to use Semtech SX126x LoRa chips and modules to communicate does seem warranted.
I run a test and can send up to 232 bytes. RAK7258 Gateway and Chirpstack running on RPI3. US915, DR3 and ADR off.
Search sensors on I2C
=====================================
RAK4631 LoRaWan test
=====================================
=====================================
SX126x initialization
=====================================
=====================================
Syncword = 2414
=====================================
Start network join request
OTAA joined and got dev address 01DDA933
switch to class C done
Sending frame
Send success 2 bytes
Sending frame
Send success 12 bytes
Sending frame
Send success 22 bytes
Sending frame
Send success 32 bytes
Sending frame
Send success 42 bytes
Sending frame
Send success 52 bytes
Sending frame
Send success 62 bytes
Sending frame
Send success 72 bytes
Sending frame
Send success 82 bytes
Sending frame
Send success 92 bytes
Sending frame
Send success 102 bytes
Sending frame
Send success 112 bytes
Sending frame
Send success 122 bytes
Sending frame
Send success 132 bytes
Sending frame
Send success 142 bytes
Sending frame
Send success 152 bytes
Sending frame
Send success 162 bytes
Sending frame
Send success 172 bytes
Sending frame
Send success 182 bytes
Sending frame
Send success 192 bytes
Sending frame
Send success 202 bytes
Sending frame
Send success 212 bytes
Sending frame
Send success 222 bytes
Sending frame
Send success 232 bytes
Sending frame
Send success 242 bytes
Sending frame
UP failed -1
The sources can be found on the Github issue. But you have to change the nodeDeviceEUI, nodeAppEUI, nodeAppKey
The log from Chirpstack is in the ZIP file as well.
1 Like