www.cloudynights.com/topic/812944-homebr...aux-port/?p=12330652

Cloudy night provided valuable information on connecting a homemade USB adapter.

It looks like I need to force RTS/CTS and rewrite cpp to connect.

It seems that a setting item that uses RTS/CTS is required to connect directly to AUX.

So far I can see, the DIY cable currently works only when connecting to USB/HC (19200) but not AUX/PC.
I also built a DIY AUX USB Relay MCU cable: USB ⇆ Nexstar AUX Relay for Celestron Mounts
By means of the cable I was able to sniff all the AUX bus commication between e.g. HC and MC for an AVX mount, it is documented in issue:
Celestron AUX driver remote control without HC #745

Based on the sniffed information, the idea was to completely omit the HC by sending the same AUX packets from AUX driver to MC
as the HC is sending. See PR: Fix sendingWithoutHC 0x40 0xc0 and logging (#758)

Cheers
Thomas

Thank you for information.

What I created seems to work on Windows, but INDI doesn't seem to connect without forcing RTSCTS.


I will check the information on the link you provided.

thank you.

Looking at the information, USB ⇆ Nexstar AUX Relay for Celestron Mounts and the USB connection adapter I made seem to have the same mechanism.

In the case of this circuit, it seems that RTS/CTS is also used, so it seems that permission is required on the driver side. (Although it is recognized by the system on Linux, it cannot be connected with INDI. Perhaps the reason why you can connect with CPWI on Windows is because it supports RTS/CTS.)

The self-made WIFI connection created by the same author can be connected and operated without using HC.

However, when I checked it before, the right ascension was off by 90 degrees when GOTO was used with the German equatorial mount. I'm assuming it's because the driver only has the coordinates of the forked equatorial mount.

The problem with the correct pier side is indeed a bug, I checked the code and the pierSide parameter is ignored for GEM mounts:
celestronaux.cpp#L1779
The code for the GEM mounts is: celestronaux.cpp#L1819

I think the following patch shall solve the problem:

Regarding the index position at startup, we sniffed the communication between the hand controller (HC) and the motor controller (MC). Powering up the mount with attached HC is a <em>cold start</em>
and at some time step one has to confirm at the HC that the mount is at index position, that is counter weights down pointing north (see: 745#issuecomment-1463761161 )

Answering the final step on the HC with quick align corresponds to 3 AUX commands send to the MC.

• MTR_SET_POSITION
• MTR_SET_CORDWRAP_POSITION
• MTR_CORDWRAP_ON

The Celestron AUX driver now imitates after connecting the HC cold start.

For what it’s worth, I found that on Windows, using ASCOM, my CGEM-II works best if I connect with the CPWI application and send a “Quick Align” to the mount. Maybe the “Use Last Alignment” would also work if you’re not at the index position?

The key was that the mount seems to need some sort of alignment that Indi wasn’t sending last time I tried it (about 8 months ago).

So with the updated code, as you might expect, I've able to verify indoors that the Scope appears to be behaving normally with respect to meridian flips. *Thank you!*

I'll be able to try it in 5 hours outside.

With respect to initial starting position, I'll try to do a polar alignment using the HC (without Kstars), cycle the power to the mount to quickly get back to the index position and choose last alignment before removing the hand controller. If there is a simpler solution for startup, that would be great, but this doesn't seem onerous. The only nagging question is that I presume once last alignment is chosen, the mount will be begin tracking away from its index position.

Thomas, thank you for figuring this out! I actually just fixed it today and didn't know about your fix, I wish I checked this post earlier! I also verified with Chris that meridian flip works correctly now.

A quick daytime test just now showed the meridian flip worked, I'll check on alignment and all that good stuff tonight.

Jasem, thanks for fixing the pierSide issue.
I think except the last alignment HC imitation, the AUX driver is getting closer and closer being complete.
Regarding the last alignment, how about saving the encoder values (saveConfigItems) when the AUX driver disconnects.
In the connection tab one could add a property, such as "cold start (start at index)"
and "warm start (last alignment)". We could extend the function startupWithoutHC(bool isColdStart),
and send as currently implemented in case of cold start:


and is case of warm start the last stored encoder values.

I am currently at holiday and cannot sniff what the HC is sending in terms of last alignment. When I am
home I will report. I believe "last alignment" shall be the last encoder values.

Cheers
Thomas

I have the wifi accessory, if you point me at some docs I can probably sniff that communication.

Are you still wanting data about the driver? I'm using a Celestron CGX. If I connect via the NextStar handset port, kstars reflects my scopes position correctly, If I use the PC port on the mount and use the celestron-aux driver, it points to the north horizon. 00.