I’m interested in what is possible with LoRaWAN can came across your community.
I’ve been reading around and for a gateway it seems the easiest and cheapest when working with a Pi is the RAK2245. The main question I have regarding this is the number of nodes it supports. I keep seeing the figure of 500/km2, but then also 8 simultaneous channel uplink.
Does this mean that it can have 500 nodes registered to it, but only 8 of those can be sending data at the same time to the gateway? What happens if a 9th tries?
I also note that it says 1 channel downlink, does that mean it can send data to a single node at a time?
There are 3 classes of LoRaWAN comms, everything does A with B & C being extensions that change how the nodes listen, what is supported by the RAK2245?
Finally (for now) the communication between a node and gateway, is that best effort or guaranteed?
You are right, only 8 simultaneous transmissions can be received. However as a node using the public TTN network is only allowed an average airtime of 30 seconds there is plenty of time the airwaves are empty even with 500 nodes.
What class of node is supported does not depend on the hardware as long as it is at least 8 channels capable. (So not a single channel gateway)
The software on the gateway and at the back-end determines the type of node supported. Currently TTN only supports class A, so even if a gateway supports class B & C it won’t work.
With regards to the best effort/guaranteed question, do some more reading regarding LoRaWAN. Don’t expect us to do all your homework
Not only that, but transmitting a downlink blocks out reception on all 8 uplink channels. Because of this the use of downlinks needs to be kept to a minimum, which requires a lot of strategic thinking.
though TTN FUP puts some additional constraints on spectrum useage as Jac states, you still need to be aware that as LoRaWAN is a broadcast system if there are other networks (be they private or public, running in the area on same channels all GW’s within range see all the traffic and ‘receive’ & process the messages - even if subsequently dropped by back-end so if in area with other nets you need to be aware of potentially unpredictable potential GW capacity consumption… hence need for e.g. FUP vs everyone banging up against legal duty cycle limits! Apps should be designed for reduced up (and down) links and for fact messages may get lost if in highly trafficed areas…
