LMiC fails to send application payload larger than 51 bytes

asif2920 · August 11, 2017, 10:37pm

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.

arjanvanb · August 12, 2017, 11:42am

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

asif2920 · August 12, 2017, 10:29pm

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.

arjanvanb · August 13, 2017, 7:46am

Did you try to enlarge MAX_LEN_FRAME?

github.com

matthijskooijman/arduino-lmic/blob/master/src/lmic/lorabase.h#L40


// Radio parameter set (encodes SF/BW/CR/IH/NOCRC)
typedef u2_t rps_t;
TYPEDEF_xref2rps_t;


enum { ILLEGAL_RPS = 0xFF };
enum { DR_PAGE_EU868 = 0x00 };
enum { DR_PAGE_US915 = 0x10 };


// Global maximum frame length
enum { STD_PREAMBLE_LEN  =  8 };
enum { MAX_LEN_FRAME     = 64 };
enum { LEN_DEVNONCE      =  2 };
enum { LEN_ARTNONCE      =  3 };
enum { LEN_NETID         =  3 };
enum { DELAY_JACC1       =  5 }; // in secs
enum { DELAY_DNW1        =  1 }; // in secs down window #1
enum { DELAY_EXTDNW2     =  1 }; // in secs
enum { DELAY_JACC2       =  DELAY_JACC1+(int)DELAY_EXTDNW2 }; // in secs
enum { DELAY_DNW2        =  DELAY_DNW1 +(int)DELAY_EXTDNW2 }; // in secs down window #1
enum { BCN_INTV_exp      = 7 };
enum { BCN_INTV_sec      = 1<<BCN_INTV_exp };

asif2920 · August 14, 2017, 4:29pm

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.

arun · August 17, 2017, 8:04am

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.

asif2920 · August 18, 2017, 7:39pm

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

arun · August 19, 2017, 8:22pm

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.

arjanvanb · August 19, 2017, 8:27pm

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…

arun · August 19, 2017, 8:55pm

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

arjanvanb · August 19, 2017, 8:58pm

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

arun · August 19, 2017, 9:14pm

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.

asif2920 · August 21, 2017, 12:37am

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

asif2920 · August 21, 2017, 12:40am

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?

arun · August 21, 2017, 8:46am

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.

asif2920 · August 21, 2017, 6:51pm

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.

arjanvanb · August 21, 2017, 6:59pm

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

asif2920 · August 22, 2017, 5:40pm

Sure thing.

JorenJ · May 25, 2018, 11:36am

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

arjanvanb · May 25, 2018, 2:52pm

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?