2-Part ProMini logger runs > 1 Year on a Coin Cell

This ‘two-part’ logger fits nicely inside a 50mL Falcon tube. Soldering the Pro Mini & RTC together takes about 20 minutes. The 4K EEprom on the RTC board will hold 4096 1-byte RTC temperature readings (~ 40 days worth @ 15 min. intervals) and that’s easily extended with $1 memory chips or modules.

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 cheap modules carrying half a dozen unspecified bits. So let’s just build one and see how it goes…

Modifying the RTC module:

Clipping the VCC leg (the 2nd leg in from that corner) forces the DS3231 to run from the coin cell full time.
Disconnect the modules indicator LED by removing its limit resistor.
Remove the 200ohm charging resistor & bridge VCC to the backup power line at the black end of diode.
Three mods to the RTC module: Running from the Vbat also disables 32KHz output so I usually clip that header pin. Watch out for the ‘-M’ variant of the DS3231. We’ve had several batches of those over the years where the temperature register was off by 5°C or more. Try to use ‘-N’ or ‘-SN’ chips if you can get them.

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. Drift on these DS3231 RTCs is usually a loss of ~4-5 seconds per month, but could be up to twice that for -M variants of the chip.

Modify the Pro Mini board:

90° header tails on the left side are clipped to avoid accidental contact with the I2C jumpers later. Vcc & Gnd left long.
Carefully clip away the regulator from the 2-leg side. Also remove the power LED limit resistor.
Optional: Add the regulators orphaned 4.7µF(?) input cap to the rail by bridging it to VCC.
Three removals & one addition prep this Pro Mini clone for assembly. The reset switch is removed to avoid compression by heat-shrink later. The logger can then only be restarted with a serial connection, but that’s on purpose.

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. At 8Mhz the ‘official’ lowest safe voltage for the 328p is 2.7v, so that’s where the default BOD is usualy set. But I sleep with BOD off because I’ve noticed that if the BOD does get triggered by low battery voltages then the processor goes into a high 1mA drain condition and this makes AA’s leak battery goop all over the inside of our normal 3-part loggers. But you still have the ‘default’ 2.7v BOD while the processor is operating so you probably want to stop logging when the rail starts reaching ~2750mv. Also keep in mind that there is range on that brownout threshold, from min. 2.5v to max. 2.9v. So one 328p may be more tolerant to running at low voltages than another.

Join the two components:

Resistor legs wrapped in heat shrink extend the A4/A5 I2C bus. These two wires must cross over each other to align with RTC connections.
Add a layer of double-sided foam tape to prevent contact between the two boards. Extend the VCC & GND headers with resistor legs. Then remove the tape backing.
Carefully thread the four I2C bus jumpers through the RTC modules pass-through port. Press the two boards together onto the double sided tape.
Solder the connections to the RTC module. Now you can see why I trimmed the three header pins on that one side.

NOTE: Don’t trim down the VCC & GND wires if you are going to add a rail buffering cap – the leftover ‘tails’ make perfect connection points for that extra capacitor. (see below for details)
Clip the (non-functional) 32kHz pin and add solder to the SQW header pin on the RTC module. Solder a resistor leg to interrupt input D2 on the Pro Mini.
Add heat shrink & join D2 to the RTC SQW alarm output.
Then heat shrink the entire stack with ~4.5cm of 25mm (1inch) diameter tubing & cut that away from the battery holder.
The 2-module stack usually draws ~1µA in powerDown, but with part variability some go up to 2µA. Cheap modules often have leftover flux residue which can cause current leaks. It’s worth the time scrub these boards with isopropyl alcohol before assembly to reach the lowest possible power consumption. I found no significant difference in sleep current between setting unused pins to INPUT_PULLUP or to OUTPUT_LOW.

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 [with BOD off]. 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 yearswhich is ridiculous. We know from the datasheet that 575µA 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 battery only delivers about 110mAh with our logger consuming whatever we measure + 3µA (RTC actual) + 0.3µA (self-discharge). 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 ‘raw’ option helps spot memory alignment errors when adding new sensors to the base code. There is also an unlabeled ‘test’ option which skips the EEprom erase during development & testing. If you see random characters in the download window you have the baud rate set incorrectly. Reset the baud and the menu should display properly HOWEVER you then need to close & re-open the window (this restarts the promini with serial window at the correct baud). If you try to Ctrl-A & Ctrl-V when the the window still has garbled characters at the top then those are the only charcters that will copy out.

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. Then copy/paste (Ctrl-A & Ctrl-V) everything from the IDE window into a text editor so you can 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 Oscillator Stop Flag (OSF) and, if needed, asks the user to enter current time as YYYY, MM, DD, HH(24h), MM, and SS to reset the clock:

