New to this forum but very interested in using lora for my use case. I am however relatively unfamiliar with signals, antennas and the likes.
I’m currently faced with a challenge: I have a very large building (approx. 300m x 300m) several (9-10) stories high and built with massive concrete floors and walls. Spread out through this building are several LoRa temperature sensors. I’m trying to receive the signals from as many sensors as possible with a single gateway.
After researching the internet and this forum, I’ve found a number of factors to take into account:
Gateway placement - the higher the better - is this also true when the sensors are in the building below?
Antennas - there seem to be many different kinds varying in length, gain and type (omnidirectional?).
My question is: would you be willing to share some best practices/experiences for a scenario like this?
My experience of LoRaWAN in large masonry/concrete structures is that each wall/floor penetration will cost you about 20 to 30 dB of link budget. However, you should test this on the actual structure or a similar one as large modern structures are often not as heavily built as they appear.
You want to use a single gateway? I can’t see any way that a single gateway located in or on the structure could provide coverage to everywhere in the structure you describe.
Getting an antenna up high is the normal rule to get “above the ground clutter” and get longer range but this does not apply in your case.
Any antenna with gain increases TX and RX power in some directions and reduces it in others. For short range inside a dense building, where sensors could be in any direction, the use of omni antennae is likely to be best.
We placed a Multitech outdoor gateway on the roof of our relatively modern (steel/concrete floors) 3-storey 300m x 300m building and that gives us a good signal throughout the building. We did the reasonable thing and radio-surveyed the building before and after (using an Adeunis test device, which is useful but overpriced IMHO). The gateway has a conventional antenna placed vertically, but we still get a good signal directly below the antenna even though the radiation pattern would suggest otherwise (“omni” doesn’t include vertical…) - our guess is that is because much of the reception we’re getting is actually via reflections from neighbouring buildings but we don’t know.
We have additional in-building (Multitech) gateways available to use as we were expecting poor spots but so far we haven’t used them.
Don’t rule out putting the gateway in the middle of the building - the roof is great if you want geographic coverage, but that’s not really your goal.
Though if you are using a mobile data modem for backhaul, then you need to be somewhere where that has sufficient signal.
Indoor grade gateways aren’t that expensive, if this is a “real” project, you may be able to justify several. Perhaps start by trying the single gateway in various locations and seeing which nodes are able to report in. That may show you if there’s a combination of two or three positions which would reach them all.
Absolutly definetly you need to survey the building.
No need for expensive kit here, a couple of Arduino Pro Minis and appropriate LoRa modules will do it; one as TX the other as RX. An SX1262 for the TX would be best. Set one Pro Mini up in the position where you think the gateway might be, use the gateway antenna you intend to use.
Use some link test software that transmits decending power packets. Then at various locations in the building use the receiver to see which power packets you are getting. This is a more reliable link test than relying on the RSSI readings which tend to be guesswork particularly with signals near the limit.
I keep a couple of old Semtech SX1272 & SX1276 dual handset LoRa EVK’s for just such use Set one up at target GW site pinging smallish packets 6-20bytes to simulate real Tx’s at SF7 or 8 for short range coverage checks or move to SF 9 or 10 for longer range and then use SF11 or 12 for extreme outlyers or hard to reach places to check coverage & feasability. If all looks good on the second hansdset then I swap GW location to an original IoT Starter Kit as standard 8channel GW ref design and LoRa Motes to check coverage using LoRaWAN so I can easily log metadata and (if outdoors) GPS location offline if not able to get an internet connection at the target site initially or use one of my small GW builds as a test GW with (TTN of course!) backend checks - if GW Console shows traffic am good to go - and can check headroom for signal levels as needed, etc
And how are is it divided up? Because if it’s one enormous cavern, one gateway may do, if it’s multiple rooms, then the survey is indicated. If the devices are on the floor surrounded by metal racking, that’s another matter.
How many devices will be used? Are they off the shelf items or bespoke?
Ensure you cost out everyone’s time - as it may be cheaper to get a crate of TT Indoor Gateways liberally scattered than spending too much time being overly scientific.
And if you have lots of devices, it may well be simpler to use LoRa P2P or WiFi or NRF24 …
Thinking about it, my starting design for this would be 9 gateways, one for each floor, with the gateways ~central to each floor. After a radio survey maybe the antennas on each floor could be moved around to optimise the coverage between floors. If budget is tight then start with 3 gateways (floors 2, 5, 8 i.e. covering ~ 3 floors each) and increase from there. I’ve learned the antenna makes all the difference (obvious I know, but I’ve also learned antennas are a specialist topic…)
Having seen the reference to deploying 400 nodes and being worried about MQTT in another thread:
I’d get clarification on the budget.
This can be simply solved by getting a TTIG, pair it to your mobile phone’s hot spot, get a device that uplinks when you press a button, go to site and try it all out. This should answer pretty much every question you have and Excel can make you a loverly heat map file to explain things to others.
I wouldn’t use a TTIG for this, but rather something without its wifi connection quirks, and with the ability to get a local packet log, so that I could do testing even without an Internet connection.
No real need for a network server, modern packet forwarders break out the device address of packets, it’s not really like you need to worry if someone is spoofing you during a site survey. And if the signal levels are good, the rate of errors will be pretty low. So really checking the MIC (what only a network server could theoretically do) isn’t that important for a survey.
I’d be careful of the power bank though; they’re often electrically noisy, had issues in the past with a more primitive radio gadget which had 10x reduction in effective receive range when running on one. LoRa is far more interference resistant but this is about finding the point where it can no longer get through, so at the least, do an A/B range check between the particular powerbank and a mains supply before relying on it for a survey.
Be aware that when applying LoRaWAN for large indoor applications where there can be a large number of nodes, care should be taken that RF output power of nodes gets minimized and messages shall only be sent when useful (e.g. when state has actually changed).
If these aspects are not taken care of then the neighbourhood can (and will) be continuously flooded with LoRaWAN messages, way outside of the boundaries of those buildings.
You make some philosophically interesting points. I can recall one situation where someone considering an apartment building project had argued it was better to put the gateway on the building across the street from the one having the nodes.
the challenge here is that LoRaWAN only works efficiently in unconfirmed uplink mode, which basically means relying on repetition to ensure that on average important information gets through.
There might however be some form of balance - “nothing’s changed in a few hours” but in actuality things do change throughout the day as the sun moves, people come and go, HVAC systems with time schedules change mode, etc - and often it’s precisely these patterns which people want to see.
On a campus nearby there was some desk/table occupancy application with 1000+ nodes covering multiple buildings. The (single) gateway was/is indeed located outside on one of the roofs.
The nodes transmitted each 10 minutes, 24/7, at full RF power their status. Whether the status had changed or not, wheter there were any people in the buildings or not.
This actually flooded the neighborhood way outside of the campus with useless LoRaWAN messages. It was so worse that I was unable to see and detect my own messages on my gateway traffic log on the TTN console. They quickly scrolled off screen before I could check them and the log was truncated to 100 messages.
Luckily they stopped because the application was unsuccessful due to desks/tables being relocated and switched regularly (uncontrolled) so their occupation status had become of little use (they did not report their location). At least it got me some impressive received messages counts on my gateways…
That’s correct (unfortunately) but there is a difference between repeating a status change a few times (when knowing the area has good gateway coverage) and blatantly reporting every 10 minutes, 24/7, 365 with 1000+ nodes whether status has changed or not.
The above i.m.o. also advocates that for large indoor applications, nodes should have coverage of multiple gateways in each area (from gateways inside the building).
The adjacent building or even a few 100m away might be better than the roof or halve way up. As it is solid objects that causes more RF loss the free space.
So consideration need to be given thru (if you ca term it this way) how many objects the RF have to travel.
How true! Our entire Smart City / Smart Building research theme at Cambridge is based around the superiority of asynchronous messages signalling ‘events’ rather than periodic messages reporting ‘status’ (we have one experiment where the difference in traffic is 10^7) but the industry is REALLY badly set up to support that.
We’re interested in (relatively) low-latency recognition of composite events, aka “patterns” (for want of a better one, our catchy example is a school shooting) and waiting 5 minutes to find out motion in every corridor is exceptionally rapid is just dumb. Asynchronous message processing end-to-end reduces the latency by a factor of, say, 10^3 (500ms vs 5 minutes) AND typically reduces the message volume by a greater amount (each sensor sends less irrelevant data, and a high volume of sensors don’t continuously send traffic from low use areas at a rate only needed for infrequent situations)
Pretty much everyone we deal with, in industry and academia, suggests we could reduce latency by speeding up the polling cycle, which suggests they’ve never deployed more than a couple of sensors. The platforms in use throw away the real-time nature of the data the instant it arrives on the platform also, i.e. the data gets stored and all processing simply refers to that stored data, often by polling the storage (sigh).
We typically aim for a balance between ‘event-driven’ messages (giving us low latency) and periodic status reporting at a much lower frequency (which at least allows us to detect the sensor has failed).
The particular weaknesses of most current off-the-shelf sensors are (1) they are usually configurable for periodic reporting only or (2) the event-driven message is identical to the periodic ‘status’ message so you need a heuristic to recognize the events.
We’ve found Elsys and RadioBridge LoraWAN sensors are configurable for some asynchronous messaging, so we’re not entirely dependent upon custom development.
Anyone else like to comment or have useful suggestions please do so (bluejedi can you give the name of your nearby campus? We’d talk to them so see what they learned, but we’re starting from a fundamental position much more aligned to your comments as we’re doing the CS, rather than e.g. an environmental analysis).
It’s easy to get snowblind with what’s normal for XXXXX. Certainly many devices just sit and phone in a number every so often and then there server side does the “thinking”.
Some devices actually have alarm logic built in - so they can phone home as soon as a threshold has been breached, uplink more frequently (but not excessively) and perhaps have another higher threshold where it uplinks even faster, awaiting an alarm acknowledgement so it knows that the control centre knows. Or even two levels of ack, which I did once with a very important beer related application, where both the device & control had various ack levels and uplinks were frequent until the device knew that something intelligent (perhaps human) was on the case, at which point it could be told to uplink at a rate suitable for the central intelligence agency to monitor the situation or just shut up.
Some hysteresis needs to be introduced so alarms don’t keep being triggered and rescinded when the values move up and down.
As for your rather distasteful example, some local intelligence would be needed - activity in the halls needs to be co-related to class change time. It would be a good candidate for machine learning as you could look at how much activity, the outside temperature & if it’s raining as well as time window. Find a better example, the US uses audio sensors, hitching a marketing ride on this subject is wrong unless you actually have a solution you can ship right now.
Perhaps you need to use a hybrid device - mostly off the shelf but one you can control the logic of data measurement & uplinks.
Set one up at target GW site pinging smallish packets 6-20bytes to simulate real Tx’s at SF7 or 8 for short range coverage checks or move to SF 9 or 10 for longer range and then use SF11 or 12 for extreme outlyers or hard to reach places to check coverage & feasability. If all looks good on the second hansdset then I swap GW location to an original IoT Starter Kit as standard 8channel GW ref design and LoRa Motes to check coverage using LoRaWAN so I can easily log metadata and (if outdoors) GPS location offline if not able to get an internet connection at the target site initially or use one of my small GW builds as a test GW with (TTN of course!) backend checks - if GW Console shows traffic am good to go - and can check headroom for signal levels as needed, etc