The future of single-channel gateways

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.


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.


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.


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.


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.


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. :slight_smile:

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:


So, do nothing and keep tolerating SCG’s on TTN! :grinning:

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.

The main issue with single channel gateways is people adapting their nodes to use that single channel. This means that frequency is be less available for other use. And while there may not be other TTN gateways within reach of such nodes (which makes people use a SCG to provide coverage) there are other LoRaWAN networks around for which there will be an impact. In my opinion TTN community gateways should not be ‘bad neighbors’ or ‘encourage the nodes’ to become bad neighbors. Keep in mind we are all sharing the precious radio spectrum…

A solution to minimize impact would be to use a frequency (at least in EU868 regions) that does not match any of the three required channels. At the moment most SCGs use one of them because that allows ‘regular’ nodes to use them to join (eventually when a request happens to match the frequency the gateway uses).


Did you notice that in fact currently the KPN nodes are the bad neighbors? They probably stay within limits but by average they do use far more airtime than the average TTN node. And that is even without considering things like those Belkin LoRa devices, in that same precious spectrum.

edit: this does not mean that I believe SCG’s are a particularly good idea. It’s just to put things a bit in perspective.

I did notice that some nodes which seem to be using the KPN network based on device address are using a lot of airtime.

Your message seems to imply ‘if others are behaving badly we are allowed to do the same’. That’s a sentiment I do not feel comfortable with.

Belkins use of the same spectrum will hopefully not be one of the LoRaWAN frequencies.

1 Like

Hi guys! M xmas and happy new year! I have gone through your discussion. I strongly believe that Multiple channels and single channels gateways should co-exist. In urban areas we might need multichannel , in rular areas single channel.

I have seen that practically a single channel can handle 50 nodes…

  • what happens in a real situation (within an urban environment) when a 8 channel Lora gateway needs to handle 500-800 devices?
  • what happens in case this MULTI channel gateway dies? what about redundancy?
  • What happens with interference provided that 500 -800 devices might co-exist and talk in the same area with the same gateway?

I think that

  • we can have single channel in TTN (for sure they should have some limitations) + mark them
  • Single channel gateways are cheaper and you might have more GATEwAYS to cover the same area but at the same time you increase redundacy (you loose 50 instead of 500 nodes)
  • Reliability? maintenance? Power requirements?

If we cover a city (many services in a smart city) we might theoritically need one 8 channel gateway… but if this one goes down… Houston we have a problem (this might be caused… by hackers… or anything else)

On the other hand we might have a redundacy system…

I quess its not just black and white… or is it?

the future are cheap multichannel gateways with build in BlueTooth imho.

as said many many times before… ss gateways are a great way to learn and experiment, but now the prices for real gateways have come down from 1000 to 100 dollar, the price is no longer an argument for a serious user/company.

* a special single channel ‘lane’ ? I would not 'ban them on the network

1 Like

agree 100%, as someone who played with single channel gateways it was fine for a bit but in reality very limiting, with the price drops we now have its a no brainer to get a full gateway setup as they are so cheap - the big benefit of getting a real gateway setup is asking people to not just think about their own nodes but to help serve the wider TTN community, whereas single channels gateways are driven by in individuals needs