Understanding automation-based corrections/sync #Mach2GTO #Keypad


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.
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?

Join main@ap-gto.groups.io to automatically receive all group messages.