search

things4u / ESP-1ch-Gateway

Version 6 of the single channel gateway
MIT License
358 stars 143 forks source link

Fixed! New ESP ABP device do not get to online over 1ch esp gateway #86

Closed orimate closed 2 years ago

orimate commented 2 years ago

Hello,

I have an ESP based TTGO oled device in the V2 console, it works just fine. Before the migrate to V3 I wanted to try with another Chip as a new device in the V3. I registered a new APB device in the V3, I changed the NWSKEY, APPSKEY and DEVADDR and I uploaded the sketch (LMIC). I have a gateway in the V2 and another one in the V3. Both are receiving the Packets, I see that in the WebGUI, but in the V3 Console by the device section shows nothing. I wrote a post in the Things network forum.  I was informed that the packet broker drops the messages because in the message by frequency the variable is "868099975" and not exactly "868100000" and the new Stack V3 is really sensitive to that. 

Gateway1 Node1 Node2 Node3 Node4

Here is my message from the V3 gateway log:

{
  "name": "gs.up.receive",
  "time": "2021-07-18T11:56:30.600686327Z",
  "identifiers": [
    {
      "gateway_ids": {
        "gateway_id": "xxx-gateway-001" <==  of coruse it is not mine
      }
    },
    {
      "gateway_ids": {
        "gateway_id": "xxx-gateway-001", <==  of coruse it is not mine
        "eui": "MYEUI in HEX"
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.UplinkMessage",
    "raw_payload": "QPctCyYAawAB0SS6I3oXlNoXo1vw6puGwvXKEzb+QttBU+c=",
    "payload": {
      "m_hdr": {
        "m_type": "UNCONFIRMED_UP"
      },
      "mic": "20FT5w==",
      "mac_payload": {
        "f_hdr": {
          "dev_addr": "260B2DF7",
          "f_ctrl": {},
          "f_cnt": 107
        },
        "f_port": 1,
        "frm_payload": "0SS6I3oXlNoXo1vw6puGwvXKEzb+Qg=="
      }
    },
    "settings": {
      "data_rate": {
        "lora": {
          "bandwidth": 125000,
          "spreading_factor": 7
        }
      },
      "coding_rate": "4/5",
      "frequency": "868099975",  //<---------------------------------------------------------
      "timestamp": 1112970797
    },
    "rx_metadata": [
      {
        "gateway_ids": {
          "gateway_id": "xxx-gateway-001",
          "eui": "MYEUI in HEX"
        },
        "timestamp": 1112970797,
        "rssi": -43,
        "channel_rssi": -43,
        "snr": 9,
        "uplink_token": "CiEKHwoTb3JpbWF0ZS1nYXRld2F5LTAwMhIIfJ69///wrPgQrazakgQaDAjurdCHBhDUiq+eAiDIv+qRsp0B"
      }
    ],
    "received_at": "2021-07-18T11:56:30.600556884Z",
    "correlation_ids": [
      "gs:conn:01FAWJES6Y57CC16WN58X2A8FJ",
      "gs:uplink:01FAWQK508Z8WTB4WWXVYZ1TY9"
    ]
  },
  "correlation_ids": [
    "gs:conn:01FAWJES6Y57CC16WN58X2A8FJ",
    "gs:uplink:01FAWQK508Z8WTB4WWXVYZ1TY9"
  ],
  "origin": "ip-10-100-12-248.eu-west-1.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_GATEWAY_TRAFFIC_READ",
      "RIGHT_GATEWAY_TRAFFIC_READ"
    ]
  },
  "unique_id": "01FAWQK50809VJ2Z1X9R87Q60N"
}

I made an experiment and I traveled to a dedicated gateway and I activated my ESP V3 device. I saw the message in my V3 consol by device. This means the client should OK,

Here is the message from the console: As I suspected the frequency is exactly "8681000000".

