Is there someone that can explain the technical benefits of 16 channel gateway compared to 8 channel gateway? I understand an 8 channel gateway will able to talk to 8 sensors at one time but how does SF play a part and what is the threshold to move to a 16 channel gateway?
Any input would be helpful…
Thanks,
Sammy
Maybe. The way it actually works is that the nodes (“sensors”) are supposed to randomly choose a channel. Having a larger number means less likelihood of a collisions if two try to transmit on the same frequency at the same time.
Spreading factor provides some additional diversity - in theory a gateway can receive two signals on the same frequency at the same time if they are at different spreading factors and the signal levels aren’t so drastically different that one completely drowns out the other.
But “talk to” brings up the other side of the problem - a gateway can only reply to once node at a time, and while it is doing so it loses the ability to hear any other nodes. For this reason LoRaWAN networks need to run “uplink mostly” with replies being comparatively rare. And of course even uplinks should be sparse - widely spaced in time.
the technical benefits of 16 channel gateway compared to 8 channel gateway
On a private network this would let you have more capacity in the uplink direction, but still not in the downlink one.
However, this is the TTN forum, and TTN configures nodes to only use 8 channels. So for our purposes here, there is no real benefit at all.
And a 16 channel gateway wouldn’t really help you have one box run both TTN and a private network, because the primary conflict there is between downlink requests by the two uncoordinated networks’ servers.
If you wanted to invest in more than an 8 channel gateway, then rather than getting a 16 channel one it would be better to get two 8 channel gateways, each of which has 1 downlink reply transmitter. And ideally don’t put them in quite the same place, though if you have an excellent place (like a mountain top) there could be utility in doing even that.
Thank you for your response! Very helpful! Understood, TTN only configured nodes to only use 8 channels. So the only benefit I see is the 16 channels gateway captures more sensor traffic in a certain time frame. Hence, reducing the possibility of collisions.
Only if the nodes are actually using more channels. Otherwise there’s only a slight increase in the statistical chances of success in a circumstance where it’s unclear which signal a given gateway chip’s multiple internal engines should chase - the chances that having two 8-channel chips monitoring the same frequencies via the same algorithm fed by the same antenna would make an improvement are relatively slight.
Does anyone know how many channels are on the The Things Network gateway? This seems like something that should be disclosed on the website but its not included in the specs.
Eight, just like anything else that is an actual LoRaWAN gateway and not a very expensive premium product. There are actually three different "Things Network gateway"s but they are all 8 channel, and they all really do have that somewhere in their specifications, either explicitly or in the identification of the LoRa chips used.
The only variations from 8 channel you are likely to personally encounter are the “fakeways” that use one or two node class radios to do a bad job of impersonating a small fraction of a gateway’s job.
One thing: do not mix number of channel and receiver: the current gateway chip (based SX1301) have 8 channels and 8 receivers so you can only ever only receive 8 packet at the same time, but the next chip (SX1302) has 16 modems for 8 channels, so with this kind of gateway you can actually receive up to 16 frame at the same time supposing they are using a unique combination of channel and SF.
And about the use of 2 gateway monitoring the same frequencies: you could see clear benefits if you limit the spreading listen by each gateway: for example one for SF 5 to 8 and another for SF 9 to 12.
you could see clear benefits if you limit the spreading listen by each gateway: for example one for SF 5 to 8 and another for SF 9 to 12.
Hello. Looking for any way to solve same thing - ability to implement 16-64 channel LoRaWAN gateway by using commonly available SX1301/SX1302 ICs.
Do I understand correct that splitting by SF can be implemented using chan_multiSF_All option in global_conf.json configuration file?