I found a bug caused by miscommunication between the INDI EQMod driver and the AstroEQ firmware. During initialization, the INDI EQMod driver sets the slew speed to the Custom Rate value, which sends a :G[axis]30 command to the AstroEQ which sets highspeed, forward mode (or at least for me, my Custom Rate is x662). However, INDI EQMod never sends the :J command after the :G command, so the AstroEQ doesn't update the :f value to reflect that it is ready to change to highspeed mode.

"[DEBUG] SetRARate() : rate = 662 "
"[MOUNT] SetMotion() : Axis = 1 -- dir=forward mode=slew speedmode=highspeed "
"[SCOPE] CheckMotorStatus() : Axis = 1 "
"[COMM] dispatch_command: \":f1\", 4 bytes written "
"[COMM] read_eqmod: \"=101\", 5 bytes read "
"[MOUNT] StopWaitMotor() : Axis = 1 "
"[COMM] dispatch_command: \":K1\", 4 bytes written "
"[COMM] read_eqmod: \"=\", 2 bytes read "
"[COMM] dispatch_command: \":f1\", 4 bytes written "
"[COMM] read_eqmod: \"=101\", 5 bytes read "
"[COMM] dispatch_command: \":G130\", 6 bytes written "
"[COMM] read_eqmod: \"=\", 2 bytes read "
"[MOUNT] SetSpeed() : Axis = 1 -- period=7 "
"[COMM] dispatch_command: \":f1\", 4 bytes written "
"[COMM] read_eqmod: \"=101\", 5 bytes read "        <----still shows 101 (lowspeed, forward, slew, not moving, initialized)
"[COMM] dispatch_command: \":I1070000\", 10 bytes written "
"[COMM] read_eqmod: \"=\", 2 bytes read "
Then, when you unpark the mount and try to perform a low speed movement in the same direction, INDI EQMod thinks that AstroEQ is already in lowspeed, forward mode because of the response to :f not having updated yet, and therefor doesn't send another :G command. INDI EQMod then sends the :J command to start moving, which causes AstroEQ to finally switch over to highspeed mode.

The bug only affects the very first slew command for an axis, and only if the slew command is at lowspeed and forward. The result is a highspeed ticking motion, but the ticking is only because of the proper :I value being set for what should be lowspeed. The bug also affects tracking (tracking = lowspeed forward slew), if you enable it immediately without slewing RA before hand to work around the bug (by sending a :G then :J, to clear out the :G that was sent without a :J).

There are a few ways I thought of to fix this:
  • AstroEQ could update :f after receiving :G or :I (might cause problems if already moving)
  • INDI EQMod could always send a :G before a :J (might slow down guiding)
  • INDI EQMod could avoid initializing the Custom Rate and sending the first :G without a :J

I have also posted this on the AstroEQ forum.

Read More...