What version of KStars are you running? Are you on 2.9.6 or are you running a nightly/bleeding-edge build? If the version you are using was built after June 3, perhaps it's possible that these changes are responsible? It seems likely to me that this is a regression of some sort, as I seriously doubt that the Polar Alignment Helper could have been broken ever since it was introduced a year ago and nobody would have noticed. It does look like some fairly major changes were made, so perhaps the bug was introduced there? These changes were made after 2.9.6 (the latest stable version) was released though, so unless you're running the bleeding-edge version, the problem would have to be older than that.

I'm running 2.9.6 bleeding, specifically

kstars-bleeding/xenial,now 6:2.9.6+201805251429~ubuntu16.04.1 amd64 [installed]

The recent changes just changed the workflow, not the calculations. It does look like the correct vector is mirrored. The code defines the correction vector as follows:
Now I noticed that I wasn't calculating the Position Angle between the Mount Axis Center & Celestial Pole, it was just measuring the magnitude between them. Could it be that the PA would determine the orientation of the correction vector? Maybe most folks had PAs that wouldn't warrant a "flip" but you did? Of course this is all in the air and speculation, so I added more debug statements.

Tonight, I will test it in my observatory. First I will do a normal check, then I will try to adjust the mount to reflect your misalignment and see how it goes.

Thanks for your efforts on this. I did the reverse movement using the vector provided and I think I have success at 22arcsecs off NCP - take a look at the attached screen capture. But, I no longer see Polaris in my polar scope, so either it is way out, or something else is going on. As I type this, I am running the Guiding Assistant in PHD2 - I'll get it run for 20min or so and see what it computes as the Polar Align error - it probably will be a bit more as I'm doing this in a wind between 25 and 35 kph. At least its dark...

I picked a star close to the intersection the meridian and the equator and ran the PHD2 guiding assistant for about 1000 seconds - it reported a polar alignment error of 6.4 minutes. Given it was windy and PHD2 had an issue with the calibration, I don't know how accurate the estimate was. It also reported a DEC drift rate of about -1.67" per minute - that would indicate more that a 22" polar align error I think.

fmozza,

I had recent problems with polar alignment, because I am using a diagonal
in front of the camera, which mirrors (horizontally flips) the image.

Are you using an imaging train that has an odd number of reflections?
That would cause a mirror image. I may be off here, but I did not get
a response to my initial entreaties, and my experiments led me to
use the capability of my camera driver to "flip" the image horizontally.

This *seems* to have fixed the problem for me, but your camera may
not have that capability, and I *still* may be incorrect, not having received
input from the developers. Yet, my "fix" seems to work.

See my previous posts on this subject, and weigh in if you like.

Gregory

I may be wrong, but if I understand the math being used to determine the alignment of the RA axis, it seems that the images being mirrored should not affect the result... or at least, if it does affect the output somehow, I'd consider that a bug. Astrometry.net is capable of handling images of either positive or negative parity (i.e. "normal" vs. "flipped,") so unless the Astrometry.net settings are incorrect, such as being told to only search for positive-parity solutions when the images actually have negative parity, they should still solve. Each of the three solved plates equates to a great circle on the celestial sphere, defined by the central coordinate of the image and its rotation, neither of which should be affected by the parity of the images, and these three great circles should intersect (or roughly intersect, accounting for error) at two points corresponding to +90 and -90 degrees declination. That's not to say that mirrored images definitively aren't to blame, simply that there's no practical reason why the system wouldn't be able to handle them, as far as I can tell.

Greg,

Thanks for chiming in. I read through your posts and am a little more puzzled. I have no diagonals in my setup. The image parity is negative, but parity or orientation shouldn't matter. One possibility is that the software makes an assumption of what hemisphere I'm in - I'm north, but if the software assumes south, then the difference in vector direction makes sense.

jmh

Actually, I got an email before from a user in the southern hemisphere saying the correction vector was opposite, so I disabled any modifications for south hemisphere. Maybe I just got them switched? Need to look again.

Edit: never mind, the email was about rotation direction of mount in the rotation phase and not about correction vector.

jmh recently wrote:

> I read through [Greg's] posts and am a little more puzzled. I have no diagonals in my setup.

I see...then, no reflections, or an even number of reflections?

> The image parity is negative, but parity or orientation shouldn't matter.

I quite agree. And to re-state, there is no problem I can see with solving or
astrometry.net, which seems to be able to solve no matter the parity or
orientation; and the calculated *positions* are correct.

What I question (only from experiment, not from knowledge of the code),
is the calculation of the correction vector.

> One possibility is that the software makes an assumption of what hemisphere I'm in -
> I'm north, but if the software assumes south, then the difference in vector direction
> makes sense.

I hope a developer can determine what's going on, *if* anything is going on.
My *guess* would be that the calculation of the correction vector *may* be off
under certain circumstances. (?)

Greg

I only just now came across this post. I had observed the same problem a couple of months ago. Polar alignment got progressively worse with each run of the alignment module.
At the time I thought I was doing something wrong, so I went back to polar aligning with my polar scope, which works very well at up to 300s exposures at 1600mm with perfectly round stars, so I am obviously getting very close to the NCP.
Haven't gone back to using the polar alignment module since, but would very much like to as soon as this has been fixed. I believe I was using the nightly Ekos build at the time.

What was your setup exactly? main scope pr guide scope?

Mount: iOptron SmartEQPro+
Imaging scope: WO-Z61 (not used for alignment)
Guidescope: Orion miniguide scope (30mm/130mm) (not used for alignment)
Polemaster: camera mounted in polar alignment scope tunnel, in the rotational axis of the mount (used for alignment to eliminate deviations caused by flexure)

I saw exactly what was described by Gonzo: With every iteration of the alignment procedure, my deviation approximately doubled.

I then tried it again using my imaging scope. Results were the same. Deviation doubled with each iteration and it made no difference whether the mount was rotating clockwise or counterclockwise (i.e. East or West)