things4u / ESP-1ch-Gateway

Version 6 of the single channel gateway
MIT License
364 stars 147 forks source link

Overcoming payload length limitation of 155 bytes #28

Open PticDado opened 4 years ago

PticDado commented 4 years ago

Dear Mr. Westenberg,

First of all, I would like to thank you for creating the ESP-1ch-Gateway. I made extensive use of it and it is really valuable to me. A problem I came across is that there seems to be a limitation with regard to the payload length. My end device sends 228 bytes long payload that doesn't get through the unmodified ESP-1ch-Gateway software. It seems that it only allows for up to 155 bytes long payloads. I experimented with various modifications to the software and ended up with the following:

_txRx.ino char b64[384]; // originally 256

loraModem.h

define PAYLOAD_LENGTH 0xFF // originally 0x40

#define MAX_PAYLOAD_LENGTH  0xFF  // originally 0x80

uint8_t payLoad[256];  // originally 128                        

struct LoraUp {
    uint8_t     payLoad[256];   // originally 128

configGway.h

define _SPIFFS_FORMAT 1

#define _SPREADING SF7
#define _CAD 0
#define A_SERVER 0  
#define A_MAXBUFSIZE 256  // originally 192
#define A_OTA 0
#define _STAT_LOG 0
#define _LOCALSERVER 0
#define _TRUSTED_NODES 0
#define _TRUSTED_DECODE 0

Basically, I have increased various arrays which I thought might be too small. Additionally, I tried to turn off just everything that is not essential to the uplink operation. I didn't test the downlink operation, however. With these modifications the 228 byte long end-device payload somehow gets through. Although the modifications seem to work, I am well aware that my insight into the internal workings of the software is insufficient. It would be most welcome and appreciated if somebody could do that in a qualified manner in order to properly extend the functionality and overcome the limitations of the software. I'm not sure if that's an issue, but I came across currentAddr > 64 and payLength>=128 in the _loraModem.ino that might also need some attention.

Best regards,

Radovan

platenspeler commented 4 years ago

I will have a look. But stupid question: Why would you need such a nig buffer when LoRa asks us to save on space?

Thanks,

Maarten

PticDado commented 4 years ago

Dear Mr. Westenberg,

Thank you for your prompt response. As much as I understand it is necessary to limit the on-air transmission time. That’s where the maximum data payload size limitation comes from, which is of course related to the data rate and conversely to the spreading factor / bandwidth configuration. Please allow me to draw your attention to pages 16 and 18 of the document https://lora-alliance.org/sites/default/files/2018-04/lorawantm_regional_parameters_v1.1rb_-_final.pdf

Best regards,

Radovan