This is correct.
NINA internally works on the basis of J2000. Basically, anything that comes from a static database of coordinates - plate solve results, planetarium apps, NINA's own internal object database, the coordinates saved in targets and sequences - are all J2000. When telling the mount to slew to those coordinates, they are precessed, or transformed, accordingly based on what the mount driver advertises as its EquatorialSystem (that's the name of the ASCOM driver property). The precession is done via the widely-used routines that are part of the USNO's NOVAS library ().
toggle quoted message
Show quoted text
On May 14, 2025, at 08:05, Paul Kanevsky <yh@...> wrote:
On Tue, May 13, 2025 at 11:43 PM, Chip Louie wrote:
I'm wondering how it can GOTO the same place with the J2000 on or off?
That is actually how it's supposed to work with NINA. The ASCOM driver tells NINA what precession coordinates are expected by Gemini, and NINA tries to ensure that the correct coordinates are sent. This may not work if some of the other apps settings are changed after they are connected to NINA, or if the apps are not reporting their precession settings correctly for some reason. It's a complex problem with many moving parts, all coordinated (pun not intended!) by NINA.
