1. Topics
  2. [ap-ug] Happy New Year from AstroPhysics - 2 new tutorial videos!

[ap-ug] Happy New Year from AstroPhysics - 2 new tutorial videos!

Dale Ghent
 

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

On Dec 30, 2022, at 15:54, Brian Valente <bvalente@...> wrote:

Hello fellow Astronuts

Interested in Dec Arc Modeling?
Want to know how to use the AP NINA tools for on-the-fly model building?

You're in luck!
Astro-Physics has two new tutorial videos for you covering Dec Arc Modeling

It's a two-parter:

Part 1 details using APCC and APPM for Dec Arc Modeling
https://youtu.be/JhHTKKPp8nk

Part 2 covers using NINA and the AP Tools plugin to automate Dec Arc Modeling 'on the fly".
https://youtu.be/wL-hpGQxCGw

Part 2 features our very own Wade Hilmo explaining how he uses NINA and the AP Tools plugin to automate his sessions. It's an excellent and well presented demonstration. Thanks a million Wade!

As a bonus, you can also download his NINA auto sequencer template he uses in the video (link in the description). The provided template makes it so easy to get up to speed.


As always, we continue to work on new educational materials and videos, so please consider subscribing to the AP YouTube channel and turning on the Notify bell.

If you have requests for other topics or content, please reply here or drop a line to AP!


Brian

Brian Valente
 

Thanks Dale - great commentary and followup detail




On Wed, Jan 4, 2023 at 4:17 PM Dale Ghent <daleg@...> wrote:
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

> On Dec 30, 2022, at 15:54, Brian Valente <bvalente@...> wrote:
>
> Hello fellow Astronuts
>
> Interested in Dec Arc Modeling?
> Want to know how to use the AP NINA tools for on-the-fly model building?
>
> You're in luck!
> Astro-Physics has two new tutorial videos for you covering Dec Arc Modeling
>
> It's a two-parter:
>
> Part 1 details using APCC and APPM for Dec Arc Modeling
> https://youtu.be/JhHTKKPp8nk
>
> Part 2 covers using NINA and the AP Tools plugin to automate Dec Arc Modeling 'on the fly".
> https://youtu.be/wL-hpGQxCGw
>
> Part 2 features our very own Wade Hilmo explaining how he uses NINA and the AP Tools plugin to automate his sessions. It's an excellent and well presented demonstration. Thanks a million Wade!
>
> As a bonus, you can also download his NINA auto sequencer template he uses in the video (link in the description). The provided template makes it so easy to get up to speed.
>
>
> As always, we continue to work on new educational materials and videos, so please consider subscribing to the AP YouTube channel and turning on the Notify bell.
>
> If you have requests for other topics or content, please reply here or drop a line to AP!
>
>
> Brian
>
>








--

Ray Gralak
 

Hi Dale,

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.
Unparking is a single monotonic command to the mount (:Q#) and cannot fail unless the mount lost connection.

So, I would need to see the driver and APCC logs to determine what happened. But, many applications, including some of my own, have
been unparking and enabling tracking in succession for years, so I am not sure why this would be happening with NINA.

-Ray
W Hilmo
 

Hi Dale, thanks for the response.

Regarding the possible race condition, I ran into this a very long time (and a few versions) ago.  I don't remember the specific details, but it was intermittent, happening once out of every 4 or 5 sessions.  It always happened at the start of the session, and the problem was always that when it tried to do the initial plate solve, the mount was still parked and trying to plate solve the horizon.  I added the delay as a test (probably after checking the logs to try and discern the nature of the problem, but it was long enough ago that I don't remember).  Since adding the delay, the problem never recurred.  Sometimes, I follow up on these to see if there is a bug that needs to be fixed, but I didn't do so right away with the one for some reason.  In order to make an actionable bug report, I would want to go back and reproduce it so that I could try to narrow it down further.

Brian and I actually talked about both this, and the non-optimal sequence steps.  I offered to go back and sanitize the sequence to sanitize it and make it "correct" and showing best practices. Ultimately, we decided that it would be more interesting to show an organic setup, warts and all, rather than produce polished demo of an idealized situation.  So the sequence shown was an object specific variant of the same sequence that I've actually been using and updating all summer.  Shortly after we made that video, the clouds rolled in, and have been here ever since.  When we get another stretch of clear skies, I'll probably go back and build a new sequence to use as the foundation for this year.  If I do that, I'll make the changes that you suggest below.

