The future of single-channel gateways

Gateways [obsolete] SCPF
7

In my area, there are two full gateways within a 2 km range. But I cannot get an OTAA node to join the network using those gateways. After my node has been activated via my single channel gateway, messages sent by the node are also received by the two full gateways. So single channel gateways that support OTAA can be useful to help nodes getting activated. Activation may take longer because only one of three join channels is monitored, but a slow activation is better than no activation at all.

The ‘negative’ scenario’s of single channel gateways only apply when there are no full gateways in range. In that scenario full gateways would also occasionally receive messages send by a node in that area, quite comparable to a single channel gateway receiving only one in eight messages.

When there are full gateways in range, messages sent on all frequencies will be received by the full gateways in the neighborhood. Occasionally the messages will also be received by the single channel gateway. When the network decides to schedule a downlink using the single channel gateway (triggered by the reception of the message on that single channel gateway) it will just work. Downlinks on other channels will be scheduled to be sent by the full gateways. So in my opinion there is no drawback on also having some single channel gateways in an area with good full gateway coverage. In fact: this is the reason I started developing the single channel gateway. My idea was that if there were more gateways receiving (some) messages that would help in getting better geolocation via LoRaWan.

I agree that it is not desirable to ‘cripple’ nodes to use only one channel. People should be aware that LoRaWan is ‘send and hopfully it will be received’. So if there is no gateway in close range, it should be expected that some (most?) messages will not be received. Having only a single channel gateway in your area will at least have some messages received by the network, mimicking an area with no gateway in close range.

Maybe not showing single channel gateways on the map will avoid confusion. Using another icon clearly stating the channel the SCG is listening to is another option. BTW when I started with LoRaWan it took me a while to find out that ‘planned gateways’ weren’t there (yet); very confusing.

I think the idea to use a different frequency for single channel gateways is a bad idea, because it targets the wrong problem. If there is enough coverage by full gateways there is no problem, while if there are not enough full gateways they will help to ‘fill the gaps’ (handeling OTAA and some downlinks). If there are no full gateways SCG’s will provide some connectivity for LoRaWan compliant nodes, which in my opinion is better than no connectivity at all.

I think the only part of the network that should take SCG’s into account is the ADR algorithm: it is probably best not to use single channel gateway measurements to determine optimal datarates.

3 Likes
9

You are halfway there. Let me share my dodgy ideas.

First, every single person who makes a single channel gateway should be encouraged to make a network scanner, that allows them to visualize at least one sub band, with all 8 channels. Thanks to a friends help, I created a Lora frequency scanner & visualiser. It’s absolutely brilliant, allowing you to confirm precisely what channels your radio broadcasts on, and when. You can see interference, and you can see what the spectrum is like - whether it is flooded with traffic, moderately used, or completely empty (48 hours of scanning shows that sub bands 1 & 2 are completely empty of traffic in my part of the world…). It shows detail precisely, allowing you to instantly distinguish between received and transmitted packets and confirm if your packets are within spec, frequency wise. Refer SDR - software defined radio, using rtl-sdr and gqrx SDR (on Linux - in my case, a Pine64 SBC / Ubuntu 16 LTS & Mate, so I can make the scanner easily portable). Cost about $20 to $30 Australian, using entirely free software. Every gateway and node operator should make or buy one of these - it should be official policy for the things network.

Second, people who make single channel gateways should be encouraged to use and try different versions of the Arduino Lmic libraries. They are strange, you see… so far, I have 5 different versions that I pull into my scripts for different reasons. I have two Australian versions, both a bit broken but basically functional, even one locally made which has a repair on the DB output issue that affects all using RFM95s, allowing us to use full 20 dBm output and lower it if we like. This experimentation gives you a good idea of the complexities of the scripts that make up a Lora gateway and modifying them each time you change leads to insight. Here in Australia our frequency is 915 to 928. There is NO spare spectrum for isolating single channel gateways. Also, there is no recommended Lmic for Arduino that has Australian support. So AFAIK we have no choice but to recode and modify, and sit our DIY gateways in your spectrum.

