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.
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:
That would imply that the firmware in ‘LoRaWAN Certified’ nodes cannot be reprogramed, is that the case ?
Hi @LoRaTracker, my industrial experience is that if you need formal certification and commissioning then there will be limits on what the user can do without breaking the certification or commissioning.
In the case of the DigitalMatter GPS trackers the result appears to be:
Most makers reject this compromise as they need open access to the hardware and firmware.
Most industrial users accept this compromise as they need to reduce risk.
probably not the type of sensor that s going to be deployed in this case, but water meters typically have alarm logic (on top of configurable regular reporting intervals).
LoRaWAN certification would certainly be reassuring - but if you’ve built a device to a reference design using Semtech code, is it not a bit academic?
It strike me of more use is having (real) CE or FCC or similar certification so that you can use a MCU+Radio module in a product without having to get that element certified.
Hi @descartes…
Good heavens man, are you trying to put lawyers out of work? It’s all about money, liability and risk - and that means lawyers.
Back to the OP and a “large concrete building”. The builder wants to buy a bunch of LoRaWAN stuff from Descartes Galactic Enterprises PLC (DGE). The project is being run by accountants and lawyers. They worry about catastrophes and ask “Who are these DGE people?” and “How big is their product liability insurance?”. DGE’s insurer says “You’ll need to prove this stuff is ok before we’ll insure it”.
DGE has a choice:
Never going to exist - I stop as soon as the lawyers get involved - really. But Hotblack Desiato may …
I do take your point, but you may have missed the “a bit” bit. Certainly if someone is doing a project on the “lawyers are involved in the sales contract” scale, getting the certification is a minor expense. I’d still want to spend more money on testing the devices than on making them certifiable.
But for covering a large concrete building, we can start first week of Nov and evolve the project. Or we can spend a few months with some lawyers hammering out details. The first gets the job done whilst the project still has some point. The second sees the project become obsolete before the ink has been manufactured for the contract.
After 15 years of research, the lawyers have changed the classification of Descartes Galactic Enterprises PLC from “harmless” to “mostly harmless”.
thanks sebastianb, yes we’ve used 3 types of water meters, and these generally have an ‘alarm’ mode for tampering (i.e. sent as what we would call an ‘event’ rather than a periodic status reading) as well as sending their usage data periodically. FWIW I have not seen an example where the water meter sends a timely water-related ‘event’ such as (simplest) usage exceeding a threshold - I could imagine more sophisticated events like ‘usage not normal’. The meters are pretty impressive in terms of specification… waterproof with a 25-year (lifetime) battery life - sending 24 readings per day batched into a message every 12 hours.
The meters we’ve tested are from Diehl, Arad and Itron - I browsed around for links but most of these things are still in the development/evaluation stage (as understandably there’s a dependency on an available LoraWAN network which the water companies, in the main, don’t yet have).
There are two types of water meters, those measuring usage and those measuring presence. I guess the alarming kind meant by the OP is the second one, providing an alarm as soon as water is detected as that generally indicates a leak or other issue.