SUIx, comprehensive long duration intervalometer. Something for you? - page 2 - 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?

  • 63 Replies
  • 12819 Views
*

Offline Mlapse

  • *****
  • 568
  • S95 S110
Re: SUIx, comprehensive long duration intervalometer. Something for you?
« Reply #10 on: 06 / August / 2020, 15:42:20 »
Advertisements
Quote from: Caefix on 06 / August / 2020, 15:37:28
RAW disabled.
ND just for fun/max. flexibility?

You can still enable RAW in CHDK, but no longer from the SUIx menu.

I'll put ND on the list.
Logged
frustration is a key ingredient in progress
*

Offline Caefix

  • *****
  • 940
  • Sorry, busy deleting test shots...
Re: SUIx, comprehensive long duration intervalometer. Something for you?
« Reply #11 on: 06 / August / 2020, 15:52:07 »
 :) I´m updated to V0.4.0. now.
Found line 77:
    set_raw_nr(1) -- disable Canon's dark frame substraction
Logged
All lifetime is a loan from eternity.
*

Offline Mlapse

  • *****
  • 568
  • S95 S110
Re: SUIx, comprehensive long duration intervalometer. Something for you?
« Reply #12 on: 06 / August / 2020, 16:17:02 »
Quote from: Caefix on 06 / August / 2020, 15:52:07
:) I´m updated to V0.4.0. now.
    set_raw_nr(1) -- disable Canon's dark frame substraction

yes, if you want dark frame substraction that's the line you should remove or disable....oh no, you had an old version without it, so you actually want it :)
« Last Edit: 06 / August / 2020, 16:28:56 by Mlapse »
Logged
frustration is a key ingredient in progress
*

Offline reyalp

  • ******
  • 14000
Re: SUIx, comprehensive long duration intervalometer. Something for you?
« Reply #13 on: 06 / August / 2020, 22:22:24 »
Quote from: Mlapse on 06 / August / 2020, 12:00:57
I am still trying to find out what steps the reboot procedure actually takes. Is the person who thought that up still an active member?
Do you mean what CHDK does? Or the logic from waterwingz ultimate.lua?
Logged
Don't forget what the H stands for.
*

Offline Mlapse

  • *****
  • 568
  • S95 S110
Re: SUIx, comprehensive long duration intervalometer. Something for you?
« Reply #14 on: 07 / August / 2020, 03:28:34 »
Quote from: reyalp on 06 / August / 2020, 22:22:24
Do you mean what CHDK does?

Yes and specifically in what order/when.
Also what values are not saved, these at least include img number and time...from what moment?


SUIx reads the day and first folder from a ucount file at reboot, but when/how does Canon/CHDK set the time and other missing values?
I'm still figuring that out with some trial and error, and that is really a slow process with dead ends.
It seems I lose time before the last picture is taken or switch to playback.

What I am trying to do is find a more ideal moment/timing/code for this function in SUIx,
by understanding what happens better I expect to create a more reliable reboot and timing.

Although, by now I am fairly satisfied with the way I've got it working in my test rig...I think it might be more reliable if i can filter out the last inconsistancies and make them work for me.

I have tested reboot with the same values and get somewhere between -14 and -31 canon-seconds until the script is active again.
And that is a bit of a wide range...how does this happen.
Would it help when rebooting if ucount held the last used folder, instead of letting canon search through the folders for the last one?
 
the real question is: how to manipulate that time at reboot so it is always close to the same time, be that -14 or -31 or any other fixed value does not matter.

