rawopint.lua: Fast, accurate intervalometer with raw exposure metering - page 22 - Completed and Working Scripts - CHDK Forum

rawopint.lua: Fast, accurate intervalometer with raw exposure metering

  • 210 Replies
  • 93978 Views
*

Offline reyalp

  • ******
  • 14137
Re: rawopint.lua: Fast, accurate intervalometer with raw exposure metering
« Reply #210 on: 27 / April / 2025, 16:13:16 »
Advertisements
Hi there,Any idea why the camera stopped working during these series (.csv files attached)? I suspect my gimbal is not working properly and it accelerated the camera too much and it froze. I was using rawopint 0.25.Best
Hi,
The only thing I see in the logs is that the shooting interval becomes very unstable, especially in the rawopint_250420_2.csv

In rawopint_250420_1.csv everything looks normal up to exp 333: Interval is 1s, sleep is around 600 to 700ms, so shots are completing well within the interval. Exposure parameters are quite normal: ISO 80, shutter around 1/80.

At 333, sleep is -190, meaning the previous shot took ~1.2s instead of .3 like before. It's not too unusual to have occasional slow shots like this, but starting starting around 387, it gets much worse. At 397, sleep is -1470, and at 443, it's -12520, meaning it took more than 12 seconds for the shot to complete, which is definitely not normal. Exposure is still normal, so it's not just a long exposure.

In rawopint_250420_2.csv, it's unstable from the start.

Interestingly, the value -12520 shows up several times, maybe suggesting something is timing out at that point. The raw hook timeout is 10s, and the shoot hook 2s + interval. The script currently just ignores timeouts, I should add a log message.
edit: Actually, re-reading the code, the timeouts mentioned above are how long the script would block inside a hook, which shouldn't be relevant here. The timeout waiting for a hook to be ready is 10s for both, and the script would end with an error if it was exceeded here, which obviously hasn't happened because we see multiple -12520 sleeps in a single run.

The time between exp_start and raw_ready is short, so the shooting process is taking normal time, which suggests that the delay happens when the camera is trying to save the jpeg.

To me, that suggests the SD card might be going bad, though it certainly isn't definitive. As far as the gimbal goes, I guess if the camera moved really violently maybe it could interfere with SD communication or cause other glitches, but I certainly wouldn't expect that in normal usage.

If possible, I'd suggest trying a fresh SD card. You could also try benchmarking the one you used with crystalmark or similar, if the results are very bad or you get errors on a PC that would help confirm. It's possible that low level formatting would make it behave better, but if it's really the card causing 10s+ delays, I'd think it was probably going bad.

If the camera crashed (shut down) when this happened, then the ROMLOG might provide additional clues.
« Last Edit: 27 / April / 2025, 23:15:14 by reyalp »
Don't forget what the H stands for.

 

Related Topics


SimplePortal © 2008-2014, SimplePortal