TTN V3

[Samuel-ZDM]

Hello!

Does this end device code work with TTN V3? When I register, which version of LoRaWAN has to be placed?

thanks in advance.

[Samuel-ZDM]

Hello.

I tested using an ESP32 as a gateway, but I was not successful, I don't know if it is the gateway or if the lib can influence the sending of data. Wait the return.

Thank you very much in advance.

[ricaun]

Hello,

Should work with TTN V3, I have some atmega328p as a node and works fine.

The LoRaWan version should be really low, 1.0.2 should work, but the library does not have any Mac capabilities. Just the basic send and receive.

I never test with esp8266/esp32 gateways only with a 8 channels gateways.

Check the frequency and sf values, with one channel gateway need to match both.

[Samuel-ZDM]

Hello. Thanks for your answer.

So the problem must be ESP32. I didn't know what it could be, but if yours is working, it must be ESP32.

Perfect. I don't use MAC commands as I use a lot of memory.

I think the error must be between ESP32 and Network Server, as I'm seeing messages arriving at the gateway with US frequency setting.

I'm going to have to get an 8-channel gateway.

Thanks.

[Samuel-ZDM]

Hello!

I tested it with an 8-channel gateway and uplink is working, only downlink I'm not able to receive. I see that the message is received at the gateway but the message does not arrive at the end-device. The strangest part of this is that I have an OTAA device and the response from the join the end-device receives.

Is the downlink timeout different?

Thank you very much

[ricaun]

Good question, I don't know if the delay1 has changed on v3. The default delay1 on uplink is 1000ms, maybe change to 5000ms like the join delay1.

[Samuel-ZDM]

Exactly. Changed to 5000ms, but still doesn't receive.

I could see it changed because every uplink is sent a downlink, so I see that a downlink message has arrived, but it's not the downlink I'm sent because the package isn't unpacked or anything, it seems the downlink never reaches the end-device.

Thank you again.

[ricaun]

You need to check the frequency, sf and bw is correct. Should be the same as the gateway.

The otaa is working? The device is join the network? Or the device never receive a join accept?

[Samuel-ZDM]

The end-device receives join and manages to send the packages later, only when I try to send downlink it does not receive, even with a time of 5000ms.

Now in TTN V3, every uplink it sends a downlink, I think it's a confirmation of receipt, this message the end-device can also receive.

The problem is in the downlink. Looking at the gateway it is at the correct frequency and SF and BW are also correct.

[ricaun]

That's really strange... If join works the downlink should work too. I don't know what is causing this issue, what version of the LoRaWan are you using ?

[Samuel-ZDM]

I am using LoRaWAN version 1.0.2 with regional parameter REV B. Very strange indeed. Because the join works and the downlink doesn't.

[ricaun]

Hmmm...

What configuration are you using?! On the node?

// ttn US915
static LoRa_config txLoRa = {903900000, 7, 125000, 5, true, false, 0x34, 8};
static LoRa_config rxLoRa = {923300000, 7, 500000, 5, false, true, 0x34, 8};
static LoRa_config rxLoRa2 = {923300000, 12, 500000, 5, false, true, 0x34, 8};

const static int delay_join = 5000;
const static int delay_uplink = 1000;

Share this values!

[Samuel-ZDM]

It is the same.

// ttn US915
static LoRa_config txLoRa = {903900000, 7, 125000, 5, true, false, 0x34, 8};
static LoRa_config rxLoRa = {923300000, 7, 500000, 5, false, true, 0x34, 8};
static LoRa_config rxLoRa2 = {923300000, 12, 500000, 5, false, true, 0x34, 8};

const static int delay_join = 5000;
const static int delay_uplink = 1000;

[Samuel-ZDM]

The underlined message is the downlink, it is just like the others. Looks like unzipping time is coming in some different format, because the end-device can't find the port or the size of the message.

[ricaun]

You need to change the delay_uplink to 5000.

const static int delay_uplink = 5000;

To set the delay_rx1 to 5000 milli seconds.

[ricaun]

The code is with the ttn v2, gonna update if this change works =D

[Samuel-ZDM]

I changed it, it seems that it is not able to unzip the package.

I was doing this test now, it looks like the end-device receives the packet but can't unzip the message, because the port and size are null. In that image it's with 5000ms.

[Samuel-ZDM]

My settings are like this :

TTN V3:

End-device:

static LoRa_config txLoRa = {903900000, 7, 125000, 5, true, false, 0x34, 8};
static LoRa_config rxLoRa = {923300000, 7, 500000, 5, false, true, 0x34, 8};
static LoRa_config rxLoRa2 = {923300000, 12, 500000, 5, false, true, 0x34, 8};

const static int delay_join = 5000;
const static int delay_uplink = 5000;

When the end-device receives downlink:

Send Message!
LoRa_RxMode!
Receive!
Port = Length = Value = 60

[ricaun]

You are receiving something....

Try this:

void onReceive(int packetSize) {
  busy = 0;
  Serial.println("Receive!");
  LoRaWanPacket.clear();
  while (LoRa.available()) {
    LoRaWanPacket.write(LoRa.read());
  }
  int port = LoRaWanPacket.decode();
  int length = LoRaWanPacket.length();

  Serial.print("Port = ");
  Serial.println(port);
  Serial.print("Length = ");
  Serial.println(length );
}

