Thank you Brian and Wade for putting these videos together! I think the videos are great explainers of the two systems and how they can work well together.

Wade brought up a few things in the second video and in subsequent posts that I can answer.

1. The race condition that was noted in turning on tracking, around the 14:00 mark in video 2. Perhaps this is something Ray should look at. Turning tracking on from the client is a synchronous operation - setting the ASCOM driver's Tracking property to true in this case. It should return after the driver internally verifies that tracking is in fact set to the requested state. That is, we (NINA, the client) expects the mount to reflect the requested state upon returning; not some time afterwards, even if it's a very short amount of time.

On the topic of that block of instructions in your sequence: With an unparked mount with a tracking rate of 0, NINA will enable tracking before slewing, as ASCOM specifies that a mount must be tracking before a slew to an RA+Dec coordinate can be issued. So you can consider removing those last 3 instruction before your IC410 target block. The "Slew and center" operation will implicitly turn on tracking so that it can do its of slewing to the target's coordinates. You can also move the Unpark to within your target bloc, say after the "Wait for Altitude > 20"

We keep implicit operations to a minimum in the instructions, but there are a few places where it makes sense to have them - turning on tracking in order to slew to a coordinate is one. Another is disabling any active guiding before slewing and reenabling it when the slew completes.


2. Automatically choosing an existing model and loading that in automatically if it's not too stale (and, how stale is too stale?) is something I've been noodling over. There is no database of models that makes this easy, so the only way to know what's available is to open each and every .pnt file on the system and parse each one to discover their age and what part of the sky they pertain to. Knowing the date it was created is easy since that's recorded in the .pnt file, but the model parameters are something that I'll need to look at. I would need to find a way to rewind the model to find out which declination it is relevant to.

Then there are considerations for different imaging sites ..

Then there is the aspect of managing these .pnt files as they accumulate over time. Are models from 1 year ago needed? How about 6 month old ones? 2 weeks? Etc.

It can actually get to be a bit of a loaded question, and dec-arc models are so quick to make that I've largely deferred to "punt and just make a new model." Since they're not laborious to make, I kind of feel like the exercise outlined above is a questionable overoptimization that can introduce its own issues and complicate a simple process.


As always, documentation can be found at https://daleghent.com/astro-physics-tools

/dale