I am working with the setup of Arduino Uno and Arduino M0 boards with RFM95 transceivers, running LMiC library, on US915 bands and currently I am trying to send packets with size more than 51 bytes. As I understand, I should be able to send more bytes as I increase the data rate, but, for some reason, I cannot get it working for above 52 bytes of the frame size, independently of the data rate in use.
Is it something that LMiC library is restricting or TTN limits? Or is it something that I am misunderstanding? If so, how can I send frame above this size, since LoRaWAN specifications say that for US bands it should work up to 242 bytes of the frame size.
Thank you for the reply.
That is very unfortunate, but, if that is the case, is there any other library for Arduino environment I could use so that it would work with the packet size up to maximum possible for that particular SF?
Maybe I should’ve mentioned it before, but I purposely want to send that big of a packet. Currently, I am looking into packet drop depending on the packet size, SF and distance from the gateway, so it is crucial for me to able to see how the relationship between data rate, payload size, distance and packet drop will work in my current setup.
Yes, I’ve tried it for several different values, but none of them seems to work. Device just stops sending anything for anything larger than 51 bytes.
In my experience, by default when ADR is ON, the device would start sending with SF12 which would have the limitation on number of bytes for the application payload.
So you can try turning OFF the ADR.
May I know how you are confirming that the device is transmitting at the configured datarate DR/SF?
Generally I use a easily available RTL-SDR as spectrum analyzer to see the message(it is good enough to differentiate if the device is transmitting in SF7 or SF12). otherwise you can check the lora gateway logs if there is an access.
I couldn’t think of any other cause at the moment if the configured DR is matching the transmitted DR.
Well, like noted in earlier answers, without modifications the LMiC library simply only allocates 64 bytes for the full packet, which includes a 13 bytes LoRaWAN header…
Nobody said that changing one constant, without even knowing why the limit exists, would fix things… (If even recompiled correctly after changing it.)
To be honest, It worked with my setup and I was happy that i managed to send my complete CoAP application payload ~80Bytes. To note: It was just for an experimental purpose.
If I understood correctly, you changed the LMiC library constant to a higher value and were able to send ~80 bytes of data? Can you tell me a bit more - which devices, SF you were using?
Ok, got it working for much larger packet sizes. The problem was, that I changed the frame length in lorabase.h file, but there is another constant specified in lmic.h within the src folder of the library. Now I was able to send 115 bytes, and I am pretty sure it can go up to max length specified in LoRaWAN. Thanks for the help.
I came across the same problem. None of your solutions work on my project. I use a raspberry pi with a lora/gps shield and I can try 48 bytes, if I go higher it wont work. Anybody know some other solution?
In many, if not all, regions it is the maximum size for SF12 anyhow, so if the node needs to work in all situations, that’s your maximum.
51 bytes allows for, for example, as many as 25 values between 0 and 65,536, or 12 values between 0 and 4,294,967,296.
It might also be the maximum if you ever want to move to a different provider. Like the FAQ of a Dutch provider states:
What is the size of KPN LoRa packets?
The maximimum size that can be used all the time is 51 bytes. (When FOpts field within the LoRa packet is empty, this can be 54 bytes).
Maybe “at all times” refers to the worst-case SF12, but this is just one example.
