Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Celestron AUX - Command MC_AUX_GUIDE/MC_AUX_GUIDE_ACTIVE #685

Open
astrogene1000 opened this issue Nov 19, 2022 · 11 comments
Open

Celestron AUX - Command MC_AUX_GUIDE/MC_AUX_GUIDE_ACTIVE #685

astrogene1000 opened this issue Nov 19, 2022 · 11 comments
Assignees
@knro
Labels
bug Something isn't working

Comments

@astrogene1000
Copy link

Celestron AUX driver, latest Master
HC Version: 5.31
MC version ALT/AZ 5.14.0
Mount: Nexstar SE w/usb serial

Ekos Driver Selection '* Wedge'

Connect driver in HC/USB Mode
Now whether the driver had been instructed to do other things prior, e.g. SYNC's and GoTO's or not:

Navigate to Guide Tab
Enter value(s) for Guide(N/S) or Guide(E/W) and press set
Example Command 0x26 is sent with "CMD <50 03 11 26 32 05 00 FF>"

Encapsulated HC command format
0x50
msglen
destID
msgId
Data1
Data2
Data3
responseBytes

So setting 0xff as the number of response bytes to expect back means none
(from auxproto.cpp int AUXCommand::responseDataSize() )

The number of bytes value expected back is not defined here:
https://github.com/jochym/nexstar-evo/blob/master/doc/notes.md

Command 0x26 is in auxproto.h
MC_AUX_GUIDE = 0x26,
MC_AUX_GUIDE_ACTIVE = 0x27,
Command is not in switch table of auxproto.cpp so CMD prints out as hex

Results: Constant error's after that, HBX itself does not respond to -any- button presses, frozen all around

Log output:
CSER 37.196737 sec : RES (8 B): <3B 04 11 20 01 00 00 00>
CSER 37.196875 sec : Got 4 bytes: ; payload length field: 4 ; MSG:
CSER 37.196939 sec : [00 04 11 20 01 00]
CAUX 37.197003 sec : RES <MC_GET_POSITION> ALT -> APP [00 00 00]
ALIGNMENT 37.198774 sec : Mount -> Sky RA: 13:47:45 DE: 0:00:17 AZ: 180:00:43 AL: 51:14:24 HA: 9:19:50 Pier: PIER_UNKNOWN
CAUX 38.200073 sec : CMD <MC_GET_POSITION> APP -> AZM
CSER 38.250459 sec : CMD <50 01 10 01 00 00 00 03>
CSER 38.250687 sec : RES (8 B): <3B 04 10 20 01 00 00 00>
CSER 38.250775 sec : Got 4 bytes: ; payload length field: 4 ; MSG:
CSER 38.250849 sec : [00 04 10 20 01 00]
CAUX 38.250923 sec : RES <MC_GET_POSITION> AZM -> APP [00 00 00]
CAUX 38.251009 sec : CMD <MC_GET_POSITION> APP -> ALT
CSER 38.301275 sec : CMD <50 01 11 01 00 00 00 03>
CSER 38.301501 sec : RES (8 B): <3B 04 11 20 01 00 00 00>
CSER 38.301577 sec : Got 4 bytes: ; payload length field: 4 ; MSG:
CSER 38.301641 sec : [00 04 11 20 01 00]
CAUX 38.301705 sec : RES <MC_GET_POSITION> ALT -> APP [00 00 00]
ALIGNMENT 38.303530 sec : Mount -> Sky RA: 13:47:46 DE: 0:00:17 AZ: 180:00:43 AL: 51:14:24 HA: 9:19:49 Pier: PIER_UNKNOWN
->>>>CAUX 39.136337 sec : CMD <26> APP -> ALT [32 05]
CSER 39.186744 sec : CMD <50 03 11 26 32 05 00 FF>
CAUX 39.303982 sec : CMD <MC_GET_POSITION> APP -> AZM
CSER 39.354322 sec : CMD <50 01 10 01 00 00 00 03>
ERROR 39.354512 sec : Resp. char 4 is 03 ascii ^C
ERROR 39.354592 sec : RES <00 28 6D 8D F4 C4 EC 01>
CAUX 39.354667 sec : CMD <MC_GET_POSITION> APP -> ALT
CSER 39.404910 sec : CMD <50 01 11 01 00 00 00 03>
ERROR 39.405100 sec : Resp. char 4 is 03 ascii ^C
ERROR 39.405167 sec : RES <00 28 6D 8D F4 C1 46 77>
ALIGNMENT 39.406717 sec : Mount -> Sky RA: 13:47:48 DE: 0:00:17 AZ: 180:00:43 AL: 51:14:24 HA: 9:19:48 Pier: PIER_UNKNOWN
CAUX 40.407999 sec : CMD <MC_GET_POSITION> APP -> AZM
CSER 40.458342 sec : CMD <50 01 10 01 00 00 00 03>
ERROR 40.458524 sec : Resp. char 4 is 03 ascii ^C
ERROR 40.458601 sec : RES <00 28 6D 8D F4 F5 00 13>
CAUX 40.458672 sec : CMD <MC_GET_POSITION> APP -> ALT
CSER 40.509109 sec : CMD <50 01 11 01 00 00 00 03>
ERROR 40.509318 sec : Resp. char 4 is 03 ascii ^C
ERROR 40.509396 sec : RES <00 28 6D 8D F4 00 00 00>

