Power Off Sleep Circuit based on Real Time Clock (DS3231)

Power Off Sleep Circuit based on Real Time Clock (DS3231)

Background

This note describes a brief investigation prompted by the request “ideas for an external circuit that uses and external RTC (Real Time Clock) to switch power on and off to the pico” from @byron.

https://forum.dronebotworkshop.com/components/external-power-on-off-control-circuit/

It may be noted that @byron indicated the desire to make a small number of the systems, and hence whilst this article mainly describes a 'development station' for developing code, etc., it is also modular in that the 'production' systems consisting of ust the RTC, Pico and 3 x AA battery pack are intended for 'standalone' usage, after being initially programmed at the 'development station'.

This study was based on controlling a Pico, but the principle appears transferable to any low power 3.3V microcontroller that supports the I2C bus, especially if they are supported by the Arduino IDE and associated libraries. At the time of writing, the RTC is available as a PCB module, plus the additional electronic components (1 FET and 3 resistors), are available at a very low cost.

Introduction

There is increasing interest in systems which periodically ‘wake up’, perform a task such as taking some environmental sampling measurements, then go back to ‘sleep’. When the system is required to work from a time-limited power source such as a battery, it is obviously advantageous to minimise the power draw. If the ‘sleep’ time is much greater than the ‘wake’ time, then even a relatively small current draw during ‘sleep’ can consume more of the battery’s life than that used during the ‘wake’ time.

Many microcontrollers support one or more variations of ‘sleep’, ‘hibernation’, etc., which can be utilised to maximise battery life, and some support a real-time clock which can continue to run in the ‘sleep’ state, and also support a method of being woken by that clock. Such a device has the potential to be a good solution if it also provides the necessary resources to efficiently support all of the required ‘wake’ time tasks. This approach can minimise the circuit complexity and may have the advantage that the microcontroller is on task when it ‘wakes’.

However, the ideal situation can prove difficult to achieve. Typical issues include:

• Cannot find a microcontroller with all of the required resources to perform the wake time tasks and a built-in real-time clock that can wake it when required.
• The sleep facility of some microcontrollers have flaws, causing poor wake reliability.
• Power consumption in sleep mode is too high. This may be the microcontroller itself, and/or it may be related to the microcontroller’s power supply.
• The internal clock may not be very accurate. For short periods of time, say minutes to hours, this may not be a problem, but over a period of say months, even small rate errors can accumulate to become substantial.

This note discusses an alternate strategy of completely powering down the microcontroller for the ‘sleep’ periods, and using a real-time clock device to ‘wake’ it up. Thus, the microcontroller power consumption during the ‘sleep’ time is zero. The real-time clock function is provided by a single device which is claimed to be able to perform the clock and alarm functions for more than eight years whilst powered by a single CR2032 lithium based cell.

This strategy implies that the microcontroller is performing a boot at each power up, although non volatile memory could be used to store data between “wakes”.

Real-Time Clock

The DS3231 was chosen as the real-time clock. This plastic package was distributed by Maxim Integrated, who have since been acquired by Analog Devices, who list it as a current part.

However, many people, including myself, chose to purchase an “anonymous” 3rd party, low cost, PCB module containing the device. Neither the device, nor the PCB have any obvious trademarks, and it was sourced through a relatively local supplier on Ebay, so I don’t know if the device was manufactured by Analog Devices. However, whilst my testing is limited, it does appear to function, albeit early indications the time keeping may be reasonable, but not as accurate as suggested in the data sheet. Similar boards are widely advertised on the usual marketplaces, including Amazon and AliExpress. There are also alternate board designs, also based around the same RTC device, so care should be taken when ordering.

The circuit of the board is on the Web, e.g.: https://circuitdigest.com/microcontroller-projects/interfacing-ds3231-rtc-with-arduino-and-diy-digital-clock

