How does Planner know....?

[Mike Dodd]

While developing my Planalyzer program (http://astronomy.mdodd.com/files/Planalyzer.zip), I discovered that Planner's properties don't include the flip margins that ACP uses (flipcnfig.txt) while running a plan. These margins introduce a significant delay in the plan run-time. Does Planner know about these margins and if so, how does it know? More specifically, does Planner include the flip time in its plan duration calculations?

Also, does Planner have any knowledge of when dawn flats must begin? In other words, if I set up a plan where the imaging and darks run until 9:00am and check the Dawn Flats box, will Planner tell me that dawn flats are impossible?

Thanks for any information on these questions.

Mike

[Bob Denny]

I saw that Planalyzer post when I came in this morning... that's very clever and useful!!! In answer to your questions, Planner does not take into account anything about meridian flipping - in fact it can't even be told whether the scope is a fork or german mount. And depending on the plan, it could be quite significant.

Same goes for testing for dawn/dusk. There are no functions inside Planner for that. It was originally designed to operate in conjunction with a planetarium, which would be used to visualize when it started to get light. As time went on, I added manual editing and then addition of manual targets, etc. etc. so it evolved.

It could be that Planner should evolve to become more and more aware of the sky including meridian and sunset/rise. You could also argue that it should be aware of ACP's horizon and tilt-up limits, and with time control features enabled, warn about those as well.

I have some ideas on how to get the relevant ACP settings from the observatory into Planner, like a one-button config that would download all that stuff from ACP into Planner, then let you save it as a profile. But the totality of making planner sky-aware is pretty ambitious. I still want to do it some day though.

What's disappointing is that Planner de-evolved from it's original vision into something much simpler because most people couldn't cope with the timing features at all. I had to add an option to disable them.

[Jim McMillan]

Hi Bob,

What's disappointing is that Planner de-evolved from it's original vision into something much simpler because most people couldn't cope with the timing features at all. I had to add an option to disable them.

Please, please, don't feel like the timing features of Planner aren't important. I rely on them exclusively. As you know, before Planner, I used a self-built spreadsheet to do what Planner does with respect to figuring out the timing of a multi-target imaging night. Even when only image a handful of targets, that's a huge hassle that Planner solves effectively and efficiently!

It's in that efficiency-minded thought process that I want to help support the case for an "#imageuntil" directive. This would be the "cat's meow" with respect to not being perfect with the timing developed in Planner and using 100% of the available imaging time. There's almost always some unaccounted for time - meaning actual versus Planner. Things like flips, extra long autofocus, plate-solve offsets, extra long guider startups, etc. make Planning not quite an exact science. To deal with this in practice, I set a couple of the parameters a little long (like download time and pointing exposure times), and manually edit the Planner-generated #waituntil commands for target 2 (and beyond) to be a little earlier. That way, I make sure there's no idle time for a perfectly executed Plan while never starting target 2 (etc.) too early if target 1 ends prematurely for some reason. In this circumstance, an #imageuntil would be perfect. Of course, dawn flat plans and taking darks would also benefit from this directive as well.

FWIW.

Jim

[Mike Dodd]

I saw that Planalyzer post when I came in this morning... that's very clever and useful!!! In answer to your questions, Planner does not take into account anything about meridian flipping. [...]
Same goes for testing for dawn/dusk.[...]

That's interesting. I found significant differences in Planalyzer's calculated run-times and ACP's log from actually running plans. With the help of Planalyzer's Log Analyzer, I discovered the image download times I'd specified in Planner were far too short, and the pre- and post-flip margins in ACP made a big difference as well.

It could be that Planner should evolve to become more and more aware of the sky including meridian and sunset/rise. [...]

I'm considering adding some code in Planalyzer to calculate sunrise, and from that, the critical time for dawn flats, and indicate to the user if any part of a plan extends past that time. I found an algorithm on the Web, and it doesn't look too complicated.

I have no idea how to do meridian crossings without the use of an ephemeris, about which I know nothing.

I have some ideas on how to get the relevant ACP settings from the observatory into Planner, like a one-button config that would download all that stuff from ACP into Planner, then let you save it as a profile. [...]

I think that would be great, especially the flip safety margins.

Ah well, enough programming for a while. ACP has collected hundreds of images of IC 405 (nearly a gigabyte), and it's time to begin processing them.

BTW I've added a Planalyzer page to my Web site that shows some screen shots and has a link to download the Zip file http://astronomy.mdodd.com/planalyzer.html

Mike

[Bob Denny]

Mike --

Look in AutoFlat.vbs for the function NextDawnDusk(). That will give you the date/time of the upcoming dawn or dusk, given the sun elevation you want to define for "dawn" or "dusk" (e.g. -18 deg for astronomical twilight). It depends on ACP, however, for the Greenwich Mean Sidereal Time and conversion to/from Julian dates. So for Planalyzer, it wouldn't be good as is unless you only wanted to run it on a system that has ACP installed :-))

For info on getting GMST (and it does need to be the mean ST) see

http://aa.usno.navy.mil/faq/docs/GAST.php

Maybe you can adapt the code.

As for meridian crossings, that's simply the time at which the sidereal time is equal to the right ascension. No ephemeris needed once you can go from loca or julianl time to sidereal time, and the formula on the USNO site above is really simple and plenty accurate for what you're trying to do.

If you need info on Julian conversions I can give you that too.

[Dick Berg]

Hi Mike,

Here's code I use to generate the Hour Angle, given the geocentric Julian date (includes decimals of a day), the RA and the observatory longitude. Perhaps this will be helpful to you.

Function HA(GJD, ra, Lontude)
Longitude = Lontude / 15 ' Observatory longitude, in H.hhhhhhhhh
GMST = 280.46061837 + 360.98564736629 * (GJD - 2451545) ' third-order term not needed for required accuracy here
GMSThours = (GMST - (360 * Int(GMST / 360))) / 15 ' GMST in H.hhhhhhhh in range 0-24 hours
LMST = GMSThours + Longitude ' LMST in H.hhhhhhh
HAprov = LMST - ra ' derived HA of object, could cross 0 or 24 hour boundary
If HAprov < -12 Then HAprov = HAprov + 24
If HAprov > 12 Then HAprov = HAprov - 24
HA = HAprov
End Function

[Mike Dodd]

Hi Bob,


It's in that efficiency-minded thought process that I want to help support the case for an "#imageuntil" directive.
Jim

I second the motion 100%. This would guarantee a plan would never run past the dawn flat time. And using Planalyzer would make it easy to tweak the plan to get the number of exposures that would end at the desired time.

Mike