astrogene1000

Chris, the 'closest direction' nframe test code I sent was test code. To make it 'correct' there needs to be a switch for 'cord wrap' versus 'closest direction'. The original...

To me, this issue does not look like an AUX driver issue In the 22-17-19 log file I found this. A solution is calculated and criteria met. Then a Slew...

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...

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...

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](url) TimerHit in celestronaux.cpp, /* ESN 11192022 */ if (MountTypeSP[EQUATORIAL].getState() == ISS_ON) { // if (GuideWENP.s == IPS_BUSY)...

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

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...

Is doesn't lock up :-), but also does nothing using modified indi_celestron_gps DEBUG 84.281574 sec : CMD DEBUG 84.310454 sec : RES DEBUG 86.311174 sec : guideTimer dir N, ticks...

@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...

Sorry but the line state should not affect timeout's as to when the framework returns control to the calling program. The time span is always almost exactly 1000ms, not something...