• EEPROM AT24C32D is superfluous for this purpose, and can optionally be removed.
•  
• Board was designed for a rechargeable battery, but is usually used with a CR2032. Hence the battery charging circuit, consisting of U4 and D1 should be disabled by removing U4.
•  
• The LED1 and U3 are “Vcc powered” indicator, which is useful when first commissioning the software, but should be disabled to minimise external power drain before deploying the system.
•  
• Resistor Array R1 provides pull ups for 4 of the DS3231 open drain outputs. Considering each resistor in turn:
  • 32K connection is not required for this application, and could result in some battery drain, so it is best disconnected.
  •  
  • INT*/SQW pin will require a pullup, but NOT to this board’s “Vcc”, so this one MUST be disconnected.
  •  
  • SDA and SCL I2C outputs require pull up to Vcc, but it may be more convenient to remove the whole array, and provide separate resistors.

Microcontroller “Input Pullup”s are unsuitable for I²C SDA and SCL

SDA and SCL outputs must be pulled to Vcc. It has been suggested that the “Input Pullup” option often provided with microcontrollers can be utilised for the purpose. However, these internal pull ups are intended to set the voltage on unused pins. The value will depend on the microcontroller design, for example the ATmega328P datasheet lists a typical value of 20 – 50 kOhms.

But for the I2C network data bus, which must meet timing obligations, a value range of 2-5 kOhms is typically required for reliable operation.

When tested without explicit pull up resistor using a Pico, the databus appeared to function, but an oscilloscope measurement showed very slow rising edges resulting in a coarse sawtooth waveform, (instead of ‘flat topped’ square pulses) which was close to failing to meet timing requirements. It is strongly recommended to ensure appropriate pull up resistors (costing 1 cent each?) are used.

Battery Power Source

For this study, it was decided to power a Pico from a set of 3 x AA alkaline batteries, and the DS3231 would be responsible for controlling the gate voltage of a p-channel MOSFET that switched the supply to the Pico. To minimise the parts count, the DS3231 was set to fire its alarm at the time the microcontroller was required to wake, whilst the microcontroller would instigate returning to power off state by sending a reset alarm signal to the DS3231 via the I2C bus, after completing its tasks for that wake period. Hence the electronic parts count is reduced to just 1 transistor and 3 resistors, including the 2 resistors for I2C bus pull ups.

The DS3231 can support a limited range of regular wake schedules, such as once per hour without updating its configuration, but since the microcontroller can send commands to the DS3231 whilst it is powered on each ‘wake’, then the programmer may prefer to explicitly set each next ‘wake’ time, thus enabling a very complex schedule to be performed.

Development Process

In normal usage, the RTC is responsible for powering up the Pico, and the Pico in turn is responsible for cutting it own power supply, by writing to the RTC over the I2C bus. This is more complicated than the common development process approach for Arduino or similar systems, in which power to the microcontroller is continually available, often via the USB connection that is also used used for download etc. Hence, a phased approach was adopted for this, and offered as a suggestion for future development work for a final application.

The overall circuit for the development station is shown below, which consists of 5 blocks:

Battery and Power Switch 

 The core of the switch is Q1, the P-channel MOSFET, whose gate is pulled up to its source by a 1 MegOhm resistor, which in the absence of any other connections, holding the channel of Q1 at a very high impedance, so that no current flow could be measured. These two components, together with the battery, forms the power supply for both the Pico and the Vcc supply to the RTC.

Q1 is physically small (SOT-23) device, nominally described as SI2301DS, although the device was inscribed A1SHB. It was chosen for its relatively low Rds (Resistance between drain and source) of 230 milliOhm with a Vgs (voltage from gate to source) of just -2.5V, and current carrying capacity of up to 2.5 A. Assuming a maximum Pico current demand of 100mA, the predicted voltage drop using V = IR, would be 0.1 (A) X 0.23 (Ohm) = 23 mV, and the power dissipation using P = IV, would be 0.1 (A)* 23 (mV) = 2.3 mW.

Note that the horizontal line at the bottom of this circuit snip is the 0V or common ground line for the whole circuit. When controlled by the RTC, Q1 gate is driven by an open drain INT/SQW output of the RTC, which effectively connects the Q1 gate to the 0V, thereby applying a Vgs voltage to Q1 (virtually) equal to that of the battery, nominally -4.5 V, ensuring Q1 is fully ‘switched on’.