Note: No sensor data is lost from the EEprom when you replace a dead coin cell and you can do the entire data retrieval process on UART with no battery present. But time reset should only be done after installing a new battery or the settings will not be retained. You can force a time reset by temporarily removing the battery.

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 which will serve as End-Of-File markers during the next data 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 much 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 )

Here CLKPR restores the CPU to 8MHz just before entering powerdown sleep, and then slows the processor to 1MHz after waking. The extra height of that first spike is due to the pullup on SQW. Cutting the trace to that resistor and using an internal pull-up reduces wake current by 750µA.
Here the logger was left at 1MHz when it entered powerdown sleep(s). Waking now takes 16 milliseconds – wasting even more power through the 4k7 on SQW when the RTC alarm is asserted.

Sensor readings are captured every time the RTC alarms at SampleIntervalMinutes, but the ‘lowest’ coin cell voltage is usually recorded only ‘Once-Per-Day’ at the midnight rollover. The logger can be forced to log the battery voltage at every EEprom 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 3mA*10msec sustained write current. ADC prescaler ratio is changed to compensate for the reduced main system clock speed. Peak load is reduced by looping through SLEEP_MODE_ADC readings until the battery voltage starts rising after the write finishes. This assures that the lowest coincell voltage is captured though the exact timing of that minimum varies from one memory chip to the next. Logger shutdown gets triggered when the EEprom write brings the rail voltage below the 2750 mv cut-off, which happens when the internal resistance of the coincell rises at end of life.

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.

We made extensive use these RTC temp records in our cave drip loggers at the beginning of the project.

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.

The headers on this common BMP280 module align with the 32k headers in a ‘back-to-back’ configuration. The tails on the YL-90 breakout extend far enough to connect the two boards. Note this sensor module has no regulator which is better for low power operation.
Pin alignment between the YL-90 and this BH1750 module is slightly more complicated as you must keep the light sensor facing out. BMP280 sensors usually run about two years, but the BME280 variant (includes RH) has a shorter lifespan and should be replaced yearly.
After removing the EEprom’s redundant pullups, clip away the plastic spacers around the header pins. Then wiggle the BH1750 over the headers on the 32k module. Solder the points where the pins pass through the 1750 board. I2C pullups on the sensor boards can be removed but having 2.7-3k total is actualy better for a 3v system than the single 4k7 on the RTC module.
I2C pin arrangement on the RTC module does not match that on the sensors. But the required cross-overs are easy with a 4 wire F-F Dupont cable. (which usually comes with those red 32k modules) For loggers that will get knocked around during deployment, it’s better to solder these connections.
Removing the 662k reg. & bridging the in->out reduces sensor board sleep from 3µA to < µA

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:

D6=10kΩ 1% reference resistor , D7=10k NTC, D8=300ohm, D9=CDS cell. Note that the CDS cell could be replaced with ANY any type resistive sensor.A typical 10kNTC reaches ~65kΩ near -10°C and an LDR usually reaches 65k at midnight in an urban environment.
All four passives are connected TOGETHER. So you MUST first float the lines you are not reading to isolate them from the circuit while you read a specific sensors resistance.
A 104 cap to GND completes the ICU timing circuit. With 0.1uF as the reservoir cap, each read takes ~1-2msec in sleep mode IDLE.

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. Don’t expect the NTC you have in your hands to match exactly the values provided by its manufacturer. Fortunately there are several online calculators to choose from when determining your NTC thermistor constants. For calibration data, I use a food dehydrator to heat the loggers to around 45-55°C, let it cool for a few hours to room temp. for the midpoint, and then put them in the refrigerator overnight for a cold point ~5°C.

