Low power RTC with alarm

[PICMICRO]

I am going to make battery powered RTC using PIC16f676. However, there won't be any display. . I will just be sounding an alarm through out the day on pre-set weekly-schedule.

What I want to ask is what is the best strategy to go for maximum power saving.
1. Running Timer1 from sepearte LP oscillator (32.768Khz) and Running main uC from 4 Mhz internal oscillator. Waking up on every 2 seconds from Timer1 interrupt, updating registers (and sounding alarm if necessary) and going back to sleep.

2. Running main uC itself from LP oscillator (32.768 Khz) and using TMR0 interrupt for counting time. Never go to sleep.

 

[Ian Rogers]

The lowest power requirements are on the slowest clock speeds so using an external 32.768khz and sleeping will be the best for low power.

(you can still sleep and use the watchdog )

Ian

 

[PICMICRO]

I can't both run CPU at 32.768khz and sleep. I need to keep time. So the question is what consumes more power and by how much
1. Running CPU at 32.768 khz with all peripherals off.
2. CPU at sleep and Timer1 LP oscillaotr running at 32.768 khz and keeping time.

If options 2 consumes much less power then I will go for it and wake up the C.P.U only occasionally. But the advantage of 2 shouldn't of outworked by the power consumed by 4 MHz cpu during the brief wake-up time.

 

[dougy83]

So the question is what consumes more power and by how much

Datasheet says (all @2V):
FOSC XTAL 32kHz -> 8.5uA
T1OSC 32kHz -> 4uA
FOSC IntRC 4MHz -> 340uA

