Choosing the right Gateway for scalable system

Hello!
I’m pretty stuck with choosing the right gateway. We want to design a security and fire alarm that has a LORA network that is scalable from 10-750 sensors(that are bought from the market-we are not going to design sensors/end devices) and I’m planning to use SF=7 and BW=125. And the device should be cheap enough and the budget is pretty tight for that solution: how to understand how many sensors I can put on a single gateway?
It would be nice if you give me how to calculate the load on the network.
Those sensors should be used in security and fire alarm of the building in order not to spend a lot of cables(I know that it is bad but the customer wants a device).
I’m looking on rak833 gateway module but it doesn’t seem to be a reliable enough device for fire and security alarm-I’ve got no Idea how many sensors I can connect to that thing. The data transmission is pretty small: I think 20 bytes of data or even less. Once in a day just a battery and status check of the sensors and if something happens like opening the door or breaking the window or fire smoke sensor detected something-there would be a data transmission, maybe some an actuator device like opening the closed door or smoke ventilation system start signal. My budget is very limited 70$ for hardware, excluding LORA and for LORA I can use around 80-90-100$ maximum, otherwise, there is almost no sense of that device just because of the same price with cables. The connection should be pretty reliable.

and you choose LoRaWAN … LOL

My budget is very limited 70$ for hardware, excluding LORA and for LORA I can use around 80-90-100$ maximum, otherwise, there is almost no sense of that device just because of the same price with cables.

cable the building would be my advice :upside_down_face:

1 Like

I would suggest declining this project entirely - the budget is order-of-magnitude unreasonable for something actually in the field, a business cannot survive under such constraints.

To address your actual question though, gateways have no concept of how many nodes they are supporting. Only network servers know that, and if you are asking here you are supposedly asking about TTN and thus its servers, not yours.

With nominally 8 receive channels, your actual scaling issue tends to be the “everybody talking at once” problem.

Your daily monitoring won’t be an issue for a huge number of nodes (though using only low-range SF7 will probably limit how many you can support, especially indoors)

The bigger problem is what happens when there is an actual fire. Likely the first few nodes exposed will get a message out, but as the first spreads if all the nodes are persistent in transmitting you may soon end up with a total storm and almost nobody getting through. Perhaps you don’t care as people are probably now well aware from the initial reports that the building is on fire, but knowing which parts are burning (and in what order) could still be useful.

With a reasonable budget, LoRa might fit your purposes, but LoRaWAN probably not. One thing you could possible do is reserve some radio channels for initial reports and only allow a node to send on them a handful of times before getting out of the way, and then have other channels for “still on fire but not burned up yet” reports. Try to keep the messages as short as possible. Once you realize LoRaWAN doesn’t really fit, you could drastically reduce the length of the headers, too.

Most gateways support 8 channels in two tightly clustered groups. You can get gateways with 16 or more channels, but there’s a redundancy argument is getting more cheap gateways, than fewer expensive ones.

Hi @Daud, I do not think that any insurance company will accept a LoRa/LoRaWAN solution for fire or security.

1 Like

Even I agree with a cable, problem is a client-he wants a device that: will cost around 100-150$, doesn’t need a cable to use sensors and it would be fire alarm or security alarm. Before we were thinking about ZigBee and realized that it is almost dead and not able to support hundreds of devices at all.

Yep, it seems to be that we gonna recieve just a few alert notifications and we had to make full alert until someone enter the password and reset the alarm device.
Can you show how to calculate how many time does it take to recive all the messages from whole amount of sensors ? As far as I understood, it can take up to 1 hour just to recive all the messages because 8 devices send messages with a speed V and then other 8 devices send messages and time for each group would be (10+13)bytes/speed and entire time of check would be like (#sensors/8)*(26/speed), right ? There is spreading factor and bandwidth that affect speed and so on, but I would like to see calculations or where I can get those.
But at the gateways some producers put Single-board PCs but if it is able to maintain a lot of devices, why they just don’t use a small MCU instead ?

If you find in Uzbekistan that qualified insurance company-I would be happy to use services of that company :sweat_smile:
The idea is just to kill maintenance and use very low-qualified people for mounting.
But I’m not going to produce that device and sell iot-my problem only to design it and make the first prototype.

if it is not LORA and LORAWAN, could you recommend any other technology that fits to that task ? Because we tried Zigbee and it was terrible, NB-IOT is too slow, so LORA seems to be more or less okay but for 750 devices to single station it would be a disaster, soooo I would like to use wi-fi that is cheap, reliable enough and a lot easier to use. But client again wants something specific and cheap

a little analyzing :sunglasses:

  • We want to design a security and fire alarm
  • that has a LORA network
  • that is scalable from 10-750 sensors (that are bought from the market - we are not going to design sensors/end devices)
  • I’m planning to use SF=7 and BW=125.
  • And the device should be cheap enough and the budget is pretty tight for that solution
  • how to understand how many sensors I can put on a single gateway?
  • I’m looking on rak833 gateway module but it doesn’t seem to be a reliable enough device for fire and security alarm
  • I’ve got no Idea how many sensors I can connect to that thing.
  • My budget is very limited 70$ for hardware, excluding LORA and for LORA I can use around 80-90-100$ maximum
  • The connection should be pretty reliable.

why only one gateway ? is that 'reliable ?
why you allready know that you use use SF=7 and BW=125 ?

to many things I read are nonsense here

sf=7 and BW=125 is just a typical example from design appnote. I agree to use any configuration and shown that as “planning”, if it is needed to make calculations.
One gateway because it is included in the device, I can use couple of them but each(cheapest as I found) modules are rak833 costs around 150 and it is already out of buget boundary- I can try to push this guy to finish the device price around 250 maaximum but it is still a madness.
I know that it sounds pretty weird because I’ve got pretty small experince in RF and that’s why I’m asking help here)

well listen to the advice then of some specialists / experienced users :
‘you can’t build a very cheap, reliable, lorawan, fire / smoke alarm with one gateway and 750 sensors’

oh… and I’m out :sunglasses:

yep and that’s why I asked about other RF interface or any advice that would be useful.
Thank you for the help.

If you consider NB-IOT too slow then you are wasting your time looking at LoRa technology which varies between slower to glacially slower than NB-IOT

Just like UDP, LoRa is “best effort” and is therefore inherently unreliable.

Yes use wires, simple.

I am surprised the question has even been asked, fire alarms have to just work so they save peoples lives.

Relying on TTN for such a system is just plain stupid.

I totaly agree with that, but it is requested by customer to design such a bad system.

So you are asking the forum for advice on how to setup a system you accept is bad ?

Good luck with that.

Hi @Daud, please refer to the US National Society for Professional Engineers (NSPE) code of ethics.

Clause 2, item b reads:

Engineers shall not complete, sign, or seal plans and/or specifications that are not in conformity with applicable engineering standards. If the client or employer insists on such unprofessional conduct, they shall notify the proper authorities and withdraw from further service on the project.

You should withdraw from this project.

2 Likes