intervalometer for daylight hours - page 2 - Feature Requests - CHDK Forum supplierdeeply
« previous next »
Pages: 1 [2] 3 4   Go Down

intervalometer for daylight hours

  • 31 Replies
  • 7400 Views
*

Offline waterwingz

  • ******
  • 12066
    • Waterwingz
Re: intervalometer for daylight hours
« Reply #10 on: 25 / March / 2013, 14:16:10 »
Advertisements
Quote from: srsa_4c on 25 / March / 2013, 14:14:32
Quote from: waterwingz on 25 / March / 2013, 14:07:22
I suppose I could risk testing with my disposable camera  (A1200) - { reboot,  shoot 10 shots,  reboot,  repeat. } and see what happens.
It's probably noted somewhere, but only reboot when the lens is in retracted state. This is even more important for a camera with a more complicated lens unit (like the SX130).
Is there a propset for that?  Simply switching to playback won't retract the lens until the Canon retract delay expires AFAIK.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Online reyalp

  • ******
  • 13109
Re: intervalometer for daylight hours
« Reply #11 on: 25 / March / 2013, 16:47:25 »
Quote from: lapser on 25 / March / 2013, 13:41:29
That could be a deal killer if the exposure count doesn't get updated. The picture file names could be duplicated.
This isn't usually a problem because the camera normally scans the card to figure out the next non-conflicting number (this behavior is explained in the Canon manuals.)  It should only bite you if you are deleting images but want to keep the sequence intact.

Quote
I wonder what would happen if you just reset the tick count back to 0? I suspect that all reyalp would break loose!
How would that be different than wrapping? We don't know for sure that wrapping is a problem, but it seems unlikely to me that Canon expects uptimes long enough for it to matter.

Note that the effects of tick count wrapping may not be completely obvious. See this classic case http://it.slashdot.org/story/09/11/18/1943209/bizarre-droid-auto-focus-bug-revealed
Logged
Don't forget what the H stands for.
*

Online reyalp

  • ******
  • 13109
Re: intervalometer for daylight hours
« Reply #12 on: 25 / March / 2013, 16:51:21 »
Quote from: waterwingz on 25 / March / 2013, 14:16:10
Is there a propset for that?  Simply switching to playback won't retract the lens until the Canon retract delay expires AFAIK.
There's an eventproc for that
http://chdk.setepontos.com/index.php?topic=6857.msg73227#msg73227
http://chdk.setepontos.com/index.php?topic=9287.msg95743#msg95743
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4393
Re: intervalometer for daylight hours
« Reply #13 on: 25 / March / 2013, 17:46:43 »
Quote from: reyalp on 25 / March / 2013, 16:51:21
Quote from: waterwingz on 25 / March / 2013, 14:16:10
Is there a propset for that?  Simply switching to playback won't retract the lens until the Canon retract delay expires AFAIK.
There's an eventproc for that
Unfortunately StoreLensForShutdown no longer exists (at least with this name). The last cameras supporting it are the ones from the first DryOS generation.
Logged
*

Online philmoz

  • *****
  • 3275
    • Photos
Re: intervalometer for daylight hours
« Reply #14 on: 25 / March / 2013, 18:29:40 »
Quote from: reyalp on 25 / March / 2013, 16:47:25
Quote from: lapser on 25 / March / 2013, 13:41:29
That could be a deal killer if the exposure count doesn't get updated. The picture file names could be duplicated.
This isn't usually a problem because the camera normally scans the card to figure out the next non-conflicting number (this behavior is explained in the Canon manuals.)  It should only bite you if you are deleting images but want to keep the sequence intact.

It's a problem, unless the images are still on the card.

If I shoot, download, delete and then reboot using CHDKPTP the camera doesn't update the counter so the next images shot will have the same numbers as the previous ones.

Requires a power cycle after deleting the images to properly update the image counter.

Phil.

Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline lapser

  • *****
  • 1093
Re: intervalometer for daylight hours
« Reply #15 on: 25 / March / 2013, 19:10:26 »
Quote from: reyalp on 25 / March / 2013, 16:47:25
Quote from: lapser on 25 / March / 2013, 13:41:29
I wonder what would happen if you just reset the tick count back to 0?
How would that be different than wrapping? We don't know for sure that wrapping is a problem, but it seems unlikely to me that Canon expects uptimes long enough for it to matter.
I was thinking that you could reset the tick count to 0 under script control, so it didn't mess up the script if it happened randomly. Also, scripts only use signed integers, so they would wrap from maximum positive to maximum negative.

Looking into how to reset it to 0, I ended up in wrapper.c
Code: (php) [Select]
long get_tick_count()
{
long t;
#if !CAM_DRYOS
    _GetSystemTime(&t);
    return t;
#else
    return (int)_GetSystemTime(&t);
#endif
}
I see a possible problem with this code. CHDK doesn't have "long" as I understand it. So if _GetSystemTime(&t) returns an 8 byte long to a CHDK 4 byte "long", it will overwrite 4 bytes past t. As luck would have it, it looks like those 4 bytes are empty stack.

