Heltec WIFI Lora v2

Gateways [obsolete] SCPF
1

I have 2 heltec boards, one is configured as a single channel gateway the other is configured as an LMIC-node

The gateway communicates to TTN and the node communicates to the the gateway and messages from the node are visible in the the gateway view on TTN.

However, my end device never registers any data.

I am using channel 8 at 903.9

I am very new to this and this is part of a project for a course I am taking. I have attached screen shots.

Also to note that I am not asking for help with the gateway. The gateway is transmitting packets correctly and I do not have issues with that

Screenshot_20211129-161509_Chrome
Screenshot_20211129-161336_Chrome
Screenshot_20211129-161320_Chrome
Screenshot_20211129-161308_Chrome
Screenshot_20211129-161246_Chrome

2

Which course? Where?

3

IoT University of Connecticut MEng Electrical engineering.

I know I could us an off the shelf gateway but there are more pieces of the project that require me to mod the gateway. Those modifications are the actual deliverables of the project however I can’t move on to those until I get this to work… which from the tutorial I followed I thought was going to be simple.

4

Please let your tutors know that the use of Single Channel Packet Forwarders are not supported on The Things Network due the disruption it causes and we ask you to disconnect it immediately.

The idea of modifying a gateway that is connected to the community network just makes the situation worse.

Your tutors could give you the information to setup your own LoRaWAN server or provide one.

1 Like
5

Please share this link with your professor, as it explains why what you have been assigned to do is not permitted.

No doubt your professors will agree that misuse of online services is not what their university means to teach.

In contrast, the $150-400 purchase cost of a proper LoRaWAN gateway based on a proper LoRaWAN concentrator card, and its placement atop one of the high rise buildings on your campus would be a wonderful resource for both the campus and the Things Network.

1 Like
6

No ubwould not think that misuse if an online service would be in the interests of the university. Nor in my interests.

However, as you describe the community stack does not seem to be in the best interests of the development of a community based system and seems geared to commercialization of the community.

At minimum the community should come together to create a method by which common hardware can be used AND be compliant

Facts you assume that are not in evidence is this is not an on campus project so costs associated with this project directly affect me not the university

My intended additiom to the gateway node is in the interests of expanding the capacity of the node so that doesn’t make the system worse it makes it better.

I have been developing open-source software for decades with contributions to many well known source codes so please do be so condescending.

If I need to spin up a private thing stack I can do that but given that it would be running the same source as the community edition I do not believe that would resolve this issue

7

LoRaWAN node hardware is NOT LoRaWAN gateway hardware, and lacks the required capabilities to fill that role.

This is fundamental to the very idea of LoRaWAN, which depends on the infrastructure role being filled by a multi-channel, multi-SF concentrator card.

Something that used the same hardware on both ends would be a different scheme, with fundamentally different design decisions.

My intended additiom to the gateway node is in the interests of expanding the capacity of the node so that doesn’t make the system worse it makes it better.

This is pure nonsense. Nodes don’t have a capacity, gateways do. And using only a single frequency drastically limits your legal duty cycle allowance, compared to using multiple ones.

If I need to spin up a private thing stack I can do that but given that it would be running the same source as the community edition I do not believe that would resolve this issue

Such an erroneous belief indicates that you do not yet understand the issue.

TTN is a community network. All TTN gateways are for the use of all nodes.

But devices that falsely claim to be gateways, while not actually having the capability to support what gateways are required to, constitute a denial of service attack on the community network, because they mislead other people’s nodes using the recommend ADR optimization to move to a data rate where they cannot reach other proper gateways, but only reach your improper non-gateway. Which it turns out they cannot reach either, because your fake device only supports the original data rate, and not the optimized one.

In contrast, fake non-gateways connected only to a private server instance are for the use of nodes in that private system only. While they still compete for airtime with other users (LoRaWAN and otherwise - the spectrum is hardly reserved for LoRaWAN) they cannot mislead other people’s TTN nodes, the way that a fake non-gateway illicitly connected to TTN’s servers does.

8

I appreciate that it will have been a bit of a surprise to join the forum to meet such a rebuttal. A cursory search using “Heltec Single Channel” would have reduced the surprise that you experienced. Such a search will also show that this is what we say to everyone who asks about SCPF’s.

Not in the slightest - it is used by communities for a wide range of sensing projects like flood & fire warnings plus a whole range of other environmental monitoring and more. It is used by some commercial organisations that do not require an SLA and this is perfectly within the remit of the TTN.