So, option
1) running CPU @32kHz uses 8.5uA.
2) uses at least 4uA. If you interrupt every 2 seconds, execute 50 instructions (i.e. the 340uA is for 2million 'awake' instructions every 2million instruction cycles - but you're only using 50 'awake' cycles out of the 2million; so current to run the cpu is 340uA * 50/2e6 ), the total is 4.0085uA.

If you use a different PIC, e.g. pic16f819, the timer1 current can be 1.8uA @ 2V.

But the advantage of 2 shouldn't of outworked by the power consumed by 4 MHz cpu during the brief wake-up time.

Have a look at the datasheet for the current drawn by the different frequency clocks - the current per instruction actually decreases as the clock freq goes up (for external crystals). If current were proportional to speed, the total current consumed for 50 instructions at any clock rate would be the same.

 

[3v0]

I have been playing with this chip for a while and like it. The 18F27J13 has an on board RTC that runs while the controller is in sleep or deep sleep (aka off). It is a 28 pin and can be had in DIP.

Deep Sleep mode: CPU Off, Peripherals Off, SRAM Off,
Currents Down to 9 nA and 700 nA with RTCC. Able to wake-up on external triggers, programmable WDT or RTCC alarm.
​

You can sleep with the CPU and the memory on at about 2uA.

The core is 2.5V and the IO runs up to 3.3V with many pins 5V tolerant.

If you are unhappy with learning or change I would not recommend this chip. There is new stuff here.

 

[Ian Rogers]

If you start your watchdog (this runs on a separate RC clock) this will fire every 18ms independent of the main clock, so with a 32.768khz main clock use the watchdog to pull out of sleep and calculate time (you can still use the WDT prescaler).

Ian

 

[dougy83]

If you start your watchdog (this runs on a separate RC clock) this will fire every 18ms independent of the main clock, so with a 32.768khz main clock use the watchdog to pull out of sleep and calculate time (you can still use the WDT prescaler).

The watchdog is not suitable to use as a RTC timebase due to its inaccuracy. Also, the main clock is switched off in sleep. You would still need timer1 running anyway to get a decent accuracy.

 

[Gayan Soyza]

Whats the battery you are going to use?

I experimented with 3V CR batteries none of them worked longer for me.Batteries were drained within 1 week.

After I shifted to DS 1307 chips those are really low power.But still the PIC side needs some external power.My alarm clocks still working without any problems.

 

[dougy83]

I experimented with 3V CR batteries none of them worked longer for me.Batteries were drained within 1 week

A CR2032 (220mA.Hr) should last for 6 years at the above calculated 4uA. If you are only getting a week out of it, you'd have to be drawing >1mA average, which would either mean that you're not in sleep mode, or there's something else taking a lot of power (e.g. the buzzer going off for too long)

 

[birdman0_o]

Combine the best of both worlds. Run the core and timer from the oscillator and when you are done the computations put it to sleep. Datasheet says 9uA at 2V. So from douggy's math above:

With an estimation of 50 cycles to do all the math.

T1OSC 32kHz -> 4uA * (32768 - 50)/32768
+ 9uA * (50) / 32768 = 4.0076 uA average.

Anyways Timer1 and sleep is the way to go. Apparently there isnt much of a difference (0.02%) between 4Mhz and the 32.768Khz so that's up to you.

 

[dougy83]

Your calcs are a little off. The instruction clock would be T1OSC/4, which is 8k & the timer overflow period is 2 seconds or 16k instruction times.

32k: 9uA * 50 / 16384 = 27.5nA
4M: 340uA * 50 / 2000000 = 8.5nA

It's quite common to have a faster main clock and more time sleeping if the operation can be event driven & if you can get the peripherals to do your work in the background (e.g. sending serial data, PWM, etc.), but this is just an aside & not relevant to the alarm clock being discussed.

 

[birdman0_o]

Quick interjection, if he's making an RTCC, wouldn't it need to be every second? Are seconds not valuable? If they aren't Timer1 could be divided down even more.

 

[dougy83]

Quick interjection, if he's making an RTCC, wouldn't it need to be every second?

No, it doesn't need to be. Timer1 holds the low 16 bits of the count, so you can resolve the current time to ~30us.

Timer1 has a minimum natural overflow interrupt period of 2 seconds. The period can be shortened by writing to the timer count (taking into account any clock stall penaties, etc.) register every interrupt.

Are seconds not valuable?

I believe time is said to be our most precious resource.

If they aren't Timer1 could be divided down even more.

You can, perhaps to reduce the number of bits required to store the time (32bit overflow counter will provide 59years without timer prescaler), but for minimal gain in current consumption.

 

[PICMICRO]

Just to clear up confusion.
I don't need to display the time, Although I need to make accurate account of it.
I just need to sound alarm in preset schedule for a week. The schedule will have resolution of only minutes (or even five minutes), so no worries if I can't sound alarm at xx:xx:51 but only xx:xx:52. I just count how many 2-seconds have passed.
I am afraid to write to Timer1 registers, because I have read somewhere (perhaps in microchip forum), that It may introduce some random error to the Timer1 counting process.
But anyways, I don't need that.

Do you have a good reference on how I can apply calibration to my RTC. The first thought coming to my mind, is to let it run for 1 week, see how much time it looses or gains, and then write a code, that freezes or jumps a few seconds at each weekend.

 

[dougy83]

I am afraid to write to Timer1 registers, because I have read somewhere (perhaps in microchip forum), that It may introduce some random error to the Timer1 counting process.
But anyways, I don't need that.

Don't be afraid; read the appropriate section of the datasheet instead. The problem only exists if you were to attempt to write the registers at the time the external clock ticks - which is 30us after your interrupt occurred (plenty of time) - so it's no problem if you wanted to write to them.

Do you have a good reference on how I can apply calibration to my RTC. The first thought coming to my mind, is to let it run for 1 week, see how much time it looses or gains, and then write a code, that freezes or jumps a few seconds at each weekend.

That will work well - and because you never display the time, noone will ever notice the time freeze/jump (not that they would anyway). If you want decent accuracy, you could keep a drift accumulator variable to keep track of the error (in units of << 1/32768Hz); when it passes 2 seconds, increment or decrement the overflow counter and update the accumulator. The accumulator can be updated every interrupt.