Sure, if possible to be set by me in the script or in chdk since the ideal value is probably cam dependant. (haven't tested that, but since the number crunching speed per model is different that seems a fair assumption)
« Last Edit: 07 / August / 2020, 07:56:41 by Mlapse »
Logged
frustration is a key ingredient in progress
*

Offline reyalp

  • ******
  • 14000
Re: SUIx, comprehensive long duration intervalometer. Something for you?
« Reply #15 on: 07 / August / 2020, 14:06:03 »
Quote from: Mlapse on 07 / August / 2020, 03:28:34
Yes and specifically in what order/when.
Also what values are not saved, these at least include img number and time...from what moment?
CHDK doesn't do anything with any of that. It turns off the display and calls the Reboot function in the canon firmware.

The Canon firmware function does not appear to save "flash param" settings, including the image number. However, the normal firmware looks at the images present on the card at startup and sets the image counter to the next sequential number if needed. So not saving the counter is usually only a problem if you are using remoteshoot or deleting image files.

Time is not saved, it comes from an onboard RTC, unless the RTC battery is dead, in which case the camera prompts to set it on startup. I'm not sure if RTC time is synced OS time while the Camera is on, or if the OS just sets its clock on boot.

Quote
Would it help when rebooting if ucount held the last used folder, instead of letting canon search through the folders for the last one?
The Canon OS scanning the folders is not under CHDK control. It can take a significant amount of time if there are a lot of images.

Quote
the real question is: how to manipulate that time at reboot so it is always close to the same time, be that -14 or -31 or any other fixed value does not matter.
I don't really understand. Are you saying there is a clock offset at reboot, separate from the actual time required to reboot?
Logged
Don't forget what the H stands for.
*

Offline Mlapse

  • *****
  • 568
  • S95 S110
Re: SUIx, comprehensive long duration intervalometer. Something for you?
« Reply #16 on: 07 / August / 2020, 15:12:27 »
Quote from: reyalp on 07 / August / 2020, 14:06:03
Are you saying there is a clock offset at reboot, separate from the actual time required to reboot?
Yes, I wish I had come up with that sentence.... :D

And that offset varies too much to be the result of a few pictures more or less.
I have specifically tried to work towards showing the negative values by changing sleep() here and there.
Why you might ask, well actually because all canons I've had my hands on have an internal clock that runs very slightly too quick.

So I pursued it to see if I could correct the time by setting reboot at an interval that matched my internal clock speed.
That obviously would only work if or when time can be set on boot by the software.

maybe this helps you to see what I see...it also works like this with less images on smaller cards.
« Last Edit: 07 / August / 2020, 16:09:26 by Mlapse »
Logged
frustration is a key ingredient in progress
*

Offline srsa_4c

  • ******
  • 4451
Re: SUIx, comprehensive long duration intervalometer. Something for you?
« Reply #17 on: 07 / August / 2020, 15:13:28 »
FWIW, data written to certain parts of camera RAM should survive a reboot.
As far as I know, the PowerShot firmware doesn't touch the part of RAM that is shadowed by the ITCM/ATCM. This is a 4kB (on DIGIC II, III, 4, 4+, 5) or 16kB (on DIGIC 6) area, starting at 0x40000000 (newer DIGICs) or 0x10000000 (DIGIC II, III). Since it isn't initialized, it has a semi-random content by default.
Logged
*

Offline Mlapse

  • *****
  • 568
  • S95 S110
Re: SUIx, comprehensive long duration intervalometer. Something for you?
« Reply #18 on: 07 / August / 2020, 15:32:38 »
Quote from: srsa_4c on 07 / August / 2020, 15:13:28
it has a semi-random content by default.
And could that contain an old time stamp that is used with the reboot? Is that what you are saying?
I can accept that, but why can it then preceed the last taken picture before reboot? that has a later timestamp...i would think the last timestamp that is roaming around should be close to the reboot moment, not 20 seconds earlyer.
« Last Edit: 07 / August / 2020, 15:35:47 by Mlapse »
Logged
frustration is a key ingredient in progress
*

Offline reyalp

  • ******
  • 14000
Re: SUIx, comprehensive long duration intervalometer. Something for you?
« Reply #19 on: 07 / August / 2020, 16:06:41 »
Quote from: Mlapse on 07 / August / 2020, 15:32:38
And could that contain an old time stamp that is used with the reboot? Is that what you are saying?
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. See the code in https://app.assembla.com/spaces/chdkptp/subversion/source/HEAD/trunk/lua/extras/synctime.lua for an example.
Testing on sx160, values set this way appear to persist through a reboot()
Logged
Don't forget what the H stands for.
Pages: 1 [2] 3 4 5 6 7   Go Up
« previous next »
 

Related Topics