The only measurable current drain by the components described thus far, from the battery occurs when Q1 is switched on, and consists of the Pico current demand, plus a few mA for the I2C bus, and few microAmps for R3 and Vcc current demand by the RTC.

The circuit snip also shows the switch Sw_option, which is intended as a manual override to power the Pico from the battery. This is useful for when the Pico is attached the PC for software development and serial monitoring, but is not being powered by the PC. For ‘production’ models, it may only be needed for initial set up tasks, such as downloading the Pico software, and might be more conveniently provided by a small jumper or similar arrangement.

In addition, the circuit snip shows LED_option and R_option, which indicate when Q1 is allowing power to flow from the battery. In a ‘production’ model, this would obviously by a further drain on the battery and probably of little utility, but for the development station it provides a useful monitoring function, especially when developing the software, when the Pico is more conveniently powered by the USB cable.

Pico and Pico USB cable

The Pico used in this study can be directly replaced by a Pico W (albeit this has not been tested), or one of the alternate microcontrollers used by Arduino and others, providing the circuit limitations are met, or the circuit is modified to accommodate any issues.

Points to note include:

• RTC INT/SQW and I2C pins have a maximum voltage limit of 5.5 V, which is effectively the maximum allowable battery voltage. Hence, 3 * 1.5 V alkaline batteries are a convenient choice.
•  
• The Pico chip itself is 3.3V maximum, and hence the Pico board has an onboard regulator. The 3.3 V output from the Pico board is used to power the Vcc pin on the RTC, , which in turn becomes the pull up voltage for the two I2C connections between the RTC and the Pico.
•  
• The circuit snip shows the connections:
  • between the RTC and the Pico - SDA, SCL, 3.3V, Gnd
  • between the Pico and the battery/power switch – Vsys (Q1 switched battery 4.5V) and Gnd
  • between the RTC and the Power Switch – INT/SQW and Gnd
  •  
• In addition, the Pico has a micro-USB port to connect to an external development computer, with internal 4 connections:
  • Data pins D+ and D-
  • 5 Vdc (from the computer)
  • Gnd
  •  
• SW2 and SW2_NOT combined form a double pole, double throw switch which is wired so when SW2 is closed, SW2_NOT is open and vice versa. SW2 closed means the Pico is powered by the host PC, via the USB cable, and SW2_NOT closed means that the Pico is powered by the 3 x AA battery pack, when the Q1 FET is conducting.
•  
• During software development and code downloading, the USB cable supplies power to the Pico, as well providing a data link. For much of the software development work, this is still convenient, but it is not compatible with powering the Pico from the switched battery source. Hence, SW2 is closed for the development work, and possibly when initialising ‘production’ modules, to enable the USB cable to be used with the power (5V) wire disconnected. SW2 is opened (and SW2_NOT closed) when using the RTC to control the power from the 3 x AA battery pack.

RTC Module and I2C Pull ups

The RTC module consists of the circuit inside the blue border. To aid identification of the parts, with the exception of the coin cell, Cell1_3.2V, the symbols have been drawn in approximately the same relative positions as the physical components on the board.

As discussed previously, for the components marked with a red X should be removed from the board, namely U4 220 Ohm resistor, U3 1kOhm resistor and R1 4 x resistor pack.

Optionally, the resistor U3 1kOhm could be left on the board as a means of determining when the Pico and RTC were being powered by the battery. This is a trade of convenience versus a small increase in the alkaline 4.5 V battery pack power consumption.

Also optionally, the EEPROM AT24C32N could be removed, eliminating the chance of it increasing the power consumption, if its functionality is not required for the final project. It was ignored in this study.

Also shown in the circuit snip, on the left hand side, is the I2C pull up provision, to replace the resistors lost when the resistor pack was removed. For the study, a 4 * 2.54mm pitch pin stack was soldered into the holes in the board, and two 4.7 kOhm resistors were soldered to a plug to complement the pins.

Complete schematic

===============================

Software

For this study, an example file for the RTC device found on GitHub was used a ‘rough’ starting point and hence the final result obviously contains some of the code from GitHub.

The code described below, should not be regarded as a finished program. Instead, it is a set of rough hints that it is hoped are a useful starting point. It is mainly broken into a series of functions that are sequentially called in the Arduino “setup()” function.

