Open a terminal and type "hwclock". It should return the current hardware time. If it is drifting then there is a problem. If it is accurate then just the software clock is drifting and that needs to be investigated.
Note that when the battery is dead or removed the hardware clock stops. The Pandora doesn't have a dedicated clock battery.
Ok, made the test. Hardware clock seems to be ok now. Also, I have just rebooted and software clock is also ok, but I think it was wrong before the reboot. Does it make sense or I am going crazy ?
I'll check later, hwclock and software before and after reboot and report results here.
been having the same problem the hwclock is at 21:33 and software is at 20:35 also when i try and change it under date and time settings after i set it and hit ok screen goes black till i hit a key and doesn't change time,
also i find it strange i had 64% battery left last night had it turned off all night till just now and it says 88%
@ptitSeb: To share experiences: I observed time drifts with all 3 Pandoras I had since 2011-05, and on every OS (currently SuperZaxxon 1.54) so far. After using it for 2-3 days, with some sleep time inbetween, you quickly get an offset of 30 minutes or more. Dunno if an offset also accumulates if keeping it on constantly, or if it only happens if you are also in low power mode, standby mode, or fully off, in which case the RTC must draw the current itself from the battery, which it does, if I understood urjaman correctly:
Nokia phones (like from the 3310 era, maybe before) are capable of the basic wakeup by RTC for the alarm clock feature. They're as off as your PC would be if you use the wakeup by RTC feature that you will propably find in the bios settings of most even relatively modern PCs. Which means deeper sleep than STR (eg. no different from normal powering off because the RTC is powered anyways, by the backup battery if all else fails). My belief was and still is that the Pandora is capable of the same wakeup by RTC from the total off state (0.24mA by measurement btw). Just that propably nobody has written the code to configure the RTC&stuff for it yet.
@WizardStan: Will do some tests with operating/lowpower/standby mode and query hwclock; date and have a reference time (desktop computer with proper ntpd), and see if software/hardware/both clocks drift.
@Kirkanos: Battery gauge and system clock problems may be related, as according to WizardStan, they both reside on the same chip, the TWL:
The TWL chip which is the battery charger is also a the real time clock. You can give it i2c commands to trigger an interrupt at a specific time. This interrupt is effectively the exact same as flipping the power switch, so can be used to turn your Pandora on at a specific time or bring it out of standby. Install the i2c-tools package from the repo and I'll see if I can remember the exact instructions that need to be sent that you can experiment with.
In addition to experiencing time drift, I also reported experience charging issues: My Pandora stops charging far before reaching full capacity. Good to know that charging and RTC functionality reside on the same chip. So far I don't see a connection to my charging issues, as my charging stalled, but the timestamps in the sysinfo log continued.
@_wb_: Via which system calls does sysinfo get the time and schedule its intervals?
It seems the Pandora has a backup battery, possibly in the form of a capacitor. I had the battery out of my Pandora for ~4 hours. After rebooting the software clock still showed the correct date, and the minutes and seconds also nearly matched the actual time, only the hours were 2 hours behind my actual local time, being exactly my offset to UTC (Vienna, UTC+0200), so I guess the "software clock readjust routine" has a bug, not considering the local timezone.
UPDATE: My assumption was wrong! The Pandora was not loosing the timezone setting, but rather the RTC was not ticking while the Pandora was without battery for 2 hours, coincidentally the same duration as my timezone offset to UTC.
Of the 3 Pandora I have, it seems only my Rebirth as the time drifting syndroms. It seems to happens only when Sleeping, but I may be wrong (because when I use it for extented period of compilation for example, it doesn't drift). My CC and my Gigahertz does not seems to drift. Strange.
FWIW, when I checked earlier today, my GHz pandora reckoned it was still March. I've always assumed it loses time when you reset it, though I forget why I think that. Now Drastic has been patched I'll have to see if it keeps time better now.
Have tried both my GC set to UTC-600 with internet sync and daylight time savings. Also without internet sync. They never tell the same time, unless I go in to both, turn on wifi and then click internet sync. I noticed a while ago that the hwclock was different than what I was seeing in the dock. I use save states constantly so that I don't have to watch unskippable movies in rpgs if I lose a big battle. I also switch my cards to a freshly charged panda when I've run out. If I'm not paying attention my date writes for the save states get everywhere. When I come back to a game, having not played it for a while, there is a good change I have to load each state to see which has the most progress.
I tried all different scenarios: under cpu stress, in normal operation (idle), low power mode, standby and off without battery (in previous test & post);
but could not reproduce the dramatic time drifts (many minutes over only a few days) I had experienced.
The timedrift resulting from my tests over ~14 hours was merely 1-2 seconds.
Another strange observation: hwclock & swclock had 1sec offset right after booting,
but at the end of my test suite, after the CPU stress test, they were in sync (=0sec) again.
Log
# Comment line
Hardware clock (command: hwclock), precision=1sec
Software clock (command: date), precision=1sec
# Fresh boot. Then setting time to reference computer, which runs proper ntpd.
# Pandora: Opening dialogue "Menu > Settings > Date & Time > Change Date and Time"
# Observing desktop clock hh:mm:ss, …57…58…59… hitting ENTER on Pandora at 0
# Human precision. As we anyhow only have 1sec precision, this is accurate enough!
Sat May 11 18:41:30 2013 0.000000 seconds
Sat May 11 20:41:29 CEST 2013
# Going into low power mode by closing lid
Sat May 11 18:42:30 2013 0.000000 seconds
Sat May 11 20:42:29 CEST 2013
# Awoke from low power mode
Sat May 11 22:11:07 2013 0.000000 seconds
Sun May 12 00:11:06 CEST 2013
# Going into standby mode by flicking the power button
Sat May 11 22:12:08 2013 0.000000 seconds
Sun May 12 00:12:07 CEST 2013
# Going into normal mode
Sun May 12 05:47:22 2013 0.000000 seconds
Sun May 12 07:47:21 CEST 2013
# Reference time on desktop computer 07:47:50.
# Reference computer was off overnight as well
# ntpd time reset was about +0.5sec, could match hwclock 49secs.
# 1sec a day is quite a harmless offset,
# I had experienced far greater drifts, more in the dimenions
# of many minutes over only few days.
# Don't know what's causing it? Maybe high CPU load?
# Starting cpu stress test
Sun May 12 06:06:45 2013 0.000000 seconds
Sun May 12 08:06:44 CEST 2013
# Finished cpu stress test
# Reference time on desktop computer was 08:39:00.
Sun May 12 06:38:58 2013 0.000000 seconds
Sun May 12 08:38:58 CEST 2013
# Hardware and software clock are in sync again,
# but now lag 2secs behind the reference.
Bug fix instruction by WizardStan
Will try that. Does this also fix the aforementioned bug, that after rebooting with a freshly inserted battery, that the software clock regains the time from the hardware clock (UTC) without applying the local timezone offset?
Does this also fix the aforementioned bug, that after rebooting with a freshly inserted battery, that the software clock regains the time from the hardware clock (UTC) without applying the local timezone offset?
No, that would be something else. Is it at all possible you actually had the battery out for almost exactly 2 hours? Because my experience has been that the RTC doesn't tick when the battery is removed, so if you take it out, wait exactly 2 hours, and then start it up again it'll be off by two hours. Try taking it out for 30 minutes and see what the time difference is then?
Does this also fix the aforementioned bug, that after rebooting with a freshly inserted battery, that the software clock regains the time from the hardware clock (UTC) without applying the local timezone offset?
No, that would be something else. Is it at all possible you actually had the battery out for almost exactly 2 hours? Because my experience has been that the RTC doesn't tick when the battery is removed, so if you take it out, wait exactly 2 hours, and then start it up again it'll be off by two hours. Try taking it out for 30 minutes and see what the time difference is then?
@WizardStan: You were right! The RTC seems to not tick while the Pandora is off!
My observed offset was the TimeWithoutBattery + 3-4 minutes, which can be accounted to shutdown (before the pause), and after the pause: booting and start taking notes. Updated my post with the false suspicion. Will update the log later, as I'm awaiting the results of a long term standby test.
@porg: System info uses SDL_GetTicks(), which uses gettimeofday() internally, to control its timing, and localtime_r() to produce the time stamps in the log files.
It could probably get confused a bit if you change time while it is running.
The RTC is not ticking when the Pandora is without a battery.
The RTC is ticking while the Pandora is in normal operation, low-power-mode, standby and while being off.
The RTC accuracy seems to not differ significantly between these modes, it drifts about 3 secs/day, this is comparable to the precision of my MacBookPro's RTC (see below).
There is a bug that the TZ is lost under some circumstances (see below). @WizardStand, I'd appreciate if you could look into this.
Bug: Timezone offset lost at reboot and at awakening from standby
When setting the time freshly, there's a timezone offset between hw clock (UTC) and sw clock (local TZ) as it should be.
At reboot, regardless wether the Pandora was battery powered or not while being off, and at awakening from standby this TZ offset is lost!
Strangely, the sw clock overrides the hw clock. Would expect the other way round.
Simply search the full log for "TZ" if you want to investigate it.
The same error repeated again and again, is causally connected to rebooting and awakening (must be a script invoked at that event).
Very likely it's connected to Wizard's stan suggested hack of inserting hwclock -s into op_power.sh, which I applied.
Before that hack, which is also noted in my log, the log does not show that TZ offset loss!
Comparison: RTC precision on Pandora vs MacBookPro
## RTC of a MacBook Pro Late 2006 with ntpd from MacOS X 10.6.8
# 1. 2013-05-13 11:44:50 kernel System Sleep
# 2013-05-13 16:18:53 ntpd time reset +0.810248 s
16443/0.810248 = 20294
# 2. 2013-05-13 23:16:42 kernel System Sleep
# 2013-05-14 09:10:10 ntpd time reset +0.128283 s
35608/0.128283 = 277574
# 3. 2013-05-14 09:24:29 kernel System Sleep
# 2013-05-14 16:01:36 ntpd time reset +0.541671 s
23827/0.541671 = 43988
## RTC of a Rebirth OpenPandora
(3600*24)/3 = 28800
# Is well within the range of sample 1+3 from MacBook Pro's RTC precision.
# MacBookPro sample 2 is extraordinarily precise-
## Explanation of the logging format & the calculations
# N. Sleep beginn
# Sleep end, ntpd time correction
duration/deviation = precision (higher is better)
Full log of my RTC tests performed over the duration of 5 days:
# Comment line
Hardware clock (command: hwclock), precision=1sec
Software clock (command: date), precision=1sec
# Setting time to reference computer, which runs proper ntpd.
# Pandora: Opening dialogue "Menu > Settings > Date & Time > Change Date and Time"
# Observing desktop clock hh:mm:ss, …57…58…59… hitting ENTER on Pandora at 0
# Human precision. As we anyhow only have 1sec precision, this is accurate enough!
Sat May 11 18:41:30 2013 0.000000 seconds
Sat May 11 20:41:29 CEST 2013
# Going into low power mode by closing lid
Sat May 11 18:42:30 2013 0.000000 seconds
Sat May 11 20:42:29 CEST 2013
# Awoke from low power mode
Sat May 11 22:11:07 2013 0.000000 seconds
Sun May 12 00:11:06 CEST 2013
# Going into standby mode by flicking the power button
Sat May 11 22:12:08 2013 0.000000 seconds
Sun May 12 00:12:07 CEST 2013
# Going into normal mode. Reference time 07:47:50
Sun May 12 05:47:22 2013 0.000000 seconds
Sun May 12 07:47:21 CEST 2013
# Drift of 29secs.
# Don't know what was causing it? Maybe high CPU load?
# Retroactive note: Must have synced time to reference time somewhere here.
# Starting cpu stress test
Sun May 12 06:06:45 2013 0.000000 seconds
Sun May 12 08:06:44 CEST 2013
# Finished cpu stress test
# Reference time 08:39:00.
Sun May 12 06:38:58 2013 0.000000 seconds
Sun May 12 08:38:58 CEST 2013
# Hardware and software clock are in sync again,
# but now lag 2secs behind the reference.
# Reference time 09:25:00
Sun May 12 07:24:58 2013 0.000000 seconds
Sun May 12 09:24:57 CEST 2013
# Bugfix /usr/pandora/scripts/op_power.sh line 219 hwclock -s
# Rebooting.
# Reference time on desktop computer 09:33:00
Sun May 12 09:32:57 2013 0.000000 seconds
Sun May 12 09:32:57 CEST 2013
# Accumulated another 1sec offset, now 3secs.
# Shutting down Pandora and leaving it off for some time.
Sun May 12 09:37:02 2013 0.000000 seconds
Sun May 12 09:37:02 CEST 2013
# Rebooted. Reference time 10:02:00.
Sun May 12 10:01:57 2013 0.000000 seconds
Sun May 12 10:01:57 CEST 2013
# No further timedrift from being off for ~20 minutes.
# Shutting down Pandora and taking out the battery.
Sun May 12 10:16:41 2013 0.000000 seconds
Sun May 12 10:16:41 CEST 2013
# Reinserted battery. Pandora booted. Reference time 13:31:00.
Sun May 12 10:21:11 2013 0.000000 seconds
Sun May 12 10:21:11 CEST 2013
# Quite some drift. If I account 2 hours to the timezone bug, still 01h09m49s of drifting remain!
# Retroactive note: Wrong assumption! RTC did not tick at all while off.
# The missing ~4.5minutes are the time it took for shutdown, booting & taking the note.
# Setting time to reference computer.
Sun May 12 11:35:30 2013 0.000000 seconds
Sun May 12 13:35:29 CEST 2013
# Shutting down, then taking battery out.
Sun May 12 17:04:46 2013 0.000000 seconds
Sun May 12 19:04:45 CEST 2013
# Reinserted battery. Pandora booted. Reference time 20:51:00.
Sun May 12 19:06:59 2013 0.000000 seconds
Sun May 12 19:06:59 CEST 2013
# RTC did not tick while off! ~2mins for shutdown, reboot & taking note.
# TZ offset between hw and sw clock disappeared!
# Setting time to reference computer.
Sun May 12 19:16:30 2013 0.000000 seconds
Sun May 12 21:16:29 CEST 2013
# TZ offset between hw and sw clock back again!
# Shutdown. Leave Pandora off for some time.
Sun May 12 19:24:53 2013 0.000000 seconds
Sun May 12 21:24:52 CEST 2013
# Rebooted. Reference time 2013-05-15 12:41:00
Wed May 15 12:40:51 2013 0.000000 seconds
Wed May 15 12:40:50 CEST 2013
# Off for 2.5 days. Drifted 9-10 seconds.
# Setting time to reference computer.
Wed May 15 10:44:30 2013 0.000000 seconds
Wed May 15 12:44:30 CEST 2013
# Shutting down, then taking battery out.
Wed May 15 10:52:12 2013 0.000000 seconds
Wed May 15 12:52:11 CEST 2013
# Rebooted. Reference time 2013-05-15 13:19:00
Wed May 15 12:53:46 2013 0.000000 seconds
Wed May 15 12:53:45 CEST 2013
# Conclusions:
# RTC not ticking while batt out!
# The 1.5min difference are the time it took for shutdown, booting & taking the note.
# TZ offset between hw and sw clock disappeared!
# Sw clock overrides hw clock. Would expect the other way round. Strange.
# Changed timezone to Paris. Nearest listed city to my city Vienna/Austria.
Wed May 15 13:00:20 2013 0.000000 seconds
Wed May 15 13:00:19 CEST 2013
# Did not change anything. Assuming TZ had still been Paris after reboot.
# Setting time to reference computer.
Wed May 15 11:28:00 2013 0.000000 seconds
Wed May 15 13:28:00 CEST 2013
# The TZ offset is back again.
# Going into standby.
Wed May 15 13:17:29 2013 0.000000 seconds
Wed May 15 15:17:29 CEST 2013
# Awoke. Reference time 2013-05-15 19:01:00
Wed May 15 17:00:59 2013 0.000000 seconds
Wed May 15 17:00:59 CEST 2013
# There is practically no offset, only a mere second.
# But strangely the offset between hw and sw clock disappeared!
# Print time
Wed May 15 17:10:49 2013 0.000000 seconds
Wed May 15 17:10:48 CEST 2013
# Setting time to reference computer.
Wed May 15 17:12:30 2013 0.000000 seconds
Wed May 15 19:12:29 CEST 2013
# After setting the time through
# Settings > Date and Time > Change Time and Date
# The TZ offset was back again.
# Going into standby. Reference time 2013-05-15 21:14:00
Wed May 15 19:15:00 2013 0.000000 seconds
Wed May 15 21:14:59 CEST 2013
# Awoke. Reference time 2013-05-16 12:46:00
Thu May 16 10:45:57 2013 0.000000 seconds
Thu May 16 10:45:57 CEST 2013
# TZ offset between hw and sw clock disappeared again.
# Standby for ~15 hours. Drifted 2-3 seconds. Unspectacular.
# Setting time to reference computer.
Thu May 16 10:51:29 2013 0.000000 seconds
Thu May 16 12:51:30 CEST 2013
# TZ offset between hw and sw clock correct again.
# Going into low power mode by closing lid.
Thu May 16 12:12:08 2013 0.000000 seconds
Thu May 16 14:12:08 CEST 2013
# Awoke. Reference time 21:24:00
Thu May 16 19:23:58 2013 0.000000 seconds
Thu May 16 21:23:58 CEST 2013
# Low power mode for ~5 hours. Drifted 1-2 seconds. Unspectacular.
Preliminary conclusion
I also recall experiencing time drifts of many minutes. But under experimental circumstances these were NOT reproducable.
In case they happen again to me or some-one else, please note down the supposedly drifted time (both hw and sw clock by issuing the commandline: hwclock;date) plus a reference time from a properly timesynced computer plus what you did before (power circumstances and application), which may led to that time drift. Thanks!
There seems no application involved but low-power-mode triggered by the lid. Interesting that this is my second Pandora with the same problem and it seems to me that the time drifting began when I put the sd cards from my old Pandora into the (bought secondhand) "new" Pandora. But I cannot tell for sure.
the -u parameter tells hwclock that the hardware clock is set as UTC
- Neelix
P.S. If a command isn't doing what you expect it to, try entering command --help at the command line: it may tell you how to fix whatever problem you are experiencing.
For example:
Code:
op-vizzini:~$ hwclock --help
BusyBox v1.13.2 (2010-06-27 17:35:25 CEST) multi-call binary
Usage: hwclock [-r|--show] [-s|--hctosys] [-w|--systohc] [-l|--localtime] [-u|--utc] [-f FILE]
Query and set hardware clock (RTC)
Options:
-r Show hardware clock time
-s Set system time from hardware clock
-w Set hardware clock to system time
-u Hardware clock is in UTC
-l Hardware clock is in local time
-f FILE Use specified device (e.g. /dev/rtc2)
That's really weird. I don't have a timezone difference between my hardware clock and system clock. I wonder if in the course of messing with stuff I accidentally changed it to always act local time. At any rate, Neelix has it: just add a "-u" to the previous hack I gave you and see if that fixes it.
edit: although that would only account for when it comes out of sleep, not during a reboot. I may need to reflash just to see what's going on.
1) The -u argument kept the TZ properly between standby/wakeup.
2) Also tested long term periods of standby and low-power-mode without hwclock -s -u in op_power.sh, and no noteworthy timedrifts happened.
(But maybe those only occur over long term, not proportionally over time, but in sudden jumps?)
3) In the unmodified state of op_power.sh the TZ loss happens not at wake-from-standby but after-bootup!
I dunno the init process on the Pandora. Some-one who knows, please investigate where the HW clock looses its UTC zone association and changes to local.
In retrospective, the "time drifts" I (and likely also ptitSeb) had experienced must have been TZ losses + some very few minutes wrong from acceptable 3sec/day drift + unprecise manual time setting, which I (/we) then perceived as "noticable timedrift", but indeed always was a TZ mess-up!
1) The -u argument kept the TZ properly between standby/wakeup.
2) Also tested long term periods of standby and low-power-mode without hwclock -s -u in op_power.sh, and no noteworthy timedrifts happened.
(But maybe those only occur over long term, not proportionally over time, but in sudden jumps?)
3) In the unmodified state of op_power.sh the TZ loss happens not at wake-from-standby but after-bootup!
I dunno the init process on the Pandora. Some-one who knows, please investigate where the HW clock looses its UTC zone association and changes to local.
In retrospective, the "time drifts" I (and likely also ptitSeb) had experienced must have been TZ losses + some very few minutes wrong from acceptable 3sec/day drift + unprecise manual time setting, which I (/we) then perceived as "noticable timedrift", but indeed always was a TZ mess-up!
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
