I am recording time series of variable stars. To do this I need to:

1. Take and image with one filter
2. Switch to another filter and take a second image (possibly for a different length)
3. Then repeat 1 & 2 for around 200-300 times.

If I create a sequence that does 1 & 2, then I can use the scheduler to repeat it some number of times. This works, but I'm wondering is there is a more straightforward way to repeat a sequence some number of times. Using the scheduler seems like overkill.

I realize the scheduler doesn't do quite what I need. It is common to want to delay after the second image for (say) 1 minute. In the sequence, I can specify a delay after the second image, but the scheduler seems to ignore this. After taking the second image, it starts the first one again without any delay.

Any way around this?

If the scheduler seems to ignore a sequence-final delay, perhaps add a dummy capture (e.g. your two desired images with delay after the 2nd, then a dummy capture with any other filter), and then use the scheduler to repeat.

Hy,

Yes, I can certainly do a dummy capture at the end of the sequence. Hopefully a delay in the middle of the captures won’t be ignored. I’ll experiment tomorrow.

I think you once told me you worked on the scheduler. Can you enter a bug report about the delay after last capture being ignored?

Bill

OK, I just tried this. As I feared, delays seem to be ignored even if in the middle of a sequence. Maybe there is a good reason for this but it would be nice if it were possible.

Another workaround is to just expose the dummy image for the length of the delay. Not sure there is a disadvantage to doing that over the other workaround.

Bill,
it should be not a bigger problem to fix this. How precisely is your requirement regarding the delay?
When we add the delay at the end of a sequence, the overall time difference will be slightly bigger than in the middle of a sequence, since restarting a sequence might add a slight delay on its own due to code performance. If say 100ms difference is no issue (just guessing, haven’t measured it), then we could fix your problem.

Cheers
Wolfgang

Wolfgang,

In my case there is no great accuracy requirement. If the delay is accurate to a couple of seconds, that is good enough.

Thanks for responding,
Bill

OK, fine, good to know. Capturing takes the delay only into account between capturing single frames. Therefore, capturing the first frame does not consider the delay and starts immediately.

From my perspective this isn't a consistent behavior. If I want to take 5 images, I could use a single frame sequence and repeat it five times with the scheduler, or use a sequence with five frames and run the sequence only once. In both cases, we should have the same delay pattern.

A change for this is already in preparation and - if everything goes fine - will be available after a couple of days in our nightly builds.

In the mean time, a workaround could also be a sequence file that has the desired number of frames. Maybe the easiest way is to create a single set of captures with the two filters and then multiplying the jobs by editing the .esq file.

Cheers
Wolfgang

Not sure I understand why these two situations would be different. If you had a single capture with a delay of (say) 1 minute and repeated it 5 times in the scheduler, I would expect:

image 1
[1 minute delay]
image 2
[1 minute delay]
image 3
[1 minute delay]
image 4
[1 minute delay]
image 5
[1 minute delay]
Done

I would expect the same pattern if the sequence had 5 images, each with a delay in it. Could you explain which one would be different and why? I just want to be sure the fix is going to solve my issue.

Thanks,
Bill

You are absolutely right, they should be identical. But currently they aren't, since the first delay is missing. That's why I would like to change the behavior so that both are identical.

Yeah, that makes no since that the first delay is missing. It would be great to get that fixed. I think delays should be “first class citizens” just like exposure times. Neither should be skipped.

I do have a workaround for now, so there is no huge rush.

The change is merged into the master source. It should be available from the nightly builds in the next few days.