Notifications
Clear all

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

51 Posts
4 Users
17 Reactions
6,784 Views
(@davee)
Member
Joined: 4 years ago
Posts: 1871
Topic starter  

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

image
  • 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 I2C 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.

 

image

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 

image

 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

image

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

image

 

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

image

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

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

 


   
Lee G and byron reacted
Quote
byron
(@byron)
No Title
Joined: 5 years ago
Posts: 1183
 

@davee

My DS3231 survived my assault by soldering iron to remove the unwanted resistors, and its hooked up on a breadboard circuit as you designed.

Heres a picture

IMG 0622

A huge thanks for you excellent work, especially for sending me the A1SHB chip pre soldered onto a carrier board.    For anyone reading, those chips are minute and a keen eye and steady hand are required to solder them.

The breadboard test works, and the sequence of the initial code that auto runs once the alarm triggers the battery power to flow to turn on the pico is

Note: the test was also to check how the DS3231 alarm could be made to alarm at 15 minute intervals

1. read the time (especially for the minutes) from the DS3231 RTC

2. establish the minutes on pico awake (e.g.  15 minutes pass the hour)

3. set the alarm to the next 15 minute time slot (i.e. 30 minutes)

4. do something, for a test I blink the pico on board LED

5. clear the alarm and remove power.

I used this exercise to put Dave's circuit into KiCad for a PCB design to re-lean how to use KiCad.  The initial design is to have a PCB as a plug in for the daughter boards such as the pico, the ds3231, the tiny mosfet on its board, etc.

Heres a pic of the 3d view of the PCB

Screenshot 2023 03 29 at 11.13.53

I'm not sure if thats the PCB I will get manufactured as in place of a mosfet daughter board I will probably go with   one of the minute mosfets placed directly on the PCB and get the PCB manufacturer to solder it to the board.  Likewise I may go for a ds3231 chip (as @Zander is going to use) instead of a DS3231 on a board.   I will have another look at this sometime over the coming months.

I found a good micropython library to use the ds3231 board where the ds3231 boards temperature sensor can also be handily read, and also a mp library to use the on board eeprom chip though I dont have any use for this in my use case scenarios.  My test code for the board is also in micropython.  I dont post any of this here as micropyton has little interest on this forum, but happy to share if anyone wants it.

So thanks again Dave, without your design and assistance this mini project would not have happened. 👍 


   
DaveE reacted
ReplyQuote
Ron
 Ron
(@zander)
Father of a miniature Wookie
Joined: 4 years ago
Posts: 7695
 

@byron Care to share what it is that @davee designed for you?

First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.


   
ReplyQuote
byron
(@byron)
No Title
Joined: 5 years ago
Posts: 1183
 

Posted by: @zander

@byron Care to share what it is that @davee designed for you?

Its already shared by dave in the post proceeding mine, in a great deal of detail.  If you mean the small board he kindly gave me with the weeny FET soldered on then heres a pic of the board design for the FET so that it can be plugged into a breadboard.

Screenshot 2023 03 29 at 16.15.33

 


   
ReplyQuote
Ron
 Ron
(@zander)
Father of a miniature Wookie
Joined: 4 years ago
Posts: 7695
 

@byron My internet is flaky, didn't see Dave's sermon. So basically what Will and I came up with in much fewer words.

First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.


   
ReplyQuote
byron
(@byron)
No Title
Joined: 5 years ago
Posts: 1183
 

Posted by: @zander

@byron My internet is flaky, didn't see Dave's sermon. So basically what Will and I came up with in much fewer words.

As neither you nor @will shared your circuit design I cant possibly comment.  The circuit Will linked to from electronoobs is of course a completely different circuit (and thanks Will for sharing that circuit) and is not used, but a useful link nevertheless. 👍 

@davee 's detailed 'sermons' as you put it are very useful for beginners in electronics like me.  You provided some useful links and the tip on the use of the DS3231 board, but as for a circuit design from Mr Ron (as ably assisted in private by Will I'm sure) we did not even get a hymn let alone a sermon.

