Last night I had a different experience: I set up the tripod/mount/telescope pointing very close to Polaris.  This time, the PA tool would take one image, start slewing, then would abort and park the mount (in the other side of the pier than what was happening before).

It wasn't clear why it was aborting, but after I used StarSense to do an ASPA, I was able to successfully run the PA tool in KStars (StarSense/ASPA was way closer than I expected!).

The thing is, even the ASPA didn't need much adjustment so I was very close to being polar-aligned right from the start.  I don't recall seeing any messaging indicating WHY the PA tool failed.  It did platesolve the first image IIRC.

I posted a message in the community forum asking for any tips on using the PA tool.  I have of course read all the KStars and Stellarmate documentation and watched the excellent videos.

Earlier this week I did a wipe and clean install of my Mac, then installed KStars/Ekos.  Walking through the setup wizard, a couple of the packages failed to install (python and astropy).  When I tried again, they said they were already installed (so clicking Setup now says "Homebrew, python and astropy are already installed" however I'm not sure if they were successful installs.

Upon connecting up to the scope last night, I discovered that the polar alignment tool can no longer automatically rotate 30 degrees.  It instructs me to wait until the mount completes its rotation, but it does not.  I can control the mount in every other way, including guiding, via the old Stellarmate OS running on RPi3 so I know Ekos is able to communicate with the mount.

Ekos just inexplicably lost the ability to automatically rotate the scope around the polar axis.

Note:  I cannot easily try the latest Stellarmate OS on RPi4 because I lost the ability to use a guide scope.  I may try to hook it up in the house today to see if I have the same polar alignment problem with rotation.

To recap, two issues:

1) When the PA is too far off, the PA tool seems to get confused and can slew the telescope to its limits.  I have not had this happen in quite a while, so I think we can close that issue.  These days the worst I seem to see is the PA correction vector being wider than the screen, but that's expected if my PA is off.

2) The issue regarding the PA tool not automatically slewing the mount appears to be a function of the SPEED dropdown, which defaults to 5x.  Changing this to 9x proves that it slews normally (I did NOT verify that it is actually slewing at 5x).  I recommend changing this default, as I imagine it would take some manner of minutes to slew 30 degrees at 5x.

Feel free to close this ticket, but I did not mark it as such because I recommended the default slew speed change.  Feel free to close it.

So the slew speed is actually determined from the current setting. Maybe I'll change that to the max by default.

Jasem, I had a rough time with polar alignments again tonight.  After getting Polaris in the right spot in my finder scope (I know this isn't a PA scope), I did a PA with Celestron's All-Star-Polar-Alignment routine (I almost always need to do this otherwise the KStars PA fails).  I then tried KStars PA and the mount immediately slewed to its limits again.

This led to an epiphany: I have an EdgeHD 9.25 with 0.7x reducer and an ASI1600MM-Pro camera.  The resulting FOV is 0.62° x 0.47°.  I just noticed in one of your videos that you need a 1° FOV.

This suddenly explains my difficulty.  Even with a reducer, my FOV is too small.  If I am very closely to being polar-aligned (after I do ASPA), it works.  But when I am close but not close enough, KStars slews the scopes to the limit.

Two suggestions:

1) After the first plate-solve (which always seems to work), warn the user if their FOV is too small.

2) When the FOV is too small, detect this and do not slew the scope to its limits.  I believe this to be a serious bug, because if a user's slew limits are not set this slew action could damage their gear.

These long-focal-length scopes really don't have many camera choices that would work.

The 1 degree limitation is no longer required, you can solve on smaller FOVs just fine. The problem you're describing actually has nothing to do with polar alignment per se, but we need logs to make sure.

Ekos calculates what coordinates we need to be at if we move 2 hours or 30 degrees, then it moves the mount W/E until we are very close to the target and then stop. Maybe the slew speed is too high? Again, the log might shed some light on this.

Good to know, thank you!  That description sounds interesting, except that it never stops to take the second image at the 30 degree mark, it rotates the ~120° or so until the mount stops.

The weather might be acceptable tomorrow night, so I will test varying the speed, direction and degree of slew and will report back with results and logs of the failures.  Thanks!

Created attachment 128444 [details]
Logs for polar alignment issue.

