Re: Understanding automation-based corrections/sync #Mach2GTO #Keypad


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.

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