The EDU build we released in 2020 provides remarkable flexibility for courses in environmental monitoring. However an instructor still needs to invest about five days ordering parts, testing components, and preparing kits for a 15-20 seat course being run remotely. (only 1/2 that is needed for in-person courses where the students pin & test the parts themselves) While that’s not unusual for university-level lab based subjects it is something of a stretch for high school teachers. And thanks to COVID chip shortages, many modules that were only 99¢ at the beginning of this project could now set you back $5 each. So with all that in mind, we’ve continued development of a ‘lite’ version of our logger with the lowest possible prep. That new baby is now ready for release with data download & control managed through the IDE’s serial monitor window.

With just three core components as our starting point, the only hardware option was to remove the SD card. Groundwork for this change was already in place with our use of an EEprom to buffer data so that high-drain SD saves only occurred once per day. Getting rid of power hungry cards also opened up the possibility of running the entire unit from the coin cell on the RTC. But a power budget that small will necessarily add complexity to the base code, which must minimize run-time even though EEproms are notoriously slow devices. And most garden-variety memory chips have a lower limit of 2.7v – so a nominal 3v CR2032 can only be allowed to fall about 300mv under load before we run into trouble. That voltage drop increases over time because the internal resistance of a coin cell is only 10 ohms when new, but approaches 100 ohms by end of life. In addition, it’s not unusual to see a 50mv delta at the battery terminals for every 5°C change in ambient.

But if theres one thing I’ve learned on this project it’s that datasheets only tell you so much about system behavior in the real world – especially with stuff constructed from ‘Lego-style’ modules carrying half a dozen unspecified bits. So let’s just build one and see how it goes…

Modifying the RTC module:

Cutting the VCC leg depowers most of the logic inside the DS3231. However the chip will still consume an average of 3µA through VBat to keep the oscillator, temperature compensation & comparator logic working. RTC current can spike as high as 650µA every 64 seconds when new temperature readings occur. Bridging VCC to Vbat also means a 3.3v UART will push some sub-milliamp reverse currents through an older cell. But I’ve yet to have a single problem (or even any detectable warming) after many days with loggers connected during development. Despite dire manufacturer warnings that reverse currents beyond 1µA will heat manganese-dioxide/lithium cells until they explode, the ones I’ve used so far survive the abuse without issue. I’ve no doubt the UART connected time is shortening the batteries lifespan slightly, in fact Panasonic specifies: “the total charging amount of the battery during it’s usage period must be kept within 3% of the nominal capacity of the battery”, so it’s a good idea to remove the battery if you are spending an extended time with the units connected to the serial line to keep the total reverse current time to a minimum. But given our tight operational margin I don’t think we can afford to lose two hundred and fifty millivolts over a Schottky protection diode. A proper solution would address this by OR-ing the two supplies with an ideal diode circuit, but on a practical level it’s easier to just to pop in a fresh battery before a long deployment.

Modify the Pro Mini board:

An 8Mhz Pro Mini continues as the heart of our loggers because the 328p is still the easiest low-power option for projects that aren’t computationally demanding. These clone boards usually sleep below 1µA with the BOD turned off, but it’s worth noting there are some with fake Atmel chips that won’t go below 150µA. Cheaper boards usually ship with ceramic regulator caps (instead of tantalums) but that just makes them more resilient if you accidentally connect power the wrong way.

Join the two components:

This two module combination usually sleeps around 1µA and most of that is the RTC’s (IBATT) timekeeping current as the 328p should only draw ~150nA in powerdown mode. If we assume four readings per hour at 5mA for 10msec, the battery life calculator at Oregon Embedded estimates a 220mAh battery will last more than 10 years…which is ridiculous. We know from the datasheet that temperature conversions bring the RTC average up to 3µA – which isn’t showing up on this direct measurement. And there’s the battery self discharge of 1-3% per year. Perhaps most important there’s the complex relationship between pulsed loads and CR2032 internal resistance, which means we’ll be lucky to get half the rated capacity before hitting brown-out at 2.7v So a more realistic estimate would start with the assumption that the batteries only deliver about 110mAh with our logger consuming whatever we measured + 3µA (RTC actual) + 0.3µA (self-discharge). To be extremely conservative we can round that up to 5µA continuous, with four 5mA*10millisecond sensor readings per hour, and we still get an estimated lifespan of about two years. So our most significant limitation is the amount of EEprom memory rather than battery power.

