Dear INDI Forum,

First of all, thank you guys for putting such an awesome piece of open source software. The ability to integrate kstars / ekos into the computer and operating system I prefer is a tremendous benefit compared to vendor released software that are often bound to a given operating system (most likely windows), which is such a presumptions limitation on end users (if it's not for the closed source, binary only libASI, I'd be running my imaging rig on FreeBSD, but oh well, one battle at a time).

I'm posting on this forum because I ran unto a strange behavior on my EQ6-R Pro mount using the built in USB port. I searched this forum and indi-3rdparty github issues and didn't find similar reports. In short, if I connect to the built in USB port using eqmod driver, and issue a manual slew command using the mount control pad under the "Mount" tab in Ekos, the mount slews accordingly. However when I let go of the slew button, the mount would come to a complete stop, but all the sudden starts to slew again in the same direction. The second slewing is accompanied with a rather disturbing, grinding noise. Hitting the "Stop Motion" button in the control panel has no effect. The only way to stop the motion is to turn off the mount.

Interestingly, if I instead connect the USB cable to the hand controller under PC Direct mode, the problem is then no more. All mount control operations work properly. But I would very much like to get rid of the hand control. Alternatively, if I use the SynScan app downloaded from SkyWatcher website, everything works fine even if I'm connected directly to the on-board USB port. I also tested the EQMod ASCOM driver (downloaded from sourceforge), which also works fine using the onboard connection.

