Questions about All Sky and Dec-Arc models in APCC


Nathan Myhrvold
 

Ray Gralak was kind enough to reply in another post about model features in APCC.   I have some additional questions and thought that moving them to a new thread might make it easier for people to follow it.

It is good to hear about the APCC Dec-Arc tracking - I had wondered what the tradeoff was between All-Sky and Dec-Arc.   Here are a couple questions - sorry if there are too many!

1.  I take it from your post that you recommend Dec-Arc tracking for astrophotography.  Which makes sense - if I am going to photograph an object with many subs, potentially for hours, why not get the best possible tracking for that object?

2. I understand that models improve like Sqrt[N], where N is the number of points on the sky input to the model.  It is nice that in APCC the number of points is unlimited but presumably that would take unlimited time to do.  Which might make perfect sense for an All-Sky model for a permanent pier - why not run the model making for hours when you first install.   But I am nomadic and typically go to a location for several days to a week of imaging (someplace in the desert).  Also, Dec-Arc models would seem to me to be disposable in the sense that once you have done an object you might not return to it for a while, so you might as well make Dec-Arc models for session (but see below). What are reasonable numbers of points for All-Sky for general pointing?   What is a reasonable number of points for Dec-Arc for astrophotography?  In case it matters, I will use a Planewave DR 350 with QHY 600M.  Focal length is 1050mm, pixel size is 3.76 microns, so 0.74 arcsec/pixel.

4. I am guessing that making a model takes 15-30 minutes or so (based on 10micron experience), and that Dec-Arc would be similar.  Most likely this is some fixed time plus some time per point for slewing, photographing, plate solving etc.   What is it typically for the recommended number of points?    If there is limited time, it seems like your call would be to spend more time on adding points to the Dec-Arc model than to the All-Sky model.  One could even skip All Sky and use the point solve and correct after slew feature in NINA or other software.

5. The Sqrt[N] improvement assumes that the model has parameters that can account for systematic effects like flexure.  In the 10micron world there are lots of stories of somebody trying to get a good model, and being frustrated until they took their rig apart and found one screw loose somewhere.   Obviously, a model can't account for random variations, but it potentially could take anything repeatable - which includes a lot of examples of flexure.  However, at some point you can't make the model have too many parameters because there will be a model fitting problem.   Also, I would imagine that the Dec-Arc model would be better able to do this than an All-Sky model.  I think that is what you mean by "all possible idiosyncrasies" - you can use a richer set of models (more parameters) without danger of overfitting - is that correct?

6.  In the 10micron world people brag about the accuracy (RMS) of their model, but that number is generated during model building, so it is only modeling accuracy - i.e. how well the model can fit the observed data - basically it is a goodness-of-fit metric.  It is not actual tracking accuracy.  I have tested that in cases where I did many subs, and then after the fact plate solved them.  Obviously, real tracking errors are greater than the modeling errors. I presume you have checked this.

7.  It is possible to save Dec-Arc models as files of some sort?   A frequent scenario - at least for me, is that across a week or so of imaging I might work on several DSO in the same night, and then return to them the next night.  This is because they rise at different times, so they have different optimum imaging periods based on their altitude.  Also, if the moon rises you can take narrowband subs, while LRGB is better done without the moon.   So, if I had 2-4 objects to visit per night, with a different Dec-Arc model for each one, I could return to it the next night without making new models.  There would of course be some small changes in position due to Earth position relative to the sun, but day-to-day my guess is that is a big deal.   

The next couple questions are quite ambitious and likely would require changes to APCC - and might not even be worthwhile.  Please forgive my curiosity.

8.  In Dec-Arc tracking it ought to be possible to use the actual astrophotos that you take to refine the model as it goes.   The simplest thing would be if you were photographing the same DSO night after night you could use last nights plate solved photos to refine the model for the next night.  I think to do this you would need a way to record the internal encoder readings for each photo.  In principle NINA or other software could (with suitable modification) put the encoder readings in the FITS header.  This probably does not happen at present, but if that were added to the NINA interface for AP mounts that might help model building.

9.  But, to get even more ambitious, in principle this could happen in parallel with taking the pictures.   In fact, you could think of this as being a bridge between the closed-loop guiding approach and the model-building approach.   Pure guiding - like PHD2 etc - takes photos in real time and quickly makes a decision to correct problems in object tracking.   It is limited by the fact that it has to be quick or else the error gets too large, but at the same time the corrections can't be too abrupt, or you cause more problems than you fix.  This is the reason for the various parameters you need to set in PHD2.   Continual improvement to a Dec-Arc model would take more processing time than the simple corrections for PHD2, but in most astrophotography cases you have minutes per exposure to update the model.   Rather than abrupt changes to get the mount pointing where it should, this would very gradually refine the tracking model.   Of course, this might not be necessary for a decent initial Dec-Arc model, but I am curious as to what you think.

10.  Another out there question.  I assume it would be possible to do the model making adaptively - for example in Dec-Arc modeling if there were modeling errors in some portion of the arc then when the model is made it could notice and call for more points in those areas.   This might not be worth it, or necessary.  I ask because 10micron model making software (really, model data gathering) has a feature where you can delete points which have large modeling errors as "outliers".   While you might have a real outlier - i.e. a passing cloud or airplane - getting rid of points with large modeling error struck me as being fundamentally wrong - what you want is MORE data in that area to verify if it is a true outlier, not just turn a blind eye to it.  So I have thought hey, if one or more data points are not modeled well, then the model making software should slew back to that part of the sky and take more data points automatically, or semi-automatically.  Again ,this might be a bad idea or unnecessary but I am curious what you think.

Nathan


Dean Jacobsen
 

Nathan, will you be working from a permanently mounted situation such as an observatory where the mount remains fixed indefinitely or are you a nomad setting up the mount for each use?  I am a nomad and have worked out an approach that suits my use, but I would do things different if my mount was permanently located in an observatory.
--
Dean Jacobsen
Astrobin Image Gallery - https://www.astrobin.com/users/deanjacobsen/


Nathan Myhrvold
 

I am nomadic – I live near Seattle but image in the desert – Arizona, Utah, Nevada or Texas.

 

Nathan

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Dean Jacobsen via groups.io
Sent: Saturday, July 2, 2022 12:42 PM
To: main@ap-gto.groups.io
Subject: [EXTERNAL] Re: [ap-gto] Questions about All Sky and Dec-Arc models in APCC

 

Nathan, will you be working from a permanently mounted situation such as an observatory where the mount remains fixed indefinitely or are you a nomad setting up the mount for each use?  I am a nomad and have worked out an approach that suits my use, but I would do things different if my mount was permanently located in an observatory.
--
Dean Jacobsen
Astrobin Image Gallery - https://www.astrobin.com/users/deanjacobsen/


Ray Gralak
 

Hi Nathan,

In your CN post, you mentioned that unguided imaging from a pointing model has been championed by 10micron. I would just like to point out that APPM predates all of the "modeling" software programs for 10micron mounts that use plate solving. And well before APPM, Software Bisque had TPoint, which was used in some Paramount setups for unguided imaging (two decades ago) without the benefit of encoders!

1. I take it from your post that you recommend Dec-Arc tracking for astrophotography. Which makes sense - if I
am going to photograph an object with many subs, potentially for hours, why not get the best possible tracking for
that object?
Yes, Dec-Arc tracking was designed for the best unguided performance for imaging.

2. I understand that models improve like Sqrt[N], where N is the number of points on the sky input to the model. It
is nice that in APCC the number of points is unlimited but presumably that would take unlimited time to do.
Which might make perfect sense for an All-Sky model for a permanent pier - why not run the model making for
hours when you first install. But I am nomadic and typically go to a location for several days to a week of imaging
(someplace in the desert).
You can create a localized Dec-Arc model with equal density (square degrees per point) as a larger All-Sky model. This will take much less time. And, it will be more accurate than an All-Sky model as the model created is not a small All-Sky model consisting of points along a Dec path, like what happens with most other manufacturers' mounts

Also, Dec-Arc models would seem to me to be disposable in the sense that once you
have done an object you might not return to it for a while, so you might as well make Dec-Arc models for session
(but see below). What are reasonable numbers of points for All-Sky for general pointing? What is a reasonable
number of points for Dec-Arc for astrophotography? In case it matters, I will use a Planewave DR 350 with QHY
600M. Focal length is 1050mm, pixel size is 3.76 microns, so 0.74 arcsec/pixel.
I don't know anything about that telescope, so you'll have to experiment. I would start with a spacing of 3-5 degrees in RA and Dec for Sky pointst.

4. I am guessing that making a model takes 15-30 minutes or so (based on 10micron experience), and that Dec-
Arc would be similar. Most likely this is some fixed time plus some time per point for slewing, photographing, plate
solving etc. What is it typically for the recommended number of points? If there is limited time, it seems like your
call would be to spend more time on adding points to the Dec-Arc model than to the All-Sky model. One could
even skip All Sky and use the point solve and correct after slew feature in NINA or other software.
You can start gathering points before the sky is fully dark, so you won't lose much imaging time. If you can leave your setup undisturbed you may be able to do a dense full sky model the first night and later save time by not having to do individual Dec Arc runs.

5. The Sqrt[N] improvement assumes that the model has parameters that can account for systematic effects like
flexure.
It's also about the accuracy of plate solves. If you haven't tried experimenting with plate solving the same images with different plate solvers, you might want to try it. There is usually some discrepancy between solutions of the various plate solvers (up to +/- 1-2 arc-secs). This is mostly irrelevant for pointing correction but every arc-second matters for accurate tracking rate correction.

In the 10micron world there are lots of stories of somebody trying to get a good model, and being
frustrated until they took their rig apart and found one screw loose somewhere. Obviously, a model can't account
for random variations, but it potentially could take anything repeatable - which includes a lot of examples of
flexure.
APPM has a "5x Verify" model option which does five(5) mapping runs in a row. The results can be used to determine if the mount has any pointing randomness.

However, at some point you can't make the model have too many parameters because there will be a
model fitting problem. Also, I would imagine that the Dec-Arc model would be better able to do this than an All-
Sky model. I think that is what you mean by "all possible idiosyncrasies" - you can use a richer set of models
(more parameters) without danger of overfitting - is that correct?
No, not really. There are multiple reasons, but I can give you one example. Typical pointing terms model telescope flexure as if the telescope is a perfect homogenous cylinder made of one material. That may not be very close to reality.

6. In the 10micron world people brag about the accuracy (RMS) of their model, but that number is generated
during model building, so it is only modeling accuracy - i.e. how well the model can fit the observed data -
basically it is a goodness-of-fit metric. It is not actual tracking accuracy. I have tested that in cases where I did
many subs, and then after the fact plate solved them. Obviously, real tracking errors are greater than the modeling
errors. I presume you have checked this.
I've performed many hundreds of hours of testing and refining Dec-Arc tracking. Since it is easy to switch between Dec-Arc and All-Sky tracking while running, I can say that I can almost always take longer unguided images without detectable star elongation using Dec Arc tracking. When All-Sky "wins" that contest it's usually because the nearest Dec arc had less than five (5) sky points, or there was a random outlier.

7. It is possible to save Dec-Arc models as files of some sort?
All of the Sky Map point data in each APPM run is stored in a plain text file. The actual models are created in memory after loading the sky mapping data. This allows testing of new models with existing data points.

> A frequent scenario - at least for me, is that across
a week or so of imaging I might work on several DSO in the same night, and then return to them the next night.
This is because they rise at different times, so they have different optimum imaging periods based on their
altitude. Also, if the moon rises you can take narrowband subs, while LRGB is better done without the moon. So,
if I had 2-4 objects to visit per night, with a different Dec-Arc model for each one, I could return to it the next night
without making new models. There would of course be some small changes in position due to Earth position
relative to the sun, but day-to-day my guess is that is a big deal.
Internally the models work with hour angle and declination, so they can be reloaded and will work later, provided the mount and scope setup remain undisturbed.

The next couple questions are quite ambitious and likely would require changes to APCC - and might not even be
worthwhile. Please forgive my curiosity.

8. In Dec-Arc tracking it ought to be possible to use the actual astrophotos that you take to refine the model as it
goes. The simplest thing would be if you were photographing the same DSO night after night you could use last
nights plate solved photos to refine the model for the next night. I think to do this you would need a way to record
the internal encoder readings for each photo. In principle NINA or other software could (with suitable
modification) put the encoder readings in the FITS header. This probably does not happen at present, but if that
were added to the NINA interface for AP mounts that might help model building.
It's an interesting idea, but I'm not sure that would help. I think tracking rate accuracy is currently limited by the accuracy of the plate solves.