Other common modifications to the basic 2-module logger include:

Shown: A 6.3v 108J buffer cap on rail wires after they pass through the RTC module. 1000µF is complete overkill as anything from 150 to 470µF would do the job 220µF 25v Tantalums are the same size as the one shown above. Avoid inserting the battery backwards or the tantalum cap will short out.
Analog ports can host a RGB indicator LED. No limit resistor is needed if you are careful to light the channels with INPUT_PULLUP which keeps the current below 50µA. Color LED’s can also be used as frequency specific light sensors. Lower LED currents are possible. Leave the D13 red led on the promini to show when you are trapped in a bootloader/restart loop.
You can connect these 32k memory modules with a 4-wire Dupont as shown above , but you can also solder them into place.
With a practiced hand you can do a memory expansion right on the RTC module without changing the sleep current: Here I’ve replaced the default 4k AT24c32 with a 64k AT24c512. 64k is the sweet spot for single sensors generating a 2-byte integer value as you can store ~340 days of data with a 15minute interval. The RTC modules default configuration pulls address pins high (=0x57) with a 4k7 resistor block, while the red YL-90 modules pull the address pins low (=0x50). So you retain the option of adding another eeprom on the I2C header pins after this upgrade. It is also possible to solder new chips onto those little red EEprom breakouts. Note: 128k AT24c1024 chips are slightly larger than the 32&64k so you have to bend the legs straight down which makes that soldering tricky. So I usually find it easier to just ‘stack’ two smaller 64k chips.

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 leakage currents are less important when you only have enough storage space for one year of operation. 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 our 2.7v cutoff as long as possible. That means we don’t need to lower the BOD with fuses & custom bootloaders that bork code portability. Pushing the limits of fuse optimization can get a little flaky on these cheap boards, so it’s good to have those ‘Get out of jail free‘ defaults available at reboot. When you only service your loggers once a year, any tweaks that require you to remember ‘special procedures’ in the field are things you’ll probably regret. (And many of those cheap eeproms on eBay also have a 2.7v lower limit)

You could also try stacking the EEproms. The rtc module pulls all address pins high (setting the lower default 4k eeprom in this picture to 0x57) but if you leave any address pins on the 64k chips ‘unconnected’ they get internally pulled to ground. (setting the bus address to 0x51 for the uper chip in this picture) AT24C512’s cost about 50¢ on eBay, and each chip you add increases overall sleep current by ~1µA.

Then use both eeproms by changing defines at the start of the code:
define opdEEpromI2Caddr 0x57
define opdEEbytesOfStorage 4096
define sensorEEpromI2Caddr 0x51
define sensorEEbytesOfStorage 65536

Leakage scales linearly with capacitance so use the Falstad simulator to see what size you actually need. Capacitors rated 10x higher than the applied voltage reduce leakage significantly. 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 loggers sleep current (whether tantalum or electrolytic) and these can be obtained on eBay for <50¢ each. So MLCCs with high voltage ratings get you closer to the low leakage values you’d get with Polypropylene, Polystyrene or Teflon film.

Note that as the buffering cap gets larger, you need to add more ‘recovery time’ sleep before the rail voltage is restored after a load. A large rail capacitor also protects the unit from impacts which might 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 actually increases when 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 a viable option for low-power systems. (…unless you pin-power them so you can cut their power during sleeps)

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 normally occur in the same pass like this, but I forced them together for this test to illustrate the effect of repeated loads:

