That is interesting! Because, thinking back, that's also what I did when I experienced the same problem a couple of months ago.

I first aligned West, got a decent alignment, and then thought I better check it by rotating East. That was not with the polemaster, though, but with my guide scope (which includes the NCP in the image, my imaging scope doesn't).

I wonder whether the problem is not in the PA module, but in the fact that there might be excessive flexure in my setup, which, of course, would double the deviation when aligning on the other side of pier.

Along the same lines, I aligned using the PA module and my guide scope last night (but only to the West) and got field rotation with 5 min exposures, although the alignment was as perfect as it gets (13"). That has never happened to me before when I aligned using the polar scope.

The good news is, the polemaster should get rid of that problem for you, provided you mount it in the polar scope tunnel, i.e. aligned with the rotational axis of the scope and without a possibility of flexure.

(The Zip tie rig you showed earlier probably won't fulfil this criterion).

Thanks for opening this thread, I may well have found out why I had the identical problem.

The problem that follows, provided I am correct, is that your 3' alignment may still result in excessive star trailing, because, well, it's not a 3' misalignment, but more like 29' misalignment (~58'/2).

Any mistake in that logic, please let me know! Clear nights are too precious to waste.

Merry X-mas!

Jo

Thanks Jo, never underestimate the holding powers of a ziptie !!! lol
I can assure you that the camera does not move and this was done as a test only.
My Atik 314+ is dead and I wanted to test / help with the PAA issue.

I'm doing some research on the Polemaster and it would appear that you can use a QHY5L-II-C or M with a 25mm lense, it's the same thing.
But the Polemaster as such cannot be used as a guider, and I would like to replace my super old QHY5 (original big red one). So more reading is needed....

The advantage of the pole master is that it comes with adapters that really bolt it down in the tunnel and that there is no chance that gravity can move it during mount rotation. Otherwise, any other camera with a lens that encompasses about 5 deg around the NCP should do it.

I'll test that when the weather clears up again.

Bonne chance!

Jo

Ok folks, I spent the last two days dabbling at this problem once again. From the logs submitted by Stephane, it appears issuing a GOTO where only the RA value is different can still cause a slight GOTO in DEC. This is probably due to the mount alignment and also due to round off errors. At any rate, I completely abandoned GOTO and instead went with the simple Go West, and Go East controls.

Since these are open ended controls, now Ekos starts moving the mount until the RA is reasonably close to the target then it stops.

Another thing I noted repeatedly is that it is impossible to have the reading from Park --> West match with West --> Park (going East). They're always different perhaps to flexure and perhaps other factors I'm not aware of. But if I repeat the Park --> West, then the results are fairly consistent, if not exactly identical. There is always random error which I estimate to be < 60" that affects the result.

Next, I found that the rotation angles must be between 30-40 degrees to get good reliable results. I tested with 15 degrees and the results were terrible and inaccurate.

All updated are now in GIT. Start from a PARKED mount at the home position (weights down, looking at celestial pole). Ekos should unpark the mount for you once you start the process. After it captures the 3rd image, you do the usual correction, then after you click done, Ekos will park the mount again. After it is parked, you can restart the process and check the error again.

Please test and let me know how it goes. Tomorrow's nightly should reflect these changes.

Hello Jasem (and all),

I finally got some clear skies and a chance to try this experiment again.
It looks as if the Polar Alignment Assistant has gone through a couple
of revisions since I used it last (I get the nightly builds).

Unfortunately, it seems something has gone amiss in the meantime
with plate solving when used with polar alignment (just random
plate solving seems to work fine). Anyway, I homed the Mach1 mount,
started the process, and the first 10-second image was taken and solved
within two seconds.

The mount then rotated west 30 degrees, and another image
was taken (it displayed correctly). The solver started, but then
timed out after 180 seconds. After several tries, I aborted the process.
Unfortunately, the mount seemed to have lost its place at that point,
so I had to begin all over again.

Since I had been using the solver locally, I switched to the online
solver at astrometry.net. The result was the same -- the solve near
the pole happened quite quickly, and the westward slew took place.
The second solve then timed out. After several tries, I aborted the
process, and of course had to start over since the mount seemed
to have lost its place, that is, the current coordinates did not match
the actual pointing position of the OTA. My guess was that
incorrect coordinates were being sent to the solver, i.e.,
after the slew, the scope coordinates were not updated, or
were calculated incorrectly.

I tried again from the beginning with an eastward rotation,
but got exactly the same result, i.e., the second solve never
succeeds.

I don't know if this behavior is peculiar to the Mach1/Astro-Physics
Experimental combination, or is more generally a fault, since
others are getting beyond this point with their mounts. Perhaps in
a couple of days (when the skies clear and I have the opportunity)
I will try again, this time with some logging turned on, and I will
examine/submit the logs to see if they contain a clue as to what
is going on.

Greg

Greg. Thanks for testing. Yes. it _could_ be related to the mount. Do this. From the mount control panel or INDI control panel, go EAST. Watch RA, does it increase or decrease? Try West, watch RA again, increases or decreases? The updated PAA uses pure EAST/WEST motion now to move the mount. Before it was using GOTO but that appears to move the mount slightly in DEC along the way which affected the process.

So believe perform the above and report back the results.

Hello Jasem,

If I understand the task correctly, his was an easy "indoor"
test to conduct, so I just set up the mount, connected, and
made sure that I could "park" it in the homed position
(A-P calls this "park 3", which is the typical position of
counterweights down, pointed to the north pole). For my
location and time, this currently gave an RA reading of
02:57:19 (DEC 89:57:06).

I then brought up the Mount Control dialog and "un-parked"
the mount. Since it was not tracking, this started the RA
to increase each second by about a second.

I then clicked and held the "west" button for about three
seconds at 600x. This gave me an RA of about 02:28:41
(decreasing, as you would expect for the westerly direction).
This also started tracking.

I then pressed the "east" button for about six seconds at
600x. This gave me an RA of about 03:19:11 (increasing,
as you would expect for the easterly direction).

The declination did not change during these tests.

Unfortunately, I will probably not have clear skies to test
and collect logs under the stars for about three days (also
will miss the lunar eclipse tonight, if the forecast is accurate. ).

Greg

Hello again,

I don't know if this is significant at all, but I noticed when using
the Mount Control that when the mount is "un-parked", the
tracking status indicator in both the mount control ("Status: Tracking")
and the Ekos mount screen (square tracking "ON" and "OFF" buttons)
indicate that the mount is tracking, when in fact it is not. The motors
remain off after the un-park, and the RA indicator continues to climb,
as it does when tracking is off (which it in fact is).

If I do a mount motion (in this case, pressing the east or west buttons
on the Mount Control), then tracking is *truly* engaged, and the
previous two indicators are unchanged, and have suddenly become
correct. But they are *incorrect* immediately after the un-park
operation.

Greg

Hello yet again,

I recently wrote:

> I don't know if this is significant at all, but I noticed when using
> the Mount Control that when the mount is "un-parked", the
> tracking status indicator in both the mount control ("Status: Tracking")
> and the Ekos mount screen (square tracking "ON" and "OFF" buttons)
> indicate that the mount is tracking, when in fact it is not. The motors
> remain off after the un-park, and the RA indicator continues to climb,
> as it does when tracking is off (which in fact it is).

After several tries of this, I noticed that the indicator on the mount
control does indeed go to the correct status ("Idle") for a brief moment
after the un-park is complete, before incorrectly going to "Tracking".

Curious.

All this perusal, of course, in the hope that (perhaps) because tracking
is not engaged after the park, then the RA is not being universally
updated after the "go west" or "go east" commands -- a completely
uninformed hypothesis.

I suppose I could test this by doing a *very* slight jog with the mount
control before engaging the Polar Alignment routine -- is that even
worth trying? (I'm obviously desperate for a solution )

Greg

I fixed an issue this week that was accepted that will fix the problem with the lx200ap_experimental driver not properly showing tracking enabled after the mount is unparked from a POWER OFF state.

What seems to be still not quite right is if you PARK the mount and do not power it off and then UNPARK the mount. In this case the INDI driver has requested tracking to restart but the mount firmware seems to not actually do this. Instead it seems to wait until the first move is requested of the mount and then it starts tracking.

I couldn't find anything in the protocol documentation from AP. When I have a chance I will have to get in touch with them and see if there is a clarification of what is going on here.

Continuing all,

I recently wrote:

> I suppose I could test this by doing a *very* slight jog with the mount
> control before engaging the Polar Alignment routine -- is that even
> worth trying? (I'm obviously desperate for a solution )

Well, I tried it last night, and -- it worked! I actually got quite a good
polar alignment (less than one arcminute from the pole) using the
westerly rotation and the non-diagonal (i.e., non-ONAG) parity of
the downloaded image. Testing the "flipped" parity case will have to
wait for another night.

Now, there was a nightly-build update in-between the time I wrote
the original problem statement and the test, so I can't say if something
changed in the driver, or if it was my tiny jog that did it. I ran out of
time for testing, otherwise I would have verified that.

Thanks to all who put some thought into this feature. I will post
further test results when I can (now that I *can* test it!).

Greg

Hey,

after experiencing problems while testing the polar assistant with the new manual slew feature I experimented quite a while yesterday.
Finally after reading this thread it occurred to me to check the orientation of the image on my sensor. Indeed (presumably due to the flattener I use) the image is upright.
When I switched on parity detection in the astrometry options it started to work and I got below one ' polar alignment accuracy with the star adventurer (the polar scope gives me typically 3.5' accuracy).

It might be a good idea to highlight the parity switch. Maybe a new tutorial would be worth it.

Cheers, Sebastian