The whole Arduino program is just one (attached) file, but I’ll provide commentary and associated listing in smaller blocks.

File introduction

Example implementation of an alarm using DS3231

Loosely Derived from

https://github.com/adafruit/RTClib/blob/master/examples/DS3231_alarm/DS3231_alarm.ino

The aim of this is not to interrupt the microcontroller board, but to support the microcontroller board power being switched by the DS3231 RTC, and the RTC providing the time.

The RTC can provide alarms at 1 per second. 1 per minute, 1 per hour and so on, with a single configuration, but it does not support more complex schedules, such as once per 23 minutes.

Hence this example, which is for every 15 seconds, relies on the microcontroller adjusting the configuration on each power up, for the next one.

The RTC alarm firing causes the power to the microcontroller to be restored, whereupon the microcontroller performs the required actions, and finally resets the alarm, causing its own power to be cut.

Although the original example code was intended to fire an interrupt to the microcontroller, this is not required for this application.

This code has a small addition to allow the microcontroller to be a Raspberry Pi Pico or Pico W.

It was requested by a person with a Pico W to act as a web server. For this prototype, only a Pico is available, and the application on each wake will be a simple 2 blink process using the on-board LED.

The Pico will be powered by 3 X AA alkaline cells, with a small p-channel MOSFET in series with the positive battery rail.

The gate of the MOSFET will be connected to the INT/SQW RTC output.

The Vcc line on the RTC board should be connected to the 3.3V out on the Pico, and ground on Pico should be connected to ground on the RTC board.

SDA, SCL of RTC should be connected to SDA Pin 20 and SCL Pin 21 of Pico to match the code in setup()

The Pico USB can be optionally connected by a data only link ... D+, D- and ground wires only, for Serial Monitor monitoring.

File Header

The code is based upon the RTClib by Adafruit Version 2.1.1 which is automatically included in an Arduino 2.0.4 installation.

Including its RTClib.h automatically includes Wire.h, required for I2C communications.

A very simple scheduling system is included to schedule every 15 seconds, and nextSecs is an array of possible values.

(The software scheduler here was only intended to demonstrate the principle ... the schedule can be as complex as the programmer wishes to make it, as it is defined in software. The basic principle is that during each wake, the programmer calculates the time of the next wake, which can range from a few seconds to 4 weeks in advance.)

The RTC is managed by an instance of the RTC_DS3231 class, called rtc.

Normally the RTC maintains the current time, but occasionally it will need to be set. This is achieved by changing FORCE_SET_RTC_DATE_TIME to “true”, and doing, a ‘one-off’ download and run.

#include <RTClib.h>
// #include <Wire.h>

// set up array for seconds times to alarm eg every 15 seconds = 0, 15, 30, 45

int nextSecs[] = {15, 30, 45, 60};

RTC_DS3231 rtc;

//+++++++++++++++++++++
// Normally set false .. To reset RTC, set to true, compile and run, then return to false
const bool FORCE_SET_RTC_DATE_TIME = false;     
//+++++++++++++++++++++  

// the pin that is connected to SQW … could be used for status printout 
// in this application but not currently connected
// 
#define CLOCK_INTERRUPT_PIN 2

bool scheduleAlarm (void)

A simple demonstration schedule that sets the alarm for the next 15 second boundary … i.e. the alarm fires at 00 , 15, 30 and 45 seconds in to each minute.

Process:
• Determine present time … say 19:43:02
• set DTNow to the seconds part … 02
• set secondsIndex to most recent quarter of a minute, using integer divide by 15 02/15 = 0
• set DTNext to time of next alarm, using next Secs[] array … 19:43:15
• send new alarm time to RTC
• return value from function … true if it failed!

// -------------------------------------------------------------------------------------

 /* DS3231 Alarm modes for alarm 1  Enumerator
                  DS3231_A1_PerSecond       Alarm once per second
                  DS3231_A1_Second          Alarm when seconds match
                  DS3231_A1_Minute          Alarm when minutes and seconds match
                  DS3231_A1_Hour            Alarm when hours, minutes and seconds match
                  DS3231_A1_Date            Alarm when date (day of month), hours, minutes and seconds match
                  DS3231_A1_Day             Alarm when day (day of week), hours, minutes and seconds match */

