Ok, a single channel gateway is not compliant to the LoRaWAN standard.
The lack of having full compliant gateways has stood in the way of deploying them for a long time.
Also TTN not delivering their gateways encouraged the development of the SCG for those who invested in the kickstarter. To a certain extend TTN contributed to the existance of so many SCG and helped to created the “issue” that is topic of this thread. .
In my opinion SCG have a purpose and they satisfy the need for a simple solution that is cost effective. The nature of SCG fits the pioneering attitude of TTN particpants. Therefore rejecting SCG it not an option in my opinion.
I do acknowledge that having SCG that are non compliant in a compliant network is undesirable.
A workaround could be to have a separate (extra) channel, as suggested, for non complaint end devices and SCG that only operate one frequency. I do not see a solution (yet) for seamless integration of SCG in the existing channel plan.
With respect to the suggested options:
Adding downlink to SCG is simple. RX1 window is implemeted many times. RX2 seems not. (I have not investigated all SCG versions.
Having a separate channelplan for SCG seems feaseable as long as seamless integration with the compliant part of the network is not the objective.
I think these suggestions allow small deployments of nodes and gateways in micro or nano cell level. It will contribute to the handoff of traffic of the “big” network.
In my opinion a ecosystem like the LoRaWAN deriviation for SCG micro and nano networks can coexist besides the LoRaWAN compliant network while sharing the same back-end infrastructure. A win-win?
When you can see the RF transmission, you can see your gateways and nodes communicating. You can pair this up with the logs, and without studying the code, confirm your radio is working, and confirm what frequencies you are using. It’s about transparency, confirmation, and understanding. You can see an OTAA join.
The argument seems to be that the network is too important to be damaged by single channel gateways that monopolise a frequency.
Well, until I made the Software Defined Radio and monitored Sub Band 1 & 2 for 24 hours I had no idea if my single channel gateway was creating issues or not, whether it was damaging the network.
I confirmed that over 24 hours, there was Zero observable lora traffic on sub bands 1 & 2 in my small regional city. This is using a roof mounted antenna. I conclude that locking a single channel gateway to a frequency won’t create network issues now or in the near future where I am. Rather, having a gateway that doesn’t have the metadata on what channels it works on and whether it supports OTAA and verified uplink & downlink is IMHO creating issues. Not having a gateway at all creates issues as well. Just as a cheap home made radio shows traffic letting you see if you are playing in a crowded field, having a few status indicators or icons on a map will allow single channel gateways to remain until they are replaced by budget compliant gateways.
I don’t understand how removing single channel gateways from the map will solve anything, as @JBraam was saying LoRa is never guaranteed, people just need to accept that.
Even when multi-channel LoRa gateways appears on the map it means nothing regarding your ability to access it and we’ll soon see the the (painful?) realisation that indoor gateways - especially where many people will place a gateway, i.e. behind the TV next to their ISP router - just won’t offer much meaningful coverage to the network.
Many people I’ve talked to started with a single channel gateway and for them getting on the map was the “badge” for their achievement. They later moved on to multi-channel gateways. To me it would be disappointing if the plan is now to “monetise” that achievement by offering it only to those who can afford the €300 up front.
I think it is a good idea to test the capabilities of a gateway, and only show it on the map if it has proven to have some required features (this also applies to ‘full’ gateways!) Maybe an indication of the range of the gateway can be shown, based on received messages.
I think a single channel gateway can contribute to the network because it can help getting OTAA nodes joined and downlinks delivered in areas with suboptimal coverage. In area’s with good coverage, a single channel gateway will just occasionally be seen as another gateway that received a message.
People that want to deploy a lot of nodes in an area, should make sure there is enough coverage in that area. If there is not enough capacity they can install a full gateway to fix that. (Hope is not a strategy )
If implemented correctly, the gateway is fully unaware of the RX window a downlink is sent in. The network just tells it to send these bytes on this time using this SF and frequency. The gateway doesn’t know why or what it is sending, it just does it because the network sais so…
Using a separate channelplan can result in a separate market for ‘single channel nodes’. or ‘dual’ (both multi/single channel compatible) nodes complicating things unnecessary.
It will be single channel nodes that will monopolise a frequency! Maybe it is better to ban those from the network…
Is it possible to create my own server for a single channel gateway without downlink to just scan packets? If so, can anyone give me some starter tips?
Just because most people on the Forum are familiar with the typical configuration of low cost gateways (8 channels), it does not mean other configurations are wrong. LoraWAN has the concept of bands with each band comprising 8 frequencies. These 8 channel gateways therefore support only a single band.
For example, Cisco’s current LoraWAN compliant gateway supports 16 channels (two bands).
I think putting less effort in building compliant gateways ‘because LoraWAN is’nt reliable after all’ is a very bad and generally unsustainable attitude. LoraWAN is best effort, and so should we be doing our best effort in building a capable and compliant network.
That’s why I’ll stick to my point: non-compliant gateways shouldn’t be on the map. It is very frustrating for new users not being able to do OTAA or test a downlink, just because the owner of the nearby gateway decided no-one needs this. Being on the map should be a badge of merit for investing time and some money in a compliant gateway.
As a middle ground, maybe SCG that do support OTAA and downlink can still be on the map, but with a different icon.
I for one don’t fear coverage issues. There are a lot of tools already to track real coverage, e.g. ttnmapper. You can’t expect gateways to reach their full theoretical coverage, but you can expect gateways to provide the basics like OTAA and downlink.
SCG’s should be on the map but it should be possible to differentiate between real gateway’s and SCG’s with an option to show either or both (and possibly other properties could be defined to be able to distinguish between different types of gateways).
To contribute to this, I just added a new feature to TTN Mapper. When you click on a gateway marker, you will see the number of channels TTN Mapper has heard the gateway on.
For a single channel gateway: Channels heard on: 1
For a LoRaWAN gateway: Channels heard on: 8
A single channel gateway of which the frequency was changed at some time in the past: Channels heard on: 2
Nice addition, but only a stop-gap measure imo. It only shows the channels the mapper reported. E.g. my gateway reports 8 channels, but others in the neighborhood only 3 - while I’m pretty sure these are iMST based gateways too.
My area is not covered by official gateways
Case 1: The chance of “congestion” exists, but also the need for a SCG is smaller because I can already connect to TTN. If I look at the map, this is less than 5% of the use cases, even in Europe.
Case 2: No problem of “congestion” exists and there is a big chance, that I will not join TTN if I have to spend 300$ for my entry ticket (full gateway). This is in >95% of the places.
I think, the growth of TTN will be considerably slowed down if you do not allow SCGs, especially for the 95% of the areas outside Amsterdam and maybe Zurich.
Summarized: I think, there is not one problem created by a SCG outside these two cities, but we created lots of problems by taking them offline,
The “10” comes from the specifications of the SX1301: 10 demodulation paths. The fact that we only use 8 doesn’t mean the gateway doesn’t support it.
The idea of using a 16 channel gateway to service multiple bands is only valid for the US and Australia (although it should be called sub-band then). In all other regions, a 16 channel gateway will listen on each channel twice to improve reception and make localization (positioning) perform better.
thanks htdvisser, now I know the context of the 10 in the original post.
as a newbie, the focus I have is country denmark and when permitted, community silkeborg (one person) so my time has been limited for vertical RF /SX1301 knowledge (something to do with time, and lack of).
I hope Silkeborg gets more members soon (ratio 3GW to 1 member is a not the best ration )
I think one issue is when you make a single channel gateway, that only works on one channel, and put this on the map. People think their node will see the gateway, but because it’s only listening on one of the 8 channels, it doesn’t have much of a chance.
)
)