I found one more run from G1x with massive timing problems. I checked the SD Card again. I had no problems with the card on an interval from 2s at home (JPG + Canon RAW). On this run now, the interval was set to 3s but sometime it goes close to 6s.
Unfortunately, without being able to reliably reproduce this, I'm not sure there's much I can do. It's still good to post, the data may become valuable later.
There are some general scenarios that come to mind:
1) As discussed before SD cards firmware is optimized for specific usage patterns, which is probably quite different from what happens under the script. Even though a card can do 14mb/s sustained writes, it's possible the actual usage pattern triggers some pathological behavior in the SD card.
2) The whole "shooting hook" principle used by the script relies on blocking the normal firmware execution deep in the shooting process, in ways the firmware designers would not expect. It seems to work, but weird side effects would not be a surprise. I suspect the shutter issues I see on D10 are an example of this, but I'm still not certain.
Some ideas of things that might have some impact
1) The interval. Maybe if the interval is short the Canon or SD card firmware sometimes gets "behind" and can never catch up.
2) Continuous mode on / off.
3) CHDK raw vs Canon raw vs jpeg only.
4) Log file writing. This is tricky, because if you disabled the log completely, it would be difficult to measure the real behavior. The log could be done entirely to RAM and written at the end, but this would require a lot of RAM for long runs. It would be possible to come up with more compact log format that just had the timing information.
5) The raw hook sleep / disable script yield settings.
It might also be possible narrow down where the delays occur, but this would probably require adding code to the CHDK core.
This can be really good seen in the not continuous moving of the ship. It might be helpful to have a warning (LED or focus light on or a noise?), when sleep goes to negative values.
This is a good idea, I'll look into to adding it for the next version.
Another think of this run is that it has much more flicker as the other runs. I’m really sure that comes from the waves in front of the video. The meter window was set to 90%/90% so the waves are full in. In cases like this, it would be not good to use the full picture for measure.
I’m thinking loud:
I’m not sure if an auto window size could be helpful for most situations.
Instead the meter_width and meter_height only a parameter like:
Spot_Window (30%/30%), Full_Window (90%/9%), Sky, Ground
How does it work to detect the Sky or Ground?
1) Using the pre shoot and dividing the full picture into a number of equal rows (may be 12).
2) Calculating a meter value of each row.
3) Calculating a mean (or median) value from all meter values.
4) Looking, which rows are above or under the mean value.
5) Combining all rows which are above or under the mean value to one widow for the following shoots.
I have intended to make the meter position adjustable, and possible add the ability to have multiple meter areas with different priorities. However, this makes both the configuration and final behavior even more complex. One idea I've toyed with is having a scripted GUI for configuration, but this would be a lot of work.
Now that 1.4 is released, I hope to spend some more time on the script.
