Not officially supportes basically means that you can’t complain when it’s not fully working. However, our backend can handle traffic from single channel gateways just fine. How well it works depends mostly on the forwarder that you’re running
I think, setting a different icon is a clear sign what gateway is in use. Also if there are three channels a full gateway is listening to join requests, three single channel gw’s could negotiate these frequencies if the gw’s are really near to each other.
If the join channels are documented on the map, the next gw provider could look and choose the best frequency. Can this be done?
I personally would not start that LoRa experiment, If I had to buy a full blown gw. Using my LoPy’s otoh is a great start.
3 Likes
Single-Channel gateways are fine for experimenting/developing, but not for production.
2 Likes
What is the level of “unofficial” support for single channel gateways? Are they displayed on the map?
I have a single channel gateway up and running but disapeared from the TTN map and it is not listed under my community…the same gateway is visible on TTNMapper.
How often is the TTN map refreshed?
1 Like
Ditto, even more odd is I can see other single channel gateways on the TTN map… but not mine
The Things Network is a non-commercial initiative and in most places of the world there currently is no TTN gateway coverage whatsoever.
Therefore success of The Things Network greatly depends on enthusiasts. Enthusiasts of who most don’t have the money to buy their own gateway (or are not willing to spend hundreds of dollars to it). Without gateway coverage it is impossible to experiment with nodes which results in much less enthusiasm and less growth of the platform.
A parallel with this is people who are interested in (experimenting with) driving a car and owning their own car. Most of them are interested solely in driving and going to places, but not in having to build their own roads before they can drive the car at all. (Mind you, there is no such thing as 4WD off-the-road TTN nodes that can function without any gateway.)
I understand that from several perspectives single channel ‘gateways’ are not ideal (at all) but I think that single channel gateways will be inevitable. Use of LoRaWAN technology is growing and for non-commercial use many people who don’t have existing gateway coverage will start experimenting with the technology using single channel gateways.
Therefore it would be good to not just condemn single channel gateways, but find a good solution to let them coexist and support them (in some way) and provide good guidance.
[update]
Above post is outdated.
See: Single Channel Packet Forwarders are deprecated and NOT Supported [guidelines]
5 Likes
That is why I proposed the dedicated single-channel frequency plan (all the way at the top)
To jump into your car-analogy, I think it’s good to realize that in LoRaWAN-world, a single-channel gateway looks like this:
You indeed get the feeling that you’re learning to drive, but your technique will be completely different.
Sure, we can build a dedicated road network for these half-cars, because you wouldn’t want these things driving on the highway next to all those expensive cars, and damaging the road.
Also, when the drivers switch to an expensive car they will have to learn how to drive all over again, because the rules are completely different now.
5 Likes
To me it sounds like you want to force everybody to buy this hopeless overpriced car:
But since 99% of the people have nothing at all (check the map) they would be happy with this one:
I am sure a solution could be found to integrate single channel gateways into the network so that everything runs smooth. But this probably needs some extensions to the protocol.
If TTN doesn’t do it maybe somebody else will. Having two competing networks will definitely not lead to less busy channels.
4 Likes
With the introduction of RAK831 you can build fully compliant gateways for about €125. That should be well within the budget of everyone who wants to experiment with LoRaWAN on a at least more than an extremely basic level.
I understand that a a large part of the makerspace will always be looking for ‘zero budget’ solutions, but when talking about long range networks you also have to think about the other users you share the same spectrum with. In a way you are forcing your decision for a low budget but non-compliant solution on them. It is indeed like @htdvisser’s analogy: you’re driving on the same road like everyone else, so your car should at least be compliant with the global minimal requirements.
7 Likes
It is not such a stretch to assume that once there are more gateways the single channel ones will simply die off. After all, why would you build one? To be connected.
Once that problem has been solved the tinkerers will probably repurpose their hardware into a node anyway. I know I will.
3 Likes
I politely disagree. Until multi-channel gateways come down in price, SCG’s are a realistic option for consumer solutions. Belkin (and some crowdsourcing projects) are developing SCG Lora gateways that are suitable for consumer solutions. In many instances, the consumer isn’t aware it’s LoRa. The Belkin devices pushed in France, plug directly into the mains and look like a network extender.
I would like to see SCG’s supported by TTN as it provides an affordable way to deliver LoRa solutions in the home.
With regards to the issue of it being single channel, one solution is to code the end-nodes firmware so that it’s mode-of-operation is to switch to a default SCG channel more frequently as part of the channel rotation. I.e. faster joins.
Don’t get me wrong. I would prefer to see quality MCGs deployed across the UK, but right now, it’s entirely possible to ship a LG01 and room multi-sensor for less than £100, SCG’s deliver affordable solutions.
2 Likes
so its only the price ? (time is on your side) not the quality of the network ? … now I politely disagree and off course someone can always start building a single channel network
1 Like
Probably all fine when connected to the Belkin infrastructure. But not when connected to TTN, as:
one solution is to code the end-nodes firmware
…is not possible when nodes don’t know/expect your TTN-connected gateway to be a single channel gateway.
In many instances, the consumer isn’t aware it’s LoRa.
The Belkin things are probably not even LoRaWAN, but just LoRa with some custom protocol.
3 Likes
Yes, No, No.
I’m suggesting that if TTN supports SCG, then it provides a more affordable route to market for consumer electronics. The price of the end-points doesn’t go down, but it does mean the manufacturer can ship consumer-friendly SCG’s to users who are outside the existing multi-channel gateways.
Agreed. Belkin aren’t LoRaWAN because they’re single channel.
Opinion: If I create an end-point that allows me to set a single-channel that is used more frequently during channel search, is there a downside if used for consumer solutions such as home monitoring, temp sensors, e.t.c?
I think that you are viewing this too much from a DIY engineering perspective, while you should consider the whole commercial picture. One gateway can and will (if the LoRaWAN ecosystem ever wants to be sustainable) serve hundreds to thousands of nodes. €100 more for a compliant gateway doesn’t matter any more in this scenario. If a manufacturer ships SCG and just gets a few more service requests about why OTAA doesn’t work with their product, the price advantage of the SCG is already gone.
I think TTN should be about scalability and community value, and frankly I don’t see SGC fitting in any of those categories. I also think that the issue will eventually solve itself, now more and more affordable compliant gateways are arriving. Therefore I think TTN development shouldn’t spend its scarce resources on this subject any longer.
From the commercial perspective, I understand and agree your position. Nicely put. 
If you look in detail to the effects that single channel gateways have in the real world there are, in my opinion, no drawbacks in tolerating them on TTN.
See my post on April 13th:
2 Likes
So, do nothing and keep tolerating SCG’s on TTN! 
1 Like
Perhaps we should simply drop the name ‘gateway’ in SCG and register them as ‘repeaters’ or something like that. I think in the current situation there are suitable use case especially with fixed sf/frequency.
But on the longer term I believe they won’t compete with real gateways but rather with stuff like BLE. I believe I saw BLE in the TTN roadmap some time ago… shouldn’t we perhaps once BLE support is there present some kind of BLE-only reference gateway model to close the gap currently filled with SCG’s?
My personal preference is that TTN recognise that SCG’s are being connected to the community network, and integrate a flag into the Gateway Settings / Information so that we can identify them as such. This information should ideally be available via the API, so that developers are able to recognise and handle data coming from SCG’s.
I’m guessing SCG’s will exist for at least 12-18 months until there’s wider LoRaWAN coverage, and after that SCG’s will still be connected to TTN as legacy devices. I’d prefer to see them acknowledged, even if not officially supported.