SUIx, comprehensive long duration intervalometer. Something for you? - page 3 - Completed and Working Scripts - CHDK Forum
« previous next »
Pages: 1 2 [3] 4 5 6 7   Go Down

SUIx, comprehensive long duration intervalometer. Something for you?

  • 64 Replies
  • 24213 Views
*

Offline Mlapse

  • *****
  • 584
  • S95 S110
Re: SUIx, comprehensive long duration intervalometer. Something for you?
« Reply #20 on: 07 / August / 2020, 16:12:54 »
Advertisements
Quote from: reyalp on 07 / August / 2020, 16:06:41
I think the suggestion is just before reboot, you could use poke() to save the current time somewhere safe, and then use peek() to get it later.
If there is really an offset between the OS clock and RTC time after reboot, maybe calling the time setting eventprocs to the current time would update it.
Thanks, i'll dive into srsa_4c suggestion and your script.
If you look at the csv, you see the log entrys have earlyer timings after reboot, so yes there really is an offset.

If canon os clock runs quicker than the RTC time on the battery and at boot it checks RTC time.
Storing at shutdown and loading stored time at boot would result in the same problem minus 10-15 sec.

So my first thought would be to use the reboot timestamp, should give a 10-15sec correction on canon os clock every time it reboots.
Not enough for my taste, but this way there are no conflicting times and it's already available when the script calls for a reboot.
Now implementing that idea.....

there is only one thing that's bothering me in this assumption.
if there is a difference between os and rtc after a while why haven't i encountered that when switching an sd card within 30 seconds, if it then initialises the rtc time it should also have had an earlyer timestamp on the new run, but those have a correct downtime gap.
 
« Last Edit: 07 / August / 2020, 17:15:48 by Mlapse »
Logged
frustration is a key ingredient in progress
*

Offline srsa_4c

  • ******
  • 4451
Re: SUIx, comprehensive long duration intervalometer. Something for you?
« Reply #21 on: 07 / August / 2020, 17:35:00 »
A reboot skips saving camera state to flash and state variables are also not written to the NVRAM on the RTC circuit. That might be a cause of unusual behaviour, after reboot.
In some cases, the Canon firmware is not prepared to correctly re-initialize certain subsystems after a reboot. Examples: DIGIC 5 ports that can't use the firmware update method, or DIGIC 6 models where firmware update boot requires hacks due to the codec that remains initialized and active after a reboot.
Logged
*

Offline Mlapse

  • *****
  • 584
  • S95 S110
Re: SUIx, comprehensive long duration intervalometer. Something for you?
« Reply #22 on: 08 / August / 2020, 02:08:45 »
thanks for the ideas, but but i cannot make this work  :(
setting the time with the script after reboot makes that first the (uncertain but) earlyer time is loaded by canon os/chdk before i can correct it.
setting the time before reboot results in the same difference.

@srsa_4c I have tested reboot on several models at my disposal and they all suffer from this time offset at reboot, i suspect all cams that support reboot do.
« Last Edit: 08 / August / 2020, 02:21:32 by Mlapse »
Logged
frustration is a key ingredient in progress
*

Online reyalp

  • ******
  • 14126
Re: SUIx, comprehensive long duration intervalometer. Something for you?
« Reply #23 on: 08 / August / 2020, 12:01:49 »
Quote from: Mlapse on 08 / August / 2020, 02:08:45
setting the time with the script after reboot makes that first the (uncertain but) earlyer time is loaded by canon os/chdk before i can correct it.
My suggestion was to set the time (to the current time) *before* reboot, on the expectation that SetHour etc would set the RTC time as well as the OS time. From my test, this appears to be the case on sx160is at least. You can verify this by using the functions to change the time (to say, 10 minutes ahead), and then rebooting, and checking whether the time is still 10 minutes ahead.

Note that the eventprocs that need to be registered might cause side effects, so the registration calls be done immediately before setting the time and rebooting, not at the start of the script.
Logged
Don't forget what the H stands for.
*

Offline Mlapse

  • *****
  • 584
  • S95 S110
Re: SUIx, comprehensive long duration intervalometer. Something for you?
« Reply #24 on: 08 / August / 2020, 13:23:43 »
Quote from: reyalp on 08 / August / 2020, 12:01:49
You can verify this by using the functions to change the time (to say, 10 minutes ahead), and then rebooting, and checking whether the time is still 10 minutes ahead.

It is not that easy, the offset is't noticable after a few shots..
I need something like 4-7 days active cam until you can see a difference big enough to not call it a fluke.
Then there are other problems from the reboot that only come out after a reboot and >15 days running.

 
« Last Edit: 08 / August / 2020, 13:39:02 by Mlapse »
Logged
frustration is a key ingredient in progress
*

Online reyalp

  • ******
  • 14126
Re: SUIx, comprehensive long duration intervalometer. Something for you?
« Reply #25 on: 08 / August / 2020, 14:43:44 »
Quote from: Mlapse on 08 / August / 2020, 13:23:43
It is not that easy, the offset is't noticable after a few shots..
I need something like 4-7 days active cam until you can see a difference big enough to not call it a fluke.
Again, I'm suggesting a simple artificial test to verify that the RTC is updated when the time setting function is called. If that's correct, then it should either fix your problem, or your problem is not actually the RTC getting out of sync with the OS clock.
Logged
Don't forget what the H stands for.
*

Offline Mlapse

  • *****
  • 584
  • S95 S110
Re: SUIx, comprehensive long duration intervalometer. Something for you?
« Reply #26 on: 09 / August / 2020, 02:30:19 »
I will try your simple test as soon as i understand how to write that.
Logged
frustration is a key ingredient in progress
*

Online reyalp

  • ******
  • 14126
Re: SUIx, comprehensive long duration intervalometer. Something for you?
« Reply #27 on: 15 / August / 2020, 02:47:22 »
Quote from: Mlapse on 09 / August / 2020, 02:30:19
I will try your simple test as soon as i understand how to write that.

Call the registration event procs
Code: [Select]
if call_event_proc('FA.Create') == -1 then
error('FA.Create failed')
end
if call_event_proc('InitializeAdjustmentFunction') == -1 then
error('InitializeAdjustmentFunction failed')
end
then call one or more of the Set* eventprocs like,
Code: [Select]
call_event_proc('SetHour',10)
Then reboot, and see if the hour you set is still set.

If it does, you can modify your script to do the same thing, but just set the time to the current time, like
Code: [Select]
t=os.date('*t')
call_event_proc('SetHour',t.hour)
call_event_proc('SetMinute',t.min)
call_event_proc('SetSecond',t.sec)
Logged
Don't forget what the H stands for.
*

Offline Mlapse

  • *****
  • 584
  • S95 S110
Re: SUIx, comprehensive long duration intervalometer. Something for you?
« Reply #28 on: 15 / August / 2020, 15:12:53 »
Thanks reyalp, it was just too hot in my home to fire up my system until now.

I've tested your suggestion and it did reboot the clock to a new time at 10ish hours.
I made a log entry after this new time was set, but before reboot...this time was still unaltered so still canon OS time as one would expect.

it'll still take a few months before I know if it solves the other problems with timing after a reboot or only contributes to the length of the reboot.
I'll get back to this as soon as I know more....the script is already running.
« Last Edit: 16 / August / 2020, 10:11:47 by Mlapse »
Logged
frustration is a key ingredient in progress
*

Online reyalp

  • ******
  • 14126
Re: SUIx, comprehensive long duration intervalometer. Something for you?
« Reply #29 on: 16 / August / 2020, 15:58:41 »
FWIW, a I added a function to CHDK 1.5 build 5552 and later which lets you set the clock without dealing with the eventprocs or native call stuff https://chdk.setepontos.com/index.php?topic=14091.0
Logged
Don't forget what the H stands for.
Pages: 1 2 [3] 4 5 6 7   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal