Of course!! Thank you so much for your help so far. This is really helpful. I'm also more familiar with the indi-eqmod code base now that I can keep tweaking it if I have time. I have mostly got rid of my manual slew needs. About the only time it's necessary is occasionally the mount would wrongfully believe it is pointed below the horizon, therefore refusing to turn on tracking, which in turn prevent the alignment module from syncing to plate solving solutions. But I can slew from my desktop. It looks like it's my iPad setup that is causing the spurious second slew which is really the cause of the problem.
Thank you again! I wish there is a way I can send you a beer 
Read More...
Also, just another observation: even with the global delay, the slewing problem is definitely better but not completely gone. I experimented with the mount quite extensively today. Turns out, even with the global delay, I'm seeing the mount go out of control in about one in 4 to 5 manual slews.
Read More...
I used my socat hack today to record what happens during a problematic slew. The full log is attached but here is what's most relevant:
## this is probably in response to the second, spurious slew command
[14:10:10.650601] :f1. [14:10:10.651333] =101.
[14:10:10.651754] :G130. [14:10:10.652651] =.
[14:10:10.652836] :f1. [14:10:10.653530] =501.
[14:10:10.653844] :I1BA0000. [14:10:10.655067] =.
[14:10:10.655282] :J1. [14:10:10.656078] =.
[14:10:10.656259] :f1. [14:10:10.656958] =501.
[14:10:11.650969] :j1. [14:10:11.652099] =08387D.
[14:10:11.652672] :j2. [14:10:11.653672] =97BE7B.
[14:10:11.654226] :f1. [14:10:11.654882] =101.
[14:10:11.655379] :f2. [14:10:11.655995] =101.
[14:10:12.658263] :j1. [14:10:12.659286] =A54D7E.
[14:10:12.660084] :j2. [14:10:12.661261] =97BE7B.
[14:10:12.661986] :f1. [14:10:12.662842] =101.
## this is probably when I turned off the mount power
[14:10:12.663561] :f2. [14:10:12.664345] =101.............8...l.............
[14:10:13.666533] :j1. [14:10:13.667306] j.First column is what sent to the mount, second column is what the mount responded. Timestamps are in square brackets. This is what happened after the mount had come to a complete stop, and started to handle the second spurious slew command. Notice that, after the J1 command is sent, the motor status as reported by the mount is "motor stopped" (:f1 -> =101.). But if you look at the axis position queries (j1 commands), you can see that the axis was indeed moving (from 0x08387D to 0xA54D7E before I shut the mount off).
Another thing I noticed is that the second K1 was never sent. This is probably because of the new
if(*motorrunning)I got the sense that it is whatever action before the J1 command that was causing the mount control board to be in an undefined state... I'll keep playing with this and report back if I find anything.
Read More...
Man I hope it clears up for you soon. I guess clear nights is one of a small number of benefits of living so close to a desert
I compiled the new code and, unfortunately, the uncontrollable slewing came back. I included the entire modified StopWaitMotor function at the end just for you to check (old code is commented out instead of deleted)
Good news though, is that the "Slew to Target" and tracking accuracies went back to what they were before.
I tested a few other functions and can pretty much confirm that the only time problems occur is when I use manual slew via my ipad vnc client, which is the cause of the second spurious start and immediately stopped slew command. All programmatic slews work properly, such as "GoTo target", "Slew to Target", and perhaps what matters to me the most, "Park" command (It's the last large movement during an unattended imaging session, occurs 4:30AM while I'm asleep). Since the second slew command is not really caused by anything KStars or Ekos/INDI related stuff, it's technically not a bug anymore On the other hand, knowing a specific sequence of action can leads to potential equipment damage is a bit nerve wracking.
I'm running a capture sequence now. What I can do tomorrow during day-time is to try another "socat" recording, but this time with timestamps included so you can take a look at the intervals these commands are sent. What I don't understand is, even if the second K1 command gets ignored, the mount should just keep moving regularly, instead of moving erratically with loud noise and not responding to subsequent stop commands, all the while reporting (via f1) that the motor is stopped.
Here is the code I tested:
void Skywatcher::StopWaitMotor(SkywatcherAxis axis)
{
bool *motorrunning;
struct timespec wait;
ReadMotorStatus(axis);
if (axis == Axis1 && RARunning)
LastRunningStatus[Axis1] = RAStatus;
if (axis == Axis2 && DERunning)
LastRunningStatus[Axis2] = DEStatus;
//DEBUGF(telescope->DBG_MOUNT, "%s() : Axis = %c", __FUNCTION__, AxisCmd[axis]);
//dispatch_command(NotInstantAxisStop, axis, nullptr);
//read_eqmod();
if (axis == Axis1)
motorrunning = &RARunning;
else
motorrunning = &DERunning;
//wait.tv_sec = 0;
//wait.tv_nsec = 100000000; // 100ms
//ReadMotorStatus(axis);
//while (*motorrunning)
//{
// nanosleep(&wait, nullptr);
// ReadMotorStatus(axis);
//}
if (*motorrunning)
{
DEBUGF(telescope->DBG_MOUNT, "%s() : Axis = %c", __FUNCTION__, AxisCmd[axis]);
dispatch_command(NotInstantAxisStop, axis, nullptr);
wait.tv_sec = 0;
wait.tv_nsec = 100000000; // 100ms
ReadMotorStatus(axis);
while (*motorrunning)
{
nanosleep(&wait, nullptr);
ReadMotorStatus(axis);
}
}
}Read More...
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.
Read More...
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.
Read More...
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!
Read More...
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.
Read More...
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...
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, 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, 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 40:45:23.0 (40.76) Longitude -111:53:27.0 (-111.89)
2022-08-26T05:04:26: [INFO] Observer location updated: Latitude 40:45:23.0 (40.76) Longitude -111:53:27.0 (-111.89)
2022-08-26T05:04:26: [INFO] Setting UTC Time to 2022-08-26T05:04:26, Offset -6
2022-08-26T05:04:26: [INFO] Observer location updated: Latitude 40:45:23.0 (40.76) Longitude -111:53:27.0 (-111.89)
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: PL2303
Mount firmware version: 3.25
Read More...