Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

End of the one channel gateways ? #94

Open
florafrisia opened this issue Aug 20, 2021 · 7 comments
Open

End of the one channel gateways ? #94

florafrisia opened this issue Aug 20, 2021 · 7 comments

Comments

@florafrisia
Copy link

Hi,

I'm searching for the solution why my gateway is not working.
I came across this article from the things industries
https://www.thethingsnetwork.org/forum/t/single-channel-packet-forwarders-scpf-are-deprecated-and-not-supported/31117

Can someone elaborate a little more about this matter that scpf are not supported anymore.

With kind regards,

Peter

@RCB07
Copy link

RCB07 commented Aug 20, 2021

Of course dont work :( Its very sad

@shybzzz
Copy link

shybzzz commented Aug 30, 2021

I can see this article is of 2019, and it worked somehow till 2021 :)

but current version of master branch of this repository does not work form me with ttn v3

@cstratton
Copy link

Weather or not is appears to work to even the slightest extent is irrelevant, even trying to connect these to TTN is explicitly prohibited.

@platenspeler
Copy link
Contributor

It works.

@cstratton
Copy link

It works.

Only in the view of those who aren't really trying to use LoRaWAN on a real LoRaWAN network, and hence ignore the problems which a gateway only present for one frequency and spreading factor combination causes to the ADR algorithm on other people's nodes that expect a LoRaWAN network to actually implement LoRaWAN.

If you want to use this, it will need to be on a private network. It is banned on TTN, because no, in fact it not only does not work properly on TTN, but fails in a fashion detrimental to others even as it may appear to sort of work to the person who installs it for their own more limited test without awareness of what it is doing to others.

@JamesOlvertone
Copy link

JamesOlvertone commented Dec 8, 2021

I am not 100% in the LoRaWAN spec but would it be possible to mimic to TTN-Server 100% compliant Nodes while in the backend sensor nodes could be anything, even raw Lora or anything else as long as you have the right receivermodule for it. I mean the whole back and forth communication from TTN through the gateway to the node should end in the gateway. If TTN sends some requests to the sensor the gateway should send the data TTN expects. The gateway manages my local nodes with keys, IDs, Join and anything else what TTN uses. This is mapped to my local sensors that can be anything.

@cstratton
Copy link

cstratton commented Dec 23, 2021

would it be possible to mimic to TTN-Server 100% compliant Nodes while in the backend sensor nodes could be anything

Possibility would be irrelevant - doing so is a violation of TTN's terms of use.

TTN is a public LoRaWAN network, if you want to do something that is not LoRaWAN, you have to run your own servers to handle your unique traffic. The public server instances exist only to support proper LoRaWAN traffic from the user community arriving from actual shared gateways that are there for the use of the community as a whole.

Their donated to the community backhaul and processing power are not for other types of traffic, no matter if it impersonates LoraWAN traffic or not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants