Understanding automation-based corrections/sync #Mach2GTO #Keypad


deonb
 

I'm going to use N.I.N.A below as a stand-in example here for automation software, but I saw similar issues with other automation software I've tried in the past.

Ok, so I found out last night that I got into a situation where N.I.N.A drifted my Mach2GTO alignment out by 12 degrees. NINA always centers after slew, so you won't immediately notice since it appears to work, until this slew "corrections" got so far away from reality that my dome slit alignment became impossible. I did start to see an error complaining about a >5 degree correction inside APCC. I also confirmed the 12 degrees by parking, manually pushing the mount to the south-east, then doing an All-Sky solve using TheSkyX.

I tried to clear/reset it by unticking everything on the Pointing Model page inside APCC (no idea if that's the right thing). It still was off, until I restarted APCC, which then zero'd out that table. This previously survived reboots/power cycles of everything. After I did this step though everything was good again. Slews were almost perfect again, slit and scope lined up again, I then did a APPM and the worse correction point was 23" so my mount level and polar alignment appears relatively good from a hardware perspective. And of course after APPM, all slews were dead-on again.

It made me realize though that I don't really know what NINA (automation software in general) does after it plate solves and sync coordinates back to the scope, how APCC coordinates the values from there with the APPM pointing model, and how it coordinates with the Absolute Encoder.

So a few questions:

1) How do I see what sync updates NINA (Automation Software in general) did to APCC? Specifically, what is the active correction value (or points) from the sync? (Not just logs)

2) How do I clear it?

3) Are the NINA correction it does per point? i.e. Does APCC build an internal pointing model for every correction, or is it just a single correction value with a last-one-wins?

4) How does NINA correction integrate with the APPM pointing model?

5) Is the effect of NINA corrections cumulative? It appears to be, I can't imagine APCC or NINA having missing a single slew/plate-solve by 12 degrees in order to finally end up with a 12 degree error. Cumulative seems ok on any other mount, but on a mount with A.E. this doesn't seem like the best strategy.

I guess what I want is the following:

a) I still want NINA to be able to plate solve and center after slew to get the last few pixels aligned (important for OAG stars).
b) BUT I need the A.E. to be much more authoritative. Either:
1) I want every slew of the mount to be based on just the AE + APPM, and never the NINA added corrections.
-or-
2) If the NINA corrections have to be there, I don't want it to be cumulative, but instead if the total corrections (NINA + APPM) disagrees by the absolute encoder values by more than let's say 0.5 degree, then I want a flat-out error state. Go Directly To Park, don't collect $200 type of thing.

Again just using NINA here as an example. This isn't because of NINA, and I don't want to just flip a NINA setting to fix this. Well, I could, but I still want APCC to error if my settings are wrong, since 12 degrees off can run a scope into the mount. But I've had similar issues with SGP and especially Stellarium as well.

Anything that syncs coordinates back to any mount can cause these kinds of issue of course, but in the case of the Mach2GTO it has an A.E... So I want that A.E. (or A.E + Pointing Model) to be an overwhelming source of truth. If something deviates more than e.g. 0.5 degree from A.E. it is either a configuration mistake or my pier fell over. In either case I don't want "correct" beyond that, it should just be a flat-out error and park, even if it was accumulated over time. How can I achieve something close to this?


Dale Ghent
 

Hi Deon,

Syncs are done by NINA or any other app via the ASCOM driver's SyncToCoordinates() method:

https://ascom-standards.org/Help/Developer/html/M_ASCOM_DriverAccess_Telescope_SyncToCoordinates.htm

The existence of a pointing model or anything else is not visible to NINA or any other app that uses the ASCOM driver, and there is no programmatic way in ASCOM for NINA to be aware of this even if it wanted to be. That stuff is all managed behind the scenes by APCC and NINA should never need to know about these things. The steps that NINA takes during a plate solve+sync operation are very pedestrian:

1. Image is captured
2. Image is fed to the configured plate solver
3. Plate solver responds with the solved coordinates in J2000
4. NINA precesses the coordinates to the equatorial system that is advertised by the ASCOM driver's EquatorialSystem property. For A-P and the vast majority of other mounts, this is JNOW.
5. The solved coordinates are then synced to the mount by calling the driver's SyncToCoordinatesI() method with the RA an dec as arguments

And that's it. I don't have an AE-equipped mount yet so I don't know of this issue you're running into. I do run APPM pointing models on my Mach1 and don't really have any noticeable issues like what you describe. I should be receiving an 1100GTO-AE in the fall, so will of course experiment with that.

We put an option in NINA under Options > Equipment > Telescope that prevents syncing in all cases. This was added because (apparently) T-Point gets confused by those. Does this 12 degree deviation (which is absolutely huge and not-subtle) occur with that on? If you want the mount to be authoritative on things and ignore any outside influences in the form of syncs, this is one way to do it. But the real question is *how* you're getting into this situation in the first place. I'll have to leave it to Ray to speak on this part.

/dale

On Jun 19, 2021, at 18:07, deonb <deonb@outlook.com> wrote:

I'm going to use N.I.N.A below as a stand-in example here for automation software, but I saw similar issues with other automation software I've tried in the past.

Ok, so I found out last night that I got into a situation where N.I.N.A drifted my Mach2GTO alignment out by 12 degrees. NINA always centers after slew, so you won't immediately notice since it appears to work, until this slew "corrections" got so far away from reality that my dome slit alignment became impossible. I did start to see an error complaining about a >5 degree correction inside APCC. I also confirmed the 12 degrees by parking, manually pushing the mount to the south-east, then doing an All-Sky solve using TheSkyX.

I tried to clear/reset it by unticking everything on the Pointing Model page inside APCC (no idea if that's the right thing). It still was off, until I restarted APCC, which then zero'd out that table. This previously survived reboots/power cycles of everything. After I did this step though everything was good again. Slews were almost perfect again, slit and scope lined up again, I then did a APPM and the worse correction point was 23" so my mount level and polar alignment appears relatively good from a hardware perspective. And of course after APPM, all slews were dead-on again.

It made me realize though that I don't really know what NINA (automation software in general) does after it plate solves and sync coordinates back to the scope, how APCC coordinates the values from there with the APPM pointing model, and how it coordinates with the Absolute Encoder.

So a few questions:

1) How do I see what sync updates NINA (Automation Software in general) did to APCC? Specifically, what is the active correction value (or points) from the sync? (Not just logs)

2) How do I clear it?

3) Are the NINA correction it does per point? i.e. Does APCC build an internal pointing model for every correction, or is it just a single correction value with a last-one-wins?

4) How does NINA correction integrate with the APPM pointing model?

5) Is the effect of NINA corrections cumulative? It appears to be, I can't imagine APCC or NINA having missing a single slew/plate-solve by 12 degrees in order to finally end up with a 12 degree error. Cumulative seems ok on any other mount, but on a mount with A.E. this doesn't seem like the best strategy.

I guess what I want is the following:

a) I still want NINA to be able to plate solve and center after slew to get the last few pixels aligned (important for OAG stars).
b) BUT I need the A.E. to be much more authoritative. Either:
1) I want every slew of the mount to be based on just the AE + APPM, and never the NINA added corrections.
-or-
2) If the NINA corrections have to be there, I don't want it to be cumulative, but instead if the total corrections (NINA + APPM) disagrees by the absolute encoder values by more than let's say 0.5 degree, then I want a flat-out error state. Go Directly To Park, don't collect $200 type of thing.

Again just using NINA here as an example. This isn't because of NINA, and I don't want to just flip a NINA setting to fix this. Well, I could, but I still want APCC to error if my settings are wrong, since 12 degrees off can run a scope into the mount. But I've had similar issues with SGP and especially Stellarium as well.

Anything that syncs coordinates back to any mount can cause these kinds of issue of course, but in the case of the Mach2GTO it has an A.E... So I want that A.E. (or A.E + Pointing Model) to be an overwhelming source of truth. If something deviates more than e.g. 0.5 degree from A.E. it is either a configuration mistake or my pier fell over. In either case I don't want "correct" beyond that, it should just be a flat-out error and park, even if it was accumulated over time. How can I achieve something close to this?


deonb
 

Thanks Dale,

I'll try tonight with the 'prevent syncing' on in N.I.N.A. I figured N.I.N.A does something simple like this - and that does seem to me that it could cause cumulative errors - through no fault of NINA.

Out of curiosity - if sync is turned off, how does NINA center after plate-solve? Does it then just slew to offset coordinates instead? (And will those thus instead be reflected in the FITS file?)

Either way, I'm looking more for an overall safety from the APCC side here. Even if the 'prevent syncing' solves the specific NINA case, I still want APCC to prevent NINA, Stellarium, PHD2 or whatever from deviating the overall correction to more than e.g. 0.5 degree from the A.E. 


Joseph Beyer
 

I had a similar observation with NINA several nights ago.  While running an APPM model and selecting targets and triggering slews from CdC the go-tos with my Mach1 were perfectly centered.  If the same coordinates were pulled from CdC into NINA (by initially selecting an object as a target in CdC then pulling those coordinates into the framing assistant) then using those coordinates in a target sequence the go-tos were not centered.  The only way I was able to have the objects centered after slewing to the target when starting the imaging sequence was to first drag the object into the center of the framing assistant and click "recenter".  I checked the coordinates used by CdC and NINA and they appeared to be the same.  I will follow up with the developers on Discord but this sounds similar to what I was observing as well.


Ray Gralak
 

There is not enough information to say for sure why the pointing errors accumulated but this is not typical behavior seen with other ASCOM client applications.

1) How do I see what sync updates NINA (Automation Software in general) did to APCC? Specifically, what is the
active correction value (or points) from the sync? (Not just logs)

2) How do I clear it?
If you need to correct the mount's position, I suggest you use APPM's "Plate Solve and RECAL" button on APPM's Run tab.

3) Are the NINA correction it does per point? i.e. Does APCC build an internal pointing model for every correction,
or is it just a single correction value with a last-one-wins?
APCC's pointing models are static once created. Sync's into the model just adjust the an offset into the model.

4) How does NINA correction integrate with the APPM pointing model?
There is no integration, nor does there need to be. NINA is not even aware that there is a pointing model.

5) Is the effect of NINA corrections cumulative? It appears to be, I can't imagine APCC or NINA having missing a
single slew/plate-solve by 12 degrees in order to finally end up with a 12 degree error. Cumulative seems ok on
any other mount, but on a mount with A.E. this doesn't seem like the best strategy.
There's something else going on if errors have accumulated to that extent. I suggest you turn off syncing in NINA until the source of the issue can be determined.

-Ray


deonb
 

On Sun, Jun 20, 2021 at 09:09 AM, Ray Gralak wrote:
There's something else going on if errors have accumulated to that extent. I suggest you turn off syncing in NINA until the source of the issue can be determined.
I feel like we're focusing on the wrong issue here. I was just using NINA as an example. This doesn't have to do with NINA. 

You can do the following to reproduce the issue in just APCC:
In APCC, go to GoTo/Recall, click Load Mount RA/Dec, add 12 degrees to Dec, click Sync. Voila, the mount sync is now off by 12 degrees.

So going back to the crux of the questions:
a) How do I see this? (i.e. How do I see the delta between the Absolute Encoder coordinates and the Synced coordinates).
b) How do I prevent this at the APCC (or even better, at the Hardware) level?


Dale Ghent
 

On Jun 19, 2021, at 22:18, deonb <deonb@outlook.com> wrote:

Thanks Dale,

I'll try tonight with the 'prevent syncing' on in N.I.N.A. I figured N.I.N.A does something simple like this - and that does seem to me that it could cause cumulative errors - through no fault of NINA.

Out of curiosity - if sync is turned off, how does NINA center after plate-solve? Does it then just slew to offset coordinates instead? (And will those thus instead be reflected in the FITS file?)

Either way, I'm looking more for an overall safety from the APCC side here. Even if the 'prevent syncing' solves the specific NINA case, I still want APCC to prevent NINA, Stellarium, PHD2 or whatever from deviating the overall correction to more than e.g. 0.5 degree from the A.E.
I'm confused by what your goal is here - it sounds like you still want centering in some form, but on the other hand you want the mount to be authoritative, which means the centering operation becomes superfluous and should be removed or turned off entirely.

I think the main question here is why or how is this gross deviation working its way into the system in the first place. Normally a centering operation will plate solve and check the solved coordinates against the target's coordinates and sync+reslew to the target coordinates if they are outside your Pointing Tolerance, which is configured under Options > Plate Solving in NINA. In other apps this is referred to as a "close loop slew."

With an encoder mount and especially with a pointing model, this centering check should essentially be a no-op as your mount ought to be spot on at any given time and certainly within NINA's default pointing tolerance, which I think is 1 arcmin. The only time when this isn't the case is if your model is screwed up, your Observing Conditions temperature measurements are in F instead of C like with Wade's recent experience, or your polar alignment is off. There are probably some other perturbations to the system that can throw things off, but APCC logs would probably help sort that out.


deonb
 

I'm confused by what your goal is here - it sounds like you still want centering in some form, but on the other hand you want the mount to be authoritative, which means the centering operation becomes superfluous and should be removed or turned off entirely.
My goal is to get APCC to reject sync coordinates that are in obvious error. Whether those sync coordinates are because of user error, misconfiguration etc. doesn't matter, I want APCC to reject it since it can easily tell that it's obviously wrong.

The NINA specific question I'll raise in Discord - it's just confusing the issue here. The most common way to run into this type of error is Stellarium, clicking "SYNC" before clicking "Current Object". User error, but the Mach2GTO should know better.

Note that APCC has specific protections against these kind of user error that's build for Relative Encoders to prevent misconfiguration errors from Planetarium Software. From the APCC ASCOM documentation:
https://www.gralak.com/apdriver/help/index.html?rcal_versus_sync.htm

So RCAL prevents a SYNC from the wrong side of the pier or more than a 5 degree single correction attempt (you can still repeat these to get > 5 degree cumulative error). This protection is great for a mount with Relative Encoders and probably the best it can be, but it leaves a lot on the table for a mount with Absolute Encoders.

The RCAL protection and RCAL->SYNC ASCOM translations is where I expect the protections to be - on the ASCOM boundary. However, currently APCC (or at least the way I have to set it up) seems to treat the Mach2GTO as a mount with Relative Encoders, with Relative Encoder based algorithms for corrections and protection, and it just uses the Absolute Encoder as an advisory for fine-tuning. Where I want it to use the Absolute Encoders as a source-of-truth and reject corrections that stray too far from it.


Ray Gralak
 

You can do the following to reproduce the issue in just APCC:
In APCC, go to GoTo/Recall, click Load Mount RA/Dec, add 12 degrees to Dec, click Sync. Voila, the mount sync is
now off by 12 degrees.
Open up APCC Advanced Settings and make sure "Prevent Errant RECALs" is checked. If that option is enabled RECALS more than 5 degrees away will be prevented.

-Ray


Ray Gralak
 

So RCAL prevents a SYNC from the wrong side of the pier or more than a 5 degree single correction attempt (you
can still repeat these to get > 5 degree cumulative error). This protection is great for a mount with Relative
Encoders and probably the best it can be, but it leaves a lot on the table for a mount with Absolute Encoders.
In regards to sync/recal checking, there is no difference in the way APCC treats mounts with relative and absolute encoders. The 5 degree range check is meant to be additional check over what the ASCOM driver does (no checking at all).

-Ray