Maybe a prayer would be more your cup o tea.  Dear Lord, I must remember to not criticise others just to big myself up.  For ever and ever amen.

 


   
ReplyQuote
Will
 Will
(@will)
Member
Joined: 3 years ago
Posts: 2585
 

@byron 

I haven't published a circuit except for the first one and that was only because the general opinion was that it would not be possible to have an RTC wake a sleeping MCU when the RTC was only run by its backup battery. The circuit as shown was only intended to illustrate a means of controlling the power to fuel further discussion.

AFAIK, Ron is still running experiments using the DS3231 chip and several variants of the module. So, I wouldn't expect him to list his final report until his research is complete.

Anything seems possible when you don't know what you're talking about.


   
ReplyQuote
Ron
 Ron
(@zander)
Father of a miniature Wookie
Joined: 4 years ago
Posts: 7695
 

@byron The electronoobs circuit is all I need, in fact I don't know why Dave invented a different one if in fact he did, TLDR his last sermon.

First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.


   
ReplyQuote
Ron
 Ron
(@zander)
Father of a miniature Wookie
Joined: 4 years ago
Posts: 7695
 

@will I forgot to mention, I did post a screen grab from the Chronodot website that says the RTC can run entirely on battery. Of course when the RTC wakes the attached processor VCC is asserted which helps with battery life for a brief convo via the I2C SCL/SDA pins. Normally that would be all I needed to prove my position, but I am going a step further and using the naked DS3231 chip which I just got (gawd they are tiny) will construct a circuit with nothing other than the RTC chip.

First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.


   
ReplyQuote
Ron
 Ron
(@zander)
Father of a miniature Wookie
Joined: 4 years ago
Posts: 7695
 

@davee WOW, that's a lot of code for what I thought was a simple task. Thanks to a library and using an interrupt my code will be a tiny percentage of yours.

First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.


   
ReplyQuote
byron
(@byron)
No Title
Joined: 5 years ago
Posts: 1183
 

Posted by: @zander

@byron The electronoobs circuit is all I need, in fact I don't know why Dave invented a different one if in fact he did, TLDR his last sermon.

Its a different circuit and better for it.    Why bother to post if you don't bother to read the post on the circuit design, but nevertheless wish to let me know you dam well wont be using it.  Pathetic.   I have not posted anything in this thread, nor has anyone, to suggest you use Dave's circuit.  I really don't care which circuit you use.  I'll leave you to ponder why oh why would anyone suggest a different circuit when Ron has found one that is all he needs. Why oh why.  The temerity of it.   As another member recently chided you not to post on a subject if it does not interest you with meaningless acetic comment.   I concur,  but in the interests of this forum I shall post no more for a long while lest I get overly annoyed with such posts you have made on this thread.  

 


   
Lee G and DaveE reacted
ReplyQuote
Ron
 Ron
(@zander)
Father of a miniature Wookie
Joined: 4 years ago
Posts: 7695
 

@byron @davee Gentlemen, I owe you both an apology. Somehow I failed to notice this was an entirely new and separate Topic. My mind was still back in the previous RTC-related Topic.

I have read through the excellent post made by Dave and looked at the diagrams. I have to re-read these a few times for reasons unrelated to my advanced years and do get the gist of what Dave is doing. It took me at least 6 re-reads and quite a few minutes of squinting at diagrams to finally 'get it'. I was getting ready to ask Dave how the heck he was getting the PICO to wake up without an ISR, but then I remembered the MOSFET Byron spoke of and the 'special circuit,' so I used a magnifying glass and turned the laptop sideways until I finally noticed (don't laugh too loud) the INT pin was connected to the special circuit. Mystery solved! I don't know why he used the INT pin that way, as I don't understand why INPUT_PULLUP doesn't work for Dave but does for me. Perhaps a follow-up Topic can explain both of those, but only if deemed to be of general interest, I am happy with the results for both of us.

There are some concepts in there I had not yet considered, like RTC loss of date/power and the concept of the warm boot and related issues. All good stuff. I have noticed some libraries provide access to those kinds of events/attributes, but many do not. I think what Dave has done is most likely all I need to consider, but if I discover more I will update the Topic.

I can tell that I upset Byron a great deal and I feel duly chastised. I for one do not want you on the sidelines, quite the contrary, I seriously considered deleting my account as I do understand I can be a PITA at times but that was the way I was during my professional career as well and I left that at the highest rank with many awards so I must have had a few offsetting good moments as well.

If Byron is still listening, has there been any progress on the PICO low power software front?

One final note, I probably will not implement this solution since I have a real dislike for polling-type solutions, I come from a world of interrupt-based design and admit I am biased. I know it's a bit theoretical but the day is fast approaching when we will be coding for multiple processors as I was doing almost 30 years ago with 6 processors. 

First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.


   
Inst-Tech reacted
ReplyQuote
(@davee)
Member
Joined: 4 years ago
Posts: 1871
Topic starter  

Hi Ron @zander,

 I hope you found something of interest.

The circuit diagrams are indeed small (I couldn't see an easy forum control to fix it), but I did include pdfs ... just click the link beside or under each of the pictures.

Look for something like:

image

As I said in the article, I was only aiming to show some of the possibilities ... not describe a finished product. 

The library I used, was picked on the basis of it being already installed, etc. , which I thought was a good asset for someone starting for the first time when everything is 'new'. Other libraries will almost certainly have their own merits.

The library didn't address the 'Aging Offset', but that is a 'nice to have feature' that is left as a challenge! Personally, when starting a new challenge, I like to see the 'under the hood/bonnet' details and not rely on totally magical but opaque library calls.

You are not alone with using interrupts in a past life, but one of the 'cute' things about having computers that cost less than a cup of 'shop' coffee is that you can afford to have them 'lying around doing nothing' for most of the time ... then bring them to life for just a few seconds to do a specialised job. Imagine, in your former life, trying to explain to someone they should buy and maintain a mainframe to work for a total of less than 1 minute a day!

And whilst I wouldn't mind if it was a polling solution, I think I could suggest it is interrupt driven ... The power switch is the highest priority interrupt .. it even trumps NMI (non maskable interrupt)! 😋 

So enjoy the freedom of your retirement, when, providing you have enough cash for food, lodgings, etc . you don't need to appease the bean counters, and consider all the possibilities.

Best wishes and take care my friend, Dave


   
Inst-Tech reacted
ReplyQuote
Ron
 Ron
(@zander)
Father of a miniature Wookie
Joined: 4 years ago
Posts: 7695
 

@davee Your comment re the power switch reminded me of when I was checking out the Manned Orbiting Lab computer system when I was at the IBM Kingston, NY factory. This was a triplex 360/67 connected by 'High-Speed Tape' to a duplex 360/67. State of the art in 1970. One of the guys who worked there told me to pull the master OFF switch, I did and nothing happened. I knew that ordinarily that switch was a dumb switch and dropped power in a very direct way that wasn't all that good for the components. All this one did having been made smart was type a message on the system console IBM Selectric typewriter something to the effect of "Master Power pulled - ignoring"

The MOL was cancelled shortly after that to be eventually replaced by the current space station Skylab.

First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.


   
Inst-Tech and DaveE reacted
ReplyQuote
byron
(@byron)
No Title
Joined: 5 years ago
Posts: 1183
 

Posted by: @zander

Gentlemen, I owe you both an apology.

Ok you can come out of the naughty corner 🤨 .  And note that once the int/sqw pin has triggered the power to the computer, then of course it runs whatever program you have compiled and previously loaded, complete with interrupts, polling or whatever.  The only thing you do have to do is to communicate with the DS3231 via i2c to clear the alarm flag so that it will power down ready for the next alarm awakening.   

A new version of micropython for all boards including the rpi pico is imminent, but I don't know if an amended deepsleep for the pico will be in the release.    I'm not sure if the deepsleep ability was an issue if using the c SDK.  Whilst the mp will be using the underlying c, it may be it was not so well implemented when calling it from mp.  I will be testing the deepsleep as far as mp is concerned when the new version arrives.


   
ReplyQuote
Page 1 / 4