compensate for drifting RTC

[BdN3504]

I would like to propose a plugin which syncs the time of the target, each time it is connected to a pc. First, the user should be able to configure whether he wants to use this feature in the plugins menu. Then there shall be an option to always sync the time or to only do it sporadically (maybe once a month or so). And of course you should be able to configure the timezone you are living in.
The best means to sync  to actual time should look something like this: when the player is connected, it somehow tries to reach a host which has the time. If it's possible to establish a connection, the time shall be synced. If not, there should be a message saying that it couldn't be done and the user is asked if he would like to sync the time of the device to the pc it's connected with.

I don't know if it is possible to make the target look for a host. If that's not possible, maybe there is a way to sync the time with the pc the device is connected to?

Do you think this is a useful feature, or do you think i shall not create a request for this?

[MarcGuay]

http://www.rockbox.org/tracker/task/2430

http://www.rockbox.org/tracker/task/530

http://www.rockbox.org/tracker/task/8744

http://www.rockbox.org/tracker/task/7845

[Mad Cow]

How would you give the player the time through UMS? All the PC has access to through UMS is the filesystem.

And what's so hard about setting the time manually? Every player I've used except for my gigabeat had a battery connected to the RTC so it never loses power and always keeps the time so you only have to do it once.

EDIT: Looked at the patch, I thought of that method before, but it's too "hacky" and I would never use it. With it, the RTC will never have the right time because of the time it takes to connect and disconnect the player.

[GodEater]

Slightly OT, but the original Apple firmware does this over UMS when it talks to iTunes by using some proprietary extra SCSI commands.

I'm pretty sure we're not going to duplicate it though.

[PaulJam]

Hi,

i was wondering if the following procedure in a plugin would be possible in order to compensate the drift of the clock without need of communication with a host computer:

Assuming the drift is constant (for example for every 10000 seconds that have passed the clock is off by one second) i could imagine that it would be possible to have a plugin that calculates the necessary correction of the clock. So when the plugin is run the first time then you set the correct time and date in the plugin and it stores the current time and date to a file. When the plugin is run next time it calculates how many seconds have passed since the last synchronization and adjusts the time accordingly and updates the time and date of the last synchronization in the file. The hard part would probably be to determine how much the clock actually drifts.

Could this work? The only complication i could imagine is when the user modifies the time through the rockbox settings.

[Llorean]

It seems to me that if you're going to manually run the plugin again, you could also simply manually look at your wristwatch and set the time.

To clarify: If the drift is constant enough, a manual plugin is silly as we could just automatically adjust for drift every boot, or similar. If the drift is not constant enough for this to be accurate, then a manual plugin is as pointless as a background fix.

[pabouk]

It seems to me that if you're going to manually run the plugin again, you could also simply manually look at your wristwatch and set the time.

I think that it is much easier to run a plug-in than to set the clock manually and in addition you do not have to have a clock

Of course the automatic way is much better - for example calculate the accumulated drift every boot and when it reaches let's say 5 seconds then adjust the RTC. This would minimize accumulating the inaccuracy added by every RTC adjustment.

The same functionality is used on UNIX systems. See the part "The Adjust Function" in http://man.he.net/man8/clock.

[PaulJam]

To clarify: If the drift is constant enough, a manual plugin is silly as we could just automatically adjust for drift every boot, or similar. If the drift is not constant enough for this to be accurate, then a manual plugin is as pointless as a background fix.

I have now found some time to test how constant the drift of the RTC in my device (H300 which uses the PCF50606) is:

Code: [Select]

Date  Time     Seconds between         Drift         Drift/day between
               measurements         in seconds       2 measurements

20.08 13:50             -         -1,07 (      -)         -
21.08 17:55      Δ=101100          8,58 (Δ= 9,65)      8,25
23.08 16:25      Δ=167400         24,81 (Δ=16,23)      8,38
26.08 09:05      Δ=232800         47,24 (Δ=22,43)      8,32
27.08 13:30      Δ=102300         56,79 (Δ= 9,55)      8,07
28.08 13:50      Δ= 87600         65,28 (Δ= 8,49)      8,37

The calculated drift per day varies between 8,07 and 8,38 seconds. I think that this is constant enough that such a functionality would make sense (at least for targets using the same RTC chip).

Maybe this thread could be moved to the "Feature Ideas" forum?

[soap]

Theoretically, how constant will the drift be?
Is RTC drift dependant on temperature?  On voltage supply?  On sunspots?   

[Rincewind]

I made an internship at a firm that sells data loggers for windparks. They use a compensation for the RTC that is dependant on the temperature (which is logged anyway). Every device is connected to a frequency counter where the amount of drift at room temperature is measured and programmed into the device before selling. From this the compensation is scaled based on temperature.

Testing with a climate fridge that tests the devices at desert and freezing temperatures over a few days showed that without compensation the drift shifted the clock by about half a minute in 4 days. With compensation it was a few seconds.

I think compensation in rockbox is possible when we assume that a device is operated and stored at room temperature most of the time. It would still need user interaction once to calibrate the drift parameter.

[oayz]

This is surely pretty nice feature. It's been very helpful on early DOS/Windows systems before people figure out s/w to modem NIS centers. Leter with internet RTC correction issue dissapered for good.

Anyway, I think this should be integrated with time setting function
- whenever we correct time by less than 1 hour we shoud be asked to use auto-correction calculated automatically based current, new last correction times.

I wish we would get summer time support as well!

[Datman]

Another solution could be a +/- adjust, like in mechanical clocks: everytime the DAP is powered on (or every i.e. 5h if someone keeps it running so many hours...) it calculates the difference between current time&date and the last saved before it was switched off. Then it applies a correction from a value manually written: 0 is the default speed; -100 is -100ppm; +100 is +100ppm (parts per million).

I.e.: 1day~90000seconds; a +50ppm correction would be +4.5seconds in 24hours. If I switch off the DAP (it writes time&date), then I power on 48 hours later it applies +9 seconds.

With a few tries a good correction can be achieved with a simple implementation. Surely it will be much better than nothing!

[Llorean]

If that's the case, you don't even need to calculate the time it's been powered off in any fine sense. Every day at midnight add 4.5 seconds. For every midnight that has passed since last power on, add 4.5 seconds. Rather than going adjusting by a percentage or anything like that, just ask the user "how many tenths of a second do I add, per day" or even "how many per week?"

People shouldn't be using these devices for too fine timing in the first place, so pick a granularity that allows a decent amount of precision, and an update schedule (daily, weekly) that means that most drift won't be more than a minute or so no matter how bad the device is. It typically benefits the user if the option is simple and easy to understand, and doesn't require them to do any calculations in their head beyond basic addition/subtraction to figure out the value to set.

[Datman]

My Sansa Fuze goes 15 seconds forward in a few (3 or 4?) days! I take the train every day and I have to be aware to look at the phone clock instead of the Fuze, because error can reach 3-4-5 minutes if I don't care to adjust the time for 1 or 2 months.

An old clock has only a screw with +/- symbols. Here there could be a scale +100/-100.

Another solution: now I set the time and click "Memo"; a week or a month later or whenever I want I set another time the time and click "Memo": it computes the correction and apply it now and everytime I power on proportionally to the elapsed time.