A triple event with a temperature reading followed the transfer of two array buffers to EEprom. [Vertical scale: 500µA /division, Horizontal: 25ms/div]
Here a 220µF tantalum capacitor was used to reduce the peak current for that same event.
Here a 1000µF tantalum [108] capacitor buffers the rail. The 30msec sleep delays used here are not quite long enough for the larger capacitor to recover.
Voltage across a coin cell that’s been running for two months with NO buffering capacitor. The trace shows the 2mA loads causing a 60mv drop; implying the cell has ~30 ohms internal resistance. [Vertical Scale: 20mv/div, Horizontal: 25ms/div]

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)

This very old coin cell experiences a much larger 250mv droopThis very old coin cell experiences a much larger 250mv droop with no capacitor buffer. Note how the initial short spike does not last long enough to cause the expected droop. [Vertical scale: 50mv/div, Horizontal: 25ms/div]
Adding a 220µF tantalum cuts that in half. This protection is considerably more important a the end of the battery life.
[Vertical scale: 50mv/div, Horizontal scale now 50ms/div]
The 1000µF tantalum limits droop to only 60mv.
[Vertical scale: 50mv/div, Horizontal scale 50ms/div]

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….)

Short periods of 8MHz operation for sensor readings. The final EEprom save peaks at ~3mA draw with CLKPR 1MHz CPU.
[H.scale: 25msec/div, V.scale 500µA/div via Current Ranger]
Voltage on that same ‘old’ CR2032 used above reached a maximum droop of 200mv with NO buffering cap.
[Vertical scale 25mv/div]
Adding a 220µF/25v tantalum capacitor holds that ‘old’ battery to only 50mv droop. That cap adds only 0.1µA leakage, so this is the size we will use on the logger.
[Vertical scale 25mv/div]
This ‘solder-free’ DIP-8 carrier module is bulky compared to the red YL-90 boards, but it lets you swap chips & configure multiple I2C address easily. Here I’ve removed the redundant power led & pullup resistors.

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 load. 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 runtime power budget where you put constants or even large lookup tables.

Most DIP8 EEproms are pin compatible with that carrier. 128k EEproms are usually divided into 64k blocks with sequential I2C addresses so the location variables don’t exceed uint16_t max of 65535. Heliosoph posted a way to combine multiple 64k EEproms into a single linear address range but with ‘combination’ sensors like the BME280 sometimes it’s easier to just send each sensor’s output to a different bank using the two bus addressed. Our code demonstrates how to do this with the OPD & sensor arrays.

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 arrays to 32 bytes each by increasing the wire library buffer length to 34 bytes:

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 an extra 138 bytes of ram over the 32-byte default. 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 may perform partial page-writes more gracefully.

An average sleep current of ~5µA*86400 sec/d burns ~432 milliampseconds/day. With an eeprom write that draws 3mA*5msec, 12 array buffer writes per day will consume about 180mAs. Cutting that in half by doubling the size of the buffer is going to save you 90mAs per day, so it will only take 5 days to earn back the power for one more day of sleep. That return is even better with old 10 millisecond/write eeproms, and reducing the number of pulse-load events may extend battery life in some way other than the actual power saved. I always do the 34-byte I2C / 32-byte buffer increases to my loggers.

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.

Here wires extend connections for the thermistor & LED to locations on the surface of the housing. Alternate power is brought in from a small solar panel – but I will post more on that little experiment later 🙂

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 & battery voltage) is easy; especially if you can subtract a fixed offset from the data first. But doing the trick with variable high resolution thermistor readings 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 parts 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 for those.

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.

2022-07-01: Addendum

Since we covered adding sensors, heres a couple of burn-down curves for the two configurations described above. Both were saving 4 bytes of data per record every 30 minutes giving a runtime storage capacity of about 150 days. Battery was logged each time the 16-byte buffer-arrays were moved to eeprom. Both loggers had a measured sleep current of ~1.5µA and were restarted to continue these burn tests on the same battery:

Cr2032 voltage after ~5months @30min sampling interval: BMP280 sensor reading Temp. & Pr. stored in 32k eeprom with NO 220µF rail buffering capacitor.
Coincell after ~5months @30min sampling interval: BH1750 sensor & 32k ‘red board’ eeprom (again, with no rail buffer cap).

