Print

[jslight]

Hi Tom,

I am having a problem with the DEC axis when guiding with KStars/Ekos on Linux using Guide Pulses.  Every time the DEC axis switches direction (including both directions during calibration), the DEC motor travels way too far.  It seemed like it might have been a microstepping issue or trying to compensate for backlash, not sure.

Everything works fine with ASCOM on Windows (except Windows of course ).
I did not test to see if the problem occurs using PHD2 or lin_guider (having problems getting these to play nicely with Ekos).
I was able to work around the problem by using an ST-4 cable from my guide camera to the AstroEQ.

I am using the v4.6 DIY board with Pololu DRV8825 stepper drivers.  I am running the latest version ( v8.12 ) of AstroEQ software and the latest version of KStars ( v2.9.8 ).

[jslight]

I did get a nice set of M27 (The Dumbbell Nebula) while playing with this.

[jslight]

I also noticed the jumps on both axes when trying to nudge the telescope at low speed (~2-16 x sidereal).

After some more research, I believe I am experiencing the 12% Low Voltage threshold of the DRV8825s while using microstepping (mentioned here: https://www.astroeq.co.uk/forum/index.php/topic,80.0.html).  If that is the cause, I'm not sure why I wasn't noticing problems with Windows or the ST-4 cable, but my steppers are NEMA17 5.4V 0.85A which should place them below that threshold.  I am attempting the diode fix; I will post the results in a few days.

[jslight]

I removed the steppers from my mount, put them on the workbench, and wired up one of them with the diodes.  I then performed all kinds of troubleshooting tests.

It seems I misunderstood the term "ticking" in that post.  It was referring to small ticks (< 1° stepper rev) with motion similar to the second hand of an analog clock.  I didn't even notice these small ticks before due to the gear ratios while on the mount.  The diodes definitely worked for smoothing out the "ticking".  I'm still deciding whether to keep them since I didn't notice the effect before and they consume extra power from my battery, I'll have to test the guiding accuracy and image quality later.

Unfortunately, the problem I am having is with much larger jumps.  I have been able to fairly regularly reproduce the jumps with both steppers on the bench (with and without diodes, no difference).  They only occur while performing multiple small blip-like movements in the same direction at low speed, and only with commands sent from INDI (not Windows or ST-4 like I had originally thought).

Using the mount position adjustment GUI of Ekos, a brief click on any direction would normally move the stepper a small amount.  A second click (sometimes more) would then usually cause the jump.  After the jump, that direction becomes unusable.  If you change direction, the unusable direction becomes usable again.

I tested it with PHD2 using the INDI EQMod driver (without Ekos) and experienced the same jumping effect.  The stepper will jump anywhere from a couple degrees to well over 90° (sometimes but rarely, like five full stepper revolutions); though the distance of the jumps seems to be mostly consistent with repeated attempts without adjustments.

I tried disabling "gear changes" and reducing micro-stepping all the way down to 4 in the config utility, both individually and together; there were changes in the distance of jumps, but none worked correctly.

After these tests, I think the problem resides within the INDI EQMod driver to AstroEQ interface.  I attempted to gather a debug log of the EQMod (AstroEQ) connection from Ekos/INDI, but when trying to enable the debugging, it immediately disables itself.   

[jslight]

Ekos changed the debugging a little with a recent update, you have to enable it using the "Logs" button on the main screen of Ekos.

I think I might have found where the problem is happening.  Notice on the second nudge, that the COMMs are missing for the CheckMotorStatus() call; it then goes straight into SetSpeed().  From the first nudge, you can see that these COMMs might have triggered a StopWaitMotor() call with its own COMMs.  I don't know much about INDI driver commands, some help would be appreciated.

First nudge (works correctly):

Code: [Select]

"[DEBUG] SlewDE() : rate = -4 "
"[DEBUG] Slewing DE at -4.00 4.00 121 144.867900 "
"[MOUNT] SetMotion() : Axis = 2 -- dir=backward mode=slew speedmode=lowspeed "
"[SCOPE] CheckMotorStatus() : Axis = 2 "
"[COMM] dispatch_command: \":f2\", 4 bytes written "
"[COMM] read_eqmod: \"=501\", 5 bytes read "
"[MOUNT] StopWaitMotor() : Axis = 2 "
"[COMM] dispatch_command: \":K2\", 4 bytes written "
"[COMM] read_eqmod: \"=\", 2 bytes read "
"[COMM] dispatch_command: \":f2\", 4 bytes written "
"[COMM] read_eqmod: \"=501\", 5 bytes read "
"[COMM] dispatch_command: \":G211\", 6 bytes written "
"[COMM] read_eqmod: \"=\", 2 bytes read "
"[MOUNT] SetSpeed() : Axis = 2 -- period=289 "
"[COMM] dispatch_command: \":f2\", 4 bytes written "
"[COMM] read_eqmod: \"=701\", 5 bytes read "
"[COMM] dispatch_command: \":I2210100\", 10 bytes written "
"[COMM] read_eqmod: \"=\", 2 bytes read "
"[MOUNT] StartMotor() : Axis = 2 "
"[COMM] dispatch_command: \":J2\", 4 bytes written "
"[COMM] read_eqmod: \"=\", 2 bytes read "

Second Nudge (jumps):

Code: [Select]

"[DEBUG] SlewDE() : rate = -4 "
"[DEBUG] Slewing DE at -4.00 4.00 121 144.867900 "
"[MOUNT] SetMotion() : Axis = 2 -- dir=backward mode=slew speedmode=lowspeed "
"[SCOPE] CheckMotorStatus() : Axis = 2 "
"[MOUNT] SetSpeed() : Axis = 2 -- period=289 "
"[COMM] dispatch_command: \":f2\", 4 bytes written "
"[COMM] read_eqmod: \"=301\", 5 bytes read "
"[COMM] dispatch_command: \":I2210100\", 10 bytes written "
"[COMM] read_eqmod: \"=\", 2 bytes read "
"[MOUNT] StartMotor() : Axis = 2 "
"[COMM] dispatch_command: \":J2\", 4 bytes written "
"[COMM] read_eqmod: \"=\", 2 bytes read "


[jslight]

After a little digging though the INDI EQMod driver source code on github, I can see that the CheckMotorStatus method only updates if at least a certain amount of time has passed since the previous update (still could be the problem).  I also see, that what I assumed were INDI driver commands, is actually the SkyWatcher Protocol implemented by the EQMod driver.

I'm still not sure if the problem is in the INDI EQMod driver or AstroEQ firmware.  I'm posting this issue on the INDI forum as well.

[jslight]

SUCCESS!!!! I solved my problem.

After finding documentation on the SkyWatcher Protocol, I went back through the INDI debug log and tried to make sense of the state of each piece involved in the process.  After looking over the commands and digging into the AstroEQ firmware source code, I finally discovered what has been causing the problem.  When stopping the motors after a movement, the "GVal" is reset to a value of 0 by motorStopRA and motorStopDC, to "switch back to slew mode", except that the proper value for slew mode is 1 (at least according to the motionIsSlew(), motionIsGoto(), and motionIsLowSpeed() methods of AstroEQ.c).  A value of 0 defines high-speed goto mode, which is being set when stopping the motor after the first movement.  Then, because the :G command is not repeated by the INDI EQMod driver for movements in the same direction and at the same sidereal rate before the next :J command, the :J causes it to switch to high-speed.

Further down in the debug log I noticed this:

First Nudge:

Code: [Select]

"[MOUNT] StartMotor() : Axis = 2 "
"[COMM] dispatch_command: \":J2\", 4 bytes written "
"[COMM] read_eqmod: \"=\", 2 bytes read "
"[SCOPE] Compute local time: lst=10.38736394 (10:23:14.51) - julian date=2458362.30804270 "
"[COMM] dispatch_command: \":j1\", 4 bytes written "
"[COMM] read_eqmod: \"=E4377A\", 8 bytes read "
"[SCOPE] GetRAEncoder() = 8009700 "
"[COMM] dispatch_command: \":j2\", 4 bytes written "
"[COMM] read_eqmod: \"=264084\", 8 bytes read "
"[SCOPE] GetDEEncoder() = 8667174 "
"[SCOPE] Current encoders RA=8009700 DE=8667174 "
"[ALIGNMENT] Status: Mnt. Algnt. NORTH Date 2458362.308043 encoders RA=8009700 DE=8667174 Telescope RA 8.486128 DEC 89.600030 "
"[ALIGNMENT]  Direction RA(deg.)  28.518543 DEC 89.600030 TDV(x 0.006134 y -0.003333 z 0.999976) "
"[ALIGNMENT] Failed TransformTelescopeToCelestial: Scope RA=8.48613 Scope DE=89.600030, Aligned RA=8.486128 DE=89.600030 "
"[COMM] dispatch_command: \":f1\", 4 bytes written "
"[COMM] read_eqmod: \"=101\", 5 bytes read "
"[COMM] dispatch_command: \":f2\", 4 bytes written "
"[COMM] read_eqmod: \"=311\", 5 bytes read "             <----------- response = motor 2 (Dec): low-speed, reverse, slew-mode, running, initialized
"[SCOPE] GetRAPeriod() = 9 "
"[SCOPE] GetDEPeriod() = 289 "
"[DEBUG] StopDE() : calling DE StopWaitMotor "
"[COMM] dispatch_command: \":f2\", 4 bytes written "
"[COMM] read_eqmod: \"=311\", 5 bytes read "            <------------ same response continues as long as motor is moving
"[MOUNT] StopWaitMotor() : Axis = 2 "
"[COMM] dispatch_command: \":K2\", 4 bytes written "
"[COMM] read_eqmod: \"=\", 2 bytes read "
"[COMM] dispatch_command: \":f2\", 4 bytes written "
"[COMM] read_eqmod: \"=311\", 5 bytes read "            <------------ same response
"[COMM] dispatch_command: \":f2\", 4 bytes written "
"[COMM] read_eqmod: \"=311\", 5 bytes read "            <------------ same response
"[COMM] dispatch_command: \":f2\", 4 bytes written "
"[COMM] read_eqmod: \"=301\", 5 bytes read "            <------------ motor has stopped moving

Second Nudge:

Code: [Select]

"[MOUNT] StartMotor() : Axis = 2 "
"[COMM] dispatch_command: \":J2\", 4 bytes written "
"[COMM] read_eqmod: \"=\", 2 bytes read "
"[SCOPE] Compute local time: lst=10.38794952 (10:23:16.62) - julian date=2458362.30806703 "
"[COMM] dispatch_command: \":j1\", 4 bytes written "
"[COMM] read_eqmod: \"=E4377A\", 8 bytes read "
"[SCOPE] GetRAEncoder() = 8009700 "
"[COMM] dispatch_command: \":j2\", 4 bytes written "
"[COMM] read_eqmod: \"=FF3F84\", 8 bytes read "
"[SCOPE] GetDEEncoder() = 8667135 "
"[SCOPE] Current encoders RA=8009700 DE=8667135 "
"[ALIGNMENT] Status: Mnt. Algnt. NORTH Date 2458362.308067 encoders RA=8009700 DE=8667135 Telescope RA 8.486713 DEC 89.612687 "
"[ALIGNMENT]  Direction RA(deg.)  28.518543 DEC 89.612687 TDV(x 0.005940 y -0.003227 z 0.999977) "
"[ALIGNMENT] Failed TransformTelescopeToCelestial: Scope RA=8.48671 Scope DE=89.612687, Aligned RA=8.486713 DE=89.612687 "
"[COMM] dispatch_command: \":f1\", 4 bytes written "
"[COMM] read_eqmod: \"=101\", 5 bytes read "
"[COMM] dispatch_command: \":f2\", 4 bytes written "               <---------- first query of Dec motor status
"[COMM] read_eqmod: \"=701\", 5 bytes read ":                      <---------- status: high-speed, reverse, slew-mode, stopped, initialized


I tested changing "GVal" to 1 when stopping the motors and it fixed the problem, though I'm not sure if it will affect any other functionality.
Entire Second Nudge after fix:

Code: [Select]

"[DEBUG] SlewDE() : rate = 4 "
"[DEBUG] Slewing DE at 4.00 4.00 121 144.867900 "
"[MOUNT] SetMotion() : Axis = 2 -- dir=forward mode=slew speedmode=lowspeed "
"[SCOPE] CheckMotorStatus() : Axis = 2 "
"[MOUNT] SetSpeed() : Axis = 2 -- period=289 "
"[COMM] dispatch_command: \":f2\", 4 bytes written "
"[COMM] read_eqmod: \"=101\", 5 bytes read "
"[COMM] dispatch_command: \":I2210100\", 10 bytes written "
"[COMM] read_eqmod: \"=\", 2 bytes read "
"[MOUNT] StartMotor() : Axis = 2 "
"[COMM] dispatch_command: \":J2\", 4 bytes written "
"[COMM] read_eqmod: \"=\", 2 bytes read "
"[SCOPE] Compute local time: lst=17.15791077 (17:09:28.48) - julian date=2458362.58937856 "
"[COMM] dispatch_command: \":j1\", 4 bytes written "
"[COMM] read_eqmod: \"=E4377A\", 8 bytes read "
"[SCOPE] GetRAEncoder() = 8009700 "
"[COMM] dispatch_command: \":j2\", 4 bytes written "
"[COMM] read_eqmod: \"=BE4084\", 8 bytes read "
"[SCOPE] GetDEEncoder() = 8667326 "
"[SCOPE] Current encoders RA=8009700 DE=8667326 "
"[ALIGNMENT] Status: Mnt. Algnt. NORTH Date 2458362.589379 encoders RA=8009700 DE=8667326 Telescope RA 15.256675 DEC 89.550703 "
"[ALIGNMENT]  Direction RA(deg.)  28.518543 DEC 89.550703 TDV(x 0.006890 y -0.003744 z 0.999969) "
"[ALIGNMENT] Failed TransformTelescopeToCelestial: Scope RA=15.2567 Scope DE=89.550703, Aligned RA=15.256675 DE=89.550703 "
"[COMM] dispatch_command: \":f1\", 4 bytes written "
"[COMM] read_eqmod: \"=101\", 5 bytes read "
"[COMM] dispatch_command: \":f2\", 4 bytes written "
"[COMM] read_eqmod: \"=111\", 5 bytes read "                 <------------ Motor 2 (Dec): low-speed, forward, slew-mode, running, initialized     WOOOOO!!!
"[SCOPE] GetRAPeriod() = 9 "
"[SCOPE] GetDEPeriod() = 289 "
"[DEBUG] StopDE() : calling DE StopWaitMotor "
"[COMM] dispatch_command: \":f2\", 4 bytes written "
"[COMM] read_eqmod: \"=111\", 5 bytes read "
"[MOUNT] StopWaitMotor() : Axis = 2 "
"[COMM] dispatch_command: \":K2\", 4 bytes written "
"[COMM] read_eqmod: \"=\", 2 bytes read "
"[COMM] dispatch_command: \":f2\", 4 bytes written "
"[COMM] read_eqmod: \"=111\", 5 bytes read "
"[COMM] dispatch_command: \":f2\", 4 bytes written "
"[COMM] read_eqmod: \"=111\", 5 bytes read "
"[COMM] dispatch_command: \":f2\", 4 bytes written "
"[COMM] read_eqmod: \"=101\", 5 bytes read "

I have forked your github repo and submitted a pull request containing the changes.

[TCWORLD]

Sorry for the delay in responding, I've been away on holiday.

Well spotted. I made a mistake when rewriting the motor routines in V8.0, which has ended up being carried through.

I've merged in the changes and uploaded a new release firmware which can be downloaded with the "Check for New Version" in the configuration utility.

[jslight]

Great, glad I could help.  Thanks for an awesome product.

I found another bug when trying to slew North or West (forward) at low speed after the first unpark, it has a fast moving ticking motion.  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.

Code: [Select]

"[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 "
"[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.  Because of the change I made to the GVal being reset properly to 1 when stopping the motor, it only occurs on the very first movement of an axis.

The problem is due to miscommunication between the components, but I'm not sure whether it should be fixed within the INDI EQMod driver or the AstroEQ firmware.

UPDATE: I forgot to mention that this also occurs if you haven't slewed the RA yet (to workaround the bug) and try to enable tracking (tracking = lowspeed forward slew).  It results in the same high speed ticking.  The ticking effect is just the result of the proper :I value for what should be lowspeed.

[TCWORLD]

I think the best solution would be to change modes, or just the high speed flag whenever the :G command is issued. However in order for that to work, it would require that a :G command is never issued while the motors are running. I believe that is the case, but I'm not 100% certain.

I could do a best of both worlds, and update the flag immediately when :G is issued, only if the axis is not currently running.

[TCWORLD]

I've created a new branch on the github repo (GValUpdateFix). If you could give that code a try (you'll need to compile) and let me know if that solves the weird behaviour.

