Sequencer Wait until timing

[pieroc]

Hello All

I am a relatively new to the sequencer and this is my first post so I hope I am not asking something too silly.

The Sequencer is great and it is close to being perfect!

Is it possible to set the function "Wait until" to a unit smaller than one second? This would be really helpful for events when timing is critical e.g. eclipses.

From some initial testing I noticed that often Wait until function kicks in almost a second after the minute. For example from the log I see:

Debug 20:26:00.955668 #1 Sequencer : Completed : Wait until 20:26

Also would it be possible to have "user-defined" Astronomical Events? This could be particular helpful for phases of an eclipse or the exact time of an occultation .

Thank you,
Piero

[admin]

Hi Piero,

currently the various waits in the sequencer check only once per second to see if the required time has arrived. I can easily change this to 0.1s checks without any significant impact, so that the step should finish very soon after the required second ticks over. However, there are no real guarantees on how quickly something happens in the sequencer, so I would be concerned about any sequence relying on sub-second accuracy. Even simple things such as starting a capture or changing exposure are not quite instant (for instance when changing exposure it may take time for the signal to reach the camera and then you may still receive between 2 and 5 frames with the old exposure that were captured and in the process of being transferred to SharpCap before the effects are seen).

I can't quite see how custom events would work - did you have a specific idea?

cheers,

Robin

[pieroc]

Hi Robin

Many thanks, I really appreciate your input. I think moving that check to 0.1s would improve things a lot.

I can see that there is a lot going on in the log so I fully appreciate there is no guarantee on how quickly things would happen. I feel that checking 10 times a second as you proposed would take us 90% of the way there and remove a large unknown from the equation (20 times a second would likely remove the issue completely). I accept that there are no guarantees here and there is no good substitute to a lot of testing!

Another improvement I think would be helpful is the ability to input the seconds for the actual requred time in the wait sequence (at the moment only HH:MM is accepted I think). I can see that one can get around this by using the delay instruction in seconds after the first wait instruction but it is not 100% ideal. I can see that most users generally may not be interested in having that in a HH:MM:SS.s format in the wait instruction as it would be of little value to them to specify when exactly they start a sequence. Perhaps a balanced solution could be achieved by allowing the input of minutes in a decimal format so, for example, 1.567 minutes are 1 minutes and 34 seconds, or create an additional instruction to be included in the advanced section. Again I appreciate that the added precision does not guarantee that the exposure is taken at that point.

I was envisaging a custom event being a simple constant expressed in a year, month, day, hour, minute, second date format that one can just enter and create. For example, in Dallas first contact C1 for the April 2024 total solar eclipse will be at 17:23:18.0 on 08/04/2024. It would make the scripts easier to read if one could create such lable rather than having to input a specific time. This could apply to other events that one may be interested in (i.e. ...do this before the event and do that after the event) such as occultations. This would just improve readability of the script, nothing else.

Finally you mention that it may take time for the signal to reach the camera when changing exposure. May I check if this is the case with both Live and Still or just Live as far as you know?

Many thanks,
Piero

[admin]

Hi Piero,

the delay is different for live mode and still mode...

In live mode there is uncertainty about which frame will receive the new settings. In still mode, frames are only captured on request, so the next frame after a settings change will have the new settings, but there is a bigger gap between frames as each one has to be requested separately.

As to the accuracy of timings, I think it will be harmless if I make the sequencer display the times as HH:MM:SS. That will then allow *manual* editing of the SCS file to put in the seconds using a text editor and the saved value should be preserved/stored/used during further edits inside SharpCap.

cheers,

Robin

[pieroc]

Hi Robin,

Thanks, this is really helpful.

I did not realise this earlier, but I can see now that I am able to edit the .scs file directly with a text editor and input there the local time as hh:mm:ss.s. From what I can see, the sequencer then uses the local time in a hh:mm:ss.s format (if that is what written in the .scs file) to "wait until" that point. The check on "wait until" is still done every second so it would be nice to make that more often to make the starting time more accurate; that will give a lot more flexibility. Do you think this could be done in the next version ?

It is really great to see such good support!

Piero

[admin]

Hi Piero,

actually, I found it was quite simple to change the editing of the times from HH:MM to HH:MM:SS, so I did that. I also changed the check interval to 50ms, so any delay should be minimal. I would note that when editing the code inside SharpCap and re-saving it will only save times to the nearest second, since it formats the text as HH:MM:SS not HH:MM:SS.DD.

These changes will be in the next update.

cheers,

Robin

[pieroc]

Many thanks Robin

Much appreciated and looking forward to the new version

Are there any tasks that tipically take a given time in scripting that remain consistent so that one can use to delay things by a further say 0.2 seconds if needed?

I think this will be helpful to folks like me who plan to use SharpCap for imaging a total solar eclipse and want to achieve reasonable synchronization of the imaging without the complication of going all the way into scripting. Testing and testing again remains essential.

Piero

[admin]

Hi Piero,

the delay step can do that for you no problem (adjust the wait down to steps 0.1s).

I would note that there is *supposed* to be a small delay between steps - at least I designed it that way, but on checking just now I found that the code for that is always bypassed, so it never happens. If I ever fix that in future then I will make it possible to configure the inter step delay down to zero.

cheers,

Robin

[JethroXP]

So glad I found this thread, I was just about to ask the same thing!

I'm traveling to Dallas for the Eclipse in April 2024, and I'm bringing 4 systems with me. I'm planning to manage the sequences for two of them with SharpCap Pro, but I'm building the sequence and specific timings and exposure lengths from Eclipse Orchestrator, which will manage my setup using my Nikon Z6. Eclipse Orchestrator builds a script that captures all the unique Eclipse phenomena at exposure lengths appropriate for those events, but it does so in timings as granular as 0.1 seconds.

I was using the SharpCap Sequence Editor to port the EO script over but was running into the same issue of not being able to specify start times more granular than 1 second.

I really appreciate your help and responsiveness to this concern Dr. Glover!

[JethroXP]

After a bit of testing I’m realizing that while my camera is consistently fast in capturing images, the writing to disk performance is less consistent. Using that “wait until time” condition has resulted in the entire sequence stalling if prior action strays even 0.1 seconds over the next start time. Is there a way to get the sequence to continue if the wait until time is in the past?