The Code: [posted on Github]

The most important difference between a coin cell powered logger and our AA powered units is that the battery has a high probability of being depleted to the point of a BOD restart loop (which causes rapid flashing of the D13 LED). So we use a multi-step serial exchange in Setup() to protect data already present in the EEprom from being accidentally overwritten.

In Setup()

A UART connection is required at start-up so those menu-driven responses can occur through the IDE serial monitor. These have fairly aggressive timeouts to avoid running the CPU during unintentional restarts. The menu sequence can be re-entered at any time simply by closing & re-opening the serial monitor window:

The first menu asks if you want to download the contents of EEprom memory to the serial monitor window. This can take a bit of time with larger EEproms at 250000 baud, which is near the fastest rate an 8MHz ProMini can reliably sustain. With the IDE you must then copy & paste (Ctrl-A & Ctrl-V) that into a text editor to save the data as a .txt file that Excel can import. While this process is a bit clunky, everyone already has the required cable and data retrieval is driven by the logger itself.

Battery replacement resets the DS3231 to Jan 1st 2000. So after a data download the logger checks the clocks EOSC register and, if needed, asks the user to enter current time as YYYY, MM, DD, HH(24h), MM, and SS to reset the clock:

Index TimeStamp(s) are then written to the internal EEprom so the timestamp for each individual sensor reading can be reconstructed during data retrieval using the record number to create an offset that gets added to the index value. This technique saves a significant amount of our limited EEprom memory and all it takes is =(Unixtime/86400) + DATE(1970,1,1) to convert Unix stamps human readable time in Excel.

The on screen menu then asks the user to enter the ‘start’ command again. Only when that second ‘start’ confirmation is received are the EEprom(s) erased by pre-loading every location with ‘0’ values that also serve as End-Of-File markers during the next download. The red D13 led then blinks slowly while the logger waits for the first sampling interval alarm to begin its run.

Main LOOP()

To save power slow functions like digitalWrite() are replaced with faster port commands. Careful attention is paid to pin states, peripheral shutdowns (power_all_disable(); saves ~0.3mA) and 15msec sleeps are used throughout for battery recovery. Waking the 328p from powerdown sleep takes 16,000 clock cycles (~2milliseconds @8MHz +60µS if BOD_OFF) and the ProMini draws ~250µA while waiting for the oscillator to stabilize. Care must be taken when using CLKPR to reduce system speed because the startup-time also gets multiplied by the divider.

( Note: For the following images a Current Ranger was used to convert µA to mV during a reading of the RTC’s temperature register at 1MHz. So 1mV on the oscilloscope means 1µA is being drawn from the Cr2032 )

Sensor readings are captured when the RTC alarms at SampleIntervalMinutes, but the ‘lowest’ coin cell voltage is usually recorded ‘Once-Per-Day’ at the midnight rollover. That battery check can be forced to occur at every EEprom write event by setting BatteryReadingEveryCycle=true at the start of the program. Two 16-bit buffer arrays are used to reduce the number of EEprom writes: sensorDataBuffer[ ] and it’s associated pointer are filled & written to the I2C EEprom in the forward direction while the opdDataBuffer[ ] gets filled and written backwards from the end of the memory space. So both can share the same EEprom and when the two EEprMemPointer(s) overlap that storage space is full and the logger shuts down. If there is more than one chip on the system then the two data streams can be sent to separate EEproms via the two EEpromI2Caddr defines at the start of the code.

CR2032 voltage is only checked during the Write_i2c_eeprom_array function because an unloaded coin cell voltage does not change – even when the battery is almost dead. At 1MHz the ProMini adds adds about 1.4mA to the EEproms 2mA write current. Peak load is reduced further by looping through SLEEP_MODE_ADC readings until the battery voltage starts rising after the write finishes. This assures that the lowest rail is captured even though the exact timing of that minimum varies from one memory chip to the next.

Adding Sensors:

The ‘RTC_ONLY’ configuration for this logger records a 0.25°C temperature record from the DS3231, index-encoded to use only one byte per reading. This allows ~4000 readings to be stored in the 4k EEprom on the RTC module. This works out to a little more than 40 days at a 15 minute sampling interval, but you can set SampleIntervalMinutes to any even divisor of 60.

