FW 1.3.0 (1.3.1?) only sends empty messages

[javafrog]

After updating the library and the FW accordingly, the receiving side (TTN) only gets empty messages. This is true for confirmed and for unconfirmed messages. OTAA join works, though.

I was using the old FW and MKRWAN1 before and the same code did work. I even have a serial debug output which clearly shows that the message is not actually empty:

Sending: d=8190,v=1.31,w=B - 64 3D 38 31 39 30 2C 76 3D 31 2E 33 31 2C 77 3D 42

This is the relevant code:

{
    Serial.println();
    Serial.print("Sending: " + messageStr + " - ");

    for (unsigned int i = 0; i < messageStr.length(); i++)
    {
        Serial.print(messageStr[i] >> 4, HEX);
        Serial.print(messageStr[i] & 0xF, HEX);
        Serial.print(" ");
    }
    Serial.println();

    int err;
    modem.beginPacket();
    modem.print(messageStr);
    err = modem.endPacket(false); // do not request packet confirmation

    if (err > 0)
    {
        Serial.println("Message sent!");
    }
    else
    {
        Serial.println("Error sending message :(");
        Serial.println("(you may send a limited amount of messages per minute, depending on the signal strength");
        Serial.println("it may vary from 1 message every couple of seconds to 1 message every minute)");
    }
}```

[aalbinati]

Hi, what band are you using? I think this might be related with this bug.
Whenever I use AU_915_TTN the join is done correctly but then the uplink packets have some error in the packet format.

[javafrog]

Thanks for your reply! I'm using the EU868 band.

[fe64970103]

I can confirm the same.

modem.write(buffer, 2) return 2 as it stores the two bytes in its internal buffer.

modem.endPacket(false) produces the following debug output while returning 2 (success, 2 bytes were sent)

22:11:48.873 -> ### AT: +CFM= 0
22:11:48.906 -> ### AT: +SENDB= 0 : 2d01

On the application server side the payload is empty. It was working fine with MKRWAN_v1. I'm using EU868 band.

[fe64970103]

Hi, any news or workaround about this?

[fe64970103]

I think I found the issue.

When you call endPacket(), modemSend() is called in turn. This one actually composes the binary frame sent to the STM32 inside the lora module. At some point sendAT() is called with:

sendAT(GF("+SENDB="),"0",":",msg_buf);

By debugging the module firmware I've discovered that 0 stands for "fPort" in LORA terminology and 0 is reserved for LoRa mac messages. Anything data related should not use 0 (https://lora-developers.semtech.com/library/tech-papers-and-guides/the-book/the-port-field/).

Changing the line to does it for me:

sendAT(GF("+SENDB="),"1",":",msg_buf);

EDIT: This has apparently already fixed in the master branch. By using the setPort() class function.

Hope that helps.

[per1234]

Thanks @javafrog and @fe64970103. If I understand correctly, we can consider this partially fixed by:

• The addition of LoRaModem::setPort (68e5509).
• The demonstration of its use in the "FirstConfiguration" example (648dff3).

Is the problem fixed by adding a call like modem.setPort(3); to your sketch @javafrog?

It seems there may be some remaining work to be done though:

• Addition of a LoRaModem::setPort to the "LoraSendAndReceive" example
• Documentation of LoRaModem::setPort in the library reference (it seems the current approach is to reuse the "MKRWAN" library's reference, the source of which is here)
• Use a non-zero default value for the LoRaModem::portToJoin member variable?

Do you agree?

[javafrog]

Thanks for the follow-up. Using modem.setPort(3) does indeed do the trick and I get data on the receiving end again.
Still, I couldn't find any information on why exactly this is necessary and what it actually does?

[fe64970103]

Check my post above and the link to the description of the port field.