How to increase the communication speed of LoRa E5?

Hi,
I am using STLRWAN2(Gateway) with LoRa-E5(Node). I can transfer data at the rate of 300 bps.

I would like to know the methods for increasing the bps, given that the ideal LoRaWAN has 5500 bps.

**Operating setup in the lab environment with Tx parameters as follows,

  1. DR5 (SF7 and BW125)
  2. Payload = 120 bytes and Preamble=13 bytes
  3. Class A with RxWIN1=10 ms and RxWIN2=20 ms

Please let me know the settings / AT commands to increase the communication speed of LoRa E5

Thank you

Hi there,
What’s the Band Plan Power table you are using?
It’s not as easy as that, more parameters need known. LOL … ie. AT command. :face_with_peeking_eye:
see Table 3-2 RF Modulation Bit Rate. LoRa SF7/125KHz 5470 bps
you need to form the command packet with crc properly . What have you tried.?
HTH
GL :slight_smile: PJ
:v:

Thanks, @PJ_Glasso, for the reply.

Code for sending a message packet of 120 bytes:
sprintf(cmd, "AT+MSGHEX=\""); for(size_t i=0; i<120; i++) { sprintf(cmd + strlen(cmd), "%02x", payload[i]); } sprintf(cmd + strlen(cmd), "\"\r\n"); at_send_check_response("+MSGHEX: ", 100, cmd);

*Increasing payload size by more than 120 bytes throws an error. Meanwhile, the maximum payload size is 242 bytes.

Here are my settings,
+INFO: Input timeout
+MODE: LWOTAA

+INFO: Input timeout
+CH: 3; 0,865062500,DR0,DR5; 1,865402500,DR0,DR5; 2,865985000,DR0,DR5;

+INFO: Input timeout
+LW: VER, V103

+INFO: Input timeout
+DR: DR5
+DR: IN865 DR5 SF7 BW125K

+INFO: Input timeout
+MODE: TEST

+INFO: Input timeout
+TEST: STOP
+TEST: RFCFG F:868000000, SF7, BW125K, TXPR:8, RXPR:8, POW:14dBm, CRC:ON, IQ:OFF, NET:OFF

+INFO: Input timeout
+MODE: LWOTAA

+INFO: Input timeout
+LW: LEN, 242

+INFO: Input timeout
+DR: IN865
+DR: IN865 DR0 SF12 BW125K
+DR: IN865 DR1 SF11 BW125K
+DR: IN865 DR2 SF10 BW125K
+DR: IN865 DR3 SF9 BW125K
+DR: IN865 DR4 SF8 BW125K
+DR: IN865 DR5 SF7 BW125K
+DR: IN865 DR6 SF7 BW250K
+DR: IN865 DR7 FSK 50kbps
+DR: IN865 DR8 RFU
+DR: IN865 DR9 RFU
+DR: IN865 DR10 RFU
+DR: IN865 DR11 RFU
+DR: IN865 DR12 RFU
+DR: IN865 DR13 RFU
+DR: IN865 DR14 RFU
+DR: IN865 DR15 RFU

Hi harishmekali,

I don’t know if this will help, but I experimented with the following AT command.

“AT+TEST=RFCFG,922.1,SF7,250,8,8,13,ON,OFF,OFF\r\n”

1 Like

Thank you @cgwaltney

1 Like

Hi @PJ_Glasso ,

Can you please share some thoughts.?

I have increased the BW=250KHz.
+DR: IN865 DR6 SF7 BW250K

According to Sandeepmistry and in theory, the maximum payload is 256 bytes BUT that is theoretical only. Max payload is regulated in LoRaWAN, and depends on the SF/BW combination, from 51 to 222 bytes as you set it.(table)

Mode Bitrate Max payload
SF7/125kHz 5470 222
SF8/125kHz 3125 222
SF9/125kHz 1760 115
SF10/125kHz 980 51
SF11/125kHz 440 51
SF12/125kHz 250 51
SF7/250kHz 11000 222

in the (H) range (868+) at least, dwell time limitations (400 ms max) impose a physical limit on the amount you can actually transmit. I have read, In older chips, SX127x, in (L) frequencies (433 etc) there are supposedly no dwell time restrictions, but somehow sending larger packets doesn’t always work. Also, remember that the 255 limit is the WHOLE budget, including preamble, header, header CRC, and possibly payload CRC. So altogether, between the overhead, and the physical restrictions due to the SF/BW combination, your packets could be too long to send, and hang the chip. You can try to:
(a) reduce the size, say 150, then add a few bytes each time and see when it breaks.
(b) use different combinations of SF/BW (reduce SF, raise BW).
are the only options left.

It’s just not designed to do more and on the edge when doing WAN , because not all nodes are the newer chipsets. So interoperability is there main concern so Giant Packets going long distance isn’t its thing. The dwell time also is the only way I have read or seen get even close to the max.
appears the best is smaller packets send more often. (requires large buffers on transmit side IMO to get close to the max…)
This is why we need an IOT Xiao IMO., the LORA use case is limited in some ways.
I think the POINT to POINT setups is where it shines, not the WAN setups that’s a patch work of networks that may not all have new Silicon.
HTH
GL :slight_smile: PJ
:v:

1 Like