Increase in payload

[jfma26]

First excuse me that I cannot write well in English, at the moment I am doing my thesis with lorashield Dragino implemented in Arduino Uno, I have a problem when I do the connection tests it works perfectly, but after a while the payload increases to 51 bytes and leaves of sending data, I suppose that changing the size limit of the payload will fix the sending of data to the limit that establishes it but there is some way that the payload stays within the limit of the library below 51 bytes. I was looking for this problem within the issues but I did not find anything, I really need help in that for my thesis. As a solution I gave him that every time he reaches the limit of 51 bytes in the payload join again and the payload is reset. I attach the image increment of the payload increment with the Hello World example from otaa. Can you set the size of the static payload ?. The example is the "Hello World"

#include <lmic.h>
#include <hal/hal.h>
#include <SPI.h>

// This EUI must be in little-endian format, so least-significant-byte
// first. When copying an EUI from ttnctl output, this means to reverse
// the bytes. For TTN issued EUIs the last bytes should be 0xD5, 0xB3,
// 0x70.
static const u1_t PROGMEM APPEUI[8] = {};
void os_getArtEui (u1_t* buf) {
  memcpy_P(buf, APPEUI, 8);
}

//
// This should also be in little endian format, see above.
static const u1_t PROGMEM DEVEUI[8] = {};
void os_getDevEui (u1_t* buf) {
  memcpy_P(buf, DEVEUI, 8);
}

// This key should be in big endian format (or, since it is not really a
// number but a block of memory, endianness does not really apply). In
// practice, a key taken from ttnctl can be copied as-is.
// The key shown here is the semtech default key.
static const u1_t PROGMEM APPKEY[16] = { };
void os_getDevKey (u1_t* buf) {
  memcpy_P(buf, APPKEY, 16);
}

static uint8_t mydata[] = "Hello, world!";
static osjob_t sendjob;

// Schedule TX every this many seconds (might become longer due to duty
// cycle limitations).
const unsigned TX_INTERVAL = 5;

// Pin mapping
const lmic_pinmap lmic_pins = {
    .nss = 10,
    .rxtx = LMIC_UNUSED_PIN,
    .rst = 9,
    .dio = {2, 6, 5},
};

void onEvent (ev_t ev) {

    switch(ev) {
        case EV_SCAN_TIMEOUT:
            Serial.println(F("EV_SCAN_TIMEOUT"));
            break;
        case EV_BEACON_FOUND:
            Serial.println(F("EV_BEACON_FOUND"));
            break;
        case EV_BEACON_MISSED:
            Serial.println(F("EV_BEACON_MISSED"));
            break;
        case EV_BEACON_TRACKED:
            Serial.println(F("EV_BEACON_TRACKED"));
            break;
        case EV_JOINING:
            Serial.println(F("EV_JOINING"));
            break;
        case EV_JOINED:
            Serial.println(F("EV_JOINED"));

            // Disable link check validation (automatically enabled
            // during join, but not supported by TTN at this time).
            LMIC_setLinkCheckMode(0);
            break;
        case EV_RFU1:
            Serial.println(F("EV_RFU1"));
            break;
        case EV_JOIN_FAILED:
            Serial.println(F("EV_JOIN_FAILED"));
            break;
        case EV_REJOIN_FAILED:
            Serial.println(F("EV_REJOIN_FAILED"));
            break;
            break;
        case EV_TXCOMPLETE:

            if (LMIC.txrxFlags & TXRX_ACK)
              Serial.println(F("Received ack"));
            if (LMIC.dataLen) {
              Serial.println(F("Received "));
              Serial.println(LMIC.dataLen);
              Serial.println(F(" bytes of payload"));
            }
            // Schedule next transmission
            os_setTimedCallback(&sendjob, os_getTime()+sec2osticks(TX_INTERVAL), do_send);
            break;
        case EV_LOST_TSYNC:
            Serial.println(F("EV_LOST_TSYNC"));
            break;
        case EV_RESET:
            Serial.println(F("EV_RESET"));
            break;
        case EV_RXCOMPLETE:
            // data received in ping slot
            Serial.println(F("EV_RXCOMPLETE"));
            break;
        case EV_LINK_DEAD:
            Serial.println(F("EV_LINK_DEAD"));
            break;
        case EV_LINK_ALIVE:
            Serial.println(F("EV_LINK_ALIVE"));
            break;
         default:
            Serial.println(F("Unknown event"));
            break;
    }
}

