In my experience is hard to distinguish between different types of USB/Serial converters from product description. 99% of low cost converters claims RS232 compatibility but they have a TTL interface (0,+5v) that works only with the so-called "TTL tolerant RS232". In our case, they can be only used for the AUX interface. For all the other mount interfaces a "quasi-https://indilib.org/telescopes/celestron/celestron-aux-driver.htmltrue" USB/RS232 converter (-5,+5v swing ) is sufficient.
Below there is a copy taken from indilib.org/telescopes/celestron/celestron-aux-driver.html of the specification of each interface of Celestron scopes, including the required voltage swing.
detectRTSCTS relies on a timeout to discriminate if the hardware handshake is present or not. At present, it is set to 300 ms. It worked well for my setup with Celestron CPC. Probably, for other mount types, it needs a different trimming. I suggest to extend it to 500ms and to test if the problem disappears.
The purpose of function getNorthAz is to make the cordwrap work even if the mount is powered up when the scope is not pointing at North. Since the CPC mount zeros the motor encoders at power up,
getNorthAz compute the offset between North and scope direction at power up. This offset is subtracted in cordwrap angular computations. If the mount is not aligned, getNorthAz returns zero, otherwise it returns the real North azimuth.
sorry, my setup is all wired with USB to serial converters, no WiFi. So, I cant help you.
just to see if I have understood well, your operations are
1. two stars alignment;
2. a goto, using Kstars goto, I suppose;
3. when goto slew ends there is a 15s small drift then tracking is ok
The position mismatch appears now or after a further goto?
Remember that the joystick motion is not yet supported by the driver.
do not mix motion commands from the telescope mount SW with motion control by celestron aux driver. The driver is not aware of commands coming from any other sources than an indi client like Kstars, do anything wrong can happen. To move the telescope, use the virtual hand control of Ekos instead. It integrates with the celestron aux driver.
As you can seen few posts above, Jockym, the main driver developer, has reworked the tracking part of the driver and suggests to use his last version 0.9. Download instructions also above.
when I wrote the equatorial alignment instructions, I was focused on my mount that is of fork type, so no meridian flip is required.
For german equatorial mount any motion crossing the meridian obviously needs the meridian flip. This is your case. But even
if you perform the meridian flip, you need to point at the same DE = 0. The 180 degrees of rotation of DE axis combined with the
180 degree of rotation of the polar axis done by meridian flip, keeps DE unchanged. DE intended as celestial coordinate.
In any case, I will add a note for GEMs in the alignment instructions.
astrogene1000_stuff wrote: Quick question please,
Is this a valid command for the AUX driver?
indi_setprop "Celestron AUX.ALIGNMENT_SUBSYSTEM_ACTIVE.ALIGNMENT SUBSYSTEM ACTIVE=On"
I am trying to do a scripted startup of a Celestron and this is throwing an error
Thank you for your time,
thanks for your feedback.
I have added some features to the indi_celestron_aux driver.
1. direct mount USB connection.
2. cordwrap position computed by alignment subsystem.
3. autoguide: the code is roughly copied from Rick's driver indi_celestron_cgx.
Unfortunately, I haven't any checking setup, so they compile and run without fatal errors but the functionality is completely untested.
If someone brave and patient wants to try them, the code is here github.com/fabriziop/indi-3rdparty/tree/celestronaux_eqtrack
Exactly! In this case the alignment conversion failed because the subsystem was disabled. Otherwise it manages correctly the zero sync point case.
knro wrote: @Fabrizo, if AUX already provides RA/DE (which I presume are final post-alignment processed coordinates), why isn't the driver is using these values as-is if no sync points are defined? Sorry if my question is stupid, I really need to dig deeper into this driver. I thought that we deal with encoders values like SkyWatcher when we're using AUX.
Great, Jack. Thanks for you testing. You are probably using version 0.7 of the driver. Here github.com/fabriziop/indi-3rdparty/tree/celestronaux_eqtrack you can find the source of the last version 0.8 (WIP), where the alignment subsystem is enabled by default and warning messages are given if some info is missing to the subsystem for working properly.