9. But, to get even more ambitious, in principle this could happen in parallel with taking the pictures. In fact, you
could think of this as being a bridge between the closed-loop guiding approach and the model-building approach.
Pure guiding - like PHD2 etc - takes photos in real time and quickly makes a decision to correct problems in object
tracking. It is limited by the fact that it has to be quick or else the error gets too large, but at the same time the
corrections can't be too abrupt, or you cause more problems than you fix. This is the reason for the various
parameters you need to set in PHD2. Continual improvement to a Dec-Arc model would take more processing
time than the simple corrections for PHD2, but in most astrophotography cases you have minutes per exposure to
update the model. Rather than abrupt changes to get the mount pointing where it should, this would very
gradually refine the tracking model. Of course, this might not be necessary for a decent initial Dec-Arc model, but
I am curious as to what you think.
One experimental feature of APCC Pro I have worked on is monitoring the RA/Dec trends from autoguider moves, which have to go through APCC, and adjust RA and Dec tracking rates. The goal is to minimizing autoguider moves. It has some potential problems though, like differentiating between a dithering move and a real autoguider move. To do that for all autoguiding programs probably would require a standardized API.

10. Another out there question. I assume it would be possible to do the model making adaptively - for example in
Dec-Arc modeling if there were modeling errors in some portion of the arc then when the model is made it could
notice and call for more points in those areas.
There shouldn't be those type of errors unless there is significant randomness in the system. And if that is the case then redoing "bad" points might not help. And you can easily filter outliers in a model with APCC, or any sky point simply by unchecking it in the list in APCC's Pointing model window.

BTW, I have many ideas for future builds of APPM and APCC modeling, but those may take some time to get approved and implemented.


-Ray


Nathan Myhrvold
 

Thanks so much for the answers!

What I meant by "championed" is that unguided mode seems to be emphasized as one of the primary selling points of the mount and as a result it seems that a high fraction of 10micron users seem to use it.   

It is certainly possible to guide a 10micron with PHD2 or similar, but I think it would be considered a little odd in that community - like buying a convertible car and never intending to put the top down.

My impression of AP is that it has a much broader reputation for being high quality, and many people buy it explicitly to use guided. Eve if it has the best unguided mode. 

But maybe I am wrong on both counts!  

But please be assured that I meant no disrespect to AP or APCC!  I take your point about the historical record.  I think professional telescopes went unguided long before amateur telescopes did, in part because really big telescopes (post Palomar) tend to have mount issues and may even be alt az.

Nathan

Nathan
Going mobile


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Ray Gralak via groups.io <iogroups@...>
Sent: Saturday, July 2, 2022 4:30:58 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: [EXTERNAL] Re: [ap-gto] Questions about All Sky and Dec-Arc models in APCC
 
Hi Nathan,

In your CN post, you mentioned that unguided imaging from a pointing model has been championed by 10micron. I would just like to point out that APPM predates all of the "modeling" software programs for 10micron mounts that use plate solving.  And well before APPM, Software Bisque had TPoint, which was used in some Paramount setups for unguided imaging (two decades ago) without the benefit of encoders!

> 1.  I take it from your post that you recommend Dec-Arc tracking for astrophotography.  Which makes sense - if I
> am going to photograph an object with many subs, potentially for hours, why not get the best possible tracking for
> that object?

Yes, Dec-Arc tracking was designed for the best unguided performance for imaging.

> 2. I understand that models improve like Sqrt[N], where N is the number of points on the sky input to the model.  It
> is nice that in APCC the number of points is unlimited but presumably that would take unlimited time to do.
> Which might make perfect sense for an All-Sky model for a permanent pier - why not run the model making for
> hours when you first install.   But I am nomadic and typically go to a location for several days to a week of imaging
> (someplace in the desert). 

You can create a localized Dec-Arc model with equal density (square degrees per point) as a larger All-Sky model. This will take much less time. And, it will be more accurate than an All-Sky model as the model created is not a small All-Sky model consisting of points along a Dec path, like what happens with most other manufacturers' mounts

> Also, Dec-Arc models would seem to me to be disposable in the sense that once you
> have done an object you might not return to it for a while, so you might as well make Dec-Arc models for session
> (but see below). What are reasonable numbers of points for All-Sky for general pointing?   What is a reasonable
> number of points for Dec-Arc for astrophotography?  In case it matters, I will use a Planewave DR 350 with QHY
> 600M.  Focal length is 1050mm, pixel size is 3.76 microns, so 0.74 arcsec/pixel.

I don't know anything about that telescope, so you'll have to experiment. I would start with a spacing of 3-5 degrees in RA and Dec for Sky pointst.

> 4. I am guessing that making a model takes 15-30 minutes or so (based on 10micron experience), and that Dec-
> Arc would be similar.  Most likely this is some fixed time plus some time per point for slewing, photographing, plate
> solving etc.   What is it typically for the recommended number of points?    If there is limited time, it seems like your
> call would be to spend more time on adding points to the Dec-Arc model than to the All-Sky model.  One could
> even skip All Sky and use the point solve and correct after slew feature in NINA or other software.

You can start gathering points before the sky is fully dark, so you won't lose much imaging time. If you can leave your setup undisturbed you may be able to do a dense full sky model the first night and later save time by not having to do individual Dec Arc runs.

> 5. The Sqrt[N] improvement assumes that the model has parameters that can account for systematic effects like
> flexure. 

It's also about the accuracy of plate solves. If you haven't tried experimenting with plate solving the same images with different plate solvers, you might want to try it. There is usually some discrepancy between solutions of the various plate solvers (up to +/- 1-2 arc-secs). This is mostly irrelevant for pointing correction but every arc-second matters for accurate tracking rate correction.

> In the 10micron world there are lots of stories of somebody trying to get a good model, and being
> frustrated until they took their rig apart and found one screw loose somewhere.   Obviously, a model can't account
> for random variations, but it potentially could take anything repeatable - which includes a lot of examples of
> flexure. 

APPM has a "5x Verify" model option which does five(5) mapping runs in a row. The results can be used to determine if the mount has any pointing randomness.

> However, at some point you can't make the model have too many parameters because there will be a
> model fitting problem.   Also, I would imagine that the Dec-Arc model would be better able to do this than an All-
> Sky model.  I think that is what you mean by "all possible idiosyncrasies" - you can use a richer set of models
> (more parameters) without danger of overfitting - is that correct?

No, not really. There are multiple reasons, but I can give you one example. Typical pointing terms model telescope flexure as if the telescope is a perfect homogenous cylinder made of one material. That may not be very close to reality.

> 6.  In the 10micron world people brag about the accuracy (RMS) of their model, but that number is generated
> during model building, so it is only modeling accuracy - i.e. how well the model can fit the observed data -
> basically it is a goodness-of-fit metric.  It is not actual tracking accuracy.  I have tested that in cases where I did
> many subs, and then after the fact plate solved them.  Obviously, real tracking errors are greater than the modeling
> errors. I presume you have checked this.

I've performed many hundreds of hours of testing and refining Dec-Arc tracking. Since it is easy to switch between Dec-Arc and All-Sky tracking while running, I can say that I can almost always take longer unguided images without detectable star elongation using Dec Arc tracking. When All-Sky "wins" that contest it's usually because the nearest Dec arc had less than five (5) sky points, or there was a random outlier.

> 7.  It is possible to save Dec-Arc models as files of some sort? 

All of the Sky Map point data in each APPM run is stored in a plain text file. The actual models are created in memory after loading the sky mapping data. This allows testing of new models with existing data points.

 > A frequent scenario - at least for me, is that across
> a week or so of imaging I might work on several DSO in the same night, and then return to them the next night.
> This is because they rise at different times, so they have different optimum imaging periods based on their
> altitude.  Also, if the moon rises you can take narrowband subs, while LRGB is better done without the moon.   So,
> if I had 2-4 objects to visit per night, with a different Dec-Arc model for each one, I could return to it the next night
> without making new models.  There would of course be some small changes in position due to Earth position
> relative to the sun, but day-to-day my guess is that is a big deal.

Internally the models work with hour angle and declination, so they can be reloaded and will work later, provided the mount and scope setup remain undisturbed.

> The next couple questions are quite ambitious and likely would require changes to APCC - and might not even be
> worthwhile.  Please forgive my curiosity.
>
> 8.  In Dec-Arc tracking it ought to be possible to use the actual astrophotos that you take to refine the model as it
> goes.   The simplest thing would be if you were photographing the same DSO night after night you could use last
> nights plate solved photos to refine the model for the next night.  I think to do this you would need a way to record
> the internal encoder readings for each photo.  In principle NINA or other software could (with suitable
> modification) put the encoder readings in the FITS header.  This probably does not happen at present, but if that
> were added to the NINA interface for AP mounts that might help model building.

It's an interesting idea, but I'm not sure that would help. I think tracking rate accuracy is currently limited by the accuracy of the plate solves.

> 9.  But, to get even more ambitious, in principle this could happen in parallel with taking the pictures.   In fact, you
> could think of this as being a bridge between the closed-loop guiding approach and the model-building approach.
> Pure guiding - like PHD2 etc - takes photos in real time and quickly makes a decision to correct problems in object
> tracking.   It is limited by the fact that it has to be quick or else the error gets too large, but at the same time the
> corrections can't be too abrupt, or you cause more problems than you fix.  This is the reason for the various
> parameters you need to set in PHD2.   Continual improvement to a Dec-Arc model would take more processing
> time than the simple corrections for PHD2, but in most astrophotography cases you have minutes per exposure to
> update the model.   Rather than abrupt changes to get the mount pointing where it should, this would very
> gradually refine the tracking model.   Of course, this might not be necessary for a decent initial Dec-Arc model, but
> I am curious as to what you think.

One experimental feature of APCC Pro I have worked on is monitoring the RA/Dec trends from autoguider moves, which have to go through APCC, and adjust RA and Dec tracking rates. The goal is to minimizing autoguider moves. It has some potential problems though, like differentiating between a dithering move and a real autoguider move. To do that for all autoguiding programs probably would require a standardized API.

> 10.  Another out there question.  I assume it would be possible to do the model making adaptively - for example in
> Dec-Arc modeling if there were modeling errors in some portion of the arc then when the model is made it could
> notice and call for more points in those areas. 

There shouldn't be those type of errors unless there is significant randomness in the system. And if that is the case then redoing "bad" points might not help. And you can easily filter outliers in a model with APCC, or any sky point simply by unchecking it in the list in APCC's Pointing model window.

BTW, I have many ideas for future builds of APPM and APCC modeling, but those may take some time to get approved and implemented.


-Ray








Bill Long
 

All 10 Micron mounts have absolute encoders in them. You cannot buy one without them, thus why a large part of their user base does unguided imaging.

The Mach 2 also only comes with encoders, and after it was released there has been a large increase in the number of people using APPM/APCC to build tracking models for unguided imaging. 

Encoders, as Ray mentioned, are not required for unguided imaging, but they do help. I have used AP models on non-encoder and encoder based AP mounts for years. 


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Nathan Myhrvold <nathanm@...>
Sent: Saturday, July 2, 2022 6:14 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Questions about All Sky and Dec-Arc models in APCC
 
Thanks so much for the answers!

What I meant by "championed" is that unguided mode seems to be emphasized as one of the primary selling points of the mount and as a result it seems that a high fraction of 10micron users seem to use it.   

It is certainly possible to guide a 10micron with PHD2 or similar, but I think it would be considered a little odd in that community - like buying a convertible car and never intending to put the top down.

My impression of AP is that it has a much broader reputation for being high quality, and many people buy it explicitly to use guided. Eve if it has the best unguided mode. 

But maybe I am wrong on both counts!  

But please be assured that I meant no disrespect to AP or APCC!  I take your point about the historical record.  I think professional telescopes went unguided long before amateur telescopes did, in part because really big telescopes (post Palomar) tend to have mount issues and may even be alt az.

Nathan

Nathan
Going mobile

From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Ray Gralak via groups.io <iogroups@...>
Sent: Saturday, July 2, 2022 4:30:58 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: [EXTERNAL] Re: [ap-gto] Questions about All Sky and Dec-Arc models in APCC
 
Hi Nathan,

In your CN post, you mentioned that unguided imaging from a pointing model has been championed by 10micron. I would just like to point out that APPM predates all of the "modeling" software programs for 10micron mounts that use plate solving.  And well before APPM, Software Bisque had TPoint, which was used in some Paramount setups for unguided imaging (two decades ago) without the benefit of encoders!

> 1.  I take it from your post that you recommend Dec-Arc tracking for astrophotography.  Which makes sense - if I
> am going to photograph an object with many subs, potentially for hours, why not get the best possible tracking for
> that object?

Yes, Dec-Arc tracking was designed for the best unguided performance for imaging.

> 2. I understand that models improve like Sqrt[N], where N is the number of points on the sky input to the model.  It
> is nice that in APCC the number of points is unlimited but presumably that would take unlimited time to do.
> Which might make perfect sense for an All-Sky model for a permanent pier - why not run the model making for
> hours when you first install.   But I am nomadic and typically go to a location for several days to a week of imaging
> (someplace in the desert). 

You can create a localized Dec-Arc model with equal density (square degrees per point) as a larger All-Sky model. This will take much less time. And, it will be more accurate than an All-Sky model as the model created is not a small All-Sky model consisting of points along a Dec path, like what happens with most other manufacturers' mounts

> Also, Dec-Arc models would seem to me to be disposable in the sense that once you
> have done an object you might not return to it for a while, so you might as well make Dec-Arc models for session
> (but see below). What are reasonable numbers of points for All-Sky for general pointing?   What is a reasonable
> number of points for Dec-Arc for astrophotography?  In case it matters, I will use a Planewave DR 350 with QHY
> 600M.  Focal length is 1050mm, pixel size is 3.76 microns, so 0.74 arcsec/pixel.

I don't know anything about that telescope, so you'll have to experiment. I would start with a spacing of 3-5 degrees in RA and Dec for Sky pointst.

> 4. I am guessing that making a model takes 15-30 minutes or so (based on 10micron experience), and that Dec-
> Arc would be similar.  Most likely this is some fixed time plus some time per point for slewing, photographing, plate
> solving etc.   What is it typically for the recommended number of points?    If there is limited time, it seems like your
> call would be to spend more time on adding points to the Dec-Arc model than to the All-Sky model.  One could
> even skip All Sky and use the point solve and correct after slew feature in NINA or other software.

You can start gathering points before the sky is fully dark, so you won't lose much imaging time. If you can leave your setup undisturbed you may be able to do a dense full sky model the first night and later save time by not having to do individual Dec Arc runs.

> 5. The Sqrt[N] improvement assumes that the model has parameters that can account for systematic effects like
> flexure. 

It's also about the accuracy of plate solves. If you haven't tried experimenting with plate solving the same images with different plate solvers, you might want to try it. There is usually some discrepancy between solutions of the various plate solvers (up to +/- 1-2 arc-secs). This is mostly irrelevant for pointing correction but every arc-second matters for accurate tracking rate correction.

> In the 10micron world there are lots of stories of somebody trying to get a good model, and being
> frustrated until they took their rig apart and found one screw loose somewhere.   Obviously, a model can't account
> for random variations, but it potentially could take anything repeatable - which includes a lot of examples of
> flexure. 

APPM has a "5x Verify" model option which does five(5) mapping runs in a row. The results can be used to determine if the mount has any pointing randomness.

> However, at some point you can't make the model have too many parameters because there will be a
> model fitting problem.   Also, I would imagine that the Dec-Arc model would be better able to do this than an All-
> Sky model.  I think that is what you mean by "all possible idiosyncrasies" - you can use a richer set of models
> (more parameters) without danger of overfitting - is that correct?

No, not really. There are multiple reasons, but I can give you one example. Typical pointing terms model telescope flexure as if the telescope is a perfect homogenous cylinder made of one material. That may not be very close to reality.

> 6.  In the 10micron world people brag about the accuracy (RMS) of their model, but that number is generated
> during model building, so it is only modeling accuracy - i.e. how well the model can fit the observed data -
> basically it is a goodness-of-fit metric.  It is not actual tracking accuracy.  I have tested that in cases where I did
> many subs, and then after the fact plate solved them.  Obviously, real tracking errors are greater than the modeling
> errors. I presume you have checked this.

I've performed many hundreds of hours of testing and refining Dec-Arc tracking. Since it is easy to switch between Dec-Arc and All-Sky tracking while running, I can say that I can almost always take longer unguided images without detectable star elongation using Dec Arc tracking. When All-Sky "wins" that contest it's usually because the nearest Dec arc had less than five (5) sky points, or there was a random outlier.

> 7.  It is possible to save Dec-Arc models as files of some sort? 

All of the Sky Map point data in each APPM run is stored in a plain text file. The actual models are created in memory after loading the sky mapping data. This allows testing of new models with existing data points.

 > A frequent scenario - at least for me, is that across
> a week or so of imaging I might work on several DSO in the same night, and then return to them the next night.
> This is because they rise at different times, so they have different optimum imaging periods based on their
> altitude.  Also, if the moon rises you can take narrowband subs, while LRGB is better done without the moon.   So,
> if I had 2-4 objects to visit per night, with a different Dec-Arc model for each one, I could return to it the next night
> without making new models.  There would of course be some small changes in position due to Earth position
> relative to the sun, but day-to-day my guess is that is a big deal.

Internally the models work with hour angle and declination, so they can be reloaded and will work later, provided the mount and scope setup remain undisturbed.

> The next couple questions are quite ambitious and likely would require changes to APCC - and might not even be
> worthwhile.  Please forgive my curiosity.
>
> 8.  In Dec-Arc tracking it ought to be possible to use the actual astrophotos that you take to refine the model as it
> goes.   The simplest thing would be if you were photographing the same DSO night after night you could use last
> nights plate solved photos to refine the model for the next night.  I think to do this you would need a way to record
> the internal encoder readings for each photo.  In principle NINA or other software could (with suitable
> modification) put the encoder readings in the FITS header.  This probably does not happen at present, but if that
> were added to the NINA interface for AP mounts that might help model building.

It's an interesting idea, but I'm not sure that would help. I think tracking rate accuracy is currently limited by the accuracy of the plate solves.

> 9.  But, to get even more ambitious, in principle this could happen in parallel with taking the pictures.   In fact, you
> could think of this as being a bridge between the closed-loop guiding approach and the model-building approach.
> Pure guiding - like PHD2 etc - takes photos in real time and quickly makes a decision to correct problems in object
> tracking.   It is limited by the fact that it has to be quick or else the error gets too large, but at the same time the
> corrections can't be too abrupt, or you cause more problems than you fix.  This is the reason for the various
> parameters you need to set in PHD2.   Continual improvement to a Dec-Arc model would take more processing
> time than the simple corrections for PHD2, but in most astrophotography cases you have minutes per exposure to
> update the model.   Rather than abrupt changes to get the mount pointing where it should, this would very
> gradually refine the tracking model.   Of course, this might not be necessary for a decent initial Dec-Arc model, but
> I am curious as to what you think.

One experimental feature of APCC Pro I have worked on is monitoring the RA/Dec trends from autoguider moves, which have to go through APCC, and adjust RA and Dec tracking rates. The goal is to minimizing autoguider moves. It has some potential problems though, like differentiating between a dithering move and a real autoguider move. To do that for all autoguiding programs probably would require a standardized API.

> 10.  Another out there question.  I assume it would be possible to do the model making adaptively - for example in
> Dec-Arc modeling if there were modeling errors in some portion of the arc then when the model is made it could
> notice and call for more points in those areas. 

There shouldn't be those type of errors unless there is significant randomness in the system. And if that is the case then redoing "bad" points might not help. And you can easily filter outliers in a model with APCC, or any sky point simply by unchecking it in the list in APCC's Pointing model window.

BTW, I have many ideas for future builds of APPM and APCC modeling, but those may take some time to get approved and implemented.


-Ray








Greg McCall
 

Thanks, Ray for all the detail and history with the mount modelling. 
In reference to use with guiding, it reminds me of a related question with dithering.

I'm portable (drive to a location and set up for the night)  with a Mach2. I've tried with a small model only (I think about 92 points) as well as a model with PHD2 guiding.
The PHD2 was more to see what RMS value it would report with a small model and to let PHD2 do the dithering. (I've tried no dithering, direct within NINA and PHD2)
I've not yet tried the advanced sequencer yet needed for the Dec-Arc in NINA (soon if we can get clear skies with all our wet weather for the last few years on the east coast of Australia)

So the related question:
1) What is the best practice re dithering while running an APPM model (all sky or dec arc)
2) Would it pay to make a smaller all-sky model and just guide? (in the case if I don't get time to plan an object, because of the random nature of doing a night's session, create an advanced sequence and Dec-Arc model)

Greg


On Sun, Jul 3, 2022 at 11:14 AM Nathan Myhrvold <nathanm@...> wrote:
Thanks so much for the answers!

What I meant by "championed" is that unguided mode seems to be emphasized as one of the primary selling points of the mount and as a result it seems that a high fraction of 10micron users seem to use it.   

It is certainly possible to guide a 10micron with PHD2 or similar, but I think it would be considered a little odd in that community - like buying a convertible car and never intending to put the top down.

My impression of AP is that it has a much broader reputation for being high quality, and many people buy it explicitly to use guided. Eve if it has the best unguided mode. 

But maybe I am wrong on both counts!  

But please be assured that I meant no disrespect to AP or APCC!  I take your point about the historical record.  I think professional telescopes went unguided long before amateur telescopes did, in part because really big telescopes (post Palomar) tend to have mount issues and may even be alt az.

Nathan

Nathan
Going mobile

From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Ray Gralak via groups.io <iogroups=siriusimaging.com@groups.io>
Sent: Saturday, July 2, 2022 4:30:58 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: [EXTERNAL] Re: [ap-gto] Questions about All Sky and Dec-Arc models in APCC
 
Hi Nathan,

In your CN post, you mentioned that unguided imaging from a pointing model has been championed by 10micron. I would just like to point out that APPM predates all of the "modeling" software programs for 10micron mounts that use plate solving.  And well before APPM, Software Bisque had TPoint, which was used in some Paramount setups for unguided imaging (two decades ago) without the benefit of encoders!

> 1.  I take it from your post that you recommend Dec-Arc tracking for astrophotography.  Which makes sense - if I
> am going to photograph an object with many subs, potentially for hours, why not get the best possible tracking for
> that object?

Yes, Dec-Arc tracking was designed for the best unguided performance for imaging.

> 2. I understand that models improve like Sqrt[N], where N is the number of points on the sky input to the model.  It
> is nice that in APCC the number of points is unlimited but presumably that would take unlimited time to do.
> Which might make perfect sense for an All-Sky model for a permanent pier - why not run the model making for
> hours when you first install.   But I am nomadic and typically go to a location for several days to a week of imaging
> (someplace in the desert). 

You can create a localized Dec-Arc model with equal density (square degrees per point) as a larger All-Sky model. This will take much less time. And, it will be more accurate than an All-Sky model as the model created is not a small All-Sky model consisting of points along a Dec path, like what happens with most other manufacturers' mounts

> Also, Dec-Arc models would seem to me to be disposable in the sense that once you
> have done an object you might not return to it for a while, so you might as well make Dec-Arc models for session
> (but see below). What are reasonable numbers of points for All-Sky for general pointing?   What is a reasonable
> number of points for Dec-Arc for astrophotography?  In case it matters, I will use a Planewave DR 350 with QHY
> 600M.  Focal length is 1050mm, pixel size is 3.76 microns, so 0.74 arcsec/pixel.

I don't know anything about that telescope, so you'll have to experiment. I would start with a spacing of 3-5 degrees in RA and Dec for Sky pointst.

> 4. I am guessing that making a model takes 15-30 minutes or so (based on 10micron experience), and that Dec-
> Arc would be similar.  Most likely this is some fixed time plus some time per point for slewing, photographing, plate
> solving etc.   What is it typically for the recommended number of points?    If there is limited time, it seems like your
> call would be to spend more time on adding points to the Dec-Arc model than to the All-Sky model.  One could
> even skip All Sky and use the point solve and correct after slew feature in NINA or other software.

You can start gathering points before the sky is fully dark, so you won't lose much imaging time. If you can leave your setup undisturbed you may be able to do a dense full sky model the first night and later save time by not having to do individual Dec Arc runs.

> 5. The Sqrt[N] improvement assumes that the model has parameters that can account for systematic effects like
> flexure. 

It's also about the accuracy of plate solves. If you haven't tried experimenting with plate solving the same images with different plate solvers, you might want to try it. There is usually some discrepancy between solutions of the various plate solvers (up to +/- 1-2 arc-secs). This is mostly irrelevant for pointing correction but every arc-second matters for accurate tracking rate correction.

> In the 10micron world there are lots of stories of somebody trying to get a good model, and being
> frustrated until they took their rig apart and found one screw loose somewhere.   Obviously, a model can't account
> for random variations, but it potentially could take anything repeatable - which includes a lot of examples of
> flexure. 

APPM has a "5x Verify" model option which does five(5) mapping runs in a row. The results can be used to determine if the mount has any pointing randomness.

> However, at some point you can't make the model have too many parameters because there will be a
> model fitting problem.   Also, I would imagine that the Dec-Arc model would be better able to do this than an All-
> Sky model.  I think that is what you mean by "all possible idiosyncrasies" - you can use a richer set of models
> (more parameters) without danger of overfitting - is that correct?

No, not really. There are multiple reasons, but I can give you one example. Typical pointing terms model telescope flexure as if the telescope is a perfect homogenous cylinder made of one material. That may not be very close to reality.

> 6.  In the 10micron world people brag about the accuracy (RMS) of their model, but that number is generated
> during model building, so it is only modeling accuracy - i.e. how well the model can fit the observed data -
> basically it is a goodness-of-fit metric.  It is not actual tracking accuracy.  I have tested that in cases where I did
> many subs, and then after the fact plate solved them.  Obviously, real tracking errors are greater than the modeling
> errors. I presume you have checked this.

I've performed many hundreds of hours of testing and refining Dec-Arc tracking. Since it is easy to switch between Dec-Arc and All-Sky tracking while running, I can say that I can almost always take longer unguided images without detectable star elongation using Dec Arc tracking. When All-Sky "wins" that contest it's usually because the nearest Dec arc had less than five (5) sky points, or there was a random outlier.