It is NOT an experimental platform for people to try out new techniques on that may impact it.

If you create a TTS OS instance, that’s fine as no other nodes will be affected by your SCPF - it will be a closed system. I’d be happy to help you with that.

9

I have spun up a private instance of thing stack and deleted the gateway interface to TTN and redirected it to my private instance.

I do understand now the reasons why the single channel gateways are not supported on the community system and I did search for certain terms through google trying to get this to work before I came to the forum and requested help. Usually my google FU is good this time it failed me.

I have ordered a full concentrator card to make a full blown gateway that beign said as my deliverable is due in 13 days I cannot wait for its arrival

I also understand the frustration with answering the same question 1000 times so theres that.

All of that being said I still have the same issue on my private stack that I had on TTN.

The stack receives messages from both the gateway and the node but the node messages are never transferred to the end device. Is there a setting that I need to set to make this work

1 Like
10

Thank you for clarifying the issues with Single channel gateways. I have deleted the config from TTN and spun up a private stack. My issue persists but perhaps I can progress from here until I recieve my full blown concentrator card. I cannot however wait until it arrives as I need to continue with my project deliverable for my course.

11

You will need some chickens and a velour black eye mask and some moonshine for the ABP configuration ritual which consists of putting all the frequencies in to the device setup so that the stack can accept uplinks and allow for frame resets.

Or use OTAA, soooooo much easier.

12

LOL, I for reference I tried OTAA with the same results, went back to ABP after that failed

I TRIED to add the frequencies to the device node and failed it gives me a mac.preset frequencies error

I am on US 902-923 and given that this is single channel the specific channel is 903900, FSB2, Channel 0

Happily rebuild again with OTAA if that will make it work better or have more diagnostic info

13 
{
  "name": "gs.up.receive",
  "time": "2021-11-30T16:39:37.570080492Z",
  "identifiers": [
    {
      "gateway_ids": {
        "gateway_id": "4-20lorawangateway",
        "eui": "7C9EBDFFFF5AF52C"
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.UplinkMessage",
    "raw_payload": "QMbmNgGAZwIKZFldJP8t",
    "payload": {
      "m_hdr": {
        "m_type": "UNCONFIRMED_UP"
      },
      "mic": "XST/LQ==",
      "mac_payload": {
        "f_hdr": {
          "dev_addr": "0136E6C6",
          "f_ctrl": {
            "adr": true
          },
          "f_cnt": 615
        },
        "f_port": 10,
        "frm_payload": "ZFk="
      }
    },
    "settings": {
      "data_rate": {
        "lora": {
          "bandwidth": 125000,
          "spreading_factor": 7
        }
      },
      "coding_rate": "4/5",
      "frequency": "903900024",
      "timestamp": 3103175535
    },
    "rx_metadata": [
      {
        "gateway_ids": {
          "gateway_id": "4-20lorawangateway",
          "eui": "7C9EBDFFFF5AF52C"
        },
        "timestamp": 3103175535,
        "rssi": -44,
        "channel_rssi": -44,
        "snr": 9,
        "uplink_token": "CiAKHgoSNC0yMGxvcmF3YW5nYXRld2F5Egh8nr3//1r1LBDv5trHCxoMCMmnmY0GEJ292o8CIJjTs52oWg=="
      }
    ],
    "received_at": "2021-11-30T16:39:37.569810589Z",
    "correlation_ids": [
      "gs:conn:01FNRVDGJSHT04SJ2QAJ82NCHB",
      "gs:uplink:01FNRVEJV2HN97PGVTFN6HAJA9"
    ]
  },
  "correlation_ids": [
    "gs:conn:01FNRVDGJSHT04SJ2QAJ82NCHB",
    "gs:uplink:01FNRVEJV2HN97PGVTFN6HAJA9"
  ],
  "origin": "2b4d6646d16f",
  "visibility": {
    "rights": [
      "RIGHT_GATEWAY_TRAFFIC_READ"
    ]
  },
  "unique_id": "01FNRVEJV26478T2S4XHH9YHTY"

image
image
image

14

Dunno - we don’t do SCPF around these parts so there’s not a huge body of knowledge.

But basically, yes, you need to hack the setup to use the one frequency & DR that the SCPF is set to. The LMIC library, the bit underlying LMIC-node, isn’t so bright that changing all the frequencies to the same one may escape its notice.

15

As already clearly stated by others, SCPF is not supported on The Things Network and its forum