void do_send(osjob_t* j){
    // Check if there is not a current TX/RX job running
    if (LMIC.opmode & OP_TXRXPEND) {
        Serial.println(F("OP_TXRXPEND, not sending"));
    } else {
        // Prepare upstream data transmission at the next possible time.
        LMIC_setTxData2(1, mydata, sizeof(mydata)-1, 0);

    }
    // Next TX is scheduled after TX_COMPLETE event.
}

void setup() {
    Serial.begin(57600);
    Serial.println(F("Starting"));

    #ifdef VCC_ENABLE
    // For Pinoccio Scout boards
    pinMode(VCC_ENABLE, OUTPUT);
    digitalWrite(VCC_ENABLE, HIGH);
    delay(1000);
    #endif

    // LMIC init
    os_init();
    // Reset the MAC state. Session and pending data transfers will be discarded.
    LMIC_reset();

    // Start job (sending automatically starts OTAA too)
    do_send(&sendjob);
}

void loop() {
    os_runloop_once();
}

[matthijskooijman]

I do not understand your problem completely.

To confirm: are you talking about downlink messages here? You are sending messages to your LMIC device and the payload is increasing in size?

You talk about "51 bytes of payload", but in your screenshot I only see up to 36. Is the problem that you're sending bigger packets, but they are not being received?

Maybe you are running into the maximum payload dictated by LoRaWAN. E.g. for EU868, the RP002-1.0.0 "Regional parameters" document, specifies:

IOW, for DR0-DR2 (SF12-SF10), the maximum payload is simply 51 bytes, no way around that. If you need bigger packets, you must either use a lower SF, or send multiple packets.

Other regions have different limits.

[jfma26]

The image was a sample of how the payload increases every so often and after a while it stops sending data when it reaches 51 bytes and there it stops sending data I'm using US915 OTAA, the problem is that the size of the payload continues to increase. Is there a way to keep the payload static or stable.

[matthijskooijman]

The screenshot shows downlink data, so that is controlled by TTN or your own application on the TTN side of things. LMIC does not influence the dowlink data size at all.

If you are sending constant-sized downlink data, then this might be a bug where the length is somehow not reset to zero, maybe.

[jfma26]

The same data is sent but internally in the Arduino monitor it increases progressively The LMIC.dataLen grows every time it sends data as you saw in the image. Is there a way to reset that value of LMIC.dataLen?. The gateway I have available at the University is Multitech MTCDTIP-LEU1-266A

[matthijskooijman]

Actually, dataLen is already reset for each packet. First, it is set to the TX packet length, then it is reset to 0 for both RX1 and RX2.

Then when an actual packet is received, it is set to the packet length from the radio directly: https://github.com/matthijskooijman/arduino-lmic/blob/54bc51df00de18d7dd236fafac6b48e2597957f1/src/lmic/radio.c#L781-L782

Later it is modified again to chop off the MAC headers and commands and leave just the payload length here: https://github.com/matthijskooijman/arduino-lmic/blob/54bc51df00de18d7dd236fafac6b48e2597957f1/src/lmic/lmic.c#L1039 https://github.com/matthijskooijman/arduino-lmic/blob/54bc51df00de18d7dd236fafac6b48e2597957f1/src/lmic/lmic.c#L1061-L1064 https://github.com/matthijskooijman/arduino-lmic/blob/54bc51df00de18d7dd236fafac6b48e2597957f1/src/lmic/lmic.c#L1331

Are you sure you're not actually sending incrementing messages? What are you using on the server side? TTN? What does the TTN console show for downlink messages?

Maybe you could add some debug prints to dump the value of dataLen early (e.g. in radio.c).

[jfma26]