> 7.  It is possible to save Dec-Arc models as files of some sort? 

All of the Sky Map point data in each APPM run is stored in a plain text file. The actual models are created in memory after loading the sky mapping data. This allows testing of new models with existing data points.

 > A frequent scenario - at least for me, is that across
> a week or so of imaging I might work on several DSO in the same night, and then return to them the next night.
> This is because they rise at different times, so they have different optimum imaging periods based on their
> altitude.  Also, if the moon rises you can take narrowband subs, while LRGB is better done without the moon.   So,
> if I had 2-4 objects to visit per night, with a different Dec-Arc model for each one, I could return to it the next night
> without making new models.  There would of course be some small changes in position due to Earth position
> relative to the sun, but day-to-day my guess is that is a big deal.

Internally the models work with hour angle and declination, so they can be reloaded and will work later, provided the mount and scope setup remain undisturbed.

> The next couple questions are quite ambitious and likely would require changes to APCC - and might not even be
> worthwhile.  Please forgive my curiosity.
>
> 8.  In Dec-Arc tracking it ought to be possible to use the actual astrophotos that you take to refine the model as it
> goes.   The simplest thing would be if you were photographing the same DSO night after night you could use last
> nights plate solved photos to refine the model for the next night.  I think to do this you would need a way to record
> the internal encoder readings for each photo.  In principle NINA or other software could (with suitable
> modification) put the encoder readings in the FITS header.  This probably does not happen at present, but if that
> were added to the NINA interface for AP mounts that might help model building.

It's an interesting idea, but I'm not sure that would help. I think tracking rate accuracy is currently limited by the accuracy of the plate solves.

> 9.  But, to get even more ambitious, in principle this could happen in parallel with taking the pictures.   In fact, you
> could think of this as being a bridge between the closed-loop guiding approach and the model-building approach.
> Pure guiding - like PHD2 etc - takes photos in real time and quickly makes a decision to correct problems in object
> tracking.   It is limited by the fact that it has to be quick or else the error gets too large, but at the same time the
> corrections can't be too abrupt, or you cause more problems than you fix.  This is the reason for the various
> parameters you need to set in PHD2.   Continual improvement to a Dec-Arc model would take more processing
> time than the simple corrections for PHD2, but in most astrophotography cases you have minutes per exposure to
> update the model.   Rather than abrupt changes to get the mount pointing where it should, this would very
> gradually refine the tracking model.   Of course, this might not be necessary for a decent initial Dec-Arc model, but
> I am curious as to what you think.

One experimental feature of APCC Pro I have worked on is monitoring the RA/Dec trends from autoguider moves, which have to go through APCC, and adjust RA and Dec tracking rates. The goal is to minimizing autoguider moves. It has some potential problems though, like differentiating between a dithering move and a real autoguider move. To do that for all autoguiding programs probably would require a standardized API.

> 10.  Another out there question.  I assume it would be possible to do the model making adaptively - for example in
> Dec-Arc modeling if there were modeling errors in some portion of the arc then when the model is made it could
> notice and call for more points in those areas. 

There shouldn't be those type of errors unless there is significant randomness in the system. And if that is the case then redoing "bad" points might not help. And you can easily filter outliers in a model with APCC, or any sky point simply by unchecking it in the list in APCC's Pointing model window.

BTW, I have many ideas for future builds of APPM and APCC modeling, but those may take some time to get approved and implemented.


-Ray








 

Hi Greg

>>>1) What is the best practice re dithering while running an APPM model (all sky or dec arc)

you can dither as you normally would, sky modeling does not impact that

>>>2) Would it pay to make a smaller all-sky model and just guide? (in the case if I don't get time to plan an object, because of the random nature of doing a night's session, create an advanced sequence and Dec-Arc model)

You could do that, but I feel like you are throwing away a better approach, which is building and using a more detailed dec-arc model. Guiding is always a "last ditch effort" to me. Modern guiding (PHD2) is astonishingly good, but is always reactive. A good model is proactive


Brian

On Sat, Jul 2, 2022 at 7:20 PM Greg McCall <emailgregnow@...> wrote:
Thanks, Ray for all the detail and history with the mount modelling. 
In reference to use with guiding, it reminds me of a related question with dithering.

I'm portable (drive to a location and set up for the night)  with a Mach2. I've tried with a small model only (I think about 92 points) as well as a model with PHD2 guiding.
The PHD2 was more to see what RMS value it would report with a small model and to let PHD2 do the dithering. (I've tried no dithering, direct within NINA and PHD2)
I've not yet tried the advanced sequencer yet needed for the Dec-Arc in NINA (soon if we can get clear skies with all our wet weather for the last few years on the east coast of Australia)

So the related question:
1) What is the best practice re dithering while running an APPM model (all sky or dec arc)
2) Would it pay to make a smaller all-sky model and just guide? (in the case if I don't get time to plan an object, because of the random nature of doing a night's session, create an advanced sequence and Dec-Arc model)

Greg


On Sun, Jul 3, 2022 at 11:14 AM Nathan Myhrvold <nathanm@...> wrote:
Thanks so much for the answers!

What I meant by "championed" is that unguided mode seems to be emphasized as one of the primary selling points of the mount and as a result it seems that a high fraction of 10micron users seem to use it.   

It is certainly possible to guide a 10micron with PHD2 or similar, but I think it would be considered a little odd in that community - like buying a convertible car and never intending to put the top down.

My impression of AP is that it has a much broader reputation for being high quality, and many people buy it explicitly to use guided. Eve if it has the best unguided mode. 

But maybe I am wrong on both counts!  

But please be assured that I meant no disrespect to AP or APCC!  I take your point about the historical record.  I think professional telescopes went unguided long before amateur telescopes did, in part because really big telescopes (post Palomar) tend to have mount issues and may even be alt az.

Nathan

Nathan
Going mobile

From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Ray Gralak via groups.io <iogroups=siriusimaging.com@groups.io>
Sent: Saturday, July 2, 2022 4:30:58 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: [EXTERNAL] Re: [ap-gto] Questions about All Sky and Dec-Arc models in APCC
 
Hi Nathan,

In your CN post, you mentioned that unguided imaging from a pointing model has been championed by 10micron. I would just like to point out that APPM predates all of the "modeling" software programs for 10micron mounts that use plate solving.  And well before APPM, Software Bisque had TPoint, which was used in some Paramount setups for unguided imaging (two decades ago) without the benefit of encoders!

> 1.  I take it from your post that you recommend Dec-Arc tracking for astrophotography.  Which makes sense - if I
> am going to photograph an object with many subs, potentially for hours, why not get the best possible tracking for
> that object?

Yes, Dec-Arc tracking was designed for the best unguided performance for imaging.

> 2. I understand that models improve like Sqrt[N], where N is the number of points on the sky input to the model.  It
> is nice that in APCC the number of points is unlimited but presumably that would take unlimited time to do.
> Which might make perfect sense for an All-Sky model for a permanent pier - why not run the model making for
> hours when you first install.   But I am nomadic and typically go to a location for several days to a week of imaging
> (someplace in the desert). 

You can create a localized Dec-Arc model with equal density (square degrees per point) as a larger All-Sky model. This will take much less time. And, it will be more accurate than an All-Sky model as the model created is not a small All-Sky model consisting of points along a Dec path, like what happens with most other manufacturers' mounts

> Also, Dec-Arc models would seem to me to be disposable in the sense that once you
> have done an object you might not return to it for a while, so you might as well make Dec-Arc models for session
> (but see below). What are reasonable numbers of points for All-Sky for general pointing?   What is a reasonable
> number of points for Dec-Arc for astrophotography?  In case it matters, I will use a Planewave DR 350 with QHY
> 600M.  Focal length is 1050mm, pixel size is 3.76 microns, so 0.74 arcsec/pixel.

I don't know anything about that telescope, so you'll have to experiment. I would start with a spacing of 3-5 degrees in RA and Dec for Sky pointst.

> 4. I am guessing that making a model takes 15-30 minutes or so (based on 10micron experience), and that Dec-
> Arc would be similar.  Most likely this is some fixed time plus some time per point for slewing, photographing, plate
> solving etc.   What is it typically for the recommended number of points?    If there is limited time, it seems like your
> call would be to spend more time on adding points to the Dec-Arc model than to the All-Sky model.  One could
> even skip All Sky and use the point solve and correct after slew feature in NINA or other software.

You can start gathering points before the sky is fully dark, so you won't lose much imaging time. If you can leave your setup undisturbed you may be able to do a dense full sky model the first night and later save time by not having to do individual Dec Arc runs.

> 5. The Sqrt[N] improvement assumes that the model has parameters that can account for systematic effects like
> flexure. 

It's also about the accuracy of plate solves. If you haven't tried experimenting with plate solving the same images with different plate solvers, you might want to try it. There is usually some discrepancy between solutions of the various plate solvers (up to +/- 1-2 arc-secs). This is mostly irrelevant for pointing correction but every arc-second matters for accurate tracking rate correction.

> In the 10micron world there are lots of stories of somebody trying to get a good model, and being
> frustrated until they took their rig apart and found one screw loose somewhere.   Obviously, a model can't account
> for random variations, but it potentially could take anything repeatable - which includes a lot of examples of
> flexure. 

APPM has a "5x Verify" model option which does five(5) mapping runs in a row. The results can be used to determine if the mount has any pointing randomness.

> However, at some point you can't make the model have too many parameters because there will be a
> model fitting problem.   Also, I would imagine that the Dec-Arc model would be better able to do this than an All-
> Sky model.  I think that is what you mean by "all possible idiosyncrasies" - you can use a richer set of models
> (more parameters) without danger of overfitting - is that correct?

No, not really. There are multiple reasons, but I can give you one example. Typical pointing terms model telescope flexure as if the telescope is a perfect homogenous cylinder made of one material. That may not be very close to reality.

> 6.  In the 10micron world people brag about the accuracy (RMS) of their model, but that number is generated
> during model building, so it is only modeling accuracy - i.e. how well the model can fit the observed data -
> basically it is a goodness-of-fit metric.  It is not actual tracking accuracy.  I have tested that in cases where I did
> many subs, and then after the fact plate solved them.  Obviously, real tracking errors are greater than the modeling
> errors. I presume you have checked this.

I've performed many hundreds of hours of testing and refining Dec-Arc tracking. Since it is easy to switch between Dec-Arc and All-Sky tracking while running, I can say that I can almost always take longer unguided images without detectable star elongation using Dec Arc tracking. When All-Sky "wins" that contest it's usually because the nearest Dec arc had less than five (5) sky points, or there was a random outlier.

> 7.  It is possible to save Dec-Arc models as files of some sort? 

All of the Sky Map point data in each APPM run is stored in a plain text file. The actual models are created in memory after loading the sky mapping data. This allows testing of new models with existing data points.

 > A frequent scenario - at least for me, is that across
> a week or so of imaging I might work on several DSO in the same night, and then return to them the next night.
> This is because they rise at different times, so they have different optimum imaging periods based on their
> altitude.  Also, if the moon rises you can take narrowband subs, while LRGB is better done without the moon.   So,
> if I had 2-4 objects to visit per night, with a different Dec-Arc model for each one, I could return to it the next night
> without making new models.  There would of course be some small changes in position due to Earth position
> relative to the sun, but day-to-day my guess is that is a big deal.

Internally the models work with hour angle and declination, so they can be reloaded and will work later, provided the mount and scope setup remain undisturbed.

> The next couple questions are quite ambitious and likely would require changes to APCC - and might not even be
> worthwhile.  Please forgive my curiosity.
>
> 8.  In Dec-Arc tracking it ought to be possible to use the actual astrophotos that you take to refine the model as it
> goes.   The simplest thing would be if you were photographing the same DSO night after night you could use last
> nights plate solved photos to refine the model for the next night.  I think to do this you would need a way to record
> the internal encoder readings for each photo.  In principle NINA or other software could (with suitable
> modification) put the encoder readings in the FITS header.  This probably does not happen at present, but if that
> were added to the NINA interface for AP mounts that might help model building.

It's an interesting idea, but I'm not sure that would help. I think tracking rate accuracy is currently limited by the accuracy of the plate solves.

> 9.  But, to get even more ambitious, in principle this could happen in parallel with taking the pictures.   In fact, you
> could think of this as being a bridge between the closed-loop guiding approach and the model-building approach.
> Pure guiding - like PHD2 etc - takes photos in real time and quickly makes a decision to correct problems in object
> tracking.   It is limited by the fact that it has to be quick or else the error gets too large, but at the same time the
> corrections can't be too abrupt, or you cause more problems than you fix.  This is the reason for the various
> parameters you need to set in PHD2.   Continual improvement to a Dec-Arc model would take more processing
> time than the simple corrections for PHD2, but in most astrophotography cases you have minutes per exposure to
> update the model.   Rather than abrupt changes to get the mount pointing where it should, this would very
> gradually refine the tracking model.   Of course, this might not be necessary for a decent initial Dec-Arc model, but
> I am curious as to what you think.