Hi Jasem, I only had a little time tonight before the clouds rolled in, but I did try the Ekos polar alignment routine several times.  The last few attempts with various mount directions, speeds, etc. are in the attached log.  Note, I was not even able to complete an Ekos polar alignment after completing the Celestron All-Star Polar Alignment.  The behavior I saw was sometimes the same (where it would slew to the limits without even stopping to take image #2), but other times it would slew to position #2, take the image, and then just sit there never actually completing the plate solve.  I do have all the index files loaded that make sense for me.

Note, I also tried VNCing into the RPi4 to try PA there, but had the same results (though that RPi4 didn't have all the index files loaded; for some reason I couldn't click on the checkboxes to download them).

So there is an issue in the mount.. the RA value is not changing yet you saw it is going all the way. So test this, in this position (where you start the PPA routine), go to INDI Control Panel --> Motion Contol.

Then click "West" and go then check the mount's RA value in main control or in Ekos mount contorl panel.. does it change? Try East and check again.

Jasem, during the PA routine the RA values only change intermittently -- but they always change when I use the hand controller, mount control pad or INDI motion control buttons.

During the PA attempt I had the mount control pad open so I could access both the motion controls and see the coordinates outside of the Alignment window.  Sure enough, usually the first PA attempt shows no RA change while the scope is slewing, and it slews to its limits.  When RA was NOT changing during a slew, if I stopped the PA routine and moved the mount back to its switches (or using the control pad) I would see RA changing.  Every time I move the scope with the control pad or the hand controller, I see RA changing.  But when the PA routine is running, it intermittently doesn't see RA change.  Sometimes, but not always, if I try again it works.  So, sometimes I can get a successful PA with as few as 3 or 4 attempts.  Sometimes, I can never get one.

I have a big video of this happening, but it's a large file.  Let me know if you want it.

SO just to confirm, if you use the PAA tool, hardly any changes in RA. But as soon as you use the Ekos Mount Panel to move it yourself Left/Right, the RA changes?

That is exactly right.  Every time I use the mount control pad or hand controller, I see RA change as the mount is slewing.  In the PA tool, it is only intermittent.

This was a fantastic observation you made.  Now I'm really watching out for the RA issue.  If it doesn't change, I stop the slew right away, re-home the mount and start over.  I think I left logging enabled last night, so I can send those if you think it'll help.  I suspect it's the same data as you had in the previous logs, though.

Note, this is on EKOS on Mac.  I confirmed the same overall behavior in StellarMate earlier in the week, but did not return to validate that the RA values don't change there as well.  I assume we'll see exactly the same thing there.

But this is really odd.. why would the RA not change as expected? If you have the handset itself, does the RA value change?

Jasem, I take that back.  I got the scope out again last night, and the first thing I did was open the mount control pad and slew in RA.  The values didn't change.  But when I slewed in DEC, suddenly the values changed in RA, too.  I couldn't trigger it again.  I don't know what this means.

I will check the handset values the next time I'm out, but I've never noticed that not changing.  I can also try another hand controller, on the off chance there's something going on with StarSense.

One other thing (sorry for piling on the observations):  In the PA tool, when it works perfectly it does seem to slew 30 degrees (twice).  Then there are times where it still works, but it slews *almost* to the limits (even with RA changing).  It's strange.  110-120° instead of the expected 60.

PLEASE READ:  This is probably a separate issue, but it might be related.  All of a sudden last night Ekos started acting very laggy (spinning MacOS beachball almost anytime I click on anything).  In the PA tool, when I clicked start it would wait almost a minute before taking the first photo.  The same thing would happen with subsequent images.  The focus module was unusable.  I gracefully quit the application and re-launched; same.  I rebooted the Mac (connected to RPi); same.  Rebooted the RPi; same.  It did not happen when I VNC'd into the Pi.  The reason I mention this is because if it hung right after I clicked the slew button, it might explain why RA didn't update and then it suddenly update later. Maybe the DEC trigger was just a timing coincidence.  I wonder about this regarding the PA issue above, too.  If it occasionally hangs after it sends the slew command, it might power past its 30 degrees.  

This is a 16GB MacBook Pro with 2.3 gHz quad-core i7, and nothing else running.  I don't think the machine was resource-constrained.

Jasem, you called it!  It seems that the StarSense hand controller does indeed have an issue.  If you power on the mount and try to slew in RA (either direction) before slewing in DEC, the RA values do not change.  When you slew in DEC, the RA values will change but can be non-sensical (jumping from 10 to 22 hours of RA in less than a second, before settling down).  I have reported this to Celestron, and will likely switch to the NexStar+ Hand Controller (which does not exhibit this behavior).

This was a new symptom while using KStars/EKos because I had recently been powering up the mount and going right into the Ekos PA routine.  Previously, I had been doing a StarSense alignment and ASPA, which was exercising the DEC motor and freeing up RA so it could update.  Strange behavior indeed.

It was intermittent because somewhere along the way I would move DEC, and the problem would mysteriously vanish.

I have not tested this at night with an assembled telescope yet; tomorrow, weather permitting.

Jasem, I believe this issue is resolved as a non-bug.  It entirely seems related to the RA-reporting oddity in the StarSense hand controller/firmware.  The issue did not occur with the NexStar+ hand controller, and I was able to repeatedly perform polar alignments on the first try.  I can't tell you how ecstatic I was to see this finally work properly!

THANK YOU SO MUCH for sticking through this issue.  Your support is phenomenal.  :-)

The only remaining question I have, if you feel like it, is: I did a PA, then did another (because it's so fast and enjoyable now!).  The second attempt was almost not worth correcting; the correction vector was maybe 2mm long on the screen.  However, when I went back a couple hours later, the vector was about an inch off.  All scope adjustments were completely tight, I was on a 15x15ft concrete pad, I had literally not even touched the scope, there was no wind, etc. I always "move to switches" immediately before starting any PA, so that shouldn't be it.  All I did was pain to different imaging objects.  In contrast, my cheap little SkyGuider Pro running a heavy RedCat/Guider combo held PA all night long.  Can you think of anything that might have introduced this error?  I am assuming the PA routine should be highly repeatable with very similar results.