toggle quoted messageShow quoted text
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.
On Jun 19, 2021, at 18:07, deonb <firstname.lastname@example.org> 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.
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?