One experimental feature of APCC Pro I have worked on is monitoring the RA/Dec trends from autoguider moves, which have to go through APCC, and adjust RA and Dec tracking rates. The goal is to minimizing autoguider moves. It has some potential problems though, like differentiating between a dithering move and a real autoguider move. To do that for all autoguiding programs probably would require a standardized API.

> 10.  Another out there question.  I assume it would be possible to do the model making adaptively - for example in
> Dec-Arc modeling if there were modeling errors in some portion of the arc then when the model is made it could
> notice and call for more points in those areas. 

There shouldn't be those type of errors unless there is significant randomness in the system. And if that is the case then redoing "bad" points might not help. And you can easily filter outliers in a model with APCC, or any sky point simply by unchecking it in the list in APCC's Pointing model window.

BTW, I have many ideas for future builds of APPM and APCC modeling, but those may take some time to get approved and implemented.


-Ray










Greg McCall
 

thanks Brian
Re PHD2, I thought it would do the dithering and the guiding (and RMS reporting) is more a side benefit. 
I was guessing that PHD2 was better at dithering rather than the built-in (direct guiding) dithering in NINA but perhaps I should just rely on built-in dithering.
If I don't use PHD2 RMS calculation during guiding, is there another method of getting a feel of how good the tracking is doing so perhaps I could model more or fewer points in the sky next time?  

On Sun, Jul 3, 2022 at 12:53 PM Brian Valente <bvalente@...> wrote:
Hi Greg

>>>1) What is the best practice re dithering while running an APPM model (all sky or dec arc)

you can dither as you normally would, sky modeling does not impact that

>>>2) Would it pay to make a smaller all-sky model and just guide? (in the case if I don't get time to plan an object, because of the random nature of doing a night's session, create an advanced sequence and Dec-Arc model)

You could do that, but I feel like you are throwing away a better approach, which is building and using a more detailed dec-arc model. Guiding is always a "last ditch effort" to me. Modern guiding (PHD2) is astonishingly good, but is always reactive. A good model is proactive


Brian

On Sat, Jul 2, 2022 at 7:20 PM Greg McCall <emailgregnow@...> wrote:
Thanks, Ray for all the detail and history with the mount modelling. 
In reference to use with guiding, it reminds me of a related question with dithering.

I'm portable (drive to a location and set up for the night)  with a Mach2. I've tried with a small model only (I think about 92 points) as well as a model with PHD2 guiding.
The PHD2 was more to see what RMS value it would report with a small model and to let PHD2 do the dithering. (I've tried no dithering, direct within NINA and PHD2)
I've not yet tried the advanced sequencer yet needed for the Dec-Arc in NINA (soon if we can get clear skies with all our wet weather for the last few years on the east coast of Australia)

So the related question:
1) What is the best practice re dithering while running an APPM model (all sky or dec arc)
2) Would it pay to make a smaller all-sky model and just guide? (in the case if I don't get time to plan an object, because of the random nature of doing a night's session, create an advanced sequence and Dec-Arc model)

Greg


On Sun, Jul 3, 2022 at 11:14 AM Nathan Myhrvold <nathanm@...> wrote:
Thanks so much for the answers!

What I meant by "championed" is that unguided mode seems to be emphasized as one of the primary selling points of the mount and as a result it seems that a high fraction of 10micron users seem to use it.   

It is certainly possible to guide a 10micron with PHD2 or similar, but I think it would be considered a little odd in that community - like buying a convertible car and never intending to put the top down.

My impression of AP is that it has a much broader reputation for being high quality, and many people buy it explicitly to use guided. Eve if it has the best unguided mode. 

But maybe I am wrong on both counts!  

But please be assured that I meant no disrespect to AP or APCC!  I take your point about the historical record.  I think professional telescopes went unguided long before amateur telescopes did, in part because really big telescopes (post Palomar) tend to have mount issues and may even be alt az.

Nathan

Nathan
Going mobile

From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Ray Gralak via groups.io <iogroups=siriusimaging.com@groups.io>
Sent: Saturday, July 2, 2022 4:30:58 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: [EXTERNAL] Re: [ap-gto] Questions about All Sky and Dec-Arc models in APCC
 
Hi Nathan,

In your CN post, you mentioned that unguided imaging from a pointing model has been championed by 10micron. I would just like to point out that APPM predates all of the "modeling" software programs for 10micron mounts that use plate solving.  And well before APPM, Software Bisque had TPoint, which was used in some Paramount setups for unguided imaging (two decades ago) without the benefit of encoders!

> 1.  I take it from your post that you recommend Dec-Arc tracking for astrophotography.  Which makes sense - if I
> am going to photograph an object with many subs, potentially for hours, why not get the best possible tracking for
> that object?

Yes, Dec-Arc tracking was designed for the best unguided performance for imaging.

> 2. I understand that models improve like Sqrt[N], where N is the number of points on the sky input to the model.  It
> is nice that in APCC the number of points is unlimited but presumably that would take unlimited time to do.
> Which might make perfect sense for an All-Sky model for a permanent pier - why not run the model making for
> hours when you first install.   But I am nomadic and typically go to a location for several days to a week of imaging
> (someplace in the desert). 

You can create a localized Dec-Arc model with equal density (square degrees per point) as a larger All-Sky model. This will take much less time. And, it will be more accurate than an All-Sky model as the model created is not a small All-Sky model consisting of points along a Dec path, like what happens with most other manufacturers' mounts

> Also, Dec-Arc models would seem to me to be disposable in the sense that once you
> have done an object you might not return to it for a while, so you might as well make Dec-Arc models for session
> (but see below). What are reasonable numbers of points for All-Sky for general pointing?   What is a reasonable
> number of points for Dec-Arc for astrophotography?  In case it matters, I will use a Planewave DR 350 with QHY
> 600M.  Focal length is 1050mm, pixel size is 3.76 microns, so 0.74 arcsec/pixel.

I don't know anything about that telescope, so you'll have to experiment. I would start with a spacing of 3-5 degrees in RA and Dec for Sky pointst.

> 4. I am guessing that making a model takes 15-30 minutes or so (based on 10micron experience), and that Dec-
> Arc would be similar.  Most likely this is some fixed time plus some time per point for slewing, photographing, plate
> solving etc.   What is it typically for the recommended number of points?    If there is limited time, it seems like your
> call would be to spend more time on adding points to the Dec-Arc model than to the All-Sky model.  One could
> even skip All Sky and use the point solve and correct after slew feature in NINA or other software.

You can start gathering points before the sky is fully dark, so you won't lose much imaging time. If you can leave your setup undisturbed you may be able to do a dense full sky model the first night and later save time by not having to do individual Dec Arc runs.

> 5. The Sqrt[N] improvement assumes that the model has parameters that can account for systematic effects like
> flexure. 

It's also about the accuracy of plate solves. If you haven't tried experimenting with plate solving the same images with different plate solvers, you might want to try it. There is usually some discrepancy between solutions of the various plate solvers (up to +/- 1-2 arc-secs). This is mostly irrelevant for pointing correction but every arc-second matters for accurate tracking rate correction.

> In the 10micron world there are lots of stories of somebody trying to get a good model, and being
> frustrated until they took their rig apart and found one screw loose somewhere.   Obviously, a model can't account
> for random variations, but it potentially could take anything repeatable - which includes a lot of examples of
> flexure. 

APPM has a "5x Verify" model option which does five(5) mapping runs in a row. The results can be used to determine if the mount has any pointing randomness.

> However, at some point you can't make the model have too many parameters because there will be a
> model fitting problem.   Also, I would imagine that the Dec-Arc model would be better able to do this than an All-
> Sky model.  I think that is what you mean by "all possible idiosyncrasies" - you can use a richer set of models
> (more parameters) without danger of overfitting - is that correct?

No, not really. There are multiple reasons, but I can give you one example. Typical pointing terms model telescope flexure as if the telescope is a perfect homogenous cylinder made of one material. That may not be very close to reality.

> 6.  In the 10micron world people brag about the accuracy (RMS) of their model, but that number is generated
> during model building, so it is only modeling accuracy - i.e. how well the model can fit the observed data -
> basically it is a goodness-of-fit metric.  It is not actual tracking accuracy.  I have tested that in cases where I did
> many subs, and then after the fact plate solved them.  Obviously, real tracking errors are greater than the modeling
> errors. I presume you have checked this.

I've performed many hundreds of hours of testing and refining Dec-Arc tracking. Since it is easy to switch between Dec-Arc and All-Sky tracking while running, I can say that I can almost always take longer unguided images without detectable star elongation using Dec Arc tracking. When All-Sky "wins" that contest it's usually because the nearest Dec arc had less than five (5) sky points, or there was a random outlier.

> 7.  It is possible to save Dec-Arc models as files of some sort? 

All of the Sky Map point data in each APPM run is stored in a plain text file. The actual models are created in memory after loading the sky mapping data. This allows testing of new models with existing data points.

 > A frequent scenario - at least for me, is that across
> a week or so of imaging I might work on several DSO in the same night, and then return to them the next night.
> This is because they rise at different times, so they have different optimum imaging periods based on their
> altitude.  Also, if the moon rises you can take narrowband subs, while LRGB is better done without the moon.   So,
> if I had 2-4 objects to visit per night, with a different Dec-Arc model for each one, I could return to it the next night
> without making new models.  There would of course be some small changes in position due to Earth position
> relative to the sun, but day-to-day my guess is that is a big deal.

Internally the models work with hour angle and declination, so they can be reloaded and will work later, provided the mount and scope setup remain undisturbed.

> The next couple questions are quite ambitious and likely would require changes to APCC - and might not even be
> worthwhile.  Please forgive my curiosity.
>
> 8.  In Dec-Arc tracking it ought to be possible to use the actual astrophotos that you take to refine the model as it
> goes.   The simplest thing would be if you were photographing the same DSO night after night you could use last
> nights plate solved photos to refine the model for the next night.  I think to do this you would need a way to record
> the internal encoder readings for each photo.  In principle NINA or other software could (with suitable
> modification) put the encoder readings in the FITS header.  This probably does not happen at present, but if that
> were added to the NINA interface for AP mounts that might help model building.

It's an interesting idea, but I'm not sure that would help. I think tracking rate accuracy is currently limited by the accuracy of the plate solves.

> 9.  But, to get even more ambitious, in principle this could happen in parallel with taking the pictures.   In fact, you
> could think of this as being a bridge between the closed-loop guiding approach and the model-building approach.
> Pure guiding - like PHD2 etc - takes photos in real time and quickly makes a decision to correct problems in object
> tracking.   It is limited by the fact that it has to be quick or else the error gets too large, but at the same time the
> corrections can't be too abrupt, or you cause more problems than you fix.  This is the reason for the various
> parameters you need to set in PHD2.   Continual improvement to a Dec-Arc model would take more processing
> time than the simple corrections for PHD2, but in most astrophotography cases you have minutes per exposure to
> update the model.   Rather than abrupt changes to get the mount pointing where it should, this would very
> gradually refine the tracking model.   Of course, this might not be necessary for a decent initial Dec-Arc model, but
> I am curious as to what you think.

One experimental feature of APCC Pro I have worked on is monitoring the RA/Dec trends from autoguider moves, which have to go through APCC, and adjust RA and Dec tracking rates. The goal is to minimizing autoguider moves. It has some potential problems though, like differentiating between a dithering move and a real autoguider move. To do that for all autoguiding programs probably would require a standardized API.

> 10.  Another out there question.  I assume it would be possible to do the model making adaptively - for example in
> Dec-Arc modeling if there were modeling errors in some portion of the arc then when the model is made it could
> notice and call for more points in those areas. 

There shouldn't be those type of errors unless there is significant randomness in the system. And if that is the case then redoing "bad" points might not help. And you can easily filter outliers in a model with APCC, or any sky point simply by unchecking it in the list in APCC's Pointing model window.

BTW, I have many ideas for future builds of APPM and APCC modeling, but those may take some time to get approved and implemented.


-Ray









--


 

Hi Greg

>>>I was guessing that PHD2 was better at dithering rather than the built-in (direct guiding) dithering in NINA but perhaps I should just rely on built-in dithering.

PHD doesn't do dithering itself, that is controlled by the imaging application. I wouldn't say there is a "best" dithering. The only purpose of dithering is to eliminate fixed pattern noise, so as long as it shifts by a pixel or two, the specific algorithm isn't critical imo.

However, there *is* a benefit to direct dithering: there is no settle time or waiting for the RMS to go down. it's just dither and go
 
>>>If I don't use PHD2 RMS calculation during guiding, is there another method of getting a feel of how good the tracking is doing so perhaps I could model more or fewer points in the sky next time?  

I would just look at the HFD/FWHM of your images and evaluate based on that. From my time spent understanding modeling, i think you are best served by a fairly dense dec arc model built around your specific target, and account for specific repeatable issues at that declination (refraction, flexure, etc.). In other words, i wouldn't cheap out on the model building points ;)



On Sat, Jul 2, 2022 at 8:19 PM Greg McCall <emailgregnow@...> wrote:
thanks Brian
Re PHD2, I thought it would do the dithering and the guiding (and RMS reporting) is more a side benefit. 
I was guessing that PHD2 was better at dithering rather than the built-in (direct guiding) dithering in NINA but perhaps I should just rely on built-in dithering.
If I don't use PHD2 RMS calculation during guiding, is there another method of getting a feel of how good the tracking is doing so perhaps I could model more or fewer points in the sky next time?  

On Sun, Jul 3, 2022 at 12:53 PM Brian Valente <bvalente@...> wrote:
Hi Greg

>>>1) What is the best practice re dithering while running an APPM model (all sky or dec arc)

you can dither as you normally would, sky modeling does not impact that

>>>2) Would it pay to make a smaller all-sky model and just guide? (in the case if I don't get time to plan an object, because of the random nature of doing a night's session, create an advanced sequence and Dec-Arc model)

You could do that, but I feel like you are throwing away a better approach, which is building and using a more detailed dec-arc model. Guiding is always a "last ditch effort" to me. Modern guiding (PHD2) is astonishingly good, but is always reactive. A good model is proactive


Brian

On Sat, Jul 2, 2022 at 7:20 PM Greg McCall <emailgregnow@...> wrote:
Thanks, Ray for all the detail and history with the mount modelling. 
In reference to use with guiding, it reminds me of a related question with dithering.

I'm portable (drive to a location and set up for the night)  with a Mach2. I've tried with a small model only (I think about 92 points) as well as a model with PHD2 guiding.
The PHD2 was more to see what RMS value it would report with a small model and to let PHD2 do the dithering. (I've tried no dithering, direct within NINA and PHD2)
I've not yet tried the advanced sequencer yet needed for the Dec-Arc in NINA (soon if we can get clear skies with all our wet weather for the last few years on the east coast of Australia)

So the related question:
1) What is the best practice re dithering while running an APPM model (all sky or dec arc)
2) Would it pay to make a smaller all-sky model and just guide? (in the case if I don't get time to plan an object, because of the random nature of doing a night's session, create an advanced sequence and Dec-Arc model)

Greg


On Sun, Jul 3, 2022 at 11:14 AM Nathan Myhrvold <nathanm@...> wrote:
Thanks so much for the answers!

What I meant by "championed" is that unguided mode seems to be emphasized as one of the primary selling points of the mount and as a result it seems that a high fraction of 10micron users seem to use it.   

It is certainly possible to guide a 10micron with PHD2 or similar, but I think it would be considered a little odd in that community - like buying a convertible car and never intending to put the top down.

My impression of AP is that it has a much broader reputation for being high quality, and many people buy it explicitly to use guided. Eve if it has the best unguided mode. 

But maybe I am wrong on both counts!  

But please be assured that I meant no disrespect to AP or APCC!  I take your point about the historical record.  I think professional telescopes went unguided long before amateur telescopes did, in part because really big telescopes (post Palomar) tend to have mount issues and may even be alt az.

Nathan

Nathan
Going mobile

From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Ray Gralak via groups.io <iogroups=siriusimaging.com@groups.io>
Sent: Saturday, July 2, 2022 4:30:58 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: [EXTERNAL] Re: [ap-gto] Questions about All Sky and Dec-Arc models in APCC
 
Hi Nathan,

In your CN post, you mentioned that unguided imaging from a pointing model has been championed by 10micron. I would just like to point out that APPM predates all of the "modeling" software programs for 10micron mounts that use plate solving.  And well before APPM, Software Bisque had TPoint, which was used in some Paramount setups for unguided imaging (two decades ago) without the benefit of encoders!

> 1.  I take it from your post that you recommend Dec-Arc tracking for astrophotography.  Which makes sense - if I
> am going to photograph an object with many subs, potentially for hours, why not get the best possible tracking for
> that object?

Yes, Dec-Arc tracking was designed for the best unguided performance for imaging.

> 2. I understand that models improve like Sqrt[N], where N is the number of points on the sky input to the model.  It
> is nice that in APCC the number of points is unlimited but presumably that would take unlimited time to do.
> Which might make perfect sense for an All-Sky model for a permanent pier - why not run the model making for
> hours when you first install.   But I am nomadic and typically go to a location for several days to a week of imaging
> (someplace in the desert). 

You can create a localized Dec-Arc model with equal density (square degrees per point) as a larger All-Sky model. This will take much less time. And, it will be more accurate than an All-Sky model as the model created is not a small All-Sky model consisting of points along a Dec path, like what happens with most other manufacturers' mounts

> Also, Dec-Arc models would seem to me to be disposable in the sense that once you
> have done an object you might not return to it for a while, so you might as well make Dec-Arc models for session
> (but see below). What are reasonable numbers of points for All-Sky for general pointing?   What is a reasonable
> number of points for Dec-Arc for astrophotography?  In case it matters, I will use a Planewave DR 350 with QHY
> 600M.  Focal length is 1050mm, pixel size is 3.76 microns, so 0.74 arcsec/pixel.

I don't know anything about that telescope, so you'll have to experiment. I would start with a spacing of 3-5 degrees in RA and Dec for Sky pointst.

> 4. I am guessing that making a model takes 15-30 minutes or so (based on 10micron experience), and that Dec-
> Arc would be similar.  Most likely this is some fixed time plus some time per point for slewing, photographing, plate
> solving etc.   What is it typically for the recommended number of points?    If there is limited time, it seems like your
> call would be to spend more time on adding points to the Dec-Arc model than to the All-Sky model.  One could
> even skip All Sky and use the point solve and correct after slew feature in NINA or other software.

You can start gathering points before the sky is fully dark, so you won't lose much imaging time. If you can leave your setup undisturbed you may be able to do a dense full sky model the first night and later save time by not having to do individual Dec Arc runs.

> 5. The Sqrt[N] improvement assumes that the model has parameters that can account for systematic effects like
> flexure. 

It's also about the accuracy of plate solves. If you haven't tried experimenting with plate solving the same images with different plate solvers, you might want to try it. There is usually some discrepancy between solutions of the various plate solvers (up to +/- 1-2 arc-secs). This is mostly irrelevant for pointing correction but every arc-second matters for accurate tracking rate correction.

> In the 10micron world there are lots of stories of somebody trying to get a good model, and being
> frustrated until they took their rig apart and found one screw loose somewhere.   Obviously, a model can't account
> for random variations, but it potentially could take anything repeatable - which includes a lot of examples of
> flexure. 

APPM has a "5x Verify" model option which does five(5) mapping runs in a row. The results can be used to determine if the mount has any pointing randomness.

> However, at some point you can't make the model have too many parameters because there will be a
> model fitting problem.   Also, I would imagine that the Dec-Arc model would be better able to do this than an All-
> Sky model.  I think that is what you mean by "all possible idiosyncrasies" - you can use a richer set of models
> (more parameters) without danger of overfitting - is that correct?

No, not really. There are multiple reasons, but I can give you one example. Typical pointing terms model telescope flexure as if the telescope is a perfect homogenous cylinder made of one material. That may not be very close to reality.

> 6.  In the 10micron world people brag about the accuracy (RMS) of their model, but that number is generated
> during model building, so it is only modeling accuracy - i.e. how well the model can fit the observed data -
> basically it is a goodness-of-fit metric.  It is not actual tracking accuracy.  I have tested that in cases where I did
> many subs, and then after the fact plate solved them.  Obviously, real tracking errors are greater than the modeling
> errors. I presume you have checked this.

I've performed many hundreds of hours of testing and refining Dec-Arc tracking. Since it is easy to switch between Dec-Arc and All-Sky tracking while running, I can say that I can almost always take longer unguided images without detectable star elongation using Dec Arc tracking. When All-Sky "wins" that contest it's usually because the nearest Dec arc had less than five (5) sky points, or there was a random outlier.

> 7.  It is possible to save Dec-Arc models as files of some sort? 

All of the Sky Map point data in each APPM run is stored in a plain text file. The actual models are created in memory after loading the sky mapping data. This allows testing of new models with existing data points.

 > A frequent scenario - at least for me, is that across
> a week or so of imaging I might work on several DSO in the same night, and then return to them the next night.
> This is because they rise at different times, so they have different optimum imaging periods based on their
> altitude.  Also, if the moon rises you can take narrowband subs, while LRGB is better done without the moon.   So,
> if I had 2-4 objects to visit per night, with a different Dec-Arc model for each one, I could return to it the next night
> without making new models.  There would of course be some small changes in position due to Earth position
> relative to the sun, but day-to-day my guess is that is a big deal.

Internally the models work with hour angle and declination, so they can be reloaded and will work later, provided the mount and scope setup remain undisturbed.

> The next couple questions are quite ambitious and likely would require changes to APCC - and might not even be
> worthwhile.  Please forgive my curiosity.
>
> 8.  In Dec-Arc tracking it ought to be possible to use the actual astrophotos that you take to refine the model as it
> goes.   The simplest thing would be if you were photographing the same DSO night after night you could use last
> nights plate solved photos to refine the model for the next night.  I think to do this you would need a way to record
> the internal encoder readings for each photo.  In principle NINA or other software could (with suitable
> modification) put the encoder readings in the FITS header.  This probably does not happen at present, but if that
> were added to the NINA interface for AP mounts that might help model building.

It's an interesting idea, but I'm not sure that would help. I think tracking rate accuracy is currently limited by the accuracy of the plate solves.

> 9.  But, to get even more ambitious, in principle this could happen in parallel with taking the pictures.   In fact, you
> could think of this as being a bridge between the closed-loop guiding approach and the model-building approach.
> Pure guiding - like PHD2 etc - takes photos in real time and quickly makes a decision to correct problems in object
> tracking.   It is limited by the fact that it has to be quick or else the error gets too large, but at the same time the
> corrections can't be too abrupt, or you cause more problems than you fix.  This is the reason for the various
> parameters you need to set in PHD2.   Continual improvement to a Dec-Arc model would take more processing
> time than the simple corrections for PHD2, but in most astrophotography cases you have minutes per exposure to
> update the model.   Rather than abrupt changes to get the mount pointing where it should, this would very
> gradually refine the tracking model.   Of course, this might not be necessary for a decent initial Dec-Arc model, but
> I am curious as to what you think.

One experimental feature of APCC Pro I have worked on is monitoring the RA/Dec trends from autoguider moves, which have to go through APCC, and adjust RA and Dec tracking rates. The goal is to minimizing autoguider moves. It has some potential problems though, like differentiating between a dithering move and a real autoguider move. To do that for all autoguiding programs probably would require a standardized API.

> 10.  Another out there question.  I assume it would be possible to do the model making adaptively - for example in
> Dec-Arc modeling if there were modeling errors in some portion of the arc then when the model is made it could
> notice and call for more points in those areas. 

There shouldn't be those type of errors unless there is significant randomness in the system. And if that is the case then redoing "bad" points might not help. And you can easily filter outliers in a model with APCC, or any sky point simply by unchecking it in the list in APCC's Pointing model window.

BTW, I have many ideas for future builds of APPM and APCC modeling, but those may take some time to get approved and implemented.


-Ray









--




Greg McCall
 

thanks, Brian, sounds like a good plan.


On Sun, Jul 3, 2022 at 2:05 PM Brian Valente <bvalente@...> wrote:
Hi Greg

>>>I was guessing that PHD2 was better at dithering rather than the built-in (direct guiding) dithering in NINA but perhaps I should just rely on built-in dithering.

PHD doesn't do dithering itself, that is controlled by the imaging application. I wouldn't say there is a "best" dithering. The only purpose of dithering is to eliminate fixed pattern noise, so as long as it shifts by a pixel or two, the specific algorithm isn't critical imo.

However, there *is* a benefit to direct dithering: there is no settle time or waiting for the RMS to go down. it's just dither and go
 
>>>If I don't use PHD2 RMS calculation during guiding, is there another method of getting a feel of how good the tracking is doing so perhaps I could model more or fewer points in the sky next time?  

I would just look at the HFD/FWHM of your images and evaluate based on that. From my time spent understanding modeling, i think you are best served by a fairly dense dec arc model built around your specific target, and account for specific repeatable issues at that declination (refraction, flexure, etc.). In other words, i wouldn't cheap out on the model building points ;)



On Sat, Jul 2, 2022 at 8:19 PM Greg McCall <emailgregnow@...> wrote:
thanks Brian
Re PHD2, I thought it would do the dithering and the guiding (and RMS reporting) is more a side benefit. 
I was guessing that PHD2 was better at dithering rather than the built-in (direct guiding) dithering in NINA but perhaps I should just rely on built-in dithering.
If I don't use PHD2 RMS calculation during guiding, is there another method of getting a feel of how good the tracking is doing so perhaps I could model more or fewer points in the sky next time?  

On Sun, Jul 3, 2022 at 12:53 PM Brian Valente <bvalente@...> wrote:
Hi Greg

>>>1) What is the best practice re dithering while running an APPM model (all sky or dec arc)