### Experiment Updates:
After experimenting it is found that the MC_AUX_GUIDE command returns 1 byte response
Found code does not ever account for a 'Set' on the GuideTab so always stays 'yellow'
Updated code to invoke 'MC_AUX_GUIDE_ACTIVE" command in TimerHit and receive 1 byte response
Found response is -always- a '1' whether 'Set' was ever done or not for Guide so code in
bool CelestronAUX::processResponse(AUXCommand &m)
for case MC_AUX_GUIDE_ACTIVE is never satisfied with a '0'

Initial conclusion:

The GUIDE N/S/E/W entry is totally broken with this Nexstar on an SE mount
If cannot get valid status upon issuing a MC_AUX_GUIDE_STATUS command then the capability to enter GUIDE SET's should be removed until resolved
@astrogene1000 astrogene1000 added the bug Something isn't working label Nov 19, 2022
@knro knro self-assigned this Nov 20, 2022
@knro
Copy link
Collaborator

knro commented Nov 20, 2022

Thank you for the report. Do I understand that we need to add MC_AUX_GUIDE to the switch list to indicate that response is 1 byte?

So we should add both MC_AUX_GUIDE and MC_AUX_GUIDE_ACTIVE there to indicate they return just 1 byte?

knro added a commit that referenced this issue Nov 20, 2022
@knro
Set MC_AUX_GUIDE and MC_AUX_GUIDE_ACTIVE response size to 1 bytes per #…
a1a20b8 
…685
@astrogene1000
Copy link
Author

Not sure any impact on EVO or other mount motor cards. The above was done on SE base motor cards. SE may just not support as seen in the 0x27 MC_AUX_GUIDE_ACTIVE response always '1' .
The Celestron firmware page https://www.celestron.com/pages/firmware-update-history lists version 7.15+/7.17+ for other mounts versus the 5.14 for the 6/8 SE line (SE line mounts not even listed).
I believe you have a Celestron mount? Try the GuideTab on it, symptom for failure besides the error messages is the HC stops scrolling the 'Press Enter' message.
The 'fix' may just be if see certain kind of mounts, no GuideTab.

I have a full source available that does the '1' byte read for MC_AUX_GUIDE and also does MC_AUX_GUIDE_ACTIVE to clear if a '0' is seen, I can provide that for testing purposes.

@astrogene1000
Copy link
Author

There are other mis-matches for response size in the AUX, example for GET_VER against an SE base with motor cards version 5.14

[2022-09-01T22:49:37.152 EDT DEBG ][ org.kde.kstars.indi] - Evolution WiFi Wedge : "[CAUX] CMD < GET_VER> APP -> AZM "
[2022-09-01T22:49:37.152 EDT DEBG ][ org.kde.kstars.indi] - Evolution WiFi Wedge : "[CSER] CMD <3B 03 20 10 FE CF> "
[2022-09-01T22:49:37.152 EDT DEBG ][ org.kde.kstars.indi] - Evolution WiFi Wedge : "[CSER] RES <3B 05 10 20 FE 05 0E BA> "
[2022-09-01T22:49:37.153 EDT DEBG ][ org.kde.kstars.indi] - Evolution WiFi Wedge : "[CAUX] RES < GET_VER> AZM -> APP [05 0E] "
[2022-09-01T22:49:37.153 EDT DEBG ][ org.kde.kstars.indi] - Evolution WiFi Wedge : "[DEBUG] Data and buffer size mismatch for GET_VER: buf[4] vs data[2] "
[2022-09-01T22:49:37.153 EDT DEBG ][ org.kde.kstars.indi] - Evolution WiFi Wedge : "[CSER] RES <3B 07 0D 20 FE 05 22 08 11 8E> "
[2022-09-01T22:49:37.153 EDT DEBG ][ org.kde.kstars.indi] - Evolution WiFi Wedge : "[CAUX] RES < GET_VER> HC+ -> APP [05 22 08 11] "
[2022-09-01T22:49:37.153 EDT DEBG ][ org.kde.kstars.indi] - Evolution WiFi Wedge : "[CAUX] CMD < GET_VER> APP -> ALT "
[2022-09-01T22:49:37.153 EDT DEBG ][ org.kde.kstars.indi] - Evolution WiFi Wedge : "[CSER] CMD <3B 03 20 11 FE CE> "
[2022-09-01T22:49:37.154 EDT DEBG ][ org.kde.kstars.indi] - Evolution WiFi Wedge : "[CSER] RES <3B 05 11 20 FE 05 0E B9> "
[2022-09-01T22:49:37.154 EDT DEBG ][ org.kde.kstars.indi] - Evolution WiFi Wedge : "[CAUX] RES < GET_VER> ALT -> APP [05 0E] "
[2022-09-01T22:49:37.154 EDT DEBG ][ org.kde.kstars.indi] - Evolution WiFi Wedge : "[DEBUG] Data and buffer size mismatch for GET_VER: buf[4] vs data[2] "