bool scheduleAlarm (void)
{
  DateTime DTNow = rtc.now();

  int DTNow_sec = DTNow.second();        // number of seconds into most recent part minute

  int secondsIndex = (DTNow_sec / 15) ;  // which 15 second quadrant of the minute did alarm happen?

  DateTime DTnext = DTNow + (nextSecs[ secondsIndex ] - DTNow_sec);  // calc next quadrant alarm time

  bool alarmSetFail = rtc.setAlarm1(
             DTnext, // TimeSpan(10),
            DS3231_A1_Second  );         // this mode triggers the alarm when the seconds match.
   return alarmSetFail;                  // false == alarm set was a success, 
}

void lostPowerRestart (void)

This routine normally does nothing … unless the RTC reports it has suffered a total power failure, or the developer has compiled with FORCE_SET_RTC_DATE_TIME set to “true”.

If either of these are true then it uses the development computer's RTC to determine the current time and sets the DS3231 to that time.

It does some general setting up of the RTC, some of which may be an out-of-date legacy of the original GitHub routine.

void lostPowerRestart (void)
{
  if(rtc.lostPower() || FORCE_SET_RTC_DATE_TIME)
  {
    Serial.printf ("WARNING : RTC CLOCK IS BEING RESET ");

    // this will adjust to the date and time at compilation
    rtc.adjust(DateTime(F(__DATE__), F(__TIME__)));
  
    //we don't need the 32K Pin, so disable it
    rtc.disable32K();
  
    // set alarm 1, 2 flag to false (so alarm 1, 2 didn't happen so far)
    // if not done, this easily leads to problems, as both register aren't reset on reboot/recompile
    rtc.clearAlarm(1);  // this is precaution on booting??
    rtc.clearAlarm(2);

    // stop oscillating signals at SQW Pin
    // otherwise setAlarm1 will fail
    rtc.writeSqwPinMode(DS3231_OFF);

    // turn off alarm 2 (in case it isn't off already)
    // again, this isn't done at reboot, so a previously set alarm could easily go overlooked
    rtc.disableAlarm(2);

    // schedule first alarm
    // schedule an alarm 155seconds in the future

    if(! scheduleAlarm() ) 
    {
        Serial.println("Error, alarm wasn't set!");
    }
    else 
    {
        Serial.println("Alarm will happen in next 15 second time slot!");
    }
  }
}

void warmReboot (void)

This is the ‘normal’ main part of the boot up cycle.

As it is demonstration code, it is mainly printing to Serial Monitor instead of a more useful task.

void warmReboot (void)
{
  // aim to print status once per loop
  // 1/ Serial Monitor timestamp using PC time (if enabled)

  // 2/ print current RTC time
    char timeNow[10] = "hh:mm:ss";
    rtc.now().toString(timeNow);
    Serial.print(timeNow);

//  3/ print RTC stored alarm date and time value
    DateTime alarm1 = rtc.getAlarm1();
    char alarm1Date[12] = "DD hh:mm:ss";
    alarm1.toString(alarm1Date);
    Serial.print("  [Alarm1: ");
    Serial.print(alarm1Date);

//  4/ print RTC alarm mode
    Ds3231Alarm1Mode alarm1mode = rtc.getAlarm1Mode();
    Serial.print(",  Mode: ");
    switch (alarm1mode) {
      case DS3231_A1_PerSecond: Serial.print("Once Per Second          "); break;
      case DS3231_A1_Second:    Serial.print("Seconds Match            "); break;
      case DS3231_A1_Minute:    Serial.print("Mins & Secs match        "); break;
      case DS3231_A1_Hour:      Serial.print("Hrs,Mins & Secs match    "); break;
      case DS3231_A1_Date:      Serial.print("Date Hrs Mins Secs match "); break;
      case DS3231_A1_Day:       Serial.print("Day Hrs Mins & Secs match"); break;
    }

    
    // the value at SQW-Pin (because of pullup 1 means no alarm)
    Serial.print("] SQW: ");
    Serial.print(digitalRead(CLOCK_INTERRUPT_PIN));

    // whether a alarm fired
    Serial.print(" Fired: ");
    Serial.print(rtc.alarmFired(1));
    Serial.println();
    
    // =================================================================================================

    // Serial.print(" Alarm2: ");
    // Serial.println(rtc.alarmFired(2));
    // control register values (see  https://datasheets.maximintegrated.com/en/ds/DS3231.pdf  page 13)
    // Serial.print(" Control: 0b");
    // Serial.println(read_i2c_register(DS3231_ADDRESS, DS3231_CONTROL), BIN);
    //==================================================================================================
}