you can dither as you normally would, sky modeling does not impact that

>>>2) Would it pay to make a smaller all-sky model and just guide? (in the case if I don't get time to plan an object, because of the random nature of doing a night's session, create an advanced sequence and Dec-Arc model)

You could do that, but I feel like you are throwing away a better approach, which is building and using a more detailed dec-arc model. Guiding is always a "last ditch effort" to me. Modern guiding (PHD2) is astonishingly good, but is always reactive. A good model is proactive


Brian

On Sat, Jul 2, 2022 at 7:20 PM Greg McCall <emailgregnow@...> wrote:
Thanks, Ray for all the detail and history with the mount modelling. 
In reference to use with guiding, it reminds me of a related question with dithering.

I'm portable (drive to a location and set up for the night)  with a Mach2. I've tried with a small model only (I think about 92 points) as well as a model with PHD2 guiding.
The PHD2 was more to see what RMS value it would report with a small model and to let PHD2 do the dithering. (I've tried no dithering, direct within NINA and PHD2)
I've not yet tried the advanced sequencer yet needed for the Dec-Arc in NINA (soon if we can get clear skies with all our wet weather for the last few years on the east coast of Australia)

So the related question:
1) What is the best practice re dithering while running an APPM model (all sky or dec arc)
2) Would it pay to make a smaller all-sky model and just guide? (in the case if I don't get time to plan an object, because of the random nature of doing a night's session, create an advanced sequence and Dec-Arc model)

Greg


On Sun, Jul 3, 2022 at 11:14 AM Nathan Myhrvold <nathanm@...> wrote:
Thanks so much for the answers!

What I meant by "championed" is that unguided mode seems to be emphasized as one of the primary selling points of the mount and as a result it seems that a high fraction of 10micron users seem to use it.   

It is certainly possible to guide a 10micron with PHD2 or similar, but I think it would be considered a little odd in that community - like buying a convertible car and never intending to put the top down.

My impression of AP is that it has a much broader reputation for being high quality, and many people buy it explicitly to use guided. Eve if it has the best unguided mode. 

But maybe I am wrong on both counts!  

But please be assured that I meant no disrespect to AP or APCC!  I take your point about the historical record.  I think professional telescopes went unguided long before amateur telescopes did, in part because really big telescopes (post Palomar) tend to have mount issues and may even be alt az.

Nathan

Nathan
Going mobile

From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Ray Gralak via groups.io <iogroups=siriusimaging.com@groups.io>
Sent: Saturday, July 2, 2022 4:30:58 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: [EXTERNAL] Re: [ap-gto] Questions about All Sky and Dec-Arc models in APCC
 
Hi Nathan,

In your CN post, you mentioned that unguided imaging from a pointing model has been championed by 10micron. I would just like to point out that APPM predates all of the "modeling" software programs for 10micron mounts that use plate solving.  And well before APPM, Software Bisque had TPoint, which was used in some Paramount setups for unguided imaging (two decades ago) without the benefit of encoders!

> 1.  I take it from your post that you recommend Dec-Arc tracking for astrophotography.  Which makes sense - if I
> am going to photograph an object with many subs, potentially for hours, why not get the best possible tracking for
> that object?

Yes, Dec-Arc tracking was designed for the best unguided performance for imaging.

> 2. I understand that models improve like Sqrt[N], where N is the number of points on the sky input to the model.  It
> is nice that in APCC the number of points is unlimited but presumably that would take unlimited time to do.
> Which might make perfect sense for an All-Sky model for a permanent pier - why not run the model making for
> hours when you first install.   But I am nomadic and typically go to a location for several days to a week of imaging
> (someplace in the desert). 

You can create a localized Dec-Arc model with equal density (square degrees per point) as a larger All-Sky model. This will take much less time. And, it will be more accurate than an All-Sky model as the model created is not a small All-Sky model consisting of points along a Dec path, like what happens with most other manufacturers' mounts

> Also, Dec-Arc models would seem to me to be disposable in the sense that once you
> have done an object you might not return to it for a while, so you might as well make Dec-Arc models for session
> (but see below). What are reasonable numbers of points for All-Sky for general pointing?   What is a reasonable
> number of points for Dec-Arc for astrophotography?  In case it matters, I will use a Planewave DR 350 with QHY
> 600M.  Focal length is 1050mm, pixel size is 3.76 microns, so 0.74 arcsec/pixel.

I don't know anything about that telescope, so you'll have to experiment. I would start with a spacing of 3-5 degrees in RA and Dec for Sky pointst.

> 4. I am guessing that making a model takes 15-30 minutes or so (based on 10micron experience), and that Dec-
> Arc would be similar.  Most likely this is some fixed time plus some time per point for slewing, photographing, plate
> solving etc.   What is it typically for the recommended number of points?    If there is limited time, it seems like your
> call would be to spend more time on adding points to the Dec-Arc model than to the All-Sky model.  One could
> even skip All Sky and use the point solve and correct after slew feature in NINA or other software.

You can start gathering points before the sky is fully dark, so you won't lose much imaging time. If you can leave your setup undisturbed you may be able to do a dense full sky model the first night and later save time by not having to do individual Dec Arc runs.

> 5. The Sqrt[N] improvement assumes that the model has parameters that can account for systematic effects like
> flexure. 

It's also about the accuracy of plate solves. If you haven't tried experimenting with plate solving the same images with different plate solvers, you might want to try it. There is usually some discrepancy between solutions of the various plate solvers (up to +/- 1-2 arc-secs). This is mostly irrelevant for pointing correction but every arc-second matters for accurate tracking rate correction.

> In the 10micron world there are lots of stories of somebody trying to get a good model, and being
> frustrated until they took their rig apart and found one screw loose somewhere.   Obviously, a model can't account
> for random variations, but it potentially could take anything repeatable - which includes a lot of examples of
> flexure. 

APPM has a "5x Verify" model option which does five(5) mapping runs in a row. The results can be used to determine if the mount has any pointing randomness.

> However, at some point you can't make the model have too many parameters because there will be a
> model fitting problem.   Also, I would imagine that the Dec-Arc model would be better able to do this than an All-
> Sky model.  I think that is what you mean by "all possible idiosyncrasies" - you can use a richer set of models
> (more parameters) without danger of overfitting - is that correct?

No, not really. There are multiple reasons, but I can give you one example. Typical pointing terms model telescope flexure as if the telescope is a perfect homogenous cylinder made of one material. That may not be very close to reality.

> 6.  In the 10micron world people brag about the accuracy (RMS) of their model, but that number is generated
> during model building, so it is only modeling accuracy - i.e. how well the model can fit the observed data -
> basically it is a goodness-of-fit metric.  It is not actual tracking accuracy.  I have tested that in cases where I did
> many subs, and then after the fact plate solved them.  Obviously, real tracking errors are greater than the modeling
> errors. I presume you have checked this.

I've performed many hundreds of hours of testing and refining Dec-Arc tracking. Since it is easy to switch between Dec-Arc and All-Sky tracking while running, I can say that I can almost always take longer unguided images without detectable star elongation using Dec Arc tracking. When All-Sky "wins" that contest it's usually because the nearest Dec arc had less than five (5) sky points, or there was a random outlier.

> 7.  It is possible to save Dec-Arc models as files of some sort? 

All of the Sky Map point data in each APPM run is stored in a plain text file. The actual models are created in memory after loading the sky mapping data. This allows testing of new models with existing data points.

 > A frequent scenario - at least for me, is that across
> a week or so of imaging I might work on several DSO in the same night, and then return to them the next night.
> This is because they rise at different times, so they have different optimum imaging periods based on their
> altitude.  Also, if the moon rises you can take narrowband subs, while LRGB is better done without the moon.   So,
> if I had 2-4 objects to visit per night, with a different Dec-Arc model for each one, I could return to it the next night
> without making new models.  There would of course be some small changes in position due to Earth position
> relative to the sun, but day-to-day my guess is that is a big deal.

Internally the models work with hour angle and declination, so they can be reloaded and will work later, provided the mount and scope setup remain undisturbed.

> The next couple questions are quite ambitious and likely would require changes to APCC - and might not even be
> worthwhile.  Please forgive my curiosity.
>
> 8.  In Dec-Arc tracking it ought to be possible to use the actual astrophotos that you take to refine the model as it
> goes.   The simplest thing would be if you were photographing the same DSO night after night you could use last
> nights plate solved photos to refine the model for the next night.  I think to do this you would need a way to record
> the internal encoder readings for each photo.  In principle NINA or other software could (with suitable
> modification) put the encoder readings in the FITS header.  This probably does not happen at present, but if that
> were added to the NINA interface for AP mounts that might help model building.

It's an interesting idea, but I'm not sure that would help. I think tracking rate accuracy is currently limited by the accuracy of the plate solves.

> 9.  But, to get even more ambitious, in principle this could happen in parallel with taking the pictures.   In fact, you
> could think of this as being a bridge between the closed-loop guiding approach and the model-building approach.
> Pure guiding - like PHD2 etc - takes photos in real time and quickly makes a decision to correct problems in object
> tracking.   It is limited by the fact that it has to be quick or else the error gets too large, but at the same time the
> corrections can't be too abrupt, or you cause more problems than you fix.  This is the reason for the various
> parameters you need to set in PHD2.   Continual improvement to a Dec-Arc model would take more processing
> time than the simple corrections for PHD2, but in most astrophotography cases you have minutes per exposure to
> update the model.   Rather than abrupt changes to get the mount pointing where it should, this would very
> gradually refine the tracking model.   Of course, this might not be necessary for a decent initial Dec-Arc model, but
> I am curious as to what you think.

One experimental feature of APCC Pro I have worked on is monitoring the RA/Dec trends from autoguider moves, which have to go through APCC, and adjust RA and Dec tracking rates. The goal is to minimizing autoguider moves. It has some potential problems though, like differentiating between a dithering move and a real autoguider move. To do that for all autoguiding programs probably would require a standardized API.

> 10.  Another out there question.  I assume it would be possible to do the model making adaptively - for example in
> Dec-Arc modeling if there were modeling errors in some portion of the arc then when the model is made it could
> notice and call for more points in those areas. 

There shouldn't be those type of errors unless there is significant randomness in the system. And if that is the case then redoing "bad" points might not help. And you can easily filter outliers in a model with APCC, or any sky point simply by unchecking it in the list in APCC's Pointing model window.

BTW, I have many ideas for future builds of APPM and APCC modeling, but those may take some time to get approved and implemented.


-Ray









--



--


Bill Long
 

Here is an example of a Dec Arc model I used the last few nights on Iris Nebula. Probably a little overkill, but the 60-point models have worked nicely for me, and they do not take much time at all to run. You will note that 4 west points did not end up in the model at the end and those were points that were in a tree. �� 







From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Greg McCall <emailgregnow@...>
Sent: Saturday, July 2, 2022 9:46 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Questions about All Sky and Dec-Arc models in APCC
 
thanks, Brian, sounds like a good plan.

On Sun, Jul 3, 2022 at 2:05 PM Brian Valente <bvalente@...> wrote:
Hi Greg

>>>I was guessing that PHD2 was better at dithering rather than the built-in (direct guiding) dithering in NINA but perhaps I should just rely on built-in dithering.

PHD doesn't do dithering itself, that is controlled by the imaging application. I wouldn't say there is a "best" dithering. The only purpose of dithering is to eliminate fixed pattern noise, so as long as it shifts by a pixel or two, the specific algorithm isn't critical imo.

However, there *is* a benefit to direct dithering: there is no settle time or waiting for the RMS to go down. it's just dither and go
 
>>>If I don't use PHD2 RMS calculation during guiding, is there another method of getting a feel of how good the tracking is doing so perhaps I could model more or fewer points in the sky next time?  

I would just look at the HFD/FWHM of your images and evaluate based on that. From my time spent understanding modeling, i think you are best served by a fairly dense dec arc model built around your specific target, and account for specific repeatable issues at that declination (refraction, flexure, etc.). In other words, i wouldn't cheap out on the model building points ;)



On Sat, Jul 2, 2022 at 8:19 PM Greg McCall <emailgregnow@...> wrote:
thanks Brian
Re PHD2, I thought it would do the dithering and the guiding (and RMS reporting) is more a side benefit. 
I was guessing that PHD2 was better at dithering rather than the built-in (direct guiding) dithering in NINA but perhaps I should just rely on built-in dithering.
If I don't use PHD2 RMS calculation during guiding, is there another method of getting a feel of how good the tracking is doing so perhaps I could model more or fewer points in the sky next time?  

On Sun, Jul 3, 2022 at 12:53 PM Brian Valente <bvalente@...> wrote:
Hi Greg

>>>1) What is the best practice re dithering while running an APPM model (all sky or dec arc)

you can dither as you normally would, sky modeling does not impact that

>>>2) Would it pay to make a smaller all-sky model and just guide? (in the case if I don't get time to plan an object, because of the random nature of doing a night's session, create an advanced sequence and Dec-Arc model)

You could do that, but I feel like you are throwing away a better approach, which is building and using a more detailed dec-arc model. Guiding is always a "last ditch effort" to me. Modern guiding (PHD2) is astonishingly good, but is always reactive. A good model is proactive


Brian

On Sat, Jul 2, 2022 at 7:20 PM Greg McCall <emailgregnow@...> wrote:
Thanks, Ray for all the detail and history with the mount modelling. 
In reference to use with guiding, it reminds me of a related question with dithering.

I'm portable (drive to a location and set up for the night)  with a Mach2. I've tried with a small model only (I think about 92 points) as well as a model with PHD2 guiding.
The PHD2 was more to see what RMS value it would report with a small model and to let PHD2 do the dithering. (I've tried no dithering, direct within NINA and PHD2)
I've not yet tried the advanced sequencer yet needed for the Dec-Arc in NINA (soon if we can get clear skies with all our wet weather for the last few years on the east coast of Australia)

So the related question:
1) What is the best practice re dithering while running an APPM model (all sky or dec arc)
2) Would it pay to make a smaller all-sky model and just guide? (in the case if I don't get time to plan an object, because of the random nature of doing a night's session, create an advanced sequence and Dec-Arc model)

Greg


On Sun, Jul 3, 2022 at 11:14 AM Nathan Myhrvold <nathanm@...> wrote:
Thanks so much for the answers!

What I meant by "championed" is that unguided mode seems to be emphasized as one of the primary selling points of the mount and as a result it seems that a high fraction of 10micron users seem to use it.   

It is certainly possible to guide a 10micron with PHD2 or similar, but I think it would be considered a little odd in that community - like buying a convertible car and never intending to put the top down.

My impression of AP is that it has a much broader reputation for being high quality, and many people buy it explicitly to use guided. Eve if it has the best unguided mode. 

But maybe I am wrong on both counts!  

But please be assured that I meant no disrespect to AP or APCC!  I take your point about the historical record.  I think professional telescopes went unguided long before amateur telescopes did, in part because really big telescopes (post Palomar) tend to have mount issues and may even be alt az.

Nathan

Nathan
Going mobile

From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Ray Gralak via groups.io <iogroups=siriusimaging.com@groups.io>
Sent: Saturday, July 2, 2022 4:30:58 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: [EXTERNAL] Re: [ap-gto] Questions about All Sky and Dec-Arc models in APCC
 
Hi Nathan,

In your CN post, you mentioned that unguided imaging from a pointing model has been championed by 10micron. I would just like to point out that APPM predates all of the "modeling" software programs for 10micron mounts that use plate solving.  And well before APPM, Software Bisque had TPoint, which was used in some Paramount setups for unguided imaging (two decades ago) without the benefit of encoders!

> 1.  I take it from your post that you recommend Dec-Arc tracking for astrophotography.  Which makes sense - if I
> am going to photograph an object with many subs, potentially for hours, why not get the best possible tracking for
> that object?

Yes, Dec-Arc tracking was designed for the best unguided performance for imaging.

> 2. I understand that models improve like Sqrt[N], where N is the number of points on the sky input to the model.  It
> is nice that in APCC the number of points is unlimited but presumably that would take unlimited time to do.
> Which might make perfect sense for an All-Sky model for a permanent pier - why not run the model making for
> hours when you first install.   But I am nomadic and typically go to a location for several days to a week of imaging
> (someplace in the desert). 

You can create a localized Dec-Arc model with equal density (square degrees per point) as a larger All-Sky model. This will take much less time. And, it will be more accurate than an All-Sky model as the model created is not a small All-Sky model consisting of points along a Dec path, like what happens with most other manufacturers' mounts

> Also, Dec-Arc models would seem to me to be disposable in the sense that once you
> have done an object you might not return to it for a while, so you might as well make Dec-Arc models for session
> (but see below). What are reasonable numbers of points for All-Sky for general pointing?   What is a reasonable
> number of points for Dec-Arc for astrophotography?  In case it matters, I will use a Planewave DR 350 with QHY
> 600M.  Focal length is 1050mm, pixel size is 3.76 microns, so 0.74 arcsec/pixel.

I don't know anything about that telescope, so you'll have to experiment. I would start with a spacing of 3-5 degrees in RA and Dec for Sky pointst.

> 4. I am guessing that making a model takes 15-30 minutes or so (based on 10micron experience), and that Dec-
> Arc would be similar.  Most likely this is some fixed time plus some time per point for slewing, photographing, plate
> solving etc.   What is it typically for the recommended number of points?    If there is limited time, it seems like your
> call would be to spend more time on adding points to the Dec-Arc model than to the All-Sky model.  One could
> even skip All Sky and use the point solve and correct after slew feature in NINA or other software.

You can start gathering points before the sky is fully dark, so you won't lose much imaging time. If you can leave your setup undisturbed you may be able to do a dense full sky model the first night and later save time by not having to do individual Dec Arc runs.

> 5. The Sqrt[N] improvement assumes that the model has parameters that can account for systematic effects like
> flexure. 

It's also about the accuracy of plate solves. If you haven't tried experimenting with plate solving the same images with different plate solvers, you might want to try it. There is usually some discrepancy between solutions of the various plate solvers (up to +/- 1-2 arc-secs). This is mostly irrelevant for pointing correction but every arc-second matters for accurate tracking rate correction.

> In the 10micron world there are lots of stories of somebody trying to get a good model, and being
> frustrated until they took their rig apart and found one screw loose somewhere.   Obviously, a model can't account
> for random variations, but it potentially could take anything repeatable - which includes a lot of examples of
> flexure. 

APPM has a "5x Verify" model option which does five(5) mapping runs in a row. The results can be used to determine if the mount has any pointing randomness.

> However, at some point you can't make the model have too many parameters because there will be a
> model fitting problem.   Also, I would imagine that the Dec-Arc model would be better able to do this than an All-
> Sky model.  I think that is what you mean by "all possible idiosyncrasies" - you can use a richer set of models
> (more parameters) without danger of overfitting - is that correct?

No, not really. There are multiple reasons, but I can give you one example. Typical pointing terms model telescope flexure as if the telescope is a perfect homogenous cylinder made of one material. That may not be very close to reality.

> 6.  In the 10micron world people brag about the accuracy (RMS) of their model, but that number is generated
> during model building, so it is only modeling accuracy - i.e. how well the model can fit the observed data -
> basically it is a goodness-of-fit metric.  It is not actual tracking accuracy.  I have tested that in cases where I did
> many subs, and then after the fact plate solved them.  Obviously, real tracking errors are greater than the modeling
> errors. I presume you have checked this.

I've performed many hundreds of hours of testing and refining Dec-Arc tracking. Since it is easy to switch between Dec-Arc and All-Sky tracking while running, I can say that I can almost always take longer unguided images without detectable star elongation using Dec Arc tracking. When All-Sky "wins" that contest it's usually because the nearest Dec arc had less than five (5) sky points, or there was a random outlier.

> 7.  It is possible to save Dec-Arc models as files of some sort? 

All of the Sky Map point data in each APPM run is stored in a plain text file. The actual models are created in memory after loading the sky mapping data. This allows testing of new models with existing data points.

 > A frequent scenario - at least for me, is that across
> a week or so of imaging I might work on several DSO in the same night, and then return to them the next night.
> This is because they rise at different times, so they have different optimum imaging periods based on their
> altitude.  Also, if the moon rises you can take narrowband subs, while LRGB is better done without the moon.   So,
> if I had 2-4 objects to visit per night, with a different Dec-Arc model for each one, I could return to it the next night
> without making new models.  There would of course be some small changes in position due to Earth position
> relative to the sun, but day-to-day my guess is that is a big deal.

Internally the models work with hour angle and declination, so they can be reloaded and will work later, provided the mount and scope setup remain undisturbed.

> The next couple questions are quite ambitious and likely would require changes to APCC - and might not even be
> worthwhile.  Please forgive my curiosity.
>
> 8.  In Dec-Arc tracking it ought to be possible to use the actual astrophotos that you take to refine the model as it
> goes.   The simplest thing would be if you were photographing the same DSO night after night you could use last
> nights plate solved photos to refine the model for the next night.  I think to do this you would need a way to record
> the internal encoder readings for each photo.  In principle NINA or other software could (with suitable
> modification) put the encoder readings in the FITS header.  This probably does not happen at present, but if that
> were added to the NINA interface for AP mounts that might help model building.

It's an interesting idea, but I'm not sure that would help. I think tracking rate accuracy is currently limited by the accuracy of the plate solves.

> 9.  But, to get even more ambitious, in principle this could happen in parallel with taking the pictures.   In fact, you
> could think of this as being a bridge between the closed-loop guiding approach and the model-building approach.
> Pure guiding - like PHD2 etc - takes photos in real time and quickly makes a decision to correct problems in object
> tracking.   It is limited by the fact that it has to be quick or else the error gets too large, but at the same time the
> corrections can't be too abrupt, or you cause more problems than you fix.  This is the reason for the various
> parameters you need to set in PHD2.   Continual improvement to a Dec-Arc model would take more processing
> time than the simple corrections for PHD2, but in most astrophotography cases you have minutes per exposure to
> update the model.   Rather than abrupt changes to get the mount pointing where it should, this would very
> gradually refine the tracking model.   Of course, this might not be necessary for a decent initial Dec-Arc model, but
> I am curious as to what you think.

One experimental feature of APCC Pro I have worked on is monitoring the RA/Dec trends from autoguider moves, which have to go through APCC, and adjust RA and Dec tracking rates. The goal is to minimizing autoguider moves. It has some potential problems though, like differentiating between a dithering move and a real autoguider move. To do that for all autoguiding programs probably would require a standardized API.

> 10.  Another out there question.  I assume it would be possible to do the model making adaptively - for example in
> Dec-Arc modeling if there were modeling errors in some portion of the arc then when the model is made it could
> notice and call for more points in those areas. 

There shouldn't be those type of errors unless there is significant randomness in the system. And if that is the case then redoing "bad" points might not help. And you can easily filter outliers in a model with APCC, or any sky point simply by unchecking it in the list in APCC's Pointing model window.

BTW, I have many ideas for future builds of APPM and APCC modeling, but those may take some time to get approved and implemented.


-Ray









--



--


Dean Jacobsen
 
Edited

On Sat, Jul 2, 2022 at 12:55 PM, Nathan Myhrvold wrote:

I am nomadic – I live near Seattle but image in the desert – Arizona, Utah, Nevada or Texas.

 

Nathan

Hi Nathan, as you can see, there are multiple ways you can approach using the APCC/APPM software for tracking rate and pointing correction.  There are also modeling capabilities built into the keypad for the Mach2 which, last I heard, AP was going to implement into the keypad for the CP4/keypad for the 1100 as well.  I don't know if that has been released yet or not.  It is hard to keep track of all of the features and capabilities that AP makes available for its mounts.

Since I am a nomad and set up new for every session [1, 2 or 3 nights in a remote location], I don't bother with "all sky" maps where I use APPM to characterize my setup from horizon to horizon west-to-east and north-to-south.  I always know my object for the night and just have the point mapper measure around the declination of my object.  For instance, if my object is at +24 declination, then I set up APPM to take measurements at +24 degrees and also bracket that "declination line" with additional lines at +22 degrees and +26 degrees.  As far as RA spacing, I will set it from 6 to 8 degrees depending on the focal length of the scope.  For my f/3.6 FSQ-106 I will set the RA spacing at 8 degrees [see below].  With my 1000mm fl Newtonian I will set the spacing closer together at 6 degrees but I always leave the dec spacing at 2 degrees.  This approach is what has worked for me.  Others may do things different.  You can experiment and see what works for you and your particular equipment.

I haven't used the Dec-Arc Tracking feature yet.  It is a new feature that was introduced after I got my mount and would require a paid upgrade to my software version.  I just don't think that I need it at the focal lengths that I image at so I haven't paid for the upgrade to get the feature... yet. :-)

Below is a screen shot of my APPM windows showing the parameters.  This mapping run would probably take about 30 minutes to run as it is getting dark.  If I were to stay out for multiple nights and wanted to switch to another target, then I would simply adjust the Min Dec and Max Dec parameters to bracket the next object.  For instance if the second night's object is at 10 degrees, then I would reset the parameters to +8 degrees and +12 degrees and leave the RA separation as it is.  I would run APPM again to create this new set of measurements and then apply the measurements to APCC Pro as a new model for the second night. The model for the first night is saved and I  could go back to it for a third night if I wanted to collect more data on the first object.  Once you see how the software is set up it is really very simple to use. 




 

--
Dean Jacobsen
Astrobin Image Gallery - https://www.astrobin.com/users/deanjacobsen/


Ray Gralak
 

Hi Greg,

1) What is the best practice re dithering while running an APPM model (all sky or dec arc)
For dithering it doesn't matter which pointing model is active, or even if no model is active.

2) Would it pay to make a smaller all-sky model and just guide? (in the case if I don't get time to plan an object,
because of the random nature of doing a night's session, create an advanced sequence and Dec-Arc model)
Even a small model will help reduce autoguider moves.

-Ray