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.
Pi gateway running Chirpstack on a PowerBank with an OLED?
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.
2 Likes
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.
1 Like
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).
1 Like
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.
That is/was actually true for the situation you refer to, there were at least 3 gateways.
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.
Thanks for your reply - much of what you say I’m already very familiar with and I agree with you - do you have specific examples of sensor with ‘alarm logic built in’ ?
Hi @CambridgeSensorNetwo, most commercial GPS asset trackers have extensive logic to detect abnormal activity and move into alarm mode with a much higher rate of uplinks and transmitting at full RF power.
1 Like
Do these ‘commercial GPS asset trackers’ keep track of the air time they use when switching to a higher uplink rate ?
I’m not aware of any generic commercial devices that can offer the flexibility that’s required. Which is why descartes & Handy Little Modules exists, in a “I think up solutions, there I exist” sort of way.
What are you actually sensing?
Hi @LoRaTracker, the ones that I use are:
They are LoRaWAN Certified so I presume that they maintain compliance to the regional regulations at all times.
thanks for the link - my browse of the interwebs puts these at around $100 which seems a good price. It is the ‘triggered’ nature of the sensor which is important to us, and a GPS theft alarm makes a lot of sense as an application requiring that reduced latency.
A misunderstanding has crept in here somehow, for which I apologise.
The (university) research we’re doing involves applying machine learning to real-time data streams from dense sensor networks. Our deployment of sensors isn’t particularly unusual, but our aspiration to spot patterns in the spatio-temporal data in a timely fashion (e.g. seconds) is somewhat advanced. As you say, the system would need to learn what’s ‘normal’ for 10:30am (maybe class time) vs. 10am (maybe class changes) i.e. include both space and time in the pattern it’s recognizing, but mostly I should choose a less controversial hypothetical example…
Sounds like (if you forgive the pun) something that Edge Impulse does: