and prices of real gateways will only drop if people buy them 
2 Likes
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
Are they available for sale? 
1 Like
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
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