DEC Tracking test


Craig Young
 

I have been a major critic of APCC over the last several years due to its poor tracking performance on my 16" RC w/1600AE mount and plate scale of 0.57 arcsec/pixel.  So it was with great enthusiasm to finally get a chance to try out the new DEC arc tracking feature in APCC.  For my photometry research program it is required that the mount track on the same pixel over a 6 hour DEC arc run.  I don't use an autoguider because of all the technical issues and instead wrote a software program called ATrack which controls the mount precisely using science image plate solving in real time to make corrections to the mount tracking.  This has been successful and achieves the goal of 1 pixel over 6 hours without an autoguider.

So last night I setup a DEC arc centered of -30 DEC (I am in southern hemisphere), east sky only using 3 DEC arcs with 1 degree spacing: -31, -30 and -29.  The RA spacing was set at 5 degrees and the arc ran from -3 HA to 0 HA.  This resulted in 9 points on each arc for a total of 27 points.  APPM collected the data which took only a few minutes and built a model based on these parameters.

I then pointed the mount at -1.5 HA and -30 DEC and recorded 20 images each of 60 seconds.  No autoguider was used and ATrack was used to measure the drift and image shift numbers without doing any corrections.

The results were spectacular.  ATrack reported an inter-image drift of less than an arcsecond, typically 0.2 arcseconds across all 20 images.  Over the 20 minutes or so of testing the image drift was no more than a couple of arcseconds with the final image being less than an arcsecond from the first image in the sequence.  Residual tracking errors in each image combine to produce an image shift over the entire run but ATrack can easily correct for this by re-centering the next image.  This is done by adding a slight bias in RA and DEC to the tracking motors for a period of time, similar to what an autoguider would do when using pulse guiding corrections.

More testing is needed but I would like to request two features:
1. A tab on APPM titled "DEC ARC models" in which you define your DEC arc.  For example, a DEC arc would be defined as centered on -30 15 27 and a spacing of 1 degree.  This would result in a APPM model of three arcs, the center arc, and an arc on either side separated by 1 degree.  In addition, the RA spacing could be specified to define the number of points on each arc.  The defaults for this would be: DEC position would be current mount DEC.  DEC spacing would be 1 degree.  RA spacing would be 5 degrees.  And a checkbox for East or West or both.  A name for the arc would also be good.  I believe this would make it easier and faster to create DEC arcs.
2. APPM is used to create multiple DEC arcs, one for each object being imaged.  Then when the mount is slewed to an object, APCC looks for the DEC arc that most closely matches the object DEC and loads it.  That way the user does not have to manually do this.

In any case, well done Ray for providing us with an excellent new tracking feature and all the hard work Ray and the AP team have put into this.  This really advances the software capability of APCC and shows how good the AP mounts and software can perform.

Craig
Crystal Lake Observatory
New Zealand


Ray Gralak
 

Thanks Craig for the feedback! I am glad your initial tests went well.

We'll definitely discuss your suggestions. Of note, NINA will soon have a feature that can invoke APPM to auto-map a couple rows of data around each target before imaging that target. Would that satisfy your item #1?

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Craig Young
Sent: Wednesday, September 1, 2021 12:18 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] DEC Tracking test

I have been a major critic of APCC over the last several years due to its poor tracking performance on my 16"
RC w/1600AE mount and plate scale of 0.57 arcsec/pixel. So it was with great enthusiasm to finally get a
chance to try out the new DEC arc tracking feature in APCC. For my photometry research program it is
required that the mount track on the same pixel over a 6 hour DEC arc run. I don't use an autoguider because
of all the technical issues and instead wrote a software program called ATrack which controls the mount
precisely using science image plate solving in real time to make corrections to the mount tracking. This has
been successful and achieves the goal of 1 pixel over 6 hours without an autoguider.

So last night I setup a DEC arc centered of -30 DEC (I am in southern hemisphere), east sky only using 3 DEC
arcs with 1 degree spacing: -31, -30 and -29. The RA spacing was set at 5 degrees and the arc ran from -3 HA
to 0 HA. This resulted in 9 points on each arc for a total of 27 points. APPM collected the data which took
only a few minutes and built a model based on these parameters.

I then pointed the mount at -1.5 HA and -30 DEC and recorded 20 images each of 60 seconds. No autoguider
was used and ATrack was used to measure the drift and image shift numbers without doing any corrections.

The results were spectacular. ATrack reported an inter-image drift of less than an arcsecond, typically 0.2
arcseconds across all 20 images. Over the 20 minutes or so of testing the image drift was no more than a
couple of arcseconds with the final image being less than an arcsecond from the first image in the sequence.
Residual tracking errors in each image combine to produce an image shift over the entire run but ATrack can
easily correct for this by re-centering the next image. This is done by adding a slight bias in RA and DEC to
the tracking motors for a period of time, similar to what an autoguider would do when using pulse guiding
corrections.

