Hey Rowland! First, thanks for digging through my walls of text, most people’s eyes glaze over! 
When I originally started using Voyager I basically did what you’re suggesting, with the difference that I had a sequence with an absolute end rather than an absolute begin … and I’ll also add the disclaimer that I likely didn’t use DragScript/ sequences properly, so there’s that … take the ST4 total time, create a sequence that did the suggested time/ count thing, set my absolute end time, done.
And you’re right, I’m definitely to the right of the 80/20 curve, so there’s that …
That said, there are some objects that only show up for a few weeks a year in an ideal imaging A position … and good nights are few and far between! Usually I have B position targets, which means I need to gather a lot of signal to get something worth stacking … like, 40-60hr of signal … so that lost time really hurts when you realize it’s probably going to be another year before you can get back to gather enough signal to finish the 50 light stack (another justification for putting lot’s of scopes on target, I’d like to finish this stuff now rather than leave it to the great grandkids) …
What I discovered when I did what you suggest (absolute end time, ST4 programmed with estimates of actual time) was that the Voyager sequence time didn’t include block execution time, only sequence execution time … times for independent block actions like focusing and guide star acquisition (even though they were noted in the sequence, like for focus failover) weren’t being covered by the sequence, which means they happened outside of the absolute end (or start) time. Unfortunately those two actions are both necessary and variable in time … so if it took longer to focus than expected due to a failover or retry, I ended up not doing a sequence I had just gotten focused for due to hitting the time limit … maddening …
The other problem was the granularity; sequences are designed for groups of pix (take 10 at 5 min) and if the sequence won’t trigger due to not enough time for 10 at 5 min and there’s enough time for 9 at 5 min it exits and, well, that’s just even more maddening … and I’m not going to make a singleton sequence for each light and chain them one after each other, did that enough with SGP!
Again, part of my problem could be that I don’t know the program well enough (maybe there’s a simple answer that I missed, easily possible!) … but fundamentally I need to do this:
Given a time allotted for an object … slew to that object, focus on that object, get a guidestar, start to track and take as many pix as possible before I need to move on to the next. That sounds simple enough, but the only way I found to do it reliably with the variable slew/ guidestar/ focusing times was as I’ve described. If I only rely on the sequence timings then I can’t factor in the slew/ focus/ guidestar times, if I take “worse case” times for those things and simply delay my sequences by those times I’m going to be having dark time go to waste …
Oh, and check your pixel scales to make sure you’re getting the right exposures with CMOS … I have an ASI 183MM CMOS for my L channel, and since I’m hideously oversampled on that with my C14 I need to have really LONG exposures to get good signal, on the order of 15-20min per light …
Thanks again for your suggestions, hopefully between you, me and Leonard we can get me out of the WatchDog program business!
- but this will involve a precise pointing slew to M64 with a meridian flip, a rotator move to PA 117, and a VCurve focus. Then the sequence says to take 60 one-minute exposures.
)
red … is ok
