Tom from AstroEQ has already posted an update that seems to fix the problem by updating :f when receiving :G only if the axis isn't moving.
www.astroeq.co.uk/forum/index.php/topic,...msg1979.html#msg1979
Read More...
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 "
Kaczorek wrote: Due to increasing security constraints in majority of browsers this issue will persist. To address This ssl will be disabled by default in the new version. I would recommend using a VNC viewer to access Astroberry Server if you have problems with accessing it with a browser.