End of the one channel gateways ?
florafrisia opened this issue · 7 comments
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
Of course dont work :( Its very sad
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
Weather or not is appears to work to even the slightest extent is irrelevant, even trying to connect these to TTN is explicitly prohibited.
It works.
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.
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.
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.