toggle quoted messageShow quoted text
On Nov 7, 2021, at 02:38, Dale Ghent <email@example.com> wrote:
I meant to get this rolling sooner, but life threw me a curveball last month. Thanks to Ray's additions to the upcoming APCC Pro 1.9.1.x, there's now an easy way to programmatically feed model creation parameters to APPM so that it can produce a model plan using that also considers the other things you might have configured in APPM - horizons, limits, ordering strategy and so on.
So I created a new sequencer instruction for my AP mount plugin for NINA called "Create Dec Arc Model". It will get the RA and dec of the current target and have APPM create a model plan based on that info. You would place this instruction at the start of a target's run so that a dec-arc model is created and put in place prior to getting down to business.
It'll currently create 3 arcs - 1 centered on or (or at least very near) the target's declination, and 2 additional arcs - one on the north side and the other on the south side of the target's declination, separated from the center arc by a configurable number of degrees. Point density along the arcs, in the RA, is another parameter that can be tuned. The arcs will begin (ie, their eastern-most extent) slightly before the target's current hour angle and extend to the configured minimum altitude or the western horizon limit, whichever is hit first. Obviously it's quite advantageous to use your local horizon limits in order to cut down on pointless (ha ha) map points.
Below is a short video of me futzing around with the new code. In it, I select a target in Stellarium (the CA nebula) and import it into NINA's Framing Assistant. I then create a target session using a small sequence template I made that has just the "Create Dec Arc Model" instruction in it. I then run that sequence. With debug logging on, the APPM configuration gets quoted in NINA's log file, so I copy and pasted that config into its own text file and loaded it into APPM to look at the point map. Presto, there's a 3-arc wide dec model based on the CA nebula's location at that time. Obviously this would all be automatic in practice, with a temporary config file being made and fed to APPM directly... this just lets me debug at each step as I work on the code.
I'll put some more polish and testing on it over the next days. If any NINA user here is interested in trying it out, see me on the NINA Discord chat.
On Nov 6, 2021, at 15:35, Ray Gralak <firstname.lastname@example.org> wrote:
Or... am I just crazy to consider reusing a model after a tear down and reassembly?You could do a simple test to find out! Specifically, you could do a Verify run in APPM with a much smaller number of points than your model. That is, a Verify run does not have to use the same points as your active model. When you do this, take a look at the measured pointing errors in the table that APPM creates in the verify run.
BTW, in case anyone is wondering, there are two main differences between a normal APPM run and a verify:
1) The Verify run keeps the active model on, while a normal run would have modeling off.
2) The Verify run will not replace your active model. That is, APPM won't ask to load it into APCC, and APPM will even warn you if you try to load a verify run.
Also, a verify run will probably be much less useful if you are checking a few Dec Arc rows, because it wouldn't take much longer to create new Dec Arcs.
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of ap@CaptivePhotons.com
Sent: Saturday, November 6, 2021 8:33 AM
Subject: [ap-gto] APPM Model sanity check (suggestion)
The discussion on refreshing reminds me to ask this.
I set up and tear down nightly, but fairly precisely in the same setup (example: I usually land within 5' of polar
aligned after I put things together).
I have built a nice model of the sky, but for just time constraints (and I guide) I do not build a new model each
night, and because I worry the model is no longer good, I generally do not use one at all.
I know that APPM has a verify process, that will check each model point for consistency (presumably to flush
out equipment variability that may be invalidating it from run to run).
Would it be possible to have a similar process, perhaps a "model sanity check", which would take 10% (or
some specified number of model points), and check just those. The idea is to see if your model is still good
but in far less time than a complete verify run (which basically takes the same time it would to build a model).
I am not sure how to interpret it, but some kind of correlation calculation could tell you if it looks good or bad,
and is worth using. The idea is spending 10 minutes to validate a fairly large model rather than 60-90 minutes
to build a new one.
Or... am I just crazy to consider reusing a model after a tear down and reassembly?