Thanks to those that have provided advice. Most advised using a separate processor as well as an ESP8266 in a tipping bucket rain gauge. lakidd suggested a ATtiny85 to detect each reed switch action and then power up the ESP, @Harvs suggested collect data with a low powered processor and
periodically wakeup the ESP and transmit the collected data
@eyal suggested similar, chaeplin proposed an ATtiny to collect data and a DS3231 clock to periodically wake the ESP8266 and PuceBaboon suggested another design where the ESP was unpowered until the reed switch was closed.
I’ve purchased ATtiny85s and a programmer but I’m keen on minimalism and the ESP32 has that functionality inbuilt and may replace the ESP8266 in this device in future. Therefore, I’ll try without an ATtiny85 in the first instance.
Previously it was suggested that a Wemos D1 mini pro powered directly from 2 LiFePO4 AA batteries could be used on the downstream side of the voltage regulator. Testing of power consumption in deep sleep in this mode was undertaken.
| Situation… | Power Consumption (uA)
| As supplied… | 365
| Without voltage regulator | 160
| Without voltage regulator |
| and USB chip… | 18.1
From this it can be seen that the Wemos D1 mini pro is only suitable with the voltage regulator and USB chip removed which makes them less desirable. Unexpectedly, the older design Wemos were better, consuming less with a voltage regulator 140uA in deep sleep, than the new design without a regulator. Testing a fake Wemos gave 180uA in deep sleep and 80uA with the regulator removed and the USB chip still in place. Wemos have a convenient form factor though, and with an OTA programming implementation may still be preferable to a custom board design.
AA batteries will fit inside the rain gauge casing which makes then convenient. I purchased Etinesan batteries which claim “600mAh (REAL CAPACITY,NO CHEATING)”. I tested one of these with a Hobbyking Eco Six charger and got 562mAh which, while below spec, is much better than the usual terrible capacity I’ve got from batteries purchased on eBay.
The ESP8266 requires 40mAsecs to transmit a sample using UDP vs 15mAsecs to wake up with WiFi but not transmit vs 5mAsecs to wake up with WiFi off and the 18uA in deep sleep is equivalent to 65mAsecs in an hour. In Canberra annual rainfall is 630mm in Bali 800mm. Each bucket tip is 0.3mm so there is 2100 bucket tips per year in Canberra. Assuming a report every 5th tip it will require 16,800mAsecs to report tips and a further 8,400mAsecs to count more tips totalling 25,200mAsecs per year. On the planned 1000maH of battery capacity it could last 7 years of bucket tips.
If it wakes hourly and transmits temperature it will cost 40mAsecs. Combined with deep sleep it could last 340 days without rain on the planned 1000maH of battery capacity . lakidd reports 1uA with a switch open and the ATtiny85 waiting for a switch closure but being below the quiescent current of the voltage regulator used in that design, seems too low. 1uA rather than 18uA when the ESP is not required to be awake would drop power consumption by a bit over half while not raining.
These estimates suggest battery time will be greater than 9 months and will be dominated by staying alive rather than reporting rain. Use of a solar cell could be considered for a future modification which would allow halving battery capacity and multi year battery life but a colleauge reports that the gauges collect bugs and have to be serviced occasionally anyway.
The algorithm would be so much easier if the RTC counter was not reset on a reboot. There seems no way to do that but there is a LUA library which does it’s best with the facilities available, though as far as I can tell there is no equivalent in the Arduino environment. The LUA libray is written in C and therefore can be adapted to Arduino, ideally as a library, but I’m not sure how much effort is required. The algorithm “will lose the time if the module is unexpectedly reset” which will happen on bucket tips. In our case time is used primarily to decide when to report bucket tips and consequently inaccuracy is not too important as reporting a little either side of the intended time is OK. Sufficient accuracy ought to be obtainable by keeping a record of the current time in RTC memory and when woken on a bucket tip using the last known time plus a fixed offset of average boot time.
Incorporating advice changes previous ideas somewhat as follows.
The Issues
- If a reset happens during a temperature reading it would be lost but that wouldn’t matter much and a temperature can be included with each bucket tip report.
- A lost bucket tip can seriously impact rainfall measurement accuracy. The minimum interval between bucket tips is 0.4 secs which is long enough for a user program to start running but not long enough to send a message. Violent rain will produce a maximum tipping interval of 29secs which is vastly longer than the absolute minimum tipping interval so resets prior to going into deeps sleep mode should be rare.
- It is quite likely that in a downpour associated with a maximum tipping rate WiFi wouldn’t get through the rain.
- Reporting no more often than 5 minute intervals helps with battery consumption.
Possible Solution
- Maintain a bucket tip counter in RTC memory.
- Always send the total so tips are never missed.
- Timing for determining tipping rate is done by the receiving station.
- Wake up every hour normally and send temperature but wake up every rainfall reporting interval after the first bucket tip until a successful report.
- By default wake up with radio off to reduce power consumption a lot.
State Diagram
