Hello,
I have a simple question.
How many end nodes can I connect to the RAK2245?
Thank you and kind regards,
Lolcocks.
That really depends on how busy they are. A handful of badly behaved ones could monopolize it, or hundreds of rarely active ones could coexist in the monitored bandwith.
Also, nodes connect to a network server through a gateway, not to the gateway itself.
There’s the option to run a compact network server install on the gateway computer, but typically an installation with lots of nodes would have a few gateways for redundancy and better coverage, all reporting to a central network server (typically today the server is logically central, but physically a cloud instance in a data center somewhere)
So what you are saying is that I could have even a hundred nodes as long as they all don’t transmit at the same time?
Hello @lolcocks,
It is really hard to determine how many nodes you are capable of connecting to any concentrator, not only RAK2245.
As @cstratton mentioned it really depends on many factors as to what is the NS, do the devices go in any duty-cycle limitations, how often do they transmit, and many other things, so it is probably impossible for anyone to give you a practically helpful response this question.
RAK2245 is using sx1301, and that chip uses SF7-SF12, when we multiply this by 8, which is the number of supported channels, that means it could theoretically handle 48 messages at the same time, depending on the configuration of the hole network.
But I guess that this is not what you are interested in, so I assume if you connect RAK2245 with RPI, it may handle thousands of nodes. When I say that, I need to note that the number can decrease or increase depending on the configuration of the nodes as well as the configuration of the gateway. In a real deployment, it may be impossible to reach this number.
This is the Semtech’s statement on the question:
Image source.
The sx1301 continuously scans 48 channel * frequency combinations for potential signals, to which it then assigns one of 8 decoder engines, so the actual limit is there.
One of the key factors in maximizing use of this is real randomness in the frequency and timing of infrequent uplinks. A bad random number generator and consistent timing could cause the same nodes attempts to collide over and over again, so the more each node does its own unique thing in time and frequency, the better.
It’s also important to minimize downlinks, because a gateway cannot receive from any node while transmitting back to one. That means being sure not to use confirmed uplink, and being sure that any exchange of tuning MAC commands quickly completes - bugs there can mean every uplink triggers a downlink, which destroys network capacity.
In some places, eg Japan, “Listen Before Talk” may be required, which means checking for activity in a channel before transmitting (the gateway is also required to, so it must be a more advanced model) But even where not a legal requirement, implementing it just in the nodes would make them less likely to collide with other nodes’ already ongoing transmissions, though there remains the possibility of nodes that are both at comparable range from the gateway but out of range of each other, and of two nodes starting to transmit on the same frequency at the same time with neither having started first by enough to be heard and so avoided by the other.