CHDK Forum
CHDK Development => General Discussion and Assistance => Topic started by: reyalp on 16 / August / 2020, 02:25:27
-
In 5552 I added a lua function set_clock to set the camera date / time.
syntax is
set_clock(year, month, day, hour, minute, second)
Values are integers and all are required.
Values are all exactly as they would appear in the camera clock: 4 digit year, month and day numbers start at 1. It is not aware of DST, the displayed time after setting is the values set, regardless of the DST setting.
If you want to set just one value, for example to set one hour forward, you could do something like
t=os.date('*t') -- current date / time as table
set_clock(t.year,t.month,t.day,t.hour + 1, t.min, t.sec)
If you want to set it from a timestamp value, you can pass the timestamp as the second parameter of os.date and use it as above. For example, to set 10 seconds ahead, you could do
t=os.date('*t', os.time() + 10)
set_clock(t.year,t.month,t.day,t.hour, t.min, t.sec)
This is a safer than manipulating individual values, since you don't have to worry about days / hours etc going out of range.
It uses the SetDate eventproc. Advantage of having it built in is that it avoids the need to call registration event procs which can have negative side effects. Additionally, it takes care of updating tick_count_offset for DNG subsec time.
The CHDK code doesn't do any validation, so if you decide to set it to 25:99 hours on Feb 30, you get whatever the camera OS does this that.
I called it set_clock because it's not symmetric with any of the various get date/time functions.
From my testing, it updates the RTC, so the set time will be kept even if the camera shuts down abnormally after the set (discussion in https://chdk.setepontos.com/index.php?topic=13856.msg143971#msg143971)
edit:
Corrected code examples to use set_clock(). Thanks Mlapse for catching the typo.
edit:
In 5553, I fixed a bug that caused seconds to be set to the minute value :-[
-
A ptp function to sync cams´ with computers´ clock could be useful, at least for rigs with cams with outdated battery. 8)
-
A ptp function to sync cams´ with computers´ clock could be useful, at least for rigs with cams with outdated battery. 8)
!require'extras/synctime'.sync()
If the camera is showing the "set time" prompt, you still need to click SET to close the menu.
I'll probably move this out of extras and make it a command now that it doesn't depend on eventprocs.
-
I did a 10 day test with reboot every day and it does exacly what is says on the tin, thanks reyalp.
I found out that the reboot takes up 22 seconds
So i reset the time to -60 seconds before reboot (2 sec sleep)
the result in the log is -58 seconds when the script starts reboot, 5 sec before script becomes active again.
It is consistant, so that is a good thing.
But I feel there is still something wrong, because of the CHDK delay to start large SD cards. 5 seconds loss seems not enough..but i'll leave that for now.
I'm still convinced that the RTC is more accurate than OS clock. If that is true setting RTC with set_clock will not solve the floating time of OS clock...it just makes it less visible
-
I'm still convinced that the RTC is more accurate than OS clock. If that is true setting RTC with set_clock will not solve the floating time of OS clock...it just makes it less visible
In my experience, the RTCs are not very accurate. I haven't measured it carefully, but my impression is seconds per day is common. I don't know how the OS clocks differs, my cameras usually don't run that long ;)
-
In my experience, the RTCs are not very accurate.
I know, most my cams run about 1 minute per month too quickly.
And what I know from the data is that, depending on how dark the period is, there is a variable difference in time between RTC and OS.
On all cams I tested It is true that the OS clock runs slightly faster than the RTC
As some of you will know, when installing windows in the old days, that last minute could take more than a lunchbreak ;)
Now, as I understand RTC is independantly running on the battery and OS is running on the system chip.
So I assume that the RTC has a non-influenced, thus stable, clock (maybe not atomic clock accurate, but consistant) while the OS clock is fluctuating because of the system reaching max load/throughput.
What do you think?
-
So I assume that the RTC has a non-influenced, thus stable, clock (maybe not atomic clock accurate, but consistant) while the OS clock is fluctuating because of the system reaching max load/throughput.
What do you think?
The crystals in normal cheap RTCs are significantly affected by temperature. For a random example, see the application note at https://www.nxp.com/products/peripherals-and-logic/signal-chain/real-time-clocks/rtcs-with-ic-bus/100-na-real-time-clock-calendar-with-battery-backup:PCF8523?&tab=Documentation_Tab&linkline=Application-Note
It notes that
* A clock running 1 s per day too fast has an inaccuracy of 1/(3600*24) = 11.57 ppm
* A deviation of 1 s per week means 1.65 ppm
The temperature dependence may be particularly significant for CHDK timelapse applications, because operating continuously for long periods can result in high internal temperatures that would be less common in normal usage.
There are also aging effects, which might be significant given that many CHDK cameras are used long beyond their typical consumer lifetime.
The OS clock is based on a high frequency timer on the SOC which I would expect to be fairly accurate and relatively unaffected by CPU load, but I don't really know. Canon probably doesn't have a requirement for high accuracy of the OS clock, since normal usage would be for it be powered off most of the time, and restarted frequently.
-
On cams with GPS. Is it possible to synchronize time with GPS time?
-
The temperature dependence may be particularly significant for CHDK timelapse applications, because operating continuously for long periods can result in high internal temperatures that would be less common in normal usage.
I've read the spec sheet but haven't done calculations on it with my data yet.
the 5 seconds per week difference between summer and winter in a 3 week run can have a few days of 20 ºC difference (32-50 ºC) at exceptional hot summer days in the run
but is usually less than 10 ºC between all runs (from the data: 31-35 januari, 32-42 ºC july)....the advantage of having it always powered is a slightly higher, but fairly stable temperature
The OS clock is based on a high frequency timer on the SOC which I would expect to be fairly accurate and relatively unaffected by CPU load, but I don't really know.
Me neither.
Since I have no realiable means to test what is the most accurate clock of the 2 I'll abandon the idea of using RTC time.
-
On cams with GPS. Is it possible to synchronize time with GPS time?
According to the SX260 manual, this seems to be a feature of the stock firmware (page 51 of the English version) under menu item "GPS Auto Time". It states that when this is enabled, the normal time setting UI is disable, so it's not clear how it would interact with set_clock.
If "GPS Auto Time" is turned off, one could probably get the time from the GPS propcase from script and then use set_clock
-
[According to the SX260 manual, this seems to be a feature of the stock firmware (page 51 of the English version) under menu item "GPS Auto Time". I
Right. I've never noticed it on my SX230. GPS is also mostly switched off. Should have read the manual ...
-
The OS clock is based on a high frequency timer on the SOC which I would expect to be fairly accurate and relatively unaffected by CPU load, but I don't really know.
I've tested that by using old logs and I think you are right, the OS clock is most reliable.
Thank you for this function, it gives me a chance to correct the time during a run.
It is really ashame that reboot does not work on Digic6, i would have liked my m10 to be able to do this.
-
On cams with GPS. Is it possible to synchronize time with GPS time?
If "GPS Auto Time" is turned off, one could probably get the time from the GPS propcase from script and then use set_clock
gps = require("gpsLib") 8)
The script test/gps_test.lua seems to have all the lines You need...
-
I noticed cameras starting from DryOS R52 have an eventproc GetTimeFromRTC which appears to return a unix-like timestamp, without the DST adjustment.
The underlying function used by the eventproc is also called from task_Startup, via the same function that calls StartWDT. This presumably where the OS clock gets initialized, and an obvious equivalent exists on earlier dryos cams without the event proc.
-
I noticed cameras starting from DryOS R52 have an eventproc GetTimeFromRTC which appears to return a unix-like timestamp, without the DST adjustment.
The underlying function used by the eventproc is also called from task_Startup, via the same function that calls StartWDT.
I added that to the dryos sigfinder, along with some slightly related functions that I found in the ixus30 firmware earlier.
-
In 5552 I added a lua function set_clock to set the camera date / time.
I did a few tests with going to play, set_clock followed by a reset once a day and later once a week and those all worked out perfectly on a 64GB card.
the only thing i could see in the log was that it skipped 2 lines before resetting the time.
it was already skipping 2 lines on reboot, so that made the "set clock" stand out in the log.
so I decided to place it in my running project that reboots after 3 weeks on a 256GB card.
alas it did not work.
because i did not put the proper chdk build on the card, it was still running 5172.
so it halted on the CHDK menu without going past set_clock to the reboot.
human error....the most annoying thing :)
is there a way to check build number without loading it in the cam?
-
well, I am very happy with set_clock, a very good addition reyalp.
I've used a 35 second correction after 3 weeks.
total run time was little over 31 days.
35 sec. did not completely correct the offset, but it seems some of the unstable side effect of reboot are also fixed.
and that has more value than a few seconds per month too much....
maybe in a few month I'll be able to set the correction to a value that makes a few seconds off per year possible.
but for now I'll accept the few minutes off per year as minor compared to the 40-50 seconds per month I had previously.
herebelow a small portion of the log.
20201122 165002 Day 22 Sun Nov 22 16:50:02 2020 IMG_0021.JPG tv: 1/8 f: 3.1 ISO: 75 TV96: 284 AV96: 322 bv: 235 V: 3.949 T: 34
20201122 165002 Day 22 Sun Nov 22 16:50:02 2020 set backlight on
20201122 165008 Day 22 Sun Nov 22 16:50:08 2020 Scheduled reboot
20201122 165008 Day 22 Sun Nov 22 16:50:08 2020 lens retraction wait
20201122 165020 Day 22 Sun Nov 22 16:50:20 2020 rebooting now
20201122 164946 Day 22 Sun Nov 22 16:49:46 2020 time set
20201122 164953 Day -- Sun Nov 22 16:49:53 2020 SUIx V0.4.4
20201122 164954 Day -- Sun Nov 22 16:49:54 2020 Card size 235 Gb Free 105 Gb
20201122 164954 Day -- Sun Nov 22 16:49:54 2020 CHDK 1.5.0 Oct 19 2020 s95 100k
20201122 165007 Day 1 Sun Nov 22 16:50:07 2020 Autostarted. Next reboot:21 days
20201122 165008 Day 22 Sun Nov 22 16:50:08 2020 Elapsed days = 22
20201122 165009 Day 22 Sun Nov 22 16:50:09 2020 Oldest image number = 1
20201122 165009 Day 22 Sun Nov 22 16:50:09 2020 Oldest DCIM folder = 100_0111
20201122 165031 Day 22 Sun Nov 22 16:50:31 2020 IMG_0022.JPG tv: 1/6 f: 3.1 ISO: 75 TV96: 261 AV96: 322 bv: 212 V: 3.935 T: 33