{
  "name": "as.up.data.forward",
  "time": "2021-07-19T15:22:06.638496062Z",
  "identifiers": [
    {
      "device_ids": {
        "device_id": "xy-my-device",
        "application_ids": {
          "application_id": "my-app"
        }
      }
    },
    {
      "device_ids": {
        "device_id": "xy-my-device",
        "application_ids": {
          "application_id": "my-app"
        },
        "dev_eui": "0000000000000001",
        "dev_addr": "MYADRINHEX"
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.ApplicationUp",
    "end_device_ids": {
      "device_id": "xy-my-device",
      "application_ids": {
        "application_id": "my-app"
      },
      "dev_eui": "0000000000000001",
      "dev_addr": "MYADRINHEX"
    },
    "correlation_ids": [
      "as:up:01FAZNRAX6M3QGSH7ZW6V54FKF",
      "ns:uplink:01FAZNRAPQ3R0JQFZQ1TN77VHM",
      "pba:conn:up:01FAXHCV1AXAQ9NHMJHYJ6ZW4K",
      "pba:uplink:01FAZNRAPJW6TDV4N7NRRQNAYR",
      "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01FAZNRAPP15RYCY8XHC1ANV8H",
      "rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01FAZNRAX6DY300XKJ8SP2FHCB"
    ],
    "received_at": "2021-07-19T15:22:06.631326075Z",
    "uplink_message": {
      "f_port": 1,
      "f_cnt": 84,
      "frm_payload": "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==",
      "rx_metadata": [
        {
          "gateway_ids": {
            "gateway_id": "packetbroker"
          },
          "packet_broker": {
            "message_id": "01FAZNRAPJW6TDV4N7NRRQNAYR",
            "forwarder_net_id": "000013",
            "forwarder_tenant_id": "ttnv2",
            "forwarder_cluster_id": "ttn-v2-eu-4",
            "forwarder_gateway_eui": "7276FF000B03205F",
            "forwarder_gateway_id": "eui-7276ff000b03205f",
            "home_network_net_id": "000013",
            "home_network_tenant_id": "ttn",
            "home_network_cluster_id": "ttn-eu1"
          },
          "rssi": -121,
          "channel_rssi": -121,
          "snr": -6.5,
          "uplink_token": "eyJnIjoiWlhsS2FHSkhZMmxQYVVwQ1RWUkpORkl3VGs1VE1XTnBURU5LYkdKdFRXbFBhVXBDVFZSSk5GSXdUazVKYVhkcFlWaFphVTlwU2tKaE1VNUtVV3hvUzFOWWFFWmFSV2Q2V0ROU01rbHBkMmxrUjBadVNXcHZhV1JZU1RKVU1WcGFWRWRqTVdJd2JFOWxWRlozWWtVMVNHRnNUbTlrZVVvNUxtNTVRbTh3TVRReVkzaFFUekYzY0hSR05WOXhObmN1WDB4R09YSjJiM0l0UmpGNFNVTldSaTR6YjBWUVZ6VTVUakpHU210R2RHMWpTVEIxYkdSRWRYVnpZMDFSUzNveFVqSnZibk5GTjFScmFHWkJOWEpQT1haaVF6bDNWMGg2Y0hwbmJsaHRaazVDVFVSNExUTjZUVlZ6TFV3MWVIazVOV2xzWW1wcU4wZFlSRUp6Y1VsR1MwVnJZbk5vY0hWSU1tcGtTRTExYTBSU01WUjJSRmd6UkVRdFZXeDZRVUpSTW5KbVVVUnFjMkZuWkdwMGFFWmlNVVpmVm5ORGNVMW1WRmRwVmtOQ1lYUkRhV0ZZTkdsWmVrdG5TVEJxYm1GbkxuSjVaR054TkU4elZsbEZhek5FYmw5ZlJraDNjbEU9IiwiYSI6eyJmbmlkIjoiMDAwMDEzIiwiZnRpZCI6InR0bnYyIiwiZmNpZCI6InR0bi12Mi1ldS00In19"
        }
      ],
      "settings": {
        "data_rate": {
          "lora": {
            "bandwidth": 125000,
            "spreading_factor": 7
          }
        },
        "data_rate_index": 5,
        "coding_rate": "4/5",
        "frequency": "868100000"  //<---------------------------------------------------------
      },
      "received_at": "2021-07-19T15:22:06.423083979Z",
      "consumed_airtime": "0.077056s"
    }
  },
  "correlation_ids": [
    "as:up:01FAZNRAX6M3QGSH7ZW6V54FKF",
    "ns:uplink:01FAZNRAPQ3R0JQFZQ1TN77VHM",
    "pba:conn:up:01FAXHCV1AXAQ9NHMJHYJ6ZW4K",
    "pba:uplink:01FAZNRAPJW6TDV4N7NRRQNAYR",
    "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01FAZNRAPP15RYCY8XHC1ANV8H",
    "rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01FAZNRAX6DY300XKJ8SP2FHCB"
  ],
  "origin": "ip-10-100-6-106.eu-west-1.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_APPLICATION_TRAFFIC_READ",
      "RIGHT_APPLICATION_TRAFFIC_READ"
    ]
  },
  "unique_id": "01FAZNRAXEPK10XE9W14E08W73"
}

