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 
PJ