More testing is needed but I would like to request two features:
1. A tab on APPM titled "DEC ARC models" in which you define your DEC arc. For example, a DEC arc
would be defined as centered on -30 15 27 and a spacing of 1 degree. This would result in a APPM model of
three arcs, the center arc, and an arc on either side separated by 1 degree. In addition, the RA spacing could
be specified to define the number of points on each arc. The defaults for this would be: DEC position would
be current mount DEC. DEC spacing would be 1 degree. RA spacing would be 5 degrees. And a checkbox
for East or West or both. A name for the arc would also be good. I believe this would make it easier and
faster to create DEC arcs.
2. APPM is used to create multiple DEC arcs, one for each object being imaged. Then when the mount is
slewed to an object, APCC looks for the DEC arc that most closely matches the object DEC and loads it.
That way the user does not have to manually do this.

In any case, well done Ray for providing us with an excellent new tracking feature and all the hard work Ray
and the AP team have put into this. This really advances the software capability of APCC and shows how
good the AP mounts and software can perform.

Craig
Crystal Lake Observatory
New Zealand


Craig Young
 

If the same target is observed with NINA, will APPM be requested to do a new map or does it use an old one?  In my case I would be observing the same 4 targets throughout the year.  If NINA could build a DEC ARC for each target and use them each night I believe that would work.

Craig


Craig Young
 

Does this mean there is an API available for APCC for use by 3rd party software?  If so I could build the 4 DEC arcs and when I switch targets ATrack could send a request to APCC to load a previously saved model and turn on DEC ARC tracking.

Craig


Dale Ghent
 

On Sep 2, 2021, at 16:31, Craig Young <craig.young.m8@gmail.com> wrote:

If the same target is observed with NINA, will APPM be requested to do a new map or does it use an old one? In my case I would be observing the same 4 targets throughout the year. If NINA could build a DEC ARC for each target and use them each night I believe that would work.
I want to move my NINA plugin in that kind of direction, with it being able to tell APPM to generate a dec-arc model on demand for each target, but there are some prerequisites that are needed on the APPM side of things to make this a programmatically smooth thing to do. I've talked to Ray about these needs and he'll look into implementing them if they're reasonably feasible. So, no guarantees on timeline or anything, but we've talked about the concept.

But say such a thing does become possible, where you can drop a "Create Dec-Arc Model" instruction into your NINA sequence template and it'll do just that based on the target's declination, then there would be some additional considerations around reuse of the model that comes out of that instance.

When APPM creates a model, it saves it as a .pnt file under C:\ProgramData\Astro-Physics\APCC\Models. These pnt files contain various metadata about the run, such as the date it was created, the location, various options that were selected, and so on. For Dec-Arc models, APPM would also need to note the declination in the metadata of each dec-arc model pnt file.

If the above were to be done, the envisioned "Create Dec-Arc Model" instruction could look at those pnt files and build a list of model creation dates and the declination they were created for. This would allow the plugin to match up an existing model to the target's declination. The model creation date would tell the instruction how old it is. Thus, using a user-suppled date limit measured in hours or fractional days, the instruction can decide if any existing model for a given declination is too old to use and instruct APPM to create a new one, or tell APPM (or APCC) to load the existing model and run with that instead. This interface - telling APCC to load a particular model - is a programmatic interface that I'm not sure exists or not. I recon it does, as APPM already seems to have a way to tell APCC to load the model it just created.

Anyway, there are some efficiencies in time that can be automated with this. If one is reasonably sure of their models as they age, they can set a use-if-no-older-than length of time in the plugin's configuration and not have to worry about time being wasted if you do a multiple night run on a specific target coordinates where you don't necessarily need a new Dec-Arc model each time. This is clearly up to user discretion, obviously, and I don't know if Dec-Arc models have any differences in sensitivities towards age compared to all-sky models.

This expiry date concept is something I could put in to the existing "Create APPM model" instruction in my plugin, though, since all that would be interested in is the creation date. No sense in creating a new model if one feels that their existing one is still valid. The instruction would then be a no-op at that point.

/dale


Craig Young
 

For my project it would be easy enough to call APCC with the filename of the model to be loaded.  Since I only do 4 targets I could create these models ahead of time.  If the tracking for a particular target shows 'age' then I can make a newer model for that target, or all the targets. 

So a simple APCC call: "Execute DEC ARC(model file name)" is all I would need.

Craig


Craig Young
 

Since the V2 driver can talk to APCC using a virtual COM port and my ATrack program uses COM port communications with Voyager, it would be easy to add a COM port command as above, sent to APCC.

Craig