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:
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:
- The user cannot change the hardware.
- The user cannot change the firmware, only install new [binary/closed-source] versions from the manufacturer.
- The user can use a wide range of configuration options to change the device behaviour.
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:
- Use an ISO 9000 QA system for development and manufacturing and get the devices formally certified. Result; insurance ok and probable sale. Risk rests with the insurer.
- Use DGE’s processes and issue a manufacturer certificate of conformity. Result; no insurance but possible sale if DGE has a good balance sheet. Risk rests with DGE.
- Tell the buyer that it’s all academic. Result; no sale.
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”.
3 Likes
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.
Ah, you speak wisely Obe-Wan… I wrongly assumed ‘Type 1’. (we have type 2 also but I took the ‘alarm’ aspect for granted…)
We have used Axioma water meters in a pilot project in a residential area.
(no affiliation or such, but reasonably happy with those)
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.
They do not offer what i would call sophisticated events, but at least there are burst, leak and backflow alarms. Leak and burst thresholds are programmable, although i don’t think the company really expects the user to program these. But they are accessible in principle.
Else they resemble what you describe - we collect hourly readings batched into 3 (later 2) messages per day, with battery lifetimes forecast to be 16+ years (but of course critically depending on network quality / SF).
It’s probably also worth referring all the way back to the SNMPv1 architecture in the 1980s. This was intended to be “trap-directed polling”, i.e. the SNMP agent in the device sends an event notification (a “trap” in SNMP vocabulary) and the Network Management System (NMS) then used intelligence to increase polling to identify the cause of the event.
A number of LoRaWAN sensors seem to expect to be operated in the same way. The ones that I have worked with where this is relevant are ultrasonic range sensors when they are used for river-level warning. The logic goes something like this:
- The ultrasonic device periodically measures range. If the range has changed, the reading is sent as an uplink.
- If the central logic thinks that the new range measurement is a significant event then it sends a downlink to configure a higher rate of sampling and uplinking.
- Once the central logic no longer requires the higher rate of uplinking, it sends a downlink to return to the normal configuration for sampling and uplinking.
The ultrasonic range sensors that I have worked with (ELSYS and RadioBridge) do not have this logic built in to the sensor but they do seem to expect to be operated in this way over the network.
With SNMP the “intelligence” in the NMS to run trap-directed polling did not materialise at the time and so everyone ended up polling for everything all the time.
There are two problems with commanding a ramp-up of measurement rate in response to an anomalous event using a network like TTN:
-
if the uplink reporting the anomalous event does not make it through, there’s no way to command a change in rate, and the node has no way to know the message did not get through
-
if one sensor goes into anomalous mode, the immediate natural desire is to ramp up the sampling of other nearby sensors as well, but that cannot be done until they individually transmit their next successful uplink at base rate