Fabrizio, what is the best way to get the 2nd sync point added? I take it that we add the first one the same way with motion control. How then do we slew to the next point, plate solve and sync? If I try to manually move the mount with motion control, and PS and sync, the next time I try a goto in Kstars I get crazy movement.
Is there a catch? You mention moving in altz?

Hello Kevin,

I do the following procedure (now I can only sync and not do a real PS)
1. using axis indexes, set physically the scope to RA/Dec = 0/0.
2. sync to 0/0.
3. slew RA with mount control arrows, for example, to be about -3h HA. Do not press Dec arrows. You will see that in spite of being equatorial, Dec changes also.
4. sync to HA = the displayed HA and Dec = 0. I have added a new feature to the Mount Control: you can copy the current displayed coordinates into input coordinate boxes by clicking above the displayed coordinates. For now, it is only merged in the kstars developement repo, so you need to build kstars from there.
5. from now on, I see regular scope movements.

Don't forget to set your latitude/longitude into INDI panel > Celestron AUX > System Management .

I have discovered also that any manual changes to the database of sync points (additions/deletions) take effect only after clicking on reinit of math plugin button of the Alignment Subsystem. The sync command is not affected, since it does automatically the reinit after the addition of each sync point.

I hope this can help.

Further tests.

With the above procedure, after the 2nd sync, slewing RA only, I still see some changes in displayed Dec, few degrees. I think that the HA taken from the displayed coords is not correctly referenced to an equatorial frame with respect to the real scope motion, may be it is still AltAz. So I made the two sync points slewing the scope with its HC to HA/Dec 0/0 and -6h/0. Now, slewing RA only, from -6h/0 to 0/0, Dec changes less than 1 degree, this is probably due to my rough alignment to the sync points.

There might be a still few rough edges in the INDI Alignment Subsystem since this is one the first *real* uses for it in non-AltAz mounts. I believe Rick also found some issues . Would you mind moving the alignment discussion to that thread so that we can all work together to resolve any issues with it?

Hello to all,
I'm sorry if I'm asking maybe stupid questions but StellarMate is new for me and I've just bought it. You're always talking of AltAz mounts. Is this the Azimutal mount? Jasem directed me to this thread, cause I wasn't sure if my Nexstar Evolution 8HD with its Azimutal mount is supported by StellarMate. It would be supported, but when I'm reading here I get a miitle bit confused. Maybe someone can get me back on the right way thanks a lot to you all!
Best regards
Frederik

OK. Thanks Jasem.

Yes, you are right, AltAz means Azimuthal. But the correct term is Altazimuth mount. To be precise, azimuthal is an adjective of something concerning the axis of motion of azimuth which is only one of the two axes of the altazimuth-mounted telescope. The other is the altitude axis.

Thanks Fabrizio! So this is supported in StellarMate, but the Guiding is a problem, but you're working on this, as I hopefully understood right
Please let me know if I'm wrong.
Thanks a lot for your help!
Best regards
Frederik

I did some test today with your latests celestronaux_eqtrack branch and:

1. Cord wrap even if it is "green" and OFF, I have to turn it ON and OFF to take effect.
2. If my first sync point is on ALT = 0 (any AZ) then alignment seams to work fine.
3. If my first sync point is on higher ALT then alignment is a mess. Adding second sync helping much, but I can not tell more about it's accuracy because of those clouds from over two months now :-/

If I can do any more tests without a sky please let me know.

It appears more users are reporting incorrect position on startup. Just wondering, is this perhaps because the driver relies on INDI::Alignment subsystem, while the mount is already aligned and is sending the *raw* encoder values to the driver while the transformed coordinates are sent off to Celestron/SkySafari software? Not sure if this make sense, this is one of the few mount drivers which I'm not familiar with how it works.

I don't know what kind of connection there might be between the driver and the skysafari. The only coordinate output of the driver toward the rest of the software system is in ReadScopeStatuswhere RightAscension and Declination are the processing result of INDI::AlignmentSubsystem.

What I am not clear about the alignment subsystem is whether it is my responsibility or not to transform from equatorial to altaz before to interact with the subsystem.

Hey Fabrizio, I've been digging into the alignment subsystem a lot lately, and I've found that I think you DO need to interact with it in either equatorial coords with an EQ mount OR alt/az coords for an alt/az mount.

I'm not sure if it has made it into a release yet, but I added some helper methods to the alignment subsystem to make it easier to deal with. You can see them in use in the tests created here:
github.com/indilib/indi/tree/master/test/alignment