Is this correct, or am I not getting something?

It seems that if Canon changed to 8 byte system time, maybe it expects its camera to stay on longer than 2 weeks.
Logged
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos
*

Offline srsa_4c

  • ******
  • 4393
Re: intervalometer for daylight hours
« Reply #16 on: 25 / March / 2013, 19:32:10 »
Quote from: lapser on 25 / March / 2013, 19:10:26
Looking into how to reset it to 0, I ended up in wrapper.c
...
I see a possible problem with this code. CHDK doesn't have "long" as I understand it. So if _GetSystemTime(&t) returns an 8 byte long to a CHDK 4 byte "long", it will overwrite 4 bytes past t. As luck would have it, it looks like those 4 bytes are empty stack.

Is this correct, or am I not getting something?

It seems that if Canon changed to 8 byte system time, maybe it expects its camera to stay on longer than 2 weeks.
Here's GetSystemTime in the SX50 firmware:
NSTUB(GetSystemTime                           , 0xff38fe84):
ff38fe84:    e92d4008    push  {r3, lr}
ff38fe88:    e1a0000d    mov   r0, sp
ff38fe8c:    ebf24351    bl    sub_ff020bd8
ff38fe90:    e59d0000    ldr   r0, [sp]        @ return value is 1 word
ff38fe94:    e8bd8008    pop   {r3, pc}

The int and long types are 32 bits.
If that 53 days uptime is uninterrupted, then the firmware can perhaps deal with the wraparound?
Logged
*

Offline waterwingz

  • ******
  • 12066
    • Waterwingz
Re: intervalometer for daylight hours
« Reply #17 on: 25 / March / 2013, 19:47:17 »
Quote from: srsa_4c on 25 / March / 2013, 19:32:10
If that 53 days uptime is uninterrupted, then the firmware can perhaps deal with the wraparound?
I noticed that too - funny how a post comes out of the blue like that when we just happen to be discussing this.

Quote from: srsa_4c on 25 / March / 2013, 17:46:43
Unfortunately StoreLensForShutdown no longer exists (at least with this name). The last cameras supporting it are the ones from the first DryOS generation.
Then a better method would be to have the script switch to playback mode and then wait one minute (plus a bit) for the lens to retract normally ?

Quote from: philmoz on 25 / March / 2013, 18:29:40
Quote from: reyalp on 25 / March / 2013, 16:47:25
Quote from: lapser on 25 / March / 2013, 13:41:29
That could be a deal killer if the exposure count doesn't get updated. The picture file names could be duplicated.
This isn't usually a problem because the camera normally scans the card to figure out the next non-conflicting number (this behavior is explained in the Canon manuals.)  It should only bite you if you are deleting images but want to keep the sequence intact.
It's a problem, unless the images are still on the card.
If I shoot, download, delete and then reboot using CHDKPTP the camera doesn't update the counter so the next images shot will have the same numbers as the previous ones.
Requires a power cycle after deleting the images to properly update the image counter.
Sorry to be obtuse, but does this mean the image numbering will work correctly after a script initiated restart as long as nothing has been deleted since the most recent power-up?  If so,  it doesn't seem like a limitation for the OP's desired usage.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline lapser

  • *****
  • 1093
Re: intervalometer for daylight hours
« Reply #18 on: 25 / March / 2013, 20:24:36 »
Quote from: waterwingz on 25 / March / 2013, 19:47:17
Then a better method would be to have the script switch to playback mode and then wait one minute (plus a bit) for the lens to retract normally ?
Or you could require the user to set the lens retract delay in play mode to 0. But it sounds like waiting 30 seconds or more wouldn't be a problem with this application.
Quote
Sorry to be obtuse, but does this mean the image numbering will work correctly after a script initiated restart as long as nothing has been deleted since the most recent power-up?  If so,  it doesn't seem like a limitation for the OP's desired usage.
It looks like it would work, considering that there's no possibility that the files on the card will change during the reboot.

So the script would need to switch to play mode, wait >30 seconds, do finishing tasks (i.e. call restore() ) if needed, and reboot. If the script needs to know it's a reboot and not a fresh start, it would have to save a file somewhere that tells it this before rebooting.
Logged
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos
*

Offline waterwingz

  • ******
  • 12066
    • Waterwingz
Re: intervalometer for daylight hours
« Reply #19 on: 25 / March / 2013, 20:33:04 »
Quote from: lapser on 25 / March / 2013, 20:24:36
It looks like it would work, considering that there's no possibility that the files on the card will change during the reboot.
I think you missed philmoz's point.   As I read it,  if any files are deleted at any time after the camera powers up,  then the camera actually needs a full powerfail reset - not just a software restart from a script - or the image numbers will be messed up.

« Last Edit: 25 / March / 2013, 20:44:41 by waterwingz »
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
Pages: 1 [2] 3 4   Go Up
« previous next »
 

Related Topics