[Samuel-ZDM]

Now it looks like it's receiving but on port 6. I'm putting it on port 1.

Send Message!
LoRa_RxMode!
Receive!
Port = 6
Length = 15
Value = 60

[ricaun]

Probably the server is sending some bytes the library is not expecting... Some MAC stuff probably.

Try to disable everything and set the MAC and PHY to the lower version.

[ricaun]

I was looking in the library and is not expecting any extra configuration bytes on the downlink response.

Could you share some downlinks in the HEX format.

We could use this https://lorawan-packet-decoder-0ta6puiniaut.runkit.sh/ to check format.

[ricaun]

Need to add some Fctr check on the code.

https://lorawan-packet-decoder-0ta6puiniaut.runkit.sh/?data=602B1203268A04000360020071035500FF01BB0D0F3F

[Samuel-ZDM]

I put the LoRaWAN 1.0 version. But the same problem remains.

I'm using a HEX timestamp to update the RTC. The first byte is just an identifier, to know that it is a timestamp, the next bytes are the time: 01 61 1D 82 E0

[ricaun]

Could you try to change the library?

https://github.com/ricaun/LoRaWanPacket/blob/bfe2479c9c74dc310d457631522f4484d3e15932/src/LoRaWanPacket.cpp#L315

To this:

uint8_t mlength = 9 + (buf[5] & 0x0F); // Add FCtrl

[ricaun]

I mean what the gateway is sending, all the data, should be something like this: 602B1203268A04000360020071035500FF01BB0D0F3F

[Samuel-ZDM]

I changed it but it's still on port 6.

The PHY of the gateway: 60B6A40C268B0200060330000071033000FF01027276EA89E4EDDC77

[Samuel-ZDM]

Tomorrow I will study more about it and meet in contact. If you get something and can share, I appreciate it. Thanks for all the help.

[ricaun]

Yeeee I need to change more stuff, tomorrow gonna update de code to fix that.

[ricaun]

I update the code, try to download the main repository and test.

https://github.com/ricaun/LoRaWanPacket/blob/5eb36c999efa77949b01da28aa3a67a87f052cc0/src/LoRaWanPacket.cpp#L314-L325

[Samuel-ZDM]

Thank you very much! It's working perfectly.

I performed some tests. When sending the downlink you have to select "Push to downlink queue (append)" to work correctly. If you put "Replace downlink" queue it doesn't select the correct port.

Thanks for all the help.

[ricaun]

Thank you very much! It's working perfectly.

I performed some tests. When sending the downlink you have to select "Push to downlink queue (append)" to work correctly. If you put "Replace downlink" queue it doesn't select the correct port.

Thanks for all the help.

Interesting, share the Replace downlink payload sensed by the gateway, probably need to add some logic to fix this issue.

[Samuel-ZDM]

Replace downlink queue: 6061BF0C268B0200060330000071033000FF0101B1218E6FCBE66354A1 Push downlink queue (append): 6061BF0C268B1000060330000071033000FF010113915E02C3F4878291

[Samuel-ZDM]

I did some more tests and I could see that sometimes when I send the downlink the end device decodes the port to -1. I don't know why, because at other times the device can decode correctly.

I did tests on both Push to downlink queue (append) and Replace downlink and get the same results.

[Samuel-ZDM]

I've tested various types of configuration on The Things Stack and the error keeps coming up. The end device receives the downlink, but the decoded port is -1. Sometimes the end device can decode correctly.

Got a downlink message from the gateway:

Message type = data
    PHYPayload = 60E72C0C268B0E00060330000071033000FF0102B06B3D6683CE

(PHYPayload = MHDR [1] | MACPayload [..] | MIC [4])
          MHDR = 60
    MACPayload = E72C0C268B0E00060330000071033000FF0102B06B

I don't know what could have changed in the message for this to be happening. Sometimes even the join message is not decoded correctly.

[ricaun]

Hello,

I was testing this weekend and fix some of the problems.

// ttn US915
static LoRa_config txLoRa = {903900000, 7, 125000, 5, true, false, 0x34, 8};
static LoRa_config rxLoRa = {923300000, 7, 500000, 5, false, true, 0x34, 8};
static LoRa_config rxLoRa2 = {923300000, 12, 500000, 5, false, true, 0x34, 8};

//  ttn AU915
  static LoRa_config txLoRa = {916800000, 7, 125000, 5, true, false, 0x34, 8};
  static LoRa_config rxLoRa = {923300000, 7, 500000, 5, false, true, 0x34, 8};
  static LoRa_config rxLoRa2 = {923300000, 12, 500000, 5, false, true, 0x34, 8};

The RX1 need to be changed:

const static int delay_join = 5000;
const static int delay_uplink = 5000;

[Samuel-ZDM]

I'm using LoRaWAN version 1.0.2 so that could be it. I will change these parameters.

Thank you very much!

[ricaun]

I test with all the version and the 1.0.3 works better.