The script was tested by setting all cameras to rsint mode, emitting the 's' character to capture the images, then timing the period it took to complete the operation on all cameras.
How are you determining when cameras complete the operation?
However, sometime later the same action started to take 2.6s on average (120 trials, totaling 720images in ~310s). The increment wasn't gradual, and was relatively consistent throughout.
Can this discrepancy be related to CHDK code on the camera side?
IMO, this is quite unlikely. Generally speaking, CHDK scripted shooting can shoot at a steady rate for thousands of shots, and I wouldn't expect it to degrade by seconds due to CHDK issues. I've been surprised before though
A few things that come to mind:
* Did lighting or exposure change? If you're in low light (including regular indoor lighting) exposure time can be relatively significant. High ISO can also add significant time for noise reduction processes.
* Did other settings on the cameras change? Raw, jpeg resolution etc, continuous mode.
* Did the scene change? More complex scenes result in larger images. This can be dramatic if you're comparing say, an out of focus scene vs a highly detailed one.
* Could it be related to IO performance on the pi? I'm not sure how you'd measure this, but most SD cards are designed for very different workloads and there's definitely been reports of them behaving poorly under load on pi.
My approach to debugging this would be
1) Check the exposure/setting stuff mentioned above
2) Try to reproduce it with a single camera. If you can, everything will be simpler.
3) Try to time the various stages of the shooting process and find out where the delay appears. For example, the time between when the 's' is sent and data becomes available, and the time from the first and last data for a given shot being written. The simplest way to measure these would probably be to add logging to the chdkptp Lua code.
For the 's' command, you could log from rsint.lua in m.rsint_once just before
con:write_msg(cmdname..' '..rest)
For receiving data, you could log from chdku.lua in chdku.rc_handler_file (assuming you're using jpeg) at the start and end of each loop iteration, and after the final fh:close()
You can get subsecond timestamps using something like
printf('%s\n',ustime.new():format('%c.%_u'))
Or monotonic microsecond counter with ticktime.get()
If you set cli_verbose=2 information will be output for each chunk received, but it doesn't include timestamps. You could override cli.dbgmsg to include timestamps.
Additional info:
CHDK version 1.4.1
CHDKPTP version: r921
FWIW, the current stable CHDK is 1.5.1 and most recent chdkptp release is r964. I'm not aware of any changes that would be directly relevant to your problem, although there were some fixes in the PTP and remoteshoot.
