New ESP ABP device do not get to online

End Devices (Nodes) [obsolete] SCPF-related
1

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. They are also ESP based Chips with 1ch gateway library. Both are receiving the Pakets, I see that in the WebGUI, but in the V3 Console by the device section shows nothing.
I have no idea where should I change my settings or my sketch that it goes online.

The keys are irrelevant I can generate a new if I get it work.

I am using ABP and not OTAA because my gateway’s uplink channel is limtied to one. If I write and test my code it is really slow to get the node online, so OTAA is not an option.!

Gateway1 Node1 Node2 Node3 Node4

TTN console uplink message from the gateway:

{
  "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"
}

Can somebody help me?
Thanks

2

I hope this can help.

3

Thanks for you quick answer but I don’t use the deep sleep function. In the gateway message list the counter is increasing. So I guess it is not the problem. If I reset the chip the counter is set to 0 and it will be increased with every message.

4

These are not gateways which can listen on 8 channels, these are what we call Single Channel Packet Forwarders which are non-compliant and disruptive to TTN so please disconnect them immediately.

This disruption is impacting you, the LMIC library will be assuming it has a full 8 channel gateway to talk to, the network server will assume it is talking to an 8 channel gateway, so in all this confusion it is highly likely that your device won’t be able to uplink reliably.

In addition, as the preference is for OTAA, anyone configuring ABP needs to be aware of numerous MAC settings that need to be in place for a library like LMIC to work well.

The link provided by @jmarino was more about the frame counters than deep sleep - if you restart your device it will start from 0. Whilst you have the checkbox set for resets, it only works under certain circumstances.

Please obtain a compliant 8 channel gateway and we’ll be happy to help you with your device - particularly if you search the forum as there are whole topics on getting the ESP32’s working.

I formatted your post as per guidelines, please read them.

6

That is not one of the frequencies used by TTN. V3 is strict and only accepts packets from a node for valid frequencies.

That means you are using hardware that is not TTN compatible and it will not work on V3. Disconnect as soon as possible and replace with a real gateway because now you are causing issues for yourself and other TTN users.

7

These are not gateways which can listen on 8 channels, these are what we call Single Channel Packet Forwarders which are non-compliant and disruptive to TTN so please disconnect them immediately.

In my area there is no gateway. I live in a small village. Unfortunately I am not able to test my code, because of that reason I flash a one channel paket forwarder. In the Engineering phase I limit the channels of the sender to one as well. The forwarder is not online every time, only if I write / test my code. In addition I really good described my gateway in the description section (ESP32 TTGO V1 1ch only uplink 868.1Mhz TTN V2) that everybody can know what kind if gateway is. Sorry,
I didn’t know or think that this solution is so terrible.

8

The size of your village is not relevant, LoRa travels a long way so there could be anyone in a 10 to 15km radius that find your gateway upsets with their devices.

If you search the forum we say this to everyone who asks for help when they have a SCPF, there are no exceptions.

Please disconnect your SCPF and look to investing in a gateway - the PyGate or TTIG are well under $100.

9

Ok, thanks for the help.

10

Can I ask why was the post set to unlisted? I guess many people could learn from my case and make the things better.

11

  1. Your topic was probably unlisted because its title does not reflect the actual issue: SCPF.
    This causes (lures) users to open the topic to read it and only then discover the topic is not relevant, obsolete and the issue was already addressed many times before.

  2. Your topic is the zillionth SCPF related question on the forum.
    Search the forum for existing information first before just posting another question that was already answered.
    Just search for SCPF and you will know why.

12

Exactly what @bluejedi said, plus it potentially alerts people to what they think is a cheap solution but uses up their time, our time and disrupts the network.

And now I lock it so as to draw a line under the situation.