This led me to believe that the issue is with INDI or indi-eqmod driver. Using socat, I was able to log the serial communications between my computer and the mount under three different setups: 1) using SynScan app and on-board USB port; 2) using INDI and hand-controller USB port; and 3) using INDI and on-board USB port (where things don't work). I've attached these logs (pretty-printed using a python program I wrote. First column is what got sent to the mount; second column is what the mount responded; things after "#" are my annotations). In brief, I noticed that the init and start-slew procedures are very similar, but the way INDI handles stop-slew is a bit weird. With INDI setup, after I let go of the slew button, the motor would come to a stop as requested by the driver. But somehow another Motion Start (J1) command is sent again to the mount, which is immediately followed by a MotionStop command (K1). This is somehow tolerated if the hand controller is used ( perhaps the lower baud rate? ), but causes the motor to spin out of control if connected directly to the on-board USB (even the motor status command (f1) is getting "motor is stopped" response as the axis rotates). This is also evidenced by the INDI log:

2022-08-26T05:04:54: [INFO] EQMod Mount is offline.
2022-08-26T05:04:43: [INFO] West Slew stopped
2022-08-26T05:04:43: [INFO] Starting West slew.
2022-08-26T05:04:41: [INFO] West Slew stopped
2022-08-26T05:04:39: [INFO] Starting West slew.
2022-08-26T05:04:26: [INFO] Observer location updated: Latitude(redacted) Longitude (redacted)
2022-08-26T05:04:26: [INFO] Observer location updated: Latitude (redacted) Longitude (redacted)
2022-08-26T05:04:26: [INFO] Setting UTC Time to (redacted)
2022-08-26T05:04:26: [INFO] Observer location updated: Latitude (redacted) Longitude (redacted)
2022-08-26T05:04:26: [INFO] Mount is unparked.
2022-08-26T05:04:26: [WARNING] Init() : Setting both ST4 guide rates to 0.5x (2)
2022-08-26T05:04:26: [WARNING] Init() : Setting default Init steps -- RAInit=8388608 DEInit = 8388608
2022-08-26T05:04:26: [WARNING] Init() : Motors already initialized
2022-08-26T05:04:26: [INFO] Mount has PPEC.
2022-08-26T05:04:26: [INFO] EQMod Mount is online.
2022-08-26T05:04:26: [INFO] Successfully connected to EQMod Mount.

I started to dig into the indi-eqmod driver code, but didn't find any immediate culprits. Since the driver pretty much only implements callbacks, I start to wonder if it's within the INDI framework where the second Start slew command is being scheduled. But I'm not familiar with the INDI code base at all so my judgement is most likely poor on this one.

Let me know if you have any follow up questions. I'd love to help in ways I can to nail this bug. Getting rid of the hand-controller would be much appreciated since it creates additional cable clutter, and I have to go through the initial screens to turn on Direct PC mode every time I turn on the mount, which is such a chore.

Some technical details:
Operating System: Ubuntu Server LTS 22.04
Kernel Version: 5.15.0
KStars version: 3.6.0 via the "kstars-bleeding" mutlaqja/ppa package
INDI version: 1.9.7 via mutlaqja/ppa package
indi-eqmod version: compiled from indi-3rdparty github repository v1.9.6 tag (the binary package from mutlagja/ppa crashes for some reason so I compiled from scratch)
USB-to-Serial chip on-board: PL2303 @ 115200
USB-to-Serial chip hand-controller: PL2303 @ 9600
Mount firmware version: 3.25

I was unable to replicate your issue. I am also using the built-in USB port on the mount, connected to my ODroid N2+ running the latest INDI and KStars built from source. Well, the latest as of about a week ago.

Does this happen every single time, or is there some special sequence to trigger this issue?

Hi Kevin,

Thanks for replying. This happens every single time a manual slew command is issued. I only tried a few times because the grinding noise makes me really nervous as my mount is only a few months old. Actually, shortly after I received the mount, I had to RMA it back to have the motor control board replaced due to an unrelated issue (won't power on). This problem is also observed with that control board (with every slew command) before it stopped working.

After some more experimenting, I was able to replicate the issue. It happens if I quickly tap the direction arrow multiple times in rapid succession. The mount then makes a terrible noise, and is unresponsive until I power cycle the mount.

I'll see if I can debug this over the weekend.

Thank you Kevin. Sorry for some reason I cannot post reply earlier.

Cheers

So I spent the day messing around with this. It does appear you were on the right track when you suggested the lower baud rate of the hand controller might be why it's working. It seems at 115200 baud, I have to add a small delay after sending commands in order for it to properly recognize the commands. Without the delay, when doing manual slews, it wouldn't process the commands properly.

I was getting the problem where it would slew uncontrollably, and not respond. It would even slew at the wrong speed, causing the terrible noise (stepper motor missing steps because it's being driven too fast).

However, I never got the "extra" go commands that you saw. I never got a "spurious" J1 followed by a K1.

Are you able to build the indi-eqmod driver from source? If so, I'd like you to try adding the small delay after sending commands to see if it fixes the problem for you.

In the indi-eqmod folder, in the skywatcher.cpp file, around line 1730, after the read_eqmod call, and before the "return true", add the following lines:

So the final result looks like this:

Looks like the delay has fixed the problem. Kudos!!

I did some additional testing on the double slew start. Turns out it's a problem of my setup. I run VNC on the mini PC and use an ipad client to connect to it so I can control it when I'm near the mount. My actual desktop computer is in the basement. I never dared to try slewing from the basement in fear of not able to reach the mount and shut it off before it runs my telescope into the ground. Problem though, is that with the iPad VNC client, to perform a click and hold, I need to double tap the screen with the second tap being a hold. This potentially is transmitted to the VNC server as a second click. I don't know how to record mouse click events in X11 so I can't be sure. With the delay in place, my mount now slews properly albeit still seeing two slew starts. After I let go of the slew button, it would come to a stop, start again, and then stop again but properly. This observation emboldened me to try slewing from the basement using a desktop VNC client, and lo and behold I'm only seeing one slew event. So it's likely the ipad vnc client that is causing the double slewing.

Thank you again for the quick fix!

Cheers and Clear Sky!

I'm glad this fixed the problem for you.

However, I'm concerned. Why does manually slewing need this delay and nothing else needs it? Why does it need it? It's not like we're sending a bunch of commands in bulk. We send one command, wait for a response, send another command, wait for a response, etc.

:shrug:

It works. I guess that's the important part.

Yup as long as it works

I had some more time playing with the setup now. I did notice a potential side effect of the delay. The symptom is that, when I use the "slew to target" function in the alignment module, I seemingly can never get the error to be under 40 arc-second no matter how many time the alignment module tries to correct. Before the code change I can easily get under 20 arc-second, usually within 2 corrections. If I understood the code correctly, this 100ms delay is introduced for ALL commands going to the mount (including the polling of axis position and motor status). I wonder if this causes enough total delay between plate solving and the actual mount movement to result in ~40" slewing error. Furthermore, I wonder if the delay could potentially causes other side effects.

I'm already running an imaging sequence for tonight but tomorrow I can try to flip back to the old code and see if I can pin this on the code change.

Well, some clouds rolled in so I did some A/B testing. Looks like the delay code is indeed causing Slew to Target inaccuracies.

Due to fear of uncontrollable axis spinning, I went back to the hand controller PC Direct mode. If I comment out the delay code, I get consistently high "Slew to Target" accuracy. Tested with a few objects all over the sky, I usually get under 20" accuracy with the second image capture. I then un-commented the delay code. My accuracy now would always fall somewhere between 50" and 30", and never below 20". I then commented out the code again, and yup, my accuracy went back up.

I also noticed that my internal guiding error has doubled. I normally get 0.8" RMS. With the delay code, I'm reading the upper 1" and sometimes even 2.5" errors. Admittedly this is a different night. But my RMS has been stable for quite some time now and seeing it at 2" is definitely strange.

Yeah, I was afraid there would be side effects. I will continue trying to take a more targeted approach instead of the shotgun approach.

I think I found the real culprit. It seems it's the extra "K1/K2" commands (stop axis commands). It appears if it sends a stop axis command when the axis is already stopped, if you send the next command too quickly, it gets ignored.

Can you try removing the delay code I sent earlier, and instead modify the "StopWaitMotor()" method, around line 1650, to look like this:

It's working for me during the daytime, but I can't test under the stars, since we have nothing but rain in the forecast for the next few days. In particular, I think it should return your guiding performance back to the way it was before.

-- Kevin