There are people working on satellite LoRaWAN to solve the gateway issue. In the mean time the standard is as it is and it requires receiving multiple frequencies at multiple spreading factors. Any changes are to be discussed with the LoRa Alliance, they maintain the standard, we (the TTN community) don’t.
Until the LoRa Alliance changes the standard any non compliant closed or open source solutions will disrupt and harm the network. You might view it differently but people investing a lot of their own money to support the community network would like to minimize disruptions and issues.
You can experiment without any issues with a local LoRaWAN network for which you could run all components on your RPi. Set it to private (a setting in the packet forwarder) and you won’t be bothering anyone.
There are people working on satellite LoRaWAN to solve the gateway issue.
nice to know that.
Any changes are to be discussed with the LoRa Alliance, they maintain the standard, we (the TTN community) don’t.
I know that. and i’m still readying their (LoRa Alliance) documentation about LoRaWAN 1.1 specification (beside few information about the 1.0.x) and from what i notice the gateway itself doesn’t perform any kind of calculation (i guess except for the signal strength, i’m not sure about that). it’s just a forwarder, take a message from end-device and send it to a network server. the thing about have a good GW is to support the whole LoRa network, your, mine and other people nodes. which is a good thing to not think only about yourself. but if we are talking about selfish, bad and cheap users that doesn’t care about others, they can install any cheap GW and infect the whole system, and they will do the codeing from scratch because LoRaWAN is a standard (a guide) to how you should implement the communication system between nodes. and they are no block in the network packet where you specify or tell the system how many frequency, SF etc…, your GW can support, i notice that all the configurations and data in packet are about the network server or the end-device. that’s why i say it’s possible and no one can control it, the only thing TTN did is hiding all single channel from their map but in real life they are exist. it’s bad thing for the network itself if they keep running all the time and surpass the fact that they where just for testing for a duration of minutes (less then hour). and as you said:
You can experiment without any issues with a local LoRaWAN network for which you could run all components on your RPi. Set it to private (a setting in the packet forwarder) and you won’t be bothering anyone.
which is not a harmful act for the network itself. people need to be responsible and know the consequences of their action, it’s sad think that we can’t block a bad GW and baned from the network. this is the work and we need to find a away to make it better. like the satellite idea they are working on. let’s hope the best for the best.
Private vs public in this context relates to the message/payload preamble in the pf per LoRaWAN spec not the tick box on the ttn console. That just shows details on the map otherwise if set to private vs made public will show as unknown. If you do put a scpf on the net be open about it…make it public so people can see to be aware, put fact it is single channel in description so people finding problems can try to avoid, show its location on the map so we know where it is to help avoid/mitigate and put up you name (user ID) so we or ttn core team can easily identify and contact if it causes significant problems and disruption
No, probably because the regional settings mandate which frequencies a LoRaWAN device must support. So not supporting some of them is not an option.
And as @Jeff-UK mentioned, the private setting is not related to TTN, I specifically suggested to use your own server and set your network to private in the packet forwarder configuration.
