Dear INDI developers,
First of all, I'd like to thank you guys for putting together such a wonderful piece of open source software. The freedom to incorporate it into the setup that is engineered to my liking is refreshing. Vendor offered software are often bound to a specific operating system (most likely windows), which is such a presumptuous limitation on what the end-user might want to use. Heck, if it's not for the binary-only, closed-source libASI, I'd rather be running my setup on FreeBSD. But oh well, one battle at a time.
I'm posting here because I ran into an issue that doesn't seem to have been mentioned either here or at the github issues. In short, if I connect to my EQ6-R Pro using the on-board USB port, and issues a manual slew command (from the control pad under the 'Mount' tab in Ekos), the mount would slew according to the command. But when I let go of the slew button, the mount would come to a complete stop, and then all the sudden start to slew again in the same direction, however this time accompanied by a loud, grinding, and frankly rather unsettling noise. Hitting the "stop motion' button in the Ekos control panel results in no effects. The only way to stop the slewing is to turn off the mount using the power switch.
Interestingly, I observed that this problem is not present if I maintain the same physical setup, but instead use either the SynScan app (downloaded from Sky-Watcher website) or the EQMOD-ASCOM (downloaded from sourceforge) driver, albeit they only run in Windows. The mount also works properly if I use INDI / Ekos but instead connect to the hand-controller USB port, and put the hand controller in PC Direct mode.
Using "socat", I was able to record the serial traffic between the computer and the mount under three different setups: 1) SynScan app connected to the on-board USB port; 2) INDI / Ekos connected to the hand controller USB port; and 3) INDI / Ekos connected to the on-board USB port. Setup 3 is what causes the slew problem. Using some python code I wrote to pretty-print the logs (attached, first column is what got sent to the mount, second column is the mount's response, and things after the hash sign are my comments), I was able to observe that the init and start slew procedures across the three setups are very similar. But the stop motion procedure is a bit weird on INDI. After issuing a StopMotion (K1) command and wait for the motor to come to a stop, INDI would issue a second StartMotion command (J1), which is then immediately followed by a StopMotion (K1) command. This sequence is evidenced by the INDI log snippet (from using the hand-controller, or setup 2):
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.
This is somehow tolerated by the hand controller (perhaps lower baud rate?), but results in the motor spinning out of control if connected directly to the on-board USB port. In fact, after the second StopSlew, the motor board would respond that the motor has stopped ("f1 -> 101") but in reality it's still slewing.
I attempted to go over the indi-eqmod driver code, but was unable to identify any apparent culprit. As the driver code seems to only implement call-backs for various commands, I started to wonder if it's within the main INDI framework that the second slew command was scheduled. But I'm very unfamiliar with the INDI code base so my judgement is most likely poor.
I'd love to help in any ways I can to nail this bug. It would be very appreciated if I can get rid of the hand controller. It creates additional cable clutter, and I have to go over the initial setup screen every time I turn the mount on, 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" package, mutlaqja/ppa
INDI version: 1.9.7 via mutlaqja/ppa
indi-eqmod version: compiled locally from indi-3rdparty on v1.9.6 tag. The binary came with mutlaqja/ppa for some reason crashes on my setup
USB-to-Serial chip on-board: PL2303 @ 115200
USB-to-Serial chip hand-controller: PL2303 @ 9600
Mount motor control board firmware version: 3.25
Best Wishes
Yi
Read More...