void blinking_webtask (void)

This was envisaged to become the ‘useful’ task, such as sending a message over the web, on each wake up. As the available Pico had no Wifi it was tasked with two blinks of 0.5 seconds on, 0.5 seconds off, using the Pico’s onboard LED.

void blinking_webtask (void)

{
  // initialize digital pin LED_BUILTIN as an output.
  pinMode(LED_BUILTIN, OUTPUT);
  
  for (int k = 0; k <2; k++)
  {
  //   Serial.println ("LED on");
    digitalWrite(LED_BUILTIN, HIGH);  // turn the LED on (HIGH is the voltage level)
    delay(500);                      // wait for a second
   // Serial.println ("LED off");
    digitalWrite(LED_BUILTIN, LOW);   // turn the LED off by making the voltage LOW
    delay(500); 
  }    
}

void reschedule_alarm_and_cutthroat (void)

This calls the scheduler to calculate and schedule the next 15 second alarm … then clears the alarm which cuts the power.

void reschedule_alarm_and_cutthroat (void)
{
// resetting SQW and alarm 1 flag
    // using setAlarm1, the next alarm could now be configured
   
    if (rtc.alarmFired(1))
    {
      // schedule an alarm 15 seconds in the future
      if(! scheduleAlarm() ) 
      {
        Serial.println("Error, alarm wasn't set!");
      }
      else 
      {
        Serial.println("Next Alarm will happen in 15 seconds!");
      }
      rtc.clearAlarm(1);
      Serial.print(" - Alarm cleared");
    }
    Serial.println();
    delay(2000 - 3);
}

void setup() and void loop()

void setup() is essentially the main() function of the whole program … at the end of setup, the alarm should be reset and the power terminated.

Hence void loop() has a different loop rate blink, to indicate that it should not have been called!

In setup(), note the two Wire.set... calls to specify which Pico pins have been connected to the I2C bus. This empirically seems to work, but Pico is not listed as a supported processor.

Obviously most of setup() is a list of calls to the functions mentioned above!

void setup() {
    Serial.begin(9600);
    delay (2000);
    Serial.println ("Pico waking up");

 //  ****************************** Magic for Pico ... tell it which pins are I2C 
 // ******************************* Note it seems to be Wire1 (I2C1 not I2C0)
 // initialise I2C
   //set the pins for i2c on wire1
  Wire.setSDA(20);
  Wire.setSCL(21);
// **********************************************************************************

  // initializing the rtc
  if(!rtc.begin()) {
    Serial.println("Couldn't find RTC!");
    Serial.flush();
    while (1) delay(10);
  }

  lostPowerRestart ();

  warmReboot ();

  blinking_webtask ();

  reschedule_alarm_and_cutthroat ();
}

//----------------------------------------------------

void loop() 
{
  // if you get here .. you have a problem!!!
      // initialize digital pin LED_BUILTIN as an output.
  pinMode(LED_BUILTIN, OUTPUT);

  for (int k = 0; k <2; k++)
  {
    digitalWrite(LED_BUILTIN, HIGH);  // turn the LED on (HIGH is the voltage level)
    delay(200);                      // wait for a second
    digitalWrite(LED_BUILTIN, LOW);   // turn the LED off by making the voltage LOW
    delay(200); 
  }  
    warmReboot (); 
 reschedule_alarm_and_cutthroat ();    
  delay (1000);
}

-------------------------------------------------

Hope this is of interest and helpful.

Thanks for getting to the bottom of this rather long note. Constructive comments are welcomed.

Best wishes, Dave