Ice Tube Firmware Question

[neutron spin]

I noticed when the clock is unplugged and powered back up the brightness setting goes back to 3.0 (dimmest). Doesn't the memory retain the last brightness setting when power is lost?...Thanks...

[adafruit]

it does that immediately to save power

[neutron spin]

That is what I thought. I thought the earlier clocks did not have that feature. Perhaps my memory is not what it used to be ....Regards...

[ib123]

Once again I suggest that documenting how the clock is designed to behave after a power interruption would be very helpful for people purchasing the clocks and wanting to know what to expect from them.

Contrary to what is said here, my newly constructed clock remembers all its settings including brightness when I unplug the clock and plug it back in.

[neutron spin]

OK...I am all ears....So which is it?...My clock VS. others.....Mine reverts back to 3.0 when power is lost...this is of course is with the latest firmware installed and yes the battery is installed.......Adafruit says yes it does go back to 3.0...but????....

[ib123]

When I was unsure if my backup battery was working I unplugged the power and then measured the voltage on C4 (easiest to measure this on the C4 side of D4).

I don't know how to tell which firmware is in the chip as there is no version number indication on the menu system, but my clock was purchased very recently.

There is no reason to change the display brightness when unplugging the clock as the display will switch off as soon as main power disappears and the backup battery then only needs to supply the 5 V logic parts of the circuit.

[neutron spin]

Wow...more weirdness!....powered down clock again and it remembered this time the brightness setting...for some odd reason the memory does not always capture the brightness setting...everything else works fine...time is accurate and battery backup appears to be working....oh well...does it really matter? ....regards...

[adafruit]

it all depends on how fast power is lost. really, the battery backup is optimized for the time not for saving the brightness settings. keep the clock plugged in at all times, dont constantly unplug/replug it because eventually it may miss saving the time to eeprom before power is lost.

[neutron spin]

Thanks Adafruit for the explanation. I wasn't trying to break the clock ...just noticed the quirk....makes sense...

[ib123]

I guess I don't understand the design of this clock yet. Why would the clock want to save the time in the EEPROM? Surely the clock needs to keep the time, not freeze the time? For the brightness setting and other settings, why not save them to EEPROM as soon as you change them, rather than waiting for a power interruption before doing so? Is there a limited number of write cycles on the EEPROM that discourages frequent writes?

My preferred behavior would be for the clock to go into standby mode on loss of main power and come back just where it left off after power is returned. I don't see a need for it to beep and blink the display on power restoration except after a cold reset.

It seems there is a little project in my future to learn how to modify and reprogram the clock firmware. I would like to add a time adjust fast/slow feature to the menus when I do so to fine tune the time keeping.

[jarchie]

I never noticed any issues with remembering brightness settings after power loss. My clock was purchased in December 2011.

From examining the Adafruit code and my own personal experience with the clock, I believe the official firmware saves the time and restarts the clock after a power outage. After the restart, the firmware loads the saved time, detects the low power condition, and sleeps, waking once-per-second to update the time. I suspect that, while sleeping, the once-per-second interrupt periodically fails to wake the clock. When this happens, the watchdog timer detects a lockup and resets the clock, sometimes resulting in noticeable time loss. When power is restored, the clock once again saves the time, restarts, loads the saved time, and otherwise runs normally.

After writing an alternative Ice Tube Clock firmware with the behavior described by ib123 (no restarting or blinking on power loss), I can say that reliably waking from power save mode with asynchronous timer interrupts is surprisingly tricky. But for those attempting to do so, the following suggestions may help:

First, before sleeping, ensure all timer2 registers have been written. If they have not, the system may not wake.

Code: Select all

while(ASSR & (  _BV(TCN2UB) | _BV(OCR2AUB) | _BV(OCR2BUB) | _BV(TCR2AUB) | _BV(TCR2BUB) ));


Second, the code in the once-per-second interrupt must take at least one quartz clock cycle to execute (32.768kHz or 30.5 microseconds), or the interrupt may be triggered more than once per second. If in doubt, set one of the timer2 registers in the code, and the while loop above will prevent the system from sleeping before the value is written, which takes more than once quartz clock cycle. For example, the following line could be placed in the once-per-second interrupt handler.

Code: Select all

OCR2B = 0;


Third---and I found no mention of this in the ATmega168 or ATmega328p datasheets---waking from sleep is unreliable if any of the timers are disabled in the power reduction register (PRR). So enable and disable timer0 and timer1 with the timer configuration registers (TCCR0A, TCCR0B, TCCR1A, and TCCR1B), and leave all timers enabled in the power reduction register.

Fourth---and this is done correctly in the official firmware---divide the system clock by at least four during sleep as higher clock speeds may prove unstable at lower voltages. Some people recommend dividing the clock by the maximum possible amount to reduce power consumption while running code, but this also forces the microcontroller to spend more time running code and less time sleeping. In my firmware, the microcontroller used less power while sleeping with a faster clock speed. So grab your multimeter, try it both ways and do whatever is more efficient.

Code: Select all

#include <avr/power.h>
// ...
clock_prescale_set(clock_div_4);


Fifth and finally, I do not think there is much need to optimize the power-loss interrupt for speed, as previously suggested. The power supply capacitors are reasonably large and the ATmega168v executes code quickly. My power-down-and-sleep code is rather inefficient, but still seems to work reliably without loosing time...

Well... I hope someone finds this information helpful. Cheers!