Third, rapid hardware and software development will define this industry, the leaders will be those who carry out this rapid change. As I understand it we have single channel gateways, then hybrid gateways (two radios over 8 channels or one sub band monitored) and full gateways (16 channels or two sub bands monitored). The single channel ones cost as much as a $15 RFM-95, and can use an old raspberry pi or Arduino lying around. Essentially, they cost nothing. A hybrid gateway is about Australian $500 to $1500. A full gateway, well here, if I want one today, I have to pay over $2500. Now, it’s all well and good to say ‘single channel gateways are rubbish’ but when you are comparing $15 to $1500 or more, you aren’t really saying anything. I’ll wager that before too long we will be able to bond together three RFM-95 modules and have a basic non-compliant gateway that is functional, for under $50. Note, this is still a bit less than $1500. In other words, you will never get rid of single channel gateways, but they will improve, somewhat, as time passes. Any attempt to cut them off will simply drive people off the things network, onto competition, or even onto private networks.

Fourth, What you want is a temporary, short term solution, until some genius bonds together three RFM95s for $50 and calls it a gateway. The question that should be asked is “how do we best manage single channel gateways right now given that they are either substantially crippled or barely functional?” I suggest the best way is to slightly modify your existing systems. You could probably do it all in a few days given a couple of people.
A) Use the ‘DIY single channel gateway’ flag to change the icon of the mapped node, to visually show it is a single channel gateway, it must say ‘untested channel 0 sub band 1, SF 7’.
B) Have the gateway require a single successful note pass an OTAA test through it, prior to this the icon of the mapped gateway must show ‘untested OTAA joins’.
C) Have the gateway require a single successful ‘confirmed uplink’ and a single ‘confirmed downlink’, from a node through to TTN - prior to this the icon of the mapped gateway must show ‘untested unconfirmed nodes’

If you can, by some means, test and display the above, you can provide a measure of verification that will go a very long way towards improving TTN, keeping us on it.

Cheers,
X

4 Likes
10

Do you have more information about the network scanner like description and build instructions?

1 Like
11

You just buy a USB tv adaptor like one mentioned here:
http://osmocom.org/projects/sdr/wiki/rtl-sdr
Cost about $20 USD
it’s a USB RTL2832U-based DVB-T dongle.

Then you take Ubuntu and use the PPA procedure here:
http://gqrx.dk/download/install-ubuntu
Cost: Free (there are windows programs that will work as well, that are also free, if you prefer)
It’s a few lines to type in, then the program and all dependencies is installed into your Gui (On Mate you can find it under the Internet folder on the start button after the PPA installation)

Lastly, you tune it to 917.9 Mhz, which here is Australian centre of Sub Band 2. You will see all packets on that entire sub band, appear, scrolling historically, as time passes. You can guess the SF by the size, you can guess if it’s a transmit or receive.

Honestly, it’s so easy to do I am kicking myself for not doing it six months ago. Of course, no one told me I could use a $30 Australian USB TV adaptor as a software defined radio to display lora packets…

4 Likes
12

I think just removing SCG from the map and gatewaylist will already solve a lot of problems. People who deploy SCG are mainly doing this for their own ‘private’ use. They know their gateway has limited capacity. If it doesn’t show up on the map, other people wont get false hopes or be confused.

It does add to the issue of unfair or unbalanced network usage though. Using non-compliant SCG may work for the use case of the owner, but doesn’t really contribute to the network as a whole.

5 Likes
13

sorry … still don’t see your point what a 7 U$ dongle and some free software has todo with improving TTN or the future of single channel gateways.

14

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:

  1. Adding downlink to SCG is simple. RX1 window is implemeted many times. RX2 seems not. (I have not investigated all SCG versions.
  2. 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?

I am looking forward to the implementation.

Cu, Remko

3 Likes
15

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.

16

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.

4 Likes
17

Some comments:

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 :wink: )

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…

3 Likes
18

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?

19

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).

1 Like
20

take a look at this: https://github.com/gotthardp/lorawan-server for a local server. So far I’ve verified it works with TTN SCG code for NodeMCU/WeMos and ABP node built from ProMini/RFM95W. Will be testing JBraam’s SCG with Multi-SF( https://github.com/JaapBraam/LoRaWanGateway ) and a ProMini/RFM95W doing OTAA tomorrow.

2 Likes
21

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.

2 Likes
22

and prices of real gateways will only drop if people buy them :wink:

2 Likes
23

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).

1 Like
24

Are they available for sale? :grin:

1 Like
25

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

10 Likes
26

The scanner is a great idea. I have order one. I wish I had one when I first started developing my gear. It would have saved a lot of time.

27

The separate SCG frequency plan is a great idea but it should not be limited to a single frequency.