| General > General Technical Chat |
| Clock circuit design idea |
| << < (4/6) > >> |
| langwadt:
https://man7.org/linux/man-pages/man8/hwclock.8.html section on adjust function |
| Connecteur:
Good point, but I think non-volatile RAM has advanced to the point where data could be stored for up to 10 years or more. |
| ebastler:
I am not sure where this incremental correction scheme would have its application niche these days. External time references are so easy to come by -- be it mains cycle counts, time broadcast stations, or NTP servers available via a fixed or wireless network. Those clocks which might benefit, namely "off the grid" portable ones, will get carried around, exposed to fluctuating temperatures, run on batteries of varying voltage... In which case I would expect the effect of those external fluctuations to dominate the inaccuracy of the clock, such that a correction of constant errors or long-term drifts doesn't cut it anymore. |
| greenpossum:
I know of one project which implemented this kind of idea: https://hackaday.io/project/169509-a-very-accurate-led-clock It may not work so well if the temperatures range is wider. I suspect the real reason it isn't implemented in cheapo clocks is 1. there is already some other source of time, and 2. even if such a scheme is used, it will cost to calibrate each unit, and if the drift is too much in the field, people will get annoyed anyway and the scheme isn't doing any good. |
| Tom45:
I once worked with a guy that had that feature in his car's clock. This was decades ago and the implementation left something to be desired. Think mechanical clock movement with no electronics involved. He said that it would overcompensate when he made a time correction. So each time he corrected the time it would overshoot in the other direction. It took quite a few iterations to get it close. No, I don't remember the manufacturer of the car. |
| Navigation |
| Message Index |
| Next page |
| Previous page |