LMiC fails to send application payload larger than 51 bytes

End Devices (Nodes)
1

Dear all,

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 in advance for any help.

2

It seems LMiC is limited to 52 bytes:

That said, if you need that many bytes, maybe LoRaWAN is not the best choice. (Or maybe you’re sending text rather than binary-encoded values?)

3

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.

4

Did you try to enlarge MAX_LEN_FRAME?

5

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.

6

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.

1 Like
7

Thanks for the reply. I’ve tried again, manually disabling the ADR, but the problem still persists.

8

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.

9

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…

10

It seems that it didn’t work out, from one of the replies from asif2920.( even after changing the MAX_LEN_FRAME).

11

Nobody said that changing one constant, without even knowing why the limit exists, would fix things… (If even recompiled correctly after changing it.)

12

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. :slight_smile:

13

I am doing exactly the same thing, using RTL-SDR to see if anything is even being transmitted or not.

14

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?

15

I was using ChisteraPi shield on a RaspberryPi3 with DR5(which I think corresponds to SF7 or 8), ADR=OFF… btw, its on EU band.

16

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.

2 Likes
17

Nice. Can you post the details at https://github.com/matthijskooijman/arduino-lmic/issues/100 as well?

2 Likes
18

Sure thing.

2 Likes
19

Hello everybody,

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?

Kind regards

20

I’d really suggest to keep far below 51 bytes:

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

  • With TTN you’ll also have to adhere to the Fair Access Policy.

  • Even TTN has a reference in code to this maximum.

That said: the suggested changes work for others using LMiC, so without any further details how would you expect us to help?