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.
The separate SCG frequency plan is a great idea but it should not be limited to a single frequency.
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.
I think, we have to distinguish two cases:
- My area is covered by “official” gateways
- 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,
5 Likes
Could someone ok a little change in the wiki concerning removal of “10” and addition of band?
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.
1 Like
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.
If there is only a single channel gateway in range a node will have a 33.3% chance to join in the first attempt (if the single channel gateway listens on one of the JOIN channels); because the node will cycle channels it will get activated eventually. After that there is a 12,5% chance that a message is received. At least the node can join and some messages will be received. In my opinion that is better than no join and no reception of messages…
If there is also a full gateway in range the node will not have any negative effects of the single channel gateway. It will join using either the single channel gateway or the full gateway. After that 100% of the messages will be received by the full gateway, and 12.5% of the messages wil also be received by the single channel gateway.
If there is also a full gateway close enough to receive uplinks, but too far to succesfully deliver downlinks, (this is the case on my location) a node will have a 33.3% chance to join in the first attempt via the single channel gateway and will get activated eventually. After that 100% of the messages will be received by the full gateway, and 12.5% of the messages wil also be received by the single channel gateway.
I don’t see any drawbacks of having a single channel gateway in range that supports multi SF’s, downlinks and OTAA.
7 Likes
Good to see that there is a discussion about the subject. Once in a while you see some examples of companies intending to flood an area with picocell gateways. Should perhaps their frequency be part of the choice for a fixed frequency for our SCG’s?
And something else… will SCG’s remain really relevant once BLE becomes more popular?
BLE is a short range technology (10s of meters). Lora is a long range technology (1000s of meters). Single or Multichannel Lora gateways are not impacted by the popularity of a short range technology.
They probably mean BT 5, which has a range of multiple 100 meters (I thought I even saw examples of multiple kilometers floating around on these forums) while keeping the same power envelope. It’s the BT SIGs take at LPWAN.
I think your right. BT5’s range is still more than an order of magnitude lower than Lora and my comment regarding the non impact is unchanged.
The range of the average single channel gateway is also more than an order of magnitude lower than a real gateway, at least based on what I read on the forum. It seems that they match pretty well in range.
I have a single channel gateway and I receive data from nodes several km away and I am only using a stub aerial on the gateway. The range figures I have seen for BT5 is 350m however I do not have a BT5 implementation yet to compare myself.
1 Like
Even BLE 4 does 400m usually with a PA (+8dBm), BLE 5 is planned to reach into the 1-2Kms at similar power. Bluetooth 5 can go up 12 dBm
For clarity, does TTN now support single channel gateways, like the Dragino Lora HAT for the Raspberry Pi? I tried a month ago and could not get it to work at all, it was the very day after TTN announced that single channel was no longer working. I don’t want to go through those hours of heartache again, if it will not work.
Thanks
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