Regarding support for choosing an existing model, here is how I think about it:  I associate my PNT files with a particular configuration and physical position of the mount.  If I change a scope, or physically move the mount, I consider any existing points to be invalid.  Also, if I see either problems tracking, or excessive guide corrections, I would toss out any existing samples and start over from scratch.

To that end, I would envision a button or something that I could use to invalidate all existing points, and perhaps move the PNT files to a configurable archive folder (I am a data pack rat, and never actually delete them...)  At that point, the system would just start building new sample points from scratch as needed.  I doubt there there would be some kind of automatic way for the software to detect that the files are no longer effective.  At least, not efficiently. Of course, it would be possible for APPM to validate a number of samples by actually slewing, plate solving, and comparing the expected results with the actual results.  But that would, at least to me, be too much overhead to bake into a sequence just to determine if a new PNT file is needed or not.  So that leaves it a manual process to retire PNT files.

As I type this, I wonder if it makes sense to suggest a change to APPM such that it can have some ability to use PNT filenames as a cue to the contents.  For example, I am looking at a file named "ApPointData-2022-11-13.pnt".  In looking at the contents of the file, it is a set of samples for dec arc tracking, and the samples are at 32, 33 and 34 degrees.  So what if the PNT filename were "ApPointData-2022-11-13_dec-arcs_32-33-34.pnt"?  Now imagine a new switch on APPM to specifiy the target declination.  With that, APPM could use the target declination to find an appropriate PNT file and use it, or create a new one if there are no appropriate ones available.  I believe that the idea of incorporating metadata into the filename is pretty much the same thing that PixInsight's WPBB does to do advanced matching of calibration files with light frames, so there is already some precedent in astro software.

Just more random thoughts...

-Wade

On 1/4/23 16:17, Dale Ghent wrote:
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
Patrick Sparkman
 

Hi Dale and Wade...BTW Thank you both for your contributions to the AP mount owners that use NINA, and Ray for the great APCC/APPM applications.  

Wade,  I have had the same error as you where very occasionally, I start a sequence with an un-park command and then the Slew, center, rotate command just gets stuck on imaging Polaris (Park 3).  I have not added a wait timer after the un-park as it does not happen frequently which makes it difficult to duplicate.  I will add the wait timer though until we learn more about the root cause of why it happens.

As for the further discussion on reusing Dec-arc models, maybe this user story would at least provide the desired user experience without dictating the solution.

As a NINA astro-imager, I would like the ability to image multiple targets at different declinations using a Dec-arc model, but without having to take the time between astronomical dusk-astronomical dawn to build each model.  

I know that sounds simplistic, and can be solved without the last part of the story by using Dale's great NINA plug-in.  Generally I image at least two, and sometimes three or more targets per night and like to image as much as possible around the meridian to get the best data.  That leads to organizing a sequence around imaging when the target is in the "sweet spot" then moving to the next target when it reaches it's sweet spot.  The current implementation of Dale's plug-in does this really well for the start of each target by providing a user defined lead in, and I can use the horizon limits to limit the west side of the model but would take dark time on the additional targets to do the modelling.  I guess what would be great would be to send APPM the Dec and starting position for all of the targets for the night, and have it build a model around each of those arcs.  Currently, APPM wouldn't do separate arcs, but perhaps Dale could build a point mapper that would have the correct points for the arcs for the night, then write those to a file and have APPM read the customer point file.

Ray,

Would the dec-arc model work properly within the dec ranges of such a custom point model?  i.e.  a custom point model with Dec arcs around -15,-16,-17...5,6,7...and 50,51,52...just a made up example of a night with three targets each with a dec in that range.  Or am I just dreaming!

-Patrick
Patrick Sparkman
 

I just played with editing a point file and importing it again.  Seemed to work great for at least importing it, but I have not tried the model run.  I just took a small model, exported it, deleted a couple of the dec arcs manually in a text editor, and re-imported it.  I know that it would need to be a lot more dense model than this, but I am glad to at least have success using the capability already within APPM.  Now, how would this process work for tracking.  I don't care about pointing accuracy, just tracking.
Brian Valente
 

Hi Patrick

If you are asking how the point model would be enabled for tracking?