That little AT24c32 doesn’t last very long with sensors that generate 2 or 4 byte integers. The solution is to combine them with larger 32k (AT24c256), or 64k (AT24c512) chips so the sensors arrive with the extra storage space they require. These EEprom modules can usually be found on eBay for ~$1 each and they work with the same page-write & addressing code as the 4k EEprom.

You must use low power sensors with a supply range that extends to our 2.7v EEprom/BOD limit. A good sensor to pair with this logger should sleep around 1µA and take readings below 1mA. Sometimes you can pin-power sensors that lack low current sleep modes although if you do that be sure to check for unexpected current leaks in other places such as bus pullup resistors. Choose libraries which allow non-blocking reads so you can sleep the ProMini while the sensor is gathering data and check that those libraries do not contain any delay() statements. In that regard my favorite sensor combination for this logger is an NTC thermistor & CDS cell which adds nothing to the sleep current. We explained how to read resistive sensors with Arduino’s Input Capture Unit in some detail back in 2019; so here I will simply show the hardware connections. Add these passives to the Pro Mini BEFORE joining it to the RTC module:

Space gets a little tight in that D9 corner so I then jumper D2->SQW with a piece of flexible wire which I can route between the boards to avoid covering the D13 LED. Other common modifications to the basic 2-module logger include:

The additions shown above push measured sleep currents to 2-3µA (so ~6µA actual) but that still gives a >1 year estimates on 110mAh. With all due respect to Ganssle et al, the debate about whether buffering caps should be used to extend operating time is something of a MacGuffin because 1uA leakage currents are far less important when you only have enough storage for one year. The 6.3v 1000µF tantalum shown above increased sleep current by about 1µA. That’s 1µA*24h*365days or about ~ 8.76 mAh/year in trade for keeping the system above 2.7v as long as possible. That means we don’t need to lower the BOD with fuses & custom bootloaders that bork code portability. And pushing the limits of power optimization can get a little flaky on these cheap boards, so it’s also good to have those ‘Get out of jail free‘ fuse defaults available at reboot. When you only service your loggers once a year, any tweaks that require ‘special procedures’ in the field are things you’ll probably regret later.

Leakage scales linearly with capacitance so use the Falstad simulator to see what size you actually need. Capacitors with a rated voltage 10x higher than the applied can reduce leakage by a significant amount. So look for 16v to 30v rated caps if you can find them. While they are a bit bulky, electrolytics also work fine. The 220µF/25v caps I tested only added ~0.1µA to the sleep current (whether tantalum or electrolytic) and these can be obtained on eBay for <50¢ each.

As the buffering cap gets larger, you need to add more ‘recovery time’ sleep before the rail voltage is restored after a large load. Using a capacitor to smooth out the current drawn also protects the unit from impacts which can briefly disconnect the spring contact under the coin cell. This is a such common problem in our other loggers that we use a drop of hot glue to lock the batteries in place before deployment.

Discussion:

CLKPR brings the ProMini down to 1MHz and a current of ~1.3 mA however the energy cost per logger event increases significantly as the system clock gets divided. But with our slim operating margin the growing internal resistance of the coin cell means we have to stay above 2.7v even if it means using less efficient code. Running from the internal oscillator might help but is avoided because our ICU timing method needs the thermal stability of an external oscillator and, the internal oscillator makes UART coms flakey. FRAM has much lower saving currents than standard EEproms but those expensive chips sleep around 30µA so they aren’t viable for low-power systems. (…unless you pin-power them so you can cut power during sleep)

In the next three images, a Current Ranger converts every 1µA drawn by the logger to 1mV for display on the scope. The last two spikes are transfers of buffer-array data into the 4K EEprom on the RTC module while the CPU takes ADC readings of the rail voltage. Note that our code staggers EEprom save events so they don’t occur in the same pass like this, but I forced them together for this test to illustrate the effect of repeated loads:

The basic RTC-only sensor configuration reached a very brief peak of ~2.7mA with no buffering cap, 1.5mA with 220µF and less than 1mA with 1000µF. The amount of voltage drop these currents create depend on the coin cells internal resistance but a typical unbuffered unit usually sees 15-30mV drops when the battery is new and this grows to ~200mV on old coin cells (pulled from loggers that have been in service since 2018). The actual drop also depends on time, with subsequent current spikes having more effect than the first as the internal reserve gets depleted. The following images display the voltage droop on a very old coin cell pulled from a logger that’s been in service since 2016 (@3µA average RTC backup)

