Wow what a great place to share about sensors. My passion has been the interface between the real world and the digital domain. The world as we know it always has layers – so while we aim for a visualized story of some aspect of the real world – say temperature or stream depth– there are many aspects of collecting the data. Last year I bought a Honeywell Internet thermostat that allows me to see and control my home heating system from an App and the internet – but it doesn’t do something that is really valuable for me, keep a record of the temperature over time. So the simplest type of measurement and control hasn’t got it all, and it’s not open source so I can’t add that feature. Sigh!
Revital Katznelson does water quality training at national water monitoring conference and often starts with the most common form of measurement – temperature, and she has a great way of discussing measurement techniques – from temperature to the newly emerging cutting edge methods for dissolved oxygen.
Stream depth is a basic measurement, easy to do with a stage gauge, but how to do it automatically.
So for a water depth/stage gauge sensor, what do I really want to measure?
Here in N California we are really needing to think about low stream flows – which translates to monitoring the last trickle of water – often measured in cfs (cubic feet /sec) – but hey, automatically measuring cfs is difficult (unless channel can be changed see https://envirodiy.org/stone-control-structure-flume/), electronically measuring stream depth is easier – but challenging at the very low end of the spectrum – the close to zero depth. Raw sensors often don’t know the “zero” – but have to be taught it, or have it calibrated into their electronics in some fashion.
Other stream depth measurement techniques are good for measuring the peak flood stage – what happens to this river/stream at flood and how does the hydrograph vary over time – which of course is telling a cryptic story about the upstream watershed.
So taking apart the measurement layers – there are often different aspects of a desired measurement – high cost (stream flow to stream depth, or the ratings curve) and lower cost – stream depth.
Measurement units come in different flavors and often fashions – the USGS uses metric feet, the high tech industry metric inches – and most measurements in the scientific domain are totally metric – or SI (System International) units. Raw sensor components know nothing about units.
Electronic raw sensor components exploit some physical parameter that translates energy of one domain to an electrical domain.
The resistive properties of materials are often used to translate the weight of water, the pressure on the sensor, to a change of resistance, which can be measured by passing a current through it.
The measurements made on raw sensor components need to be translated to measurement units. Those units in turn need some traceability to an agreed common definition of units.
One of my fun projects was writing an RS485 modbus interface to a low cost water depth pressure sensor in a language called “squirrel”, and the resulting nut ran on an “Electric Imp” with built in WiFi and the depth readings are stored on “thingspeak.net”.
The sensor is measuring something very boring – its just sitting in bottle of water – the WiFi signal doesn’t stretch very far so can’t put it in anything useful. The code is here https://github.com/neilh10/ei_modbus
In a future blog I plan to talk about water depth sensors that translate to different electrical domains- voltage and current and standards like the 4-20mA interface from purchased pressure sensors to new raw sensors like MiloneTech eTape, and water depth “wire sensors” using capacitance techniques, and of course the software layers to have the calibrated measurement readings easily visualizable.