So let me summarize:

in the V2 registered ABP device with 1ch gateway in the V2 is OK. in the V2 registered ABP device with 1ch gateway in the V3 is not OK. (Of course not, V3 gateway is not forwarded to the V2) in the V3 registered ABP device with 1ch gateway in the V2 is not OK. in the V3 registered ABP device with 1ch gateway in the V3 is not OK.

I read about from this problem OTAA device also can not come to online. Could you please help? Thanks.

shybzzz commented 2 years ago

subscribing to this - it looks like I have the similar issue

I cannot see any messages neither ABP nor OTAA on ttn v3. but I can see all of them in gateway console.

bv73 commented 2 years ago

After I got the version 6.2.8 and registered the gate in the Things Stack, I got the same problem. If it were possible to align the frequency "868099975" to "868100000", then I think it could solve the problem. And, yes, my OTAA device can not come to online too. Now my three ABP devices are working through the old V2. One gateway is still working (868.1), the other two (868.3 and 868.5) had to be disabled because they still do not work as expected.

shybzzz commented 2 years ago

I've managed to find the frequency fix here: #72 . the changes are quite straightforward but they did not merge them for some reason. it looks like rounding issue with floats - they calculate frequency value.

but I've applied the fix and it looks like to be not the only issue.

still I cannot see any data on My End Device (ABP, eu1.cloud.thethings.network) and I can see that frequency is 868100000 in Live Data of the Gateway

orimate commented 2 years ago

I've managed to find the frequency fix here: #72 . the changes are quite straightforward but they did not merge them for some reason. it looks like rounding issue with floats - they calculate frequency value.

but I've applied the fix and it looks like to be not the only issue.

still I cannot see any data on My End Device (ABP, eu1.cloud.thethings.network) and I can see that frequency is 868100000 in Live Data of the Gateway

Thanks for your informations. I don't use my device anymore. (not because of that reason) So I stay tuned, I would like to know what is the solution.

bv73 commented 2 years ago

Thanks to @shybzzz for the link and @pimente for the fix! I tried to fix like here https://github.com/things4u/ESP-1ch-Gateway/pull/72#issuecomment-882547958 (file _txRx.ino) and that works for me too. I can see and manage all data for ABP devices. pro-mini1

But for an OTAA device, the join request does not work.

orimate commented 2 years ago

Thanks to @shybzzz for the link and @pimente for the fix! I tried to fix like here #72 (comment) (file _txRx.ino) and that works for me too. I can see and manage all data for ABP devices. pro-mini1

But for an OTAA device, the join request does not work.

Hello,

I can confirm it works with ABP. I downloaded the fixed library from @itsygithub link , I changed in the configGway.h file the server to this <define _TTNSERVER "eu1.cloud.thethings.network">, and my APB device is online right now.

@VladimirBakum with OTAA device ist not so easy. The gateway has only one channel and you get the configs (downlink paramters and upload frequencys) from the server. But your gateway not listening the dowlink channel. It means your node tries to send on all frequency. The first problem your gateway is listening on only one of 9 (in Europe) your Packets 8 of 9 are going lost, and you never get the downlink.

"Strict LoRa behaviour In order to have the gateway send downlink messages on the pre-set spreading factor and on the default frequency, you have to set the _STRICT_1CH parameter to 1. Note that when it is not set to 1, the gateway will respond to downlink requests with the frequency and spreading factor set by the backend server. And at the moment TTN responds to downlink messages for SF9-SF12 in the RX2 timeslot and with frequency 869.525MHz and on SF12 (according to the LoRa standard when sending in the RX2 timeslot).

define _STRICT_1CH 0

You are advised not to change the default setting of this parameter."

You can more read in the _txRx.ino file in section:

"// _STRICT_1CH determines how we will react on downstream messages. // // If _STRICT==1, we will...."

I hope I didn't write a big nonsens maybe the other guys can clarifiy this.

I am using ABP and in the end of setup() I disable the channel what I can not listen with my gateway.

void setup() {
.
.
.
.
.
Serial.print("Disabled Channels: ");
for (int i = 1; i <= 8; i++ ) { //disable channels from 1 to 8
    LMIC_disableChannel(i);
    Serial.print(i);
    Serial.print(", ");
}
Serial.println();
// Start job
do_send(&sendjob);
} //end of setup()

Thank you for your help!