Polar Alignment 4.1 64 bit bug

[SC_Astro]

Sharpcap 4.1 64 bit
AVX mount, asi120mm, Windows 11
Experienced user of Pro version for many years. Polar alignment has always worked flawlessly. I always first use a laser pointer to get mount very close to Polaris. Last night first time with 4.1 release. Polar alignment solved quickly, I pressed Next and rotated mount as usual. solution came back with large difference to correct (several degrees). This was strange but Ok I will continue. The real issue started when I stated adjusting the altitude. When making large adjustment the PA routine would solve and only reduce the required correction by a small amount. This is contrary to my experience. but I adjusted again and could clearly see visually that the mount was no longer pointing anywhere near Polaris. But PA was solving and reducing the needed adjustment but only by a very small amount. I then stopped and changed to 4.0 version and PA worked quickly and accurately as expected.

I experienced this before when I download a 4.1 beta version but did not report since it was such a serious issue figuring that it was being worked on. Sorry.

Randy Cockrill

[admin]

Hi Randy,

sorry to hear it misbehaved for you. This isn't something I had expected as I have deliberately waited about 6 months after the initial release of SharpCap 4.1 before sending out the auto-update invite to 4.0 users recently... The idea was that any serious problems should have surfaced and been reported and fixed in that time. Nothing like this has come up so far, and I was using polar alignment quite happily about a week ago, so I suspect that there is something unusual going on causing the issue that doesn't crop up often.

I have taken a look through the log file extract that you helpfully included. Unfortunately it looks like that is the log from your SharpCap 4.0 run - the plate solving data in the log all looks fine and the first measurement for adjustment is recorded as being about 0.25 degrees or so.

The log from 4.1 would definitely be helpful, but the most useful thing to help track this down would be a series of snapshot images captured as you work through the alignment in 4.1. Capture 1 image using the snapshot button before rotating the mount, and another when you have finished rotating, then 2 or 3 during the adjustment process. With those images I can pretty much recreate the alignment session in one of the test cameras and see if I get similar results.

thanks,

Robin

[SC_Astro]

Robin
Thanks for the quick reply. Sorry for the wrong log. This log looks like the correct one.
Is there maybe a default setting that has to be changed? I just used the default settings.
Thanks again
Randy

[admin]

Hi Randy,

thanks for sending over the correct log so quickly. That reveals that the very likely cause of the issue was a bad plate solve on the image once the mount had been rotated. From the log

Code: Select all

Info   	20:32:52.993482	#17	First frame solved : Solved=True, Pos=RA=13:54:57.1,Dec=+89:23:58, ViewRotation=-174.75905, SecPerPixel=2.70, Stars=15 of 28 in 107ms	
Info   	20:32:58.087274	#17	Final First Frame : Solved=True, Pos=RA=13:54:51.8,Dec=+89:23:53, ViewRotation=-174.70538, SecPerPixel=2.69, Stars=15 of 28 in 7ms	
Warning	20:33:07.200403	#17	Not enough stars detected - found 2, but need at least 5 to plate solve
Info   	20:33:10.250278	#17	Second Frame Data : Solved=True, Pos=RA=16:43:39.1,Dec=+86:55:59, ViewRotation=117.13496, SecPerPixel=2.69, Stars=15 of 23 in 12ms
Info   	20:33:10.250608	#17	Rotation now 68.099434, center is {X=3654.803, Y=1486.6018}	
Info   	20:33:10.339298	#17	Adjustment frame : Solved=True, Pos=RA=13:54:51.8,Dec=+89:23:53, ViewRotation=-174.70538, SecPerPixel=2.69, Stars=15 of 23 in 12ms	

You can see that the first frame (pre rotation) solved at Dec=+89:23:50ish, and the first adjustment frame on the last line of the log solved at that declination too, but the 'Second position' frame solved at Dec=+86:55:59 - very different.

It's also odd that the view rotation for the adjustment frames goes back to the orientation of the initial frames (about -174). That would imply that the mount was rotated back to the original orientation for adjustment, which is surely not right.

The explanation that seems to fit best without being unrealistic would be that you have auto advance switched on for polar alignment and that you got unlucky with a bad plate solve result occurring during the alignment procedure. This bad result not only tricked auto-advance into proceeding to the next stages, it also meant that bad data was being used to calculate the offset needed, leading to the poor results.

The actual polar alignment code hasn't changed significantly between 4.0 and 4.1 with the exception of adding the GOTO movement buttons (I just checked this afternoon). However, the code to do the plate solving for polar alignment has changed to help support the new general purpose 'SharpSolve' plate solving engine in SharpCap 4.1, so that could have changed things a bit. Also star detection has been tweaked.

I would suggest trying again when you get an opportunity. If it was just a random glitch then it won't repeat (or not frequently anyway). If it does seem to happen every time then you can grab the snapshot frames as I mentioned above and I will be able to dig into the problem and work out why it is happening. I will consider requiring 3 or 4 frames in a row to all give the same plate solving result before accepting them - that would make any random glitches in plate solving much less likely to affect the final result.

cheers,

Robin

[SC_Astro]

Robin
I will try another test of it when our weather clears. I checked and the box for Auto Advance is not checked.
Also, this is actually the third time this has happened. Twice with beta version plus last night.

Since no one else is commenting that this is as an issue I don’t know what to say. If there is anything I can do to get more logging points please let me know.

Thanks for your help.
Randy

[carlomuccini]

If it could be useful ...

Just the day before last I carried out the polar alignment of my Celestron CGX-L mount as several months had passed since the last alignment.
I used manual advance and everything worked perfectly
Version 11 March 2024

Carlo

[SC_Astro]

Carlo
Thanks for your suggestion. I will try moving the mount with the controller although I have never had to do that before. Now I just need to clear out the clouds !

Randy

[SC_Astro]

I would like to give a wrap up on this issue.

I devoted last night to testing 4.1.11711 PA in all ways I could think of. I could never get it to work as it should. When I adjust Alt as recommended, Alt would move slightly but Az would move by a large amount. And vice-versa. Eventually it had me adjusting outside the PA routine’s FOV. And the process would stop.

I finally gave up and downloaded v4.1.11961 32 bit. It worked perfectly the first time and every time.

Maybe it was the 64 bit version that was the issue. I never tested 4.1.11711 32 bit. In any case I think I will stay away from the 64 but versions in the future.

Off subject. Robin if you are reading this BRAVO ! on the new Sharpcap Plate Solving routine. It is amazingly fast and accurate. Thanks so much !

[admin]

Hi,

well, it's good to hear the the latest version worked fine for you, but I am still puzzled about why 4.1.11711 would misbehave - I just checked the code changes between the two versions and there doesn't seem to be anything relevant to polar alignment results...

The only thing that does come to mind is that if SharpCap has the wrong time or lat/long information then the up/down/left/right movement directions would be wrong - the arrow to move the star into the target would still be fine, but it might suggest up when you should really move right or similar. However, I still don't see how that would be different between the two versions or between 32 and 64 bit

Glad to hear that the new plate solving tool is working nicely for you. I had been meaning to try to create one for some time, but had to leave it on hold until I had finished the documentation update for 4.1 or the documentation might have never been done!

cheers,

Robin