The Snapshot of the downlink messages is this The payload that the gateway Lora received is this All of this is received in node-red. I used Arduino Uno Lorashield dragino wiht sx1276 The infraestructure of my University is using a gateway without TTN service. I am sure I am not sending incremental packages. This is the data of the monitor of Arduino, I don't know what is wrong 316665: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0 379909: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0 382432: engineUpdate, opmode=0xc 382908: engineUpdate, opmode=0xc 383245: TXMODE, freq=903000000, len=23, SF=8, BW=500, CR=4/5, IH=0 697358: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0 EV_JOINED 698465: engineUpdate, opmode=0x808 698981: TXMODE, freq=904600000, len=26, SF=8, BW=500, CR=4/5, IH=0 763158: RXMODE_SINGLE, freq=923900000, SF=7, BW=500, CR=4/5, IH=0 825682: RXMODE_SINGLE, freq=923300000, SF=8, BW=500, CR=4/5, IH=0 825804: engineUpdate, opmode=0x900 1138303: engineUpdate, opmode=0x908 1138815: TXMODE, freq=906200000, len=26, SF=8, BW=500, CR=4/5, IH=0 1202992: RXMODE_SINGLE, freq=924500000, SF=7, BW=500, CR=4/5, IH=0 1265516: RXMODE_SINGLE, freq=923300000, SF=8, BW=500, CR=4/5, IH=0 1265637: engineUpdate, opmode=0x900 1578138: engineUpdate, opmode=0x908 1578650: TXMODE, freq=907800000, len=26, SF=8, BW=500, CR=4/5, IH=0 1642827: RXMODE_SINGLE, freq=925100000, SF=7, BW=500, CR=4/5, IH=0 1705351: RXMODE_SINGLE, freq=923300000, SF=8, BW=500, CR=4/5, IH=0 1705473: engineUpdate, opmode=0x900 2017973: engineUpdate, opmode=0x908 2018485: TXMODE, freq=909400000, len=26, SF=8, BW=500, CR=4/5, IH=0 2082662: RXMODE_SINGLE, freq=925700000, SF=7, BW=500, CR=4/5, IH=0 2145186: RXMODE_SINGLE, freq=923300000, SF=8, BW=500, CR=4/5, IH=0 2145308: engineUpdate, opmode=0x900 2457808: engineUpdate, opmode=0x908 2458320: TXMODE, freq=911000000, len=26, SF=8, BW=500, CR=4/5, IH=0 2522497: RXMODE_SINGLE, freq=926300000, SF=7, BW=500, CR=4/5, IH=0 2585021: RXMODE_SINGLE, freq=923300000, SF=8, BW=500, CR=4/5, IH=0 2585142: engineUpdate, opmode=0x900 2897643: engineUpdate, opmode=0x908 2898155: TXMODE, freq=912600000, len=26, SF=8, BW=500, CR=4/5, IH=0 2962397: RXMODE_SINGLE, freq=926900000, SF=7, BW=500, CR=4/5, IH=0 3024921: RXMODE_SINGLE, freq=923300000, SF=8, BW=500, CR=4/5, IH=0 3025129: engineUpdate, opmode=0x900 3337631: engineUpdate, opmode=0x908 3338143: TXMODE, freq=914200000, len=26, SF=8, BW=500, CR=4/5, IH=0 3402320: RXMODE_SINGLE, freq=927500000, SF=7, BW=500, CR=4/5, IH=0 3464844: RXMODE_SINGLE, freq=923300000, SF=8, BW=500, CR=4/5, IH=0 3464966: engineUpdate, opmode=0x900 3777466: engineUpdate, opmode=0x908 3777978: TXMODE, freq=903000000, len=26, SF=8, BW=500, CR=4/5, IH=0 3842155: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0 3843563: Received downlink, window=RX1, port=0, ack=0 Received 16 bytes of payload 3843819: engineUpdate, opmode=0x810 3844502: TXMODE, freq=904600000, len=12, SF=8, BW=500, CR=4/5, IH=0 3907815: RXMODE_SINGLE, freq=923900000, SF=7, BW=500, CR=4/5, IH=0 3970339: RXMODE_SINGLE, freq=923300000, SF=8, BW=500, CR=4/5, IH=0 3970462: engineUpdate, opmode=0x900 4282964: engineUpdate, opmode=0x908 4283476: TXMODE, freq=906200000, len=26, SF=8, BW=500, CR=4/5, IH=0 4347652: RXMODE_SINGLE, freq=924500000, SF=7, BW=500, CR=4/5, IH=0 4410177: RXMODE_SINGLE, freq=923300000, SF=8, BW=500, CR=4/5, IH=0 4410298: engineUpdate, opmode=0x900 4722799: engineUpdate, opmode=0x908 4723311: TXMODE, freq=907800000, len=26, SF=8, BW=500, CR=4/5, IH=0 4787553: RXMODE_SINGLE, freq=925100000, SF=7, BW=500, CR=4/5, IH=0 4850077: RXMODE_SINGLE, freq=923300000, SF=8, BW=500, CR=4/5, IH=0 4850199: engineUpdate, opmode=0x900 5162699: engineUpdate, opmode=0x908 5163211: TXMODE, freq=909400000, len=26, SF=8, BW=500, CR=4/5, IH=0 5227389: RXMODE_SINGLE, freq=925700000, SF=7, BW=500, CR=4/5, IH=0 5289913: RXMODE_SINGLE, freq=923300000, SF=8, BW=500, CR=4/5, IH=0 5290035: engineUpdate, opmode=0x900 5602536: engineUpdate, opmode=0x908 5603048: TXMODE, freq=911000000, len=26, SF=8, BW=500, CR=4/5, IH=0 5667289: RXMODE_SINGLE, freq=926300000, SF=7, BW=500, CR=4/5, IH=0 5729813: RXMODE_SINGLE, freq=923300000, SF=8, BW=500, CR=4/5, IH=0 5729934: engineUpdate, opmode=0x900 6042435: engineUpdate, opmode=0x908 6042947: TXMODE, freq=912600000, len=26, SF=8, BW=500, CR=4/5, IH=0 6107124: RXMODE_SINGLE, freq=926900000, SF=7, BW=500, CR=4/5, IH=0 6169648: RXMODE_SINGLE, freq=923300000, SF=8, BW=500, CR=4/5, IH=0 6169769: engineUpdate, opmode=0x900 6482270: engineUpdate, opmode=0x908 6482782: TXMODE, freq=914200000, len=26, SF=8, BW=500, CR=4/5, IH=0 6546960: RXMODE_SINGLE, freq=927500000, SF=7, BW=500, CR=4/5, IH=0 6609484: RXMODE_SINGLE, freq=923300000, SF=8, BW=500, CR=4/5, IH=0 6609692: engineUpdate, opmode=0x900 6922194: engineUpdate, opmode=0x908 6922705: TXMODE, freq=903000000, len=26, SF=8, BW=500, CR=4/5, IH=0 6986883: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0 6988291: Received downlink, window=RX1, port=0, ack=0 Received 16 bytes of payload 6988547: engineUpdate, opmode=0x810 6989230: TXMODE, freq=904600000, len=12, SF=8, BW=500, CR=4/5, IH=0 7052607: RXMODE_SINGLE, freq=923900000, SF=7, BW=500, CR=4/5, IH=0 7115067: RXMODE_SINGLE, freq=923300000, SF=8, BW=500, CR=4/5, IH=0 7115190: engineUpdate, opmode=0x900 7427692: engineUpdate, opmode=0x908 7428204: TXMODE, freq=906200000, len=26, SF=8, BW=500, CR=4/5, IH=0 7492445: RXMODE_SINGLE, freq=924500000, SF=7, BW=500, CR=4/5, IH=0 7554969: RXMODE_SINGLE, freq=923300000, SF=8, BW=500, CR=4/5, IH=0 7555091: engineUpdate, opmode=0x900 7867591: engineUpdate, opmode=0x908 7868103: TXMODE, freq=907800000, len=26, SF=8, BW=500, CR=4/5, IH=0 7932280: RXMODE_SINGLE, freq=925100000, SF=7, BW=500, CR=4/5, IH=0 7994804: RXMODE_SINGLE, freq=923300000, SF=8, BW=500, CR=4/5, IH=0 7994925: engineUpdate, opmode=0x900 8307426: engineUpdate, opmode=0x908 8307938: TXMODE, freq=909400000, len=26, SF=8, BW=500, CR=4/5, IH=0 8372115: RXMODE_SINGLE, freq=925700000, SF=7, BW=500, CR=4/5, IH=0 8434639: RXMODE_SINGLE, freq=923300000, SF=8, BW=500, CR=4/5, IH=0 8434761: engineUpdate, opmode=0x900 8747261: engineUpdate, opmode=0x908 8747773: TXMODE, freq=911000000, len=26, SF=8, BW=500, CR=4/5, IH=0 8811950: RXMODE_SINGLE, freq=926300000, SF=7, BW=500, CR=4/5, IH=0 8874474: RXMODE_SINGLE, freq=923300000, SF=8, BW=500, CR=4/5, IH=0 8874595: engineUpdate, opmode=0x900 9187096: engineUpdate, opmode=0x908 9187608: TXMODE, freq=912600000, len=26, SF=8, BW=500, CR=4/5, IH=0 9251785: RXMODE_SINGLE, freq=926900000, SF=7, BW=500, CR=4/5, IH=0 9314309: RXMODE_SINGLE, freq=923300000, SF=8, BW=500, CR=4/5, IH=0 9314430: engineUpdate, opmode=0x900 9626931: engineUpdate, opmode=0x908 9627443: TXMODE, freq=914200000, len=26, SF=8, BW=500, CR=4/5, IH=0 9691684: RXMODE_SINGLE, freq=927500000, SF=7, BW=500, CR=4/5, IH=0 9754208: RXMODE_SINGLE, freq=923300000, SF=8, BW=500, CR=4/5, IH=0 9754330: engineUpdate, opmode=0x900 10066830: engineUpdate, opmode=0x908 10067343: TXMODE, freq=903000000, len=26, SF=8, BW=500, CR=4/5, IH=0 10131519: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0 10133094: Received downlink, window=RX1, port=0, ack=0 Received 21 bytes of payload

