Not able to send larger payloads (>200byte)

[mcr-ksh]

Hi,

i've been testing and sending data from T-Beam V1.1 without a problem if the data size is below approx. 200 bytes. If I exceed somewhat around the 200 bytes the packet is not transmitted (or received) on my receiver. Smaller packages are received.

Sender: T-Beam V1.1
Receiver: ATmega328p + SX1279

Anyone else experiencing this kind of issue?

[IoTThinks]

1. Why you need to send so large packet?
2. By right, LoRa packet is up to 255 bytes.
   You can try to slow down the sending interval and enable CRC.

[mcr-ksh]

1. Does the "why" really matter? -> it's a requirement
2. Crc is already enabled. I'm afraid I don't understand the part about the sending interval as I write to the SPI register the bytes to be send and then trigger the register (function endPacket) to send the package.

I was just able to nail down the Problem to the LoRa.enableInvertIQ(); function. So when I call enableInvertIQ the disableInvertIQ afterwards the receiver is not getting the long packet.

[Kongduino]

In theory, the maximum payload is 256 bytes (or 255 can't remember), BUT that is theoretical only. Max payload is regulated in LoRaWAN, and depends on the SF/BW combination, from 51 to 222 bytes.

   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     |

That's for LoRaWAN (which, among other things, is restricted to BW 7 to 9, ie 125 to 500 KHz). For LoRa PHY, and lower frequencies, I haven't been able to find a similar table. But rest assured that sending 200+ bytes will involve setting your BW and SF to something like the above.

[mcr-ksh]

That is very helpful for LoraWAN. Here im talking about direct lora access to the chip. So the limits should not apply if not enforced by the chip

[Kongduino]

The limits apply in the sense that while there may be some regulatory restrictions originally (Fair Use yada yada), in the (H) range (868+) at least, dwell time limitations (400 ms max) impose a physical limit on the amount you can actually transmit. A chip that ignores that will not get FCC certification.

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. My advice would be to:

(a) reduce the size, say 150, then add a few bytes each time and see when it break.
(b) use different combinations of SF/BW (reduce SF, raise BW).

[TA2SVS]

hello @mcr-ksh I am sorry for disturbing you. I'm having the same problem and I couldn't find the crc related code anywhere. Is there any way you can share it? . I don't know how it's done. Thank you.

[mcr-ksh]

hello @mcr-ksh I am sorry for disturbing you. I'm having the same problem and I couldn't find the crc related code anywhere. Is there any way you can share it? . I don't know how it's done. Thank you.

Too long ago. I have no idea anymore. sorry.