@astrogene1000
Copy link
Author

For the MC_AUX_GUIDE/MC_AUX_GUIDE_ACTIVE attempt and experimenting to make these actually functional
See
https://github.com/astrogene1000/indi-3rdparty/tree/master/indi-celestronaux
TimerHit in celestronaux.cpp,
/* ESN 11192022 /
if (MountTypeSP[EQUATORIAL].getState() == ISS_ON)
{
// if (GuideWENP.s == IPS_BUSY) // uncomment for non-debug, stop callling every Hit
{
isGuideActive(AXIS_RA);
}
// if (GuideNSNP.s == IPS_BUSY) // uncomment for non-debug, stop callling every Hit
{
isGuideActive(AXIS_DE);
}
}
/ ESN OFF 11192022 */

Calling:
/* ESN 11192022 */
bool CelestronAUX::isGuideActive(INDI_EQ_AXIS axis) {
AUXBuffer data(2);
// data[0] = 0;
// data[1] = 0;
// AUXCommand cmd(MC_AUX_GUIDE_ACTIVE, APP, axis == AXIS_DE ? ALT : AZM, data);
AUXCommand cmd(MC_AUX_GUIDE_ACTIVE, APP, axis == AXIS_DE ? ALT : AZM);
//ESN 11192022 return sendAUXCommand(cmd);
sendAUXCommand(cmd);
//ESN 11/19/2020
readAUXResponse(cmd);
return true;
// END ESN

}

/* ESN OFF 11192022 */

@knro
Copy link
Collaborator

knro commented Nov 21, 2022

Does this make guiding fully work for your setup?

@astrogene1000
Copy link
Author

No, scope never moves and MC_AUX_GUIDE_ACTIVE returns a '1' at all times, even when MX_AUX_GUIDE was never sent..

@astrogene1000
Copy link
Author

This may explain it, from "celestrongps.cpp"
canAuxGuide = (atof(fwInfo.RAFirmware.c_str()) >= 6.12 && atof(fwInfo.DEFirmware.c_str()) >= 6.12);

So v5.14 of the SE mount does not qualify.

Reference:
6.12 - Support for "Custom Rate 9" (introduced in HC version 4.19 - see above). Added new "Aux" command to support better autoguiding via RS-232 communication via the port on the bottom of the hand control. Fixed an error that prevented some user settings from being restored when the scope is powered up.
From:
https://www.nexstarsite.com/Firmware/CGEMFirmware.htm

@knro
Copy link
Collaborator

knro commented Nov 21, 2022

Ok sorry to hear about that. Curious what if you just set to true

canAuxGuide = true

and see what happens with your mount? Most likely it's not going to work but at this stage, nothing to lose.

@astrogene1000
Copy link
Author

Is doesn't lock up :-), but also does nothing using modified indi_celestron_gps

DEBUG 84.281574 sec : CMD <50 03 11 26 32 C8 00 00>
DEBUG 84.310454 sec : RES <23>

DEBUG 86.311174 sec : guideTimer dir N, ticks -55, rate 50
DEBUG 86.311337 sec : CMD <50 01 11 27 00 00 00 01>
DEBUG 86.340249 sec : RES <01 23>

10 seconds later, response still a '1'
DEBUG 96.532578 sec : guideTimer dir N, ticks -55, rate 50
DEBUG 96.532639 sec : CMD <50 01 11 27 00 00 00 01>
DEBUG 96.561568 sec : RES <01 23>

In my clone repository, I add the code to remove the GuideTab if version is < 6.12 on AZM axis and left all the other stuff in for testing on other than an SE mount

https://github.com/astrogene1000/indi-3rdparty/tree/master/indi-celestronaux

@knro
Copy link
Collaborator

knro commented Nov 22, 2022

I never tested guiding with my Evolution mount. Hopefully tonight I can see if the existing code works at all when it comes to guide pulses.

@astrogene1000 So you disable guiding in your case and that's it?

@astrogene1000
Copy link
Author

@knro Correct, if MC version is < 6.12 then just hide the Guide TAB
CelestronGPS driver, if MC version < 6.12 then switches to timed pulses using MC_MOVE_POS : MC_MOVE_NEG
Same scheme, switch to timed pulses, could be used in AUX driver but that is subject for a different development.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@knro knro

Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@knro @astrogene1000