[matthijskooijman]

Maybe try adding:

    lmic_printf("dataLen: %u\n", LMIC.dataLen);

After this line: https://github.com/matthijskooijman/arduino-lmic/blob/54bc51df00de18d7dd236fafac6b48e2597957f1/src/lmic/radio.c#L781-L782

To see if the dataLen is still correct there?

[jfma26]

This is the result after that in the last line you can see that dataLen: 64 And payload pulled out on the Arduino monitor Received 51 bytes of payload In the end, stop sending data.

Starting EV_JOINING dataLen: 17 EV_JOINED dataLen: 29 Received 16 bytes of payload dataLen: 34 Received 21 bytes of payload dataLen: 34 Received 21 bytes of payload dataLen: 34 Received 21 bytes of payload dataLen: 34 Received 21 bytes of payload dataLen: 39 Received 26 bytes of payload dataLen: 39 Received 26 bytes of payload dataLen: 39 Received 26 bytes of payload dataLen: 39 Received 26 bytes of payload dataLen: 44 Received 31 bytes of payload dataLen: 44 Received 31 bytes of payload dataLen: 44 Received 31 bytes of payload dataLen: 44 Received 31 bytes of payload dataLen: 49 Received 36 bytes of payload dataLen: 49 Received 36 bytes of payload dataLen: 49 Received 36 bytes of payload dataLen: 49 Received 36 bytes of payload dataLen: 49 Received 36 bytes of payload dataLen: 54 Received 41 bytes of payload dataLen: 54 Received 41 bytes of payload dataLen: 54 Received 41 bytes of payload dataLen: 54 Received 41 bytes of payload dataLen: 59 Received 46 bytes of payload dataLen: 59 Received 46 bytes of payload dataLen: 59 Received 46 bytes of payload dataLen: 59 Received 46 bytes of payload dataLen: 59 Received 46 bytes of payload dataLen: 64 Received 51 bytes of payload dataLen: 64 Received 51 bytes of payload dataLen: 64 Received 51 bytes of payload dataLen: 64 Received 51 bytes of payload

[matthijskooijman]

Hm, so that shows that the packet length read from the hardware directly already has this incorrect size, so there's not much that LMIC could be doing wrong here (AFAIU, the radio itself resets this value to zero when it starts a new packet).

To be honest, I've not done much testing of downlink data (mostly OTAA only), but it really looks like the packet length sent over the radio is incorrect. If you're not sending longer packets, maybe your server software or gateway software is somehow appending new data rather than replacing it? It seems you have confirme down data, maybe the uplinks do not set the ACK and the gateway resends old data (together with new data) because of that (just guessing here)?

You could also consider trying https://github.com/mcci-catena/arduino-lmic, which is a fork of this repo that has seen some more development, if this is indeed an LMIC bug, maybe they fixed it?

[jorgemino]

Thanks in a few weeks I'll be an Engineer, thanks to your work in the library, and I was able to solve the payload problem. Thank you very much I hope at some point to help in this library. Thank you very much you are a great person

[matthijskooijman]

Cool, thanks for reporting back. Out of curiosity, did you figure out what the problem was in the end?

I'll go ahead and close this, but you can still add more comments.