Infer from AUX command 0x05 the mount model #742
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Send to AUX device 0x10 (AZM motor controller) the command 0x05 (MC_GET_MODEL) to get reply which contains the mount model version string. The command is derived from Celestron AUXBUS Scanner https://github.com/platini2/celestronauxbus currently the following mount versions can be inferred: 0x0001 : 'Nexstar GPS', 0x0783 : 'Nexstar SLT', 0x0b83 : '4/5SE', 0x0c82 : '6/8SE', 0x1189 : 'CPC Deluxe', 0x1283 : 'GT Series', 0x1485 : 'AVX', 0x1687 : 'Nexstar Evolution', 0x1788 : 'CGX' In a later commit the inferred mount model can be used to properly determined whether it a a GEM, AZ_ALT or FORK mount.
|
Thank you. This is indeed a step in the right direction. Btw, are you using this driver with your Celestron mount? If yes, which model do you have? |
|
Yes, I am using the driver with my Celestron AVX mount. The mount replies for AUX command 0x05 to the AZ motor I wrote a post on the INDI Forum: |
|
In the Celestron AUXBUS Scanner Python Code are a great deal of additional AUX commands documented, e.g. |
|
Have you tried guiding on your mount? It appears that MC_GUIDE commands have no effect and the encoders remain the same? |
|
I haven't tried it, but will try today and report back. |
|
Do you mean the AUX command: MC_GET/SET_AUTOGUIDE_RATE? I set the Guiding Rate W/E to 0.2 (HEX: 0x33 = DEC: 51, 51/256 After terminating the indiserver and restarting it again, I can see that the command MTR_GET_AUTOGUIDE_RATE is issued and correctly read: |
|
Thanks, this is useful as well, but I meant the actual guide pulses MC_AUX_GUIDE, not the rate. The issue I saw is that regardless of how long the pulses are sent, the encoder position remains the same in the logs which indicates no motion at all from the pulses. Is this what you see or does it move a bit with pulses as expected? |
|
Ok I see. I just checked it, sending guide impulse does not show any MC_AUX_GUIDE packets. When forcing in It works and I see the following AUX packets: Sending additional guide pulse shows: So probably it would be good to merge this "Model determination" PR and in a next PR determine based on the Model |
|
The Celestron AUX driver is reporting itself in getDeviceName() as: and unfortunately not as the model name |
|
This is because you need to set INDI_DEV environment variable to the final name before starting debugging. When running the actual driver from a client like KStars, it starts it with a specific name being the desired label. At any rate, let me check with CGX-L I have here to see how it behaves. |
|
Ok I tested with guiding and it works OK. However, I am still unclear on whether the HC is required for the initial startup or not? I got this explanation from Celestron:
So it appears you cannot simple use AUX via USB/PC port directly without initially using the HC to set it up and perform some sort of alignment or index positioning? |
|
I can use AUX-via-HC-USB without ever going outside to touch the mount, even after power cycling my whole telescope. Sure, the first time it was set up I used the hand controller to move to the index marks, then set set that as the home position. After that, nothing else has been required to use the hand controller. Next time I have clear skies I can try a quick align, which seems to just tell the HC that I am polar aligned and at the index marks and please just get out of my way... maybe that will have some effect on guiding, etc. It'd be nice if there was a quick align protocol command to do the same thing. |
|
I sniffed via the DIY usbauxrelay MCU the AUX-bus while the HC connected. After switching on the HC the following AUX packets are sent: After these packets are sent from HC to MC, I confirmed on the HC:
After hitting ENTER (Quick Align) the following AUX packets are sent: I used before the Celestron GPS driver and always did a quick align, and then sync'ed on 2-3 stars via astrometry and everything was fine. I guess the same should apply for the AUX driver as well. I tested the Celestron AUX driver just indoor. The important packets after Quick-Align seems to be: |
|
When the RTC is activated the AUX packets looks as follows (same procedure as above).: |
|
That's some great progress @tstibor !! Do you think we can prepare a function to call these from the AUX driver so we can end up with the same effect as using the HC? Then it would be possible to completely get rid of the HC and just rely on the driver as-is for everything!! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Send to AUX device 0x10 (AZM motor controller) the command 0x05 (MC_GET_MODEL) to get reply which contains the mount model version string.
The command is derived from Celestron AUXBUS Scanner https://github.com/platini2/celestronauxbus
currently the following mount versions can be inferred:
0x0001 : 'Nexstar GPS',
0x0783 : 'Nexstar SLT',
0x0b83 : '4/5SE',
0x0c82 : '6/8SE',
0x1189 : 'CPC Deluxe',
0x1283 : 'GT Series',
0x1485 : 'AVX',
0x1687 : 'Nexstar Evolution',
0x1788 : 'CGX'
In a later commit the inferred mount model can be used to properly determined whether it a a GEM, AZ_ALT or FORK mount.