Once you finished the mapping run and confirmed using it as the point model, you just enable Tracking Correction in the Pointing Model tab. If you are asking how well a model like that with just a few points would improve things, it's better than no model, but generally the more points the better. I aim for >100 points in an all sky model if you want to do a "map once use often" kind of approach. If that's too much you might also consider a dec arc model, which can be done quickly in an evening for a specific declination. We just released videos on this

image.png


On Thu, Jan 5, 2023 at 1:18 PM Patrick Sparkman via groups.io <psparkman=me.com@groups.io> wrote:
I just played with editing a point file and importing it again.  Seemed to work great for at least importing it, but I have not tried the model run.  I just took a small model, exported it, deleted a couple of the dec arcs manually in a text editor, and re-imported it.  I know that it would need to be a lot more dense model than this, but I am glad to at least have success using the capability already within APPM.  Now, how would this process work for tracking.  I don't care about pointing accuracy, just tracking.



--

Patrick Sparkman
 

Ok, I am running quickly down the rabbit hole.  

Here is a manually edited model that would have worked with my last session of two targets...Tadpole then Thor's Helmet.



This is 231 points and would take about 63 minutes to run.

Now, if I made a model of just Tadpole it would be 116 points and take 31 minutes.  The Thor's Helmet section would be 116 points and take 32 minutes to run.  If I start 30 minutes before it gets dark with the dual target model, I would lose 33 minutes of dark imaging time on the first target.  If I run each model on demand, I would lose 1 minute  on the first target, and 32 minutes on the second target.  I am now convincing myself that you just trade lost time on one target for the other and it is not worth the hassle.  Perhaps I should just stick to Dale's plug-in.  

Sorry if I am just rambling to the group!

Patrick Sparkman
 

Hi Bryan,

To clarify...I was not asking either of those questions.  Rather, would a modelling run with custom input points from two separated dec-arc areas still model correctly when tracking within each of those dec-arcs.
Brian Valente
 

Patrick I think either approach could work, as you pointed out there are tradeoffs to each

I don't know if there's a huge advantage to doing multiple dec arc models in one mapping run, although this seems like a novel idea i haven't really seen before. 

You might be switching your target combinations over time: I can see imaging Thor's Helmet longer (fainter target?) than tadpole so that extra time there would not help you if you switched out tadpoles to a different target. 



On Thu, Jan 5, 2023 at 1:51 PM Patrick Sparkman via groups.io <psparkman=me.com@groups.io> wrote:
Ok, I am running quickly down the rabbit hole.  

Here is a manually edited model that would have worked with my last session of two targets...Tadpole then Thor's Helmet.



This is 231 points and would take about 63 minutes to run.

Now, if I made a model of just Tadpole it would be 116 points and take 31 minutes.  The Thor's Helmet section would be 116 points and take 32 minutes to run.  If I start 30 minutes before it gets dark with the dual target model, I would lose 33 minutes of dark imaging time on the first target.  If I run each model on demand, I would lose 1 minute  on the first target, and 32 minutes on the second target.  I am now convincing myself that you just trade lost time on one target for the other and it is not worth the hassle.  Perhaps I should just stick to Dale's plug-in.  

Sorry if I am just rambling to the group!



--

Ray Gralak
 

To clarify...I was not asking either of those questions. Rather, would a modelling run with custom input points
from two separated dec-arc areas still model correctly when tracking within each of those dec-arcs.
The combined set of map points will improve tracking but tracking may or may not be as accurate as each separate set of mapped points. It depends on how far apart the sets of declinations in each mapping run are from each other.

-Ray
Brian Valente
 

>>>Rather, would a modelling run with custom input points from two separated dec-arc areas still model correctly when tracking within each of those dec-arcs.

Ah got it - I assume by "still model correctly" you mean would the tracking improvements be correctly applied in each of those dec arcs? 

Yes, provided the Declination for your targets you wish to image are within the dec arcs you are mapping




On Thu, Jan 5, 2023 at 1:53 PM Patrick Sparkman via groups.io <psparkman=me.com@groups.io> wrote:
Hi Bryan,

To clarify...I was not asking either of those questions.  Rather, would a modelling run with custom input points from two separated dec-arc areas still model correctly when tracking within each of those dec-arcs.



--

Patrick Sparkman
 

Thanks Ray!
1 - 13 of 13