Real-Time Clock stops when the device is turned off

[matejcik]

i've been experiencing trouble with TB's clock. The time always seemed pretty random when i turned on the unit. Originally, i thought that the internal clock reset when battery runs out, or maybe i can't set the hardware clock because of software bug, so the time is somewhat weird.
Today I made a point of properly setting the time (it was 14:11 CET), using hwclock to store it and then to retrieve it and everything seemed fine. Then i turned the unit off and started it half an hour later on my ride to school.
The time i set was right there. But it didn't advance. It showed something like 14:20 (time when i turned the TB off), but it was already 14:55.

Then it dawned on me: the time stops when the device is off.

That is ... somewhat scary.

anybody else experienced this? is this a property of the board, fault of my unit, fatal design flaw, an overlook that can be easily fixed by flipping a register in software? evil magic by alien overlords?


(and don't point me to ntp. i know what ntp is and what's it good for, i also know that it won't keep my darned clock in sync unless i go online every time i turn the tb on (which i don't plan on doing))

[Meizirkki]

i've been experiencing trouble with TB's clock. The time always seemed pretty random when i turned on the unit. Originally, i thought that the internal clock reset when battery runs out, or maybe i can't set the hardware clock because of software bug, so the time is somewhat weird.
Today I made a point of properly setting the time (it was 14:11 CET), using hwclock to store it and then to retrieve it and everything seemed fine. Then i turned the unit off and started it half an hour later on my ride to school.
The time i set was right there. But it didn't advance. It showed something like 14:20 (time when i turned the TB off), but it was already 14:55.

Then it dawned on me: the time stops when the device is off.

That is ... somewhat scary.

anybody else experienced this? is this a property of the board, fault of my unit, fatal design flaw, an overlook that can be easily fixed by flipping a register in software? evil magic by alien overlords?


(and don't point me to ntp. i know what ntp is and what's it good for, i also know that it won't keep my darned clock in sync unless i go online every time i turn the tb on (which i don't plan on doing))

I haven't found a way to keep the device in time when turned off either. My solution is Network Manager setting the time automatically to my local timezone.

[matejcik]

http://bugzilla.alwaysinnovating.com/show_bug.cgi?id=93

[nprnncbl]

I doubt this is fixable in software. On a standard PC, there's a battery that powers the rtc. But there is no such backup battery in the TB; when it's off, it's really off.

Hopefully, though, we'll eventually get power management with a sleep/trickle mode that keeps the clock going.

Alternatively, if you really don't want to connect to a network, you could try something like http://www.meinberg.de/english/products/msf51usb.htm which uses a radio signal, or use a gps to get the time from a satellite.

[matejcik]

as i wrote in the bug:
the tps65950 chip supposedly has a RTC feature with backup battery, so it would be theoretically possible to hook a button battery to it. i just don't know how to do it

[nprnncbl]

Rev C3 of the BeagleBoard has such a battery; you could check their schematics, or ask on the BB forum how to hack it into an existing board.

[matejcik]

yeah ... gregoire just said that "the pin is grounded and it's a BGA", which in layman terms probably means that i'd have to drill a microscopic hole through the board :/
we'll see. i have this colleague who is rather crazy and he just might be able to do it.

[glenhawk]

Wouldn't it make more sense to have a circuit that supplies the RTC from the main batteries? It seems kind of redundant to have a button cell on the board when you have two perfectly fine batteries installed.

Setting that aside (because it would require a hardware revision) it appears to me that currently a shutdown switches everything off giving you maximum battery saving at the cost of the clock. If you could properly suspend the TB by tapping the on/off button so that only a bare minimum of systems are enabled then you would get reasonable battery conservation, a clock set at the correct time and instant on (rather than having to wait for it to boot).
For me, both of these two modes would be used. I would use suspend before sticking it in my bag and travelling to work but I would shut it down over night (if it didn't need a charge) or if I did not plan on using it for a number of hours.

This is a bit off topic but the other idea I had was to have a "charge mode" for the TB. I was thinking that you could have the system "logged-out" to the multi-boot OS menu with all unnecessary devices switched off (wifi, bluetooth, etc) and on part of the screen you could have two big battery progress bars. I was going to try this as it is currently but I found two problems:

• the wifi is still flashing away (so there is no advantage to not having it logged in)
• the screen stays on (can an LED lit LCD suffer screen burn?)

[matejcik]

question is, how hard (or easy) it is to wire the main battery as a "backup source" and use it as main battery at the same time.

of course, when we get to the point of "always-on", this question will mostly go away and i'll be shutting the book down only in situations where i don't have an AC outlet available.

the biggest problem i see with "charge mode" (and yes, i've been thinking about it too, quite a lot) is that you really really want the LCD turned off, and so you can't check the charging progress ;e) (i think that you can't screenburn a LCD - the backlight is always on, and the cells darken it)
But for charging mode to work, you have to put everything you can into a low-power mode, including all the chips on the mainboard. OMAP3 hardware can do it, but i'm not sure about our kernel. Also you'd want to shut down the individual USB devices (while keeping the hub powered, because otherwise it wouldn't come back up), and i'm still trying to find out if that is possible.

[Aard]

Alternatively, if you really don't want to connect to a network, you could try something like http://www.meinberg.de/english/products/msf51usb.htm which uses a radio signal, or use a gps to get the time from a satellite.

I've been talking to a hardware geek about this topic (I've been thinking about hooking up a DCF-77 module, too). He suggested not using a DCF module due to potentially long startup time, but instead hooking up a RTC module to the I2C-bus. A most likely usable design can be found here: http://www.winpicprog.co.uk/pic_tutoria ... _board.htm

The chip used there is natively supported by the Linux RTC subsystem starting with 2.6.25, like a few others. I'll look into implementing this option once I got some spare time on my hands... (I just ordered the DS1307 which provides similar functionality, but is a bit easier to use and draws less power)