Just as an update to this, Jasem has written new driver code for his own Celestron driver which is now using the AUX approach. Look for it in the next release of the code. Beta testing of it should continue this week, but, the preliminary operation looks pretty good.

Actually, I rewrote the standard Celestron driver. The newer Celestron driver which uses AUX is being developed by Pawel Jochym.

Thanks to both of you for all your efforts on this. Now, to the testing, I can not find the Celestron slewing speed selection on the newest version. Did it somehow get lost when Sync was removed. And, without Sync, how will the mount Sync if astrometry were to fail?

The present driver also will not function unless the user deletes any existing Park.xml from the .indi directory. KStars defaults to a parked mount, deleting it is the only way to unpark the mount.


Best wishes,
Dan

There was a regression with latest code regarding slew speed, fixed now. For sync, your firmware does not support sync, maybe with the newer celestron driver it will work.

What do you mean under "your firmware does not support sync"?

LOL, I can tell this will be a lively discussion, so, I will jump in early. The version number of the hand controller determines which commands it can support. The early versions of the controller, i.e. Version 1.6 or 2.2 do not have the same commands as later versions.

I'm personally trying to get the driver to support all of the hand controllers. In the long run, it will result in less confusion and questions.
The present day set of commands are found here:
www.celestron.com/c3/images/files/downlo..._nexstarcommprot.pdf

But you should look here for the versions and what they actually do for your particular setup:
www.nexstarsite.com/

I will give several stupid questions for a better understanding (first time nobody answered them) What is actually Sync? Taking into account difference between current coordinates and expected ones, yes? Is Sync command sent to Celestron telescopes or not? Or is it just KStars accounting for difference?

KStars does not do anything. The mount think it is looking at XX, YY coordinates, when we know for a fact it is looking at AA,ZZ, so we tell it your location now is AA,ZZ and it reports its location as that from now. "Internally" and depending on the firmware, it takes the sync point difference from previously reported point and tries to predict the correct position the next time it moves. KStars simply reports whatever the mount is reporting back.

Ok, clear now, thank you very much! One more question - do I understand it right that Celestron supports only 1-star sync only?

"Depending on firmware" Why does that have anything to do with KStars, or even, the INDI driver for that matter? When I check the box for INDI to use the computer as the "Update source", I expect all commands to flow from KStars to the mount, and, I expect the mount's firmware to be irrelevant to how KStars calculates positions.

The INDI driver for the mount only needs to do 2 things. First, convey a position to the mount by moving the 2 axis motors. Setting the speed of those motors is important, but not absolutely necessary. Second, the driver may receive encoder information, or other data, and pass it along to KStars for interpretation.

All the remaining stuff is within KStars. Time, position, and, location on earth should be user settings within KStars. IF, a particular telescope mount can provide data, fine, but, that is not a requirement for KStars to position a mount. All the version number should do, is tell KStars whether a mount option CAN be used. Then, KStars can pole for that data to allow the user access to additional features.

But, if you want the telescope icon pointing at the south pole, the user should be able to mouse to the south pole on the map, click sync, and KStars should work from those coordinates for directing its actions with the motors. Right now, the Park position, should be the default "starting point" for KStars. If I understand the Celestron Hand Controllers correctly that starting point will be the difference between an Alt AZ value and the users Park value. Still, the user should be able to override the position, by using the map to mouse to a position, click Sync., KStars should then move the icon and work from the new position point.

When a Celestron mount moves to a new location, the INDI driver should allow KStars to pole Alt AZ data from the mount. This data should then update the telescope position icon. This data retrieval can be done at whatever is convenient to the hardware. If no data were available, KStars would still move the mount, and, at the end of such a move, update what position KStars believes the mount is pointing towards. KStars would use for the next move. Based on a visual observation the object was not centered, the user would manually center the desired object and Sync would allow the user to "correct" this position. In a similar sense, astrometry, may Sync the position which KStars is using, OR, astrometry may Sync and then move according to the user's desire to reach a particular ending position.

I will go deeper After powering on (without any pressing on the hand controller) the Celestron mount, how does the motors behave? Are they moved accordingly to the calculated corrections based on alignment stars or only RA motor is moving at sidereal rate? I will explain why this is important. After accomplishing initiating steps on the hand controller, as I can understand, both motors are starting to move at a rate calculated based on alignment. If we try polar alignment using Ekos, as I can understand, it is assumed that only RA motor is working, at sidereal rate. But this is not the case with an aligned Celestron mount... It means polar alignment procedure will be biased by mount's internal alignment, resulting in unachievable polar alignment. So far, do I understand it right?
I tried polar alignment described in the manual of the mount - yes, it helps, but is far from perfect. Even the classical drift method doesn't work as expected because of the both motors working. Am I deeply wrong with all the things I wrote above or it is actually true?

I'm the one trying to develop an AUX-based celestron driver. It is at early alpha stage 3rdparty/indi-nexstarevo). It will be very helpful to me to have this Xmtelremote code as reference/source of ideas/verification of my ideas. Put it somewhere if you can (I have tried googling ... nothing). You can contact me at jochym on gmail.