Weather station wake up triggered by either the RTC or a momentary switch?

(Ken Taylor) #1

The MHV building, internal environmental monitoring has been running for a while on an ESP8266 powered from a USB charger. Using this code it shows on the screen a 3 day forecast, conditions outside and conditions inside. Data is presented on Thingspeak in various ways . The outside data is obtained from a nearby weather station via Weather Underground and it would be nice to generate data from outside the MHV building, which means a battery powered device.

The intention is to use this rain gauge.

This could be combined with one of the solar radiation shields @eyal has been testing for temperature measurements or temperature measurements could be taken by a separate device built around one of these shields.

The older design Wemos were tested as consuming 140uA in deep sleep but there is a newer Wemos which doesn’t power the USB when powered by battery and therefore should be lower. So the current intention is to fit one of these powered by two AA LiFePO4, providing 2 x 600mAh, inside the rain gauge.

The rain gauge closes a momentary switch each bucket tip and I’ve been wondering the simplest way to keep the ESP8266 in deep sleep, and report each bucket tip. The starting point is this code which does deep sleep and uploads temperatures to Thingspeak but handling the rain gauge requires that it wake up the ESP. I’ve got some advice on how to do it and proposed an algorithm .

Reviews of the current plan and design advice would be appreciated.

(Derryn Harvie) #2

I’d probably attack this similar to the discussion you’ve had on Github, but with the following changes:

  • Instead of a separate RTC clock IC and microcontroller, just use a microcontroller that has an internal low speed oscillator. Pretty much every micro in the last 10yrs has this inbuilt.
  • Use a suitable regulator for the ESP that has an enable line. Therefore your microcontroller only needs to bring the enable line to the on position and the ESP will be active.

I believe this is one of those times that having a low power microcontroller do everything non-wifi related is much simpler, then just periodically wakeup the ESP and transmit the collected data. Keeping track of what has and hasn’t been sent is the only real complication to this, but that comes down to how long you want to keep a “backup” of the data.

(Ken Taylor) #4

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

(Eyal Lebedinsky) #5

A bit OT but… I was playing with some LiFePO4 batteries to see how they perform. I am using the AA (14500) size 600mAh ones from Bunnings. Here is how the battery drains running a fast loop (6 seconds) where the active part is about 400ms. Naturally, no LDO is used.

The total time is 86 hours, so on a 1minute cycle (which I often use) I can expect 860 hours (36 days). A set of three 1000mAh (18500, Bunnings 2@$13) should last 6 months (in the range that a 3400mAh Li-Ion 16850 does).

(Derryn Harvie) #6

Interesting Eyal. Correct me if I’m wrong, but on the surface these LiFePO4 batteries seem like a fairly expensive option for their run time (compared to Aldi NMHi)?

(Eyal Lebedinsky) #7

Well, at $5 each, compared to 3xAA (Aldi at $4?) which have 4 times the capacity, this is a no-brainer.

However, the benefit is for someone wanting a very small battery (one LiFePO4 AA size instead of three NiMH AA) and avoid using an LDO to be able to draw as much current as the battery can handle (much).

If a small solar charger is attached then the small capacity is not a problem either. Can even use the smaller Bunnings Duracell 14430 (AA) LiFePO4 at 400mAh. $6 for two.

For my usage (read a ds18b20 and report) I mostly employ Aldi batteries with a low current low DO and very low Iq MCP1700.

(Paul Needler) #8

I’m trying to repeat exactly the same story of project using and but am struggling with the same deep sleep RTC timer/wakeup manager issues. Did you succeed in developing this further and get a working algorithm?

(Ken Taylor) #9

Not yet. Both linked projects looked good, particularly the instructables.