I’m running these tests without help from a rail buffering cap, to see the ‘worst case’ lifespan. A new Cr2032 has an internal resistance of ~10Ω, so a 3mA eeprom writing event will only drop the rail about 30mv. But once the cell reaches 60Ω we will see drops reaching 0.2volts for those events. The 2032’s shown above are plateauing near 3v, so we should see the rail droop to ~2800mv once the batteries really start to age. (ie: to only 50mv above the 2750mv shutdown in our code)

According to Maxell’s 1Meg-ohm (3.3µA) continuous discharge test, these coincells should stay at their 3v plateau until they have delivered 140mAh [~500,000 mAs] So the rail buffering caps arn’t really needed till the cell passes that point, but I still expect them to extend lifespan by at least 30%. The longest cointinuous run to date with a 220µF cap in place is nine months and the graph for that buffered unit is perfectly flat at 3.03v with no noise at all. Of course, if we reach a year without rail buffering caps, then we’ve likely filled the eeprom… so the extra stability provided by a rail cap may only be necessary with high-drain sensors or for low temperature deployments.

And here we compare our typical logging events to the power used during the RTC’s internal temperature conversion (with a 220µF/25v tantalum buffering the rail). On all three the horizontal division is 50 milliseconds, and vertical is 100µA (via translation with a current ranger).

Typical sampling event (with 227µF rail buffer cap) peaks at 250µA, with logger sleeping for 15msec after every I2C exchange.
Saving the sensor reading array to the 64k eeprom peaks ~750µA (with 227µF)
DS3231 RTC temperature conversion by itself. This occurs every 64 seconds – occasionally this happens during the other high drain events, adding an additional 250µA for 170ms.

The datasheet spec for the DS3231 temp conversion is 125-200ms at 575-600µA, but most of the units I tested drew less. This is such a long duration load that even with a 220µF on the rail I’d expect the overlap of RTC temp conversion & eeprom writing to double the vdrops I showed earlier because the reserve has been drained.

Another thing to watch out for is that with sleep current in the 1-2µA range, it takes a minute or more to run down even the little 4.7µF caps left on the ProMini board. If you have a 220uF buffering the rail the logger will run for almost 30 minutes with no battery before the RTC flags a power loss. This means you can usually perform a quick coincell swap without loosing the time, but if you are deliberately trying to reset the RTC you will need to briefly short Vcc to GND after removing the coincell. Note that we never use the brown out detection any more because on occasions where it does get triggered the 328p in often draws ~1mA in that state until your batteries leak. The whole idea of BOD is to protect the logger, but that leakage usually destroys the machine before we can get back into the field. This is a mystery I have yet to resolve as Brownout holds the MCU in reset, which floats all pins (even those that are being used as outputs) Since the internal pull-ups are disabled during reset I have no idea where that current leak is coming from though it’s worth noting that the datasheet says: “If low power consumption during reset is important, it is recommended to use an external pull-up or pull-down.”

Also Note: 99¢ eBay sensor modules are cheap for a reason. Relative accuracy spec for the BMP280 is supposed to be ±0.12 millibar, but when I run a batch of them side-by-side I usually see a range of ±2 to 3 millibar between the records. So it’s good to do a huddle test of new loggers so you can normalize them to each other.

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

