A change in philosophy!

I managed to do a run with Advanced using simulators, just to try and start getting my head around a workflow. I came to the conclusion that I really need to fundamentally change my whole approach to imaging.

Having used the Base version very successfully for a couple of years, I developed a workflow of adding sequence files for things I wanted to image, checking conditions and target altitude on each clear night, and then adding appropriate sequences to my base DragScript, adjusting timings and letting it run. When I had enough data I would then delete the sequence file. All too often I would do an imaging run under less than ideal conditions and continue imaging a target way before or way after the meridian to try and complete it. I would rarely have more than 3 targets setup in DragScript at one time and would expect those to be completed over a period of a few clear nights.

Advanced requires a whole new philosophy of having lots of potential targets loaded but ONLY letting them run under best conditions of moon, altitude etc. That could easily give a dozen or more potential targets at a time in Scheduler all at various stages of completion potentially over many weeks or months. That is going to take a lot of getting used too!

Once you get used to it, you’ll appreciate the greatly reduced workload.

I have over a hundred targets loaded in my old scheduler that I will move to Advanced. I just add targets to the database that I think I will want to image when they are available. The scheduler will image them using the constraints I specified. If I want to get “more involved” and focus on a few targets, I can disable all the targets except the few I want to image. But I don’t do that - just let the scheduler do its job :).

Cheers,
Rowland

2 Likes

Yes I agree. This is the same way I have run Voyager over the last 1.5 yrs. I rarely had more than 3 targets in my drag script and adjusted it regularly depending upon how many images I had acquired on each target. Basically I had to plan each target every time.
So, Robo Target is a much different philosophy. It still requires planning on the front end to determine what constraints to use, which may be different for each target/filter, depending upon DEC and target type. However, I can see the great benefit of doing this only once then letting the scheduler figure it out.
Any, as Rowland says, one can always disable targets if you’re wanting to only get data on one particular one. There is a huge amount of flexibility here.

Best,
Jon