Hi all,
I just purchased a TTIG-868 gateway and I find its coverage performances amazing (without having to add any external antenna). Does anyone have an idea of the number of connected devices this gateway can support?
Thanks for your feedback,
Claire
The fair-use policy is based on 1000 nodes.
[https://www.thethingsnetwork.org/docs/lorawan/duty-cycle.html#maximum-duty-cycle](http://fair use duty cycle)
The nr of connected devices depend on a nr of factors.
Nodes simply broadcast to everybody and gateways receive (and forward) the packets they receive.
Nodes can send on different frequencies and strengths. So adding gateways is often an easy way to add more nodes.
I strongly suggest reading the learning section on the website.
The simplest answer is ‘many’, because it depends on several factors.
Do you have any specic application in mind?
What exactly do you mean with ‘connected devices’?
Thanks Alain.
Let’s suppose (1) that 2 gateways, (for example a TTIG and a Multi-Tech Conduit), are installed at the same location and connected to TTN and (2) that both gateways cover exactly the same area.
If I understand correctly, whatever their hardware configuration and processing power, both gateways will have the same performances in processing messages received from all nodes (devices) deployed in the coverage area ?
By connected devices I mean end-nodes.
I’m just wandering if all gateways would have the same capacity in processing all messages sent by end-nodes in a given coverage area or if it depends on the hardware configuration.
There will be variances - local (immediate) noise figures (external injection or internal/self generated), & reflections, antenna & cabe performance/degradation etc. (TTIG is internal vs external) and more improtantly for the two GW’s you call out one if based on SX1301, the other the lower cost SX1302…there will be spec differences and hence system performance differences (GIYF), though to first order magnitude they will be very similar. Above factors would typically affect edge of reception range or marginal signal cases.
Where they both receive and validly decode (MIC checks/CRC checks) the same messages from nodes then their onward processing capacity would be the same assuming no down stream or protocol dependent issues are introduced addressing:
Gateways don’t do much to “process” messages, that’s really the job of the network server.
To a crude approximation, putting two gateways in the same place would get you no improvement over having a single gateway there.
Looking at it in a little more detail, there would be slight improvements - times when the radio decoders on one were busy but one was available on the other, but that’s a small improvement. In theory, two gateways could send downlink replies to two nodes at overlapping times, but downlinks are supposed to be rare. And one gateway transmitting would probably blank out, or at least drastic reduce the receiving capability of its partner. In theory, if you are in a place where gateways have airtime limits, two could have more - but again, downlinks are supposed to be used rarely.
Really the only reason for putting two gateways in the same place would be to have a hot spare for redundancy. But software issues are more common than hardware, and two identical ones would share the same software. Backhaul issues can be worth worrying about, but you can give one gateway two connections to the internet…
You’d generally be better off putting the second gateway in a different location.
Or if you are developing gateway software and need to have test gateways at hand to be able to manually intervene when something goes awry. I happen to have 5 gateways at my location for that purpose
With 5 gateways (all with different antennas and located meters apart) I observe differences in what packets are received. Antenna and antenna position make a lot of difference. For nearby nodes where these factors do not come into play there are small differences where sometimes 3 or 4 gateways receive the same packet but most of the time (>98%) all 5 receive and forward the same packets.
I do things like benchmark co-located gateways of differing configuration against each other, but that’s for gateway development, not deployment.
I fully agree with all your comments. My intention was not to install two gateways in the same place, just to compare their performances if they were used in the exact same context.
To clarify my point. There is a common belief that a “small” gateway will not perform as well as a “bigger” one. For example, the LoRaWAN gateways deployed by the mobile operators are claimed to be more robust and capable of managing several thousands of end-nodes. After reading your comments, I have the feeling that, in the same condition of usage, my tiny little gateway can perform at least as well as an indoor Multi-tech Conduit (that I’m also testing). And this is good news, as the TTIG is much cheaper and much easier to install.
There are several issues there.
First, unless I’m mistaken the TTIG uses a slightly lower-spec radio chip intended for cheap gateways (like the idea of putting it in cable internet boxes). So in theory it would have less range. Also the internal antenna would be lower performance than what you could put on a gateway with interchangeable antennas
Also there were some software reliability issues with the firmware and the network software that supports it, and unfortunately unlike most other gateways where you have the option of running a custom firmware rather than the manufacturer’s build, you can’t modify the firmware of TTIG to fix those bugs
Finally wifi is not really a preferred means of connecting gateways. Most fixed installations would use wired Ethernet if available, or else in a remote situation an LTE or similar mobile data connection.
Those claims are correct. In more than one sense:
- they use gateways suited for outdoor use with generally more robust casing, mounting and wire connection solutions (screw connectors, nor RJ45 plugs)
- gateways used by telcos support > 8 channels. More frequencies means more nodes/more transmissions by existing nodes.
- telco gateways will have some remote management option build in. No telco is going to manage hundreds of gateways manually.
However, for 95% of the deployments the less industrial gateways will work just as well.
PS, the gateways do not manage nodes, they just forward data. The backend manages nodes…
Additionally, a gateway with support for more than 8 channels is of no use unless the network is operated with more than 8 channels configured.
TTN is not, and cannot be - most gateways only support 8 channels, so nodes are statically configured or told at registration that only 8 channels are available. There’s no infrastructure in place to identify that a node is near a gateway with more channels available and turn that into a MAC command to tell the node to use those extra channels.
Commercial providers of course run their own networks either with unique configurations within the options of standard protocols, or actually unique protocols.
There’s a big difference if you have to climb a tower to get to you’re gateway or have to secure access to the roof of a commercial building (with the security personel you will pay), to get all the lightning protection with certification , or have a gateway in a building with easy access and usage of the existing internet connection.
If there’s easy access it could be a good practice to put 2 gateway’s on premise, but not close to each other. --> better coverage and less chance something happens to both of them at te same time.
Thanks Alain, that’s exactly what I have in mind
And thanks to all of you for your comments and clarifications. It was very instructive.
Don’t forget the community. If you have the choice with placing the gateway to cover more of the surroundings, that’s always nice.
Done. The gateway is placed on the second floor of my house, covering a 1km radius area and declared as public in TTN. I can now see it on the TTN map