If it works, I'll have to give it a thorough testing with EQMOD to see if there are any unintended side-effects.

[jslight]

Wow, that was quick!

That definitely fixes the problem.

it would require that a :G command is never issued while the motors are running. I believe that is the case, but I'm not 100% certain.

I also believe this is the case.  It seems to be just with initialization that :G it sent without :J; nice solution.

I'll do some usage testing tonight if the winds cooperate.

[jslight]

Side-effect #1:
Repeated slews at highspeed in the same direction are toggling the highspeed flag, resulting in alternating highspeed/lowspeed slews.  It seems to be happening when :J is received, or at least that's when :f returns such.

[jslight]

LOL, we've gone full circle.  The motorStopRA/DC calls are resetting the GVal back to lowspeed slew mode, but doing so while the motors are running, so the change isn't effected until :J is called, causing :f responses to make INDI EQMod still think we are in the correct mode, thus not sending :G.

Code: [Select]

            if(readyToGo[RA] == MOTION_START_REQUESTED){
                //If we are ready to begin a movement which requires the motors to be reconfigured
                if(cmd.stopped[RA] == CMD_STOPPED){
                    //Once the motor is stopped, we can accelerate to target speed.
                    signed char GVal = cmd.GVal[RA];                      <------------------this has been reset to 1
                    if (canJumpToHighspeed){
                        //If we are allowed to enable high speed, see if we need to
                        byte state;
                        if (motionIsLowSpeed(GVal)) {                       <-------------------therefor this is true
                            //If a low speed mode command
                            state = modeState[SPEEDNORM]; //Select the normal speed mode
                            cmd_updateStepDir(RA,1);
                            cmd.highSpeedMode[RA] = false;
                        } else {
                            state = modeState[SPEEDFAST]; //Select the high speed mode
                            cmd_updateStepDir(RA,cmd.gVal[RA]);
                            cmd.highSpeedMode[RA] = true;
                        }
                        ...
Only reset GVal if it was previously in GOTO mode?

[jslight]

Yep, this seems to work.  I tested that all the problems we have been working on haven't relapsed; I also tested repetitive and alternating highspeed slews, lowspeed slews, highspeed gotos (far), lowspeed gotos (close), and tracking.  This could still affect other areas (such as ASCOM or standalone mode), I'll submit the changes to your github branch.