EDIT: Logging is enabled, log file attached from last night.
Thanks for posting the log file. It's interesting to see the comparison with an older camera.
My SX50 takes about .25 seconds to process a shot, and your camera takes about .50 seconds. The minimum time between shots also depends on the speed of saving the files, so I can't sustain 4 shots per second (more like 2).
The exposure went to 800 ISO maximum, but that's probably a little too noisy on your camera. I'd set it to 400 ISO, although the time between shots will increase to as much as 10 seconds as it gets darker.
There's a little "fluttering" of exposure when it got dark. I didn't notice anything in the video, though.
=====
I've made some progress with the script and CHDK patches in the last few days. First, I was able to apply the patches to the latest CHDK build. Phil updated Lua from 5.1.3 to 5.1.5, so I have high hopes that the problem I had with Lua yield/resume halting the script will be fixed now. I'll change the script to add the sleep(10) loop back in, or maybe coroutine.yield(), and leave a camera or two running overnight to see if the script works right now.
I'm also pretty satisfied with the script smoothing code. I fixed the rounding error in the shot meter for negative values, and added code in the script that minimizes each change (usually just 1 or -1), and spreads out the changes instead of bunching them up 3 or 4 at a time. The test videos are coming out pretty smooth.
I did have a "glitch" last night where one picture was darker by 43 and the next picture went back to normal. This happened once in 10,000 pictures. I also noticed a "glitch" during my 17,000 picture overnight camping trip, where one picture flashed much brighter. I had logging disabled, so I wasn't sure what happened. But the new "glitch" was logged, and showed that the picture that triggered the glitch looked the same as the the previous pictures. That is, it must have been an error in the value the meter returned. I'm not sure why this happened, but I added a "glitch" detector to the script. If there's a single change over 16, I ignore it, and disable the glitch detector for the next 5 shots. So it will take 2 shots to respond to sudden changes in brightness, instead of 1. But for sunsets, there shouldn't be any sudden changes, except for glitches.
Now that I've figured out a pretty simple and effective smoothing algorithm in the script, I'll see if I can move it to the shot meter code in C, adding a smoothing parameter to the shot meter enable function. I might be able to use the (double) values from the shot meter instead of the rounded integer values the script gets.