20 thoughts on “2-Part ProMini logger runs > 1 Year on a Coin Cell

  1. Brian Davis

    OK… wow. Um, you keep making me re-think, which is GREAT! Thank you!

    I admit one step I’ve not taken is stripping out the ProMini regulator and running unregulated (I’ve not even swapped to an external regulator just because I’m not sure which to do or how, and I haven’t needed it… YET). So that’s something I need to go back over everything and look at. I’ve also not taken the steps of disabling Vcc to the RTC because the soldering looked tricky… but here, with your trick of soldering a jumper from just over the diode in the battery charger circuit has me curious again for a different reason. That’s essentially connecting the RTC battery supply to the ProMini Vcc… but could you run this the other way? Remove the coin cell from the RTC (and frankly then desolder the coin cell holder off the board; it’s the biggest component and gets in the way), but do the same solder connection you do here to bring the ProMini’s Vcc rail over to the RTC, but coming in through the battery connection to keep the RTC running in low-power mode? Then my RTC and ProMini are all running off the main battery pack. Would that work? My goal here is to easily extend life by keeping the RTC in low-power mode and removing the coin cell battery holder entirely (I have enough room for batteries, but not that coin cell ironically. Also the wiring job between the RTC board and the ProMini is genius… and I wonder how much time you spend turning components around in your head. Same with the variety of sensor board / EEPROM board “co-wiring” solutions.

    I take a different strategy than you do for “different records”; instead of writing them “forward from the front and backwards from the rear” as you do, I just freely mix them with a single byte (or if I was trying to save this much memory a single bit) in the front labeling which type of record it is to decompress, but that’s just a small difference. Since I’m still using the SD card I just pack all my data records as 30 byte records so I’m doing EEPORM page writes, and battery life rather than memory is my limiting factor, but I really love this. Also, your point about editing the wire.h library to expand the buffer just two bytes, so you can write the entire 32 bytes of a page, is something I really should have done earlier, and didn’t think about… I just hate editing library files like that because it tends to really break things for others going forward, but I might have to do it.

    On data compression I need to think more… while I don’t need it to conserve total memory (SD cards are MASSIVE), I have been looking at it for compacting what I can fit in a single 30 byte record. Pressure sensors tend to be memory hogs (a single raw pressure or temperature reading takes up 4 bytes, and I’ve generally had two, so that measurement, uncompressed, chews up half the data record). Generally storing the simple differential is good enough but it’s another think I need to think about.

    Dang, I just wrote my own blog post. Sorry 🙂

    Reply
    1. edmallon Post author

      In our typical AA powered loggers, the usual RTC mod cuts the Vcc leg, and then cuts the connection from the positive coin cell terminal to the Vbat line and replaces it with a 1n1418.

      Then the systems rail provides Vbat power whenever it’s higher than the coin cell-(minus the diode drop) which is most of the time with Lithium AA’s. That diode-OR setup works fine to power the RTC from the main system battery and I have not noticed any weird drift effects, etc. from the switching.
      [edit: Now that I think about it…I should probably replace the diode on the RTC module with a lower vF Shottky to more preferentially supply from the larger lithium AA system batteries]

      On this new ‘mini’ build I’ve also thought about replacing the coin cell battery holder with a 2x AAA holder & lithium cells, as that would easily tape down on that flat surface that’s left after removing the coin cell holder. But I’m working on another little trick there for posting soonish.

      I’ve been trying to figure out a way to use Varints that works for larger thermal deltas that also doesn’t obfuscate the code to the point where it’s completely unreadable by students. But that method is really optimized for small numbers and even with the 104 caps the thermal deltas between readings of the NTC gives you four sig figs. I think I’ve an idea for a solution packing those readings into 16-byte arrays, but just adding more memory is so easy I’d really only be developing that for my own amusement.

      Barometric pressure is easier to compress after you convert it to millibar. Then you can just subtract a fixed offset of the lowest expected reading at your latitude (about 980 where I live) and this leaves you with a normal range of about 30millibar. 2*(255) = 510 so if you can live with a resolution of only 0.2 millibar, then you can encode the rest of the pressure reading in one byte. This is essentially the same way we’ve encoded the battery readings to one byte only in that case I increased the spread with a 4x multiplier. But water level is more challenging due to the greater range. Perhaps you could generate periodic index/offsets and store those in the internal EEprom since you have loads of power on normal batteries?

      And WRT wiring…yes, I probably spend far too much time on these little puzzles.

      Reply
    1. edmallon Post author

      Last time I checked FRAM had sleep currents far too high for low power systems and those EEproms are so incredibly cheap: https://www.ebay.com/sch/i.html?_from=R40&_nkw=at24c512+50pcs&_sacat=0&LH_TitleDesc=0&_sop=15

      We also use the EEprom writing load to stress the batteries, and that’s actually lead to another interesting observation: with older coin cells that have been sitting around for a while, we’re seeing cell voltages rise significantly after they have been running for a week or two with those 2-3mA pulse loads. I don’t have a ref handy but I recall reading somewhere that if you never bring a coin cell above single digit μA loads then a kind of passivation layer builds up inside which reduces the total amount of power you can get from them.

      And there are lots of other power optimizations that could be done using more energy efficient CPUs & low power RTCs. But the point of this design was to make use of the parts already on a couple of cheap eBay modules so that non-engineering students could assemble it in one afternoon lab. I think we’ve achieved that nicely with this new build.

      Reply
      1. Manu

        I solved the problem of sleep current by powering my fram with a digital output of the microcontroller (PIC24) making its sleep current probably in the nanoamp range (I didn’t have a microcurrent or a good microampmeter at the time, so I guessed it is that based on the time it worked). You also have to be careful not back powering the device from the i2c pins by disabling the i2c module in the uc. But it is effectively cheaper to use eeproms.

        Reply
        1. Stuart

          The Fujitsu FRAM in the Adafruit module doesn’t seem to have a sleep mode, just a standby mode, whereas Infineon/Cypress modules like FM24V10 have a 5uA sleep mode with operation down to 2v, which would be better than the 2.7v EEPROMS. The cost of the FRAM may outweigh the benefits though!

          Reply
  2. andrew

    an easier way to disable the LEDs is to burn them out – I use a 4 x AA NiMH battery pack – touch the leads (5 volts) across the LED, a brief flash & a millisecond later the LED is no more – saves on desoldering

    Reply
    1. edmallon Post author

      That’s one way to do it, but I think asking our students to try that method would be a recipe for even more dead Pro Mini boards in the lab…and they don’t really need help in that regard. 🙂

      Reply
    1. edmallon Post author

      The ‘basic’ two part build reads the RTC record if you uncomment ‘RTC_ONLY’ in the initial program defines. For other sensors you have to connect & enable them at the start of the code and we included BMP280 support to show people the kind of changes you need to make to add other I2C sensors.

      Yes the accuracy spec for the RTC temp is pretty rough, but when you actually test a large group of ‘-N’ and ‘-SN’ chips you find that most are only 0.25-0.5C away from actual. And that fixed offset is easy to correct over the range of temps seen by most student projects. BM sensor temps usually need exactly the same kind of correction because of self heating. The NTC requires a full calibration procedure against a reference sensor to derive the Steinhart–Hart constants – but then that’s another useful lab for the students work through.

      Reply
      1. andrew

        I’m logging a mixed bunch of sensors at present – BME280, MCP9808, SCD30, various thermistors. The I2C ones all require periodic adjustments to the correction offsets over the months/ years for maximizing accuracy. So I spent a long time with NTC thermistors but they are even more troublesome when you are aiming/ desiring better than +/-0.2% accuracy ;-(

        Reply
        1. edmallon Post author

          Yes. Things like ‘aging’ drift were far from my mind at the beginning of this project, but now, with up to a hundred loggers deployed at a given site, the data itself is telling us it’s an issue we can’t ignore. Our ratio-metric ICU method for reading thermistors is much better in that regard than traditional voltage dividers, but there are still several critical points. Sometimes there’s a known physical benchmark we can use for de-trending, but mostly we use a second calibration when the unit is retired (assuming it’s still operational…and didn’t get blown away by a Hurricane…) But that requires the drift to be both linear and unidirectional, when most of the stuff I’ve read says neither of those assumptions are true. I’ve also been playing with the idea of using the DS3231 temperature record for ‘on the fly’ drift corrections of the NTC data. That’s not perfect either, but at least it’s more characterized than cheap thermistors.

          The problem is that if you assemble a build from high quality components with really good tolerances & drift specs – you’ve probably spent too much money on them to do the kind of exploratory tattle-tale deployments that make the research more fun. In our experience, deploying 10x as many cheap sensors is more likely to give you interesting data than best-guess deployments with a small number of expensive toys – even if the cheap sensor data needs more post processing. And our ‘obviously home-made’ loggers tend to be ignored in places where nicer looking commercial equipment would quickly grow legs and walk away on its own. . .

          [Addendum: One thing that’s probably worth passing on is that the ageing effects we do see seem to be much more pronounced within the first year of a loggers lifespan. After that the whole system seems to ‘settle’ into much more constant (and slower) drift rates. So we usually run our loggers on a shelf somewhere from the moment they are made – even if they are intended for a deployment more than six months away. It’s probably not even worth calibrating them till they’ve had at least a two week short interval burn-in run]

          Reply
          1. andrew

            So glad I’ve come across your blog. What an absolute mine of info. I’ve only read a small fraction of it so far, but hopeful it may give some tips for my own logging adventures.

  3. Crides

    How did you get the 328p down to 150nA when power down? The datasheet specifies the power down current is like 40uA

    Reply
    1. edmallon Post author

      I think the 44uA in the datasheet is with both WDT (watch dog timer) & BOD (brown out detection) enabled. Rocket Scream’s Low Power library has an option to turn off the BOD in software and that’s required for sleeping down at 1uA. When you use this method the BOD is automatically re-enabled when the processor wakes so you still have protection from memory corruption. Occasionally you will get into the trap where the battery recovers but the start-up process draws enough current to pull the battery back down below the BOD cutoff, causing a restart-shutdown loop until the battery depletes. Fortunately with coin cells that limbo state doesn’t usually last long.

      Reply
  4. Oliver

    You can write the data directly to the atmega328p flash using a modified bootloader. You don’t need a RTC either: if you de-solder the high speed crystal (with a 25$ hot air station), you can replace it with a 32khz crystal! You can then run your own RTC using asynchronous timer2 and powersave sleep mode (leaving timer2 on while sleeping). It sleeps at less than 1uA while keeping accurate track of time. You can then run on your CR2032 for much longer, cause you use less current and you don’t have the 2.7V limit.

    Reply
    1. edmallon Post author

      Our whole aim with this 2-Part build was to avoid complications like bootloader mods so that the logger is easier for beginner level students to understand & work with. And with a raw crystal I’d be worried about thermal effects over the kind of time periods that loggers usually get deployed – correcting these drift errors are really what modern RTC’s do and there are several that mange it in the nA range. But you won’t find those really good RTC’s on cheep eBay modules.

      Reply
  5. Pingback: Powering an Arduino Pro Mini logger for one year on a coin cell « Adafruit Industries – Makers, hackers, artists, designers and engineers!

  6. anthony mulherin

    Wondering if it is possible to modify this to see a change in state from a float switch or ultrasonic sensor, interested in building a data logger that could be positioned in tidal creek to log on off times of a switch rising to a set level and then comparing to tide chart heights to determine access times by boat to shallow areas
    I would like to build this as a low-cost data logger build tough to handle saltwater conditions,

    Reply
    1. edmallon Post author

      This is easily done with the same circuit we use on our tipping bucket rain gauges which puts about 5msec of debounce into the event. ( See: Building an Arduino Weather station https://thecavepearlproject.org/2015/06/15/developing-an-arduino-based-weather-station/ ).
      The trick is getting two interrups to ‘interweave’ properly and I do that with a sub-loop at the end of the main loop, which only responds to the interrupt from the reed switch. Take a look at our old drip sensor code on github to see how we do that:
      https://github.com/EKMallon/The_Cave_Pearl_Project_OLD_codebuilds/blob/master/_20141002_DripSensors_WithPowerControl/_20141002_DripSensors_WithPowerControl.ino
      This uses interrups on D2 from the RTC, and D3 from the accelerometer to wake the system with sleepNwait4AccInterrupt. The ISR’s set flags, and only when the D2 RTC alarm flag is set does the processor break out of the while(clockInterrupt == false){ loop at the end of the main loop.

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s