It isn’t that hard to make an electronic rain gauge if you have a steady source of power or you don’t mind changing batteries often. But [Matthew Ford] offers a third option: a simple device with a Bluetooth Low Energy (BLE) module that can get a few years of a pair of AA batteries.
The approach has several advantages. Batteries make the device self-contained, and changing them infrequently is an obvious win. In addition, the BLE allows the device to be wireless and send data directly to an Android device. Thanks to a WH-SP-RG rain gauge, there’s not much to that part. The smart part is an nRF52832 module and some minor parts. The phone side uses an off-the-shelf Android app.
In a project like this, it is critical to have timers that really put the CPU to sleep. [Matthew] had to modify the Arduino libraries to allow the lp_timer objects to make it to an hour. Without the modifications, the timer can only reach 8.5 minutes. Sure, you could stack them, but that means taking a power hit multiple times an hour which would affect battery life.
Not the most complex project, but more complexity would mean lower battery life, so — as they say — less is more. We couldn’t help but think that with rechargeable batteries and a small solar panel, this could last a very long time.
LoRa, of course, is another choice. You can make 3D print a tipping bucket device, too.
nRF chips are pretty much the best when you want BLE and low power even though I hate using their Zephyr based Connect SDK.
Still Nordic chips are top notch.
You might find the Silabs EFR32’s more to your liking SDK-wise, and they have better power consumption figures to boot. They’ve basically held the crown for mcu power efficiency ever since they bought out Energy Micro.
Nordic nRF has serious silicon errata, nRF52832 at 49 pages and updated last week. Many regarding power consumption problems and enough to sink a product. Would not use them or consider them “top notch”.
https://www.nordicsemi.com/Products/nRF52832
Possibly ignorant question: If it can use that little power, would it not also work with a small solar cell and a supercap for operating in darkness?
The answer is probably yes, at least for a little while. Supercaps tend to have a pretty high self discharge (compared to primary and rechargeable batteries) so most of the energy stored would probably be wasted rather than power the load when in darkness.
My wireless (propriety 915Mhz) Ambient Weather WS-2000 which provides: temperature, humidity, windspeed, wind direction, rain gauge, solar radiation and UV Index runs off a built-in solar panel charged supercap and has two lithium AA backup batteries as backup has been running for 3 1/4 years and the backup batteries are normal (whatever that is)
Given a rain gauge is outside a small solar panel works fine. I combined wind speed and direction and a tipping bucket rain gauge into one instrument with a radio, and that has worked for about 5 years now with a 6v solar panel , an 18650 LiPo and a charge controller board. Plenty of room on the side of the rain gauge funnel / wind guard for the panel. I update to grafana about every 8 minutes, wouldn’t want to go any slower as watching the rain intensity of brief squalls can be interesting. As the sun is available for instruments outside, why not use it?
I wonder if there could be a good self-powering setup. Like a little cup fills with water against some spring, when it overcomes it it spills and the spring powers a little rf pulse that you can count with a connected device to measure rainfall.
Lets try with some ballpark figures:
In Germany, the average rain fall per year is 500-1000mm/A, i.e. up to ~1000kg/(m² * A). The typical rain gauge has a diameter of ~10cm, roughly 0.01m².
The small rocker as pictured above collects rain drops, swings over, and releases the water at a point roughly 1cm below.
So, the energy is up to 10kg/A * 9.81N/kg * 1cm = 98.1 Ncm/A = 0.981 J/A. ~ 1Ws/A. This is without any losses, with a 100% conversion efficiency.
A 1.2V/800mAh cell has roughly 1Wh = 3600Ws.
A small solar cell (10mm * 50mm = 500mm²) with 200W/m² catching 1000h/A of sunshine should be able to provide (500 * 200 * 10⁻⁶ W * 1000h/A) = 100 Wh/A (outdoor conditions similar to STC), and probably 1% on cloudy/rainy days.
A single BLE or ZigBee transmission is ~50…150mJ. So the Rain drop harvesting would allow ~10 transmissions per year, the single battery (ignoring self discharge) 36.000 transmissions per year (or 100 per day), and the solar cell would also support 100 transmissions on a rainy day.
Damn, then not likely practical. Could increase the collector area, drop height, and maybe a more efficient transmit but they’d all have to be pretty big increases to make it work.
I am left disappointed. I thought he would be harnessing the energy of the falling rain with some kind of microjoule harvester to power the BLE sensor.
The milled aluminum versions sold by companies like AEM (bought out High Sierra) use a simple magnetic reed switch to detect tips.
The ones I’ve been installing have a chunky Sutron 9210 Xlite datalogger running off a 12v motorcycle battery fed by a 30A solar panel. It’s definitely a power hungry system, and if we get too many rainy days in a row with no breaks in cloud cover we have to go out and swap the battery. The system is set up to report in every 15 minutes on VHF freqs set aside for the ALERT2 Hydromet data.
Our two biggest headaches are bird guano clogging the funnel and loss of accuracy during heavy rain. More rain means faster tipping which sloshes water. You also loose a measurable amount of water mid tip. Were currently looking at the next gen IR optical gauges as a lower cost lower power replacement.
Good write up on rain gauge deployment and issues: https://thecavepearlproject.org/2023/04/
High Sierra tipping bucket rain gauge: https://thecavepearlproject.org/wp-content/uploads/2023/04/20230417_mechanismhighsierratrg_640pixh.jpg
In N.C. we have IFLOWS(think they renamed it??..maybe ALERT???)
Starting a few years back they started using cell modems vs. VHF.
That worked GREAT when we lost ALL cell service for 5++ days
in HELENE……hahahaha
Gota love the gov. and their bright ideas.
BTW=== What was left of the VHF system still worked.
I wish there was a low cost, open source system for rain/WX/stream gauges like
the IFLOWS/ALERT system. With off the shelf hardware!
Using V or UHF, low cost radios in a MESH topo.
I got to talk to the guy managing their sensor network at a National Hydrologic Warning Council meeting down in Texas. He had many choice words regarding the switch to cellular only. Showed us a picture of a sensor that was still transmitting and functional after it had been completely scraped off a bridge and left in a field miles away. Lo and behold, it was one of the remaining VHF units.
haha this article is a good anecdote for why i can’t stand arduino (philosophically speaking). if i’m really designing for embedded, i want to actually program the device itself, not some limited abstraction of it. for a while now, i’ve kind of assumed i’m being foolish, hand-copying i/o mappings from the datasheet at the start of every project instead of just like #include “stm32_timers.h” or whatever. but not having proper control over the timers is just absolutely a non-starter for me. the detailed features of the timers are the reason i’m writing for embedded, usually!
anyways a note on batteries…whenever i see a project on here, a lot of times my first thought is how that project will age. people often publish their hacks the moment the prototype works, but most of my hacks have project diaries stretching back for years / decades. the AA battery is attractive but all the modern alkaline AAs spew potassium hydroxide all over your battery compartment. this is especially true for devices where the battery runs down slowly over years. i don’t know if it’s gotten worse in the last 15 years or if i just notice it now. but it’s the fatal defect in almost every AA/AAA-powered device i have.
so i switched to buying the lithium AAs, and i wound up throwing away a malfunctioning light shortly after putting lithium AAs in it, only to reuse the battery in something else and find out the battery itself had flaked out. the power from the battery oscillates in normal operation. i don’t know if the battery is defective or if the interaction between the power supply in the battery and the power supply in the light caused some sort of feedback / resonance sort of thing that fried it. but now i’m skeptical of AAs all around.
so i’m one by one replacing my AA devices with built-in-rechargeable-lithium versions. and several of my project diaries, if i scroll back a decade, started with AAs and then had to evolve away from them. especially if they have to operate in a humid environment like a rain gauge!
Interesting comments on AA batteries.
The next version of this project will use a coin cell at the rain gauge and add temperature, RH, and pressure.
It will also save more detailed historical data and serve web based charts (from an indoor ESP32), but will be able to be run completely off-line, not even a router needed.
However I did have a user of one of my other coin cell BLE weather projects report that coin cells don’t work well at below zero temperatures.
One of the most overlooked platforms for excellent low-power performance is the MSP430. It provides various sleep modes and wake-up timers that can extend battery life to the point where shelf life of the battery becomes a limiting factor.
I selected and used the MP430 ~20 years ago for a low-power battery powered project based on it 16 bit word size and very low power sleep modes and fast wake up (at the time) and large variety of options. Nice part
Hasn’t been true for at least a decade. It was the king, but modern low power ARM chips trounce it – it’s not just how good your sleep mode is, its how much total power you use while awake. Running faster so you can get back to sleep asap ends up using much less power overall than a slower chip that has a lower instantaneous consumption but needs to be on for far longer to complete it’s tasks.
Why can’t you just have the BLE in some sort of Perpetual Sleep Mode.. The only Wake State is when the Bucket Trips, the BLE Device Powers up.. Counts Internally, Sends the Data to what ever the Receiver is, Then goes back to Sleep til the Next Bucket Trip..
Lather, Rinse, Repeat till batteries are Low.. Then the BLE will alert the End User..
Cap
“Why can’t you just have the BLE in some sort of Perpetual Sleep Mode”
That is what this project does :-)
The wake states are:- bucket tips, data save timer (1hr) and BLE Advert and connection.
What software technologies used?
does ai use a linux.
AI Overview Learn more
Yes, AI development and deployment heavily utilize Linux as the operating system
due to its open-source nature, robust performance, and extensive ecosystem of toolsand libraries specifically designed for machine learning and artificial
intelligence tasks; making it a preferred platform for most AI projects,
especially in research and enterprise environments.