After many tests like those above, our optimal solution is to run the processor at 8MHz most of the time by breaking up the execution blocks with 15 millisecond POWER_DOWN sleeps before the CR2032 voltage has time to fall. The processor is brought down to 1MHz only during the EEprom save event where the block can not be divided (and that only happens when the buffering arrays are full….)

Even with fierce memory limitations we only use the 328’s internal 1k for a couple of index variables that get written while tethered to UART power. EEprom.put starts blocking the CPU from the second 3.3msec / byte, and internal EEprom writes adds an additional 8mA to the rest of the system. Multi-byte page writes aren’t possible so data saved into the 328p costs far more power than storing those bytes in an external EEprom. However it’s worth noting that reading from the internal EEprom takes the same four ticks as an external, while PROGMEM takes three and RAM takes two clock cycles. So it doesn’t really matter to your power budget where you put constants or even large lookup tables.

A simple optimization we haven’t done with the code posted on GitHub is to increase the I2C buffer. All AT-series EEproms are capable of 32-byte page-writes but the default wire library limits you to only 30 bytes per exchange because you lose two for the register location. So we used 16-byte buffer arrays in the starter code but you could increase those to 32 bytes each by increasing the wire library buffer length:

In wire.h (\Arduino\hardware\arduino\avr\libraries\Wire\src)
#define BUFFER_LENGTH 34
AND in twi.h (\Arduino\hardware\arduino\avr\libraries\Wire\src\utility)
#define TWI_BUFFER_LENGTH 34

With larger EEproms you could raise those buffers to 66 bytes for 64 data-byte transfers. That buffer gets replicated in five places so the wire library would then require more than 300 bytes of ram. 128k EEproms often refresh entire 128-byte blocks no matter how many bytes are sent, so increasing the buffer reduces wear considerably for those chips, while 64k & below usually perform partial page-writes more gracefully.

An average sleep current of ~5µA *86000 seconds burns 430mAs/day. Even with a sampling event that draws a hefty 5mA*10msec, 96 readings per day will only consume about 5mAs. Cutting that in half by doubling the size of some buffer is only going to save you 2.5mAs per day, so it will take 172 days to earn back the amount of power used by only one day of sleep. I usually do this buffer increase anyway – but only in the hopes that reducing the number of pulse-load events will extend battery life in some way other than the actual power being saved. No matter what optimizations you make, battery life in the real world can also be shortened by temperature cycling, corrosion from moisture ingress, being chewed on by an angry dog, etc.

An important topic for a later is data compression. Squashing low-rez sensor readings into only one byte (like we do with the RTC temperature) is easy; especially if you can subtract a fixed offset from the data first. But doing the same with high resolution temperatures from a thermistor is more of a challenge. Do you use ‘Frame of reference’ integer deltas, XOR’d mini-floats, or custom-packed BCD? We can’t afford much of an energy tradeoff for heavy calculations on our little 328p so I’m still looking for an ‘elegant’ solution to that puzzle.

Hopefully this new member of the Cave Pearl family goes some way toward answering people asking why we haven’t moved to a custom PCB: Using off-the-shelf parts is critical to helping other instructors base their courses on our work, and when you can build a logger in about 15 minutes, from the cheapest stuff available, that still runs for a year on the coin cell… why bother? We do sampling dives all the time with those 50mL centrifuge tubes and I’ve yet to see ‘Nunc’s from Thermo leak at depths far beyond what an IP68 housing could handle. And again you are only talking about $1 each.

We’ve been having fun embedding these ‘Pro-Minillennium Falcons’ into rain gauges and other equipment that predates the digital era. There’s a ton of old field kit like that collecting dust in the corner these days.

References:

Heliosoph: Arduino powered by a capacitor
Nick Gammon: Power Saving techniques for microprocessors
Jack Ganssle: Hardware & Firmware Issues Using Ultra-Low Power MCUs
Using a $1 DS3231 Real-time Clock Module with Arduino
An Arduino-Based Platform for Monitoring Harsh Environments
Oregon Embedded Battery Life Calculator
WormFood’s AVR Baud Rate Calculator
ATmega328P Datasheet