Polar Alignment via Platesolving

[Jean-Francois]

Hello,

And ? Do we have at least 20 people ?

I have a test version of my script ... Who is interested to try it ?


Jean-Francois

[akjudge]

I'm still in (can I vote twice?).

I'm a novice so testing the script with me is probably not the best idea. Besides I live next to Lake Erie, so my weather won't be clear for at least another month,

Once you get the beta working I would love to try it out == having a novice try to use it may be enlightening.

See my previous comment -- If I can't figure out a way to Polar Align in SharpCap, I'll be forced to learn another software (N.I.N.A).

Good luck with your script

Jim

[Jean-Francois]

Hello,

I hope that the waiting will be worth it ... I have a working script (at least the direct script, but not the "menu" version).

Here the script and a configuration file.
Copy it somewhere on your computer where you have the right to modify the file.

SASPA_Beta-Test.zip

(11.35 KiB) Downloaded 5 times

Start SharpCap and connect your camera and your mount (if motorised and connected to the computer).
Open the IronPython script console and load the script. Then start the script when you want to start the Polar Alignment.
The script name SASPA is for SharpCap All Sky Polar Alignment (I know not the best name).

Here a short description ...

SASPA_doc_1.png (68.49 KiB) Viewed 493 times

The script can be used with a full motorised mount with all the movements done automatically.
Or it can be used manually ... with the hand controller or with a movement with the hand.

Very important : the script uses the ASCOM MoveAxis function.
The mount stops only if it receives a command to stop. So use my script only with a wire connection.
Do not use a wireless connection !!

A) Check your Plate Solve (ideally the SharpSolve from SharpCap with the Ultra Hi-Res index ... need a preliminary download)
B) Set/change your location in the Settings window with the button [...]
C) Select one side for the image capture
D) Change if you want the starting position and set more images (3 is the minimum)

One word concerning the "Limit" value:
That is the limit before or after the meridian where the mount will stop.
Negative : the mount stops before the meridian, positive: the mount stops after the meridian.
With a value of -10 ... the mount will stop 10° before the meridian.
Note: take care of your mount physical limit and other software limits.
The MoveAxis function does not follow the rule of the GOTO command from the mount driver. => risk of collision.


Maybe the maximum mount rate is not correct. You can tune the RA axis movement with the "RA scaling" parameter from the Settings window [...].
Do the first time the following test ... set the start position to the East Point (Alt = 0, Az = 90), 3 images and the Limit = 0.
The counterweight bar is vertical at the start position and should be horizontal at the end point.
If the bar is not horizontal (+/- few degree), then you can change the "RA scaling" value, with < 1.0, if the mount is slower as expected.
If the mount is slower as expected, change the value to 0.9 and restart the measurement.


I did in the past weeks ... hundred of tests ... but only with the ASCOM Sky Simulator !!
It was never good weather synchronised with my presence at home.

The script can be used manually ...
- with the mount hand controller or SharpCap keypad
- with opening the RA clutch and rotate the mount manually on a new position
For this ... select first the "Manual" button and click on "New Position" for saving (and Plate Solve) a new position.
After a minimum of 3 points, click on "Calculate" for the calculation of the polar alignment errors.
Click on "Stop" for stopping the script or before starting a new measurement.

Here an example:

SASPA_doc_2.png (76.85 KiB) Viewed 493 times

The alignment in Altitude and Azimut of the mount are in degrees.
Do not try to have 0.0001 ... that will be only 0.36 arcsec. One arcminute is 0.0166 degree.

If you do the measurement points manually, is is important that the starting point is near the East or West point and that the end point is near the meridian.


Regards,
Jean-Francois

[Jean-Francois]

Hello,

I remark a problem after the calculation of the alignment error.
The first values are OK, but after some times, they change to zero ... that is not correct.
I will try to find quickly the reason ... older version of my script were doing the calculation correctly.

You can still test it ... at least the first part of the script.
One critical point is the good timing of the image capture and the Plate Solve.

Jean-Francois

[admin]

Hi Jean-Francois,

thanks for implementing this and sharing

It's a shame for this approach that the meridian flip is necessary, since you could get a longer measurement baseline (and possibly a better fit/more accuracy/more resiliance to noise) if you could measure all across the southern sky (or the northen sky for our SH observers). In theory, you might be able to collect points from both sides or the meridian by allowing an extra parameter for your best fit - a constant offset applied to all the points on one side of the meridian. Whether more points/angle range will be enough to compensate for the extra fitted parameter, I'm not sure.

Are you providing guidance on the adjustment too, or is it just measurement at the moment?

cheers,

Robin

[Jean-Francois]

Hello Robin,

Only the people using a fork mount or a German mount with sufficient free room can move "over" the meridian.
One limitation with a mount is the internal cabling. With these mount, a hard stop is limiting the maximum rotation of the axis.
On my EQ8 mount, it is around 30° (I do not know the exact value) past the meridian.

I tested the full arc with the Sky Simulator and the GSS Simulator ... it is nice .. here with 3 different arc length (no polar mis-alignment):
If the measurement points are symmetric around the meridian, the azimuth error can be precisely measured.
Note the first is measured at DEC = 0°, the other near 2° an 5°. The "larger" deviation on the first graphic is coming from the difference of the air refraction between the Sky Simulator and the ASCOM functions (and maybe the difference of the air conditions).

SASPA_doc_4.png (45.27 KiB) Viewed 464 times

For the Polar Alignment error ... here other tests with 1° in Alt or Az and with 5 arcmin:

SASPA_doc_5.png (46.36 KiB) Viewed 464 times

My script uses the last measurement point for the alignment step.
So it is better to have it near the meridian for the maximum visible effect during the alignment process.
If the end point is exactly at the East point, then no Alt-alignment can be detected.

It is my idea to upgrade my script for any new point after the measurement sequence ... so it will be good for the people using a fork mount.
The mount will be moving near the meridian (or other predefined position, ideally near the meridian)

For the other German mounts with angle limitation past meridian ... it will be the second upgrade for performing the measurement on both side of the pier.
For the mathematic ... I do not used extern mathematic library ... I wrote a linear fit of the non-linear function thank the trigonometric equation of a*cos(x+b) + c = A*cos(x) + B*sin(x) + C ... the A and B are the linear fit of the non-linear a*cos(x+b) + c function.


Concerning the guidance ... yes, it should show the value to the best alignment (similar to your Polar Alignment tool).
Today only the numerical value ... later with some graphic on the live image.
But now I remarked after uploading the ZIP file, that the last version I modified does not do the correct calculation of the adjustment value.
I will dig the difference between my last version and one preceding version.

One problem of my script is ... the "menu" version (for loading the script during the start of SharpCap) does not work ... it freezes SharpCap.
I tried to call some functions in a separate thread ... but without success until now.

Best regards,
Jean-Francois

[admin]

Hi Jean-Francois,

I will have a look at the menu version to see if I can work out why it is getting stuck and give some advice. When a script responds to a menu press (or a button click in a custom form) then you have to be more careful than usual because the script code ends up running on the user-interface thread, and that makes it much easier to end up with a deadlock.

I had all sorts of gremlins in the early versions of the code for the rotation based alignment - in fact, I think the version of that code in SharpCap 2.9 had a bug that meant that it got you moving in the right direction, but didn't fully correct for the polar alignment offset, meaning that it would always help you improve polar alignment, but needed to be run several times to actually get the alignment error down to a very small value...

cheers,

Robin

[admin]

Hi,

OK, I think the biggest issue for SharpCap stopping responding is the use of time.sleep(), particularly in while loops. If that python code ends up running in the UI thread then the UI will stop responding until the while loop completes. However, maybe the while loop is waiting for some status change from SharpCap, which might require the UI thread to process some data to let the status change, in which case you end up fully deadlocked.

For now, the best thing to do is to replace the python sleep with something like...

Code: Select all

from SharpCap.Base import UIBase

# untested - just to indicate the idea
def mysleep(seconds):
	timeout = time.time() + seconds
	while time.time() < timeout:
		sleep(0.05)
		UIBase.DoWindowsEvents()

This lets the UI remain responsive while you are sleeping if you end up sleeping on the UI thread (and it will behave just like normal sleep with a bit more CPU usage on a background thread). I will also add a SharpCap.ScriptingWait(seconds) function to the API that basically implements the above for the next update (but the code above can be used now).

After I'd tweaked the looped sleep steps myself, I ran through the process with sky simulator and had a couple of odd things happen...

1) I think it took two measurements at the same place because the image hadn't updated from sky simulator quickly enough after the slew completed. That gave only two data points, which then gave a wonderful sinusoid fit with no evidence to support it! Perhaps worth checking that the plate solve results are fairly close to the mount co-ordinates and trying capture/solve again if not?

Screenshot 2026-04-14 140404.png (36.89 KiB) Viewed 447 times

2) An error that showed when I closed the window - maybe the NowJ2000 value from the plate solve call is None?

Code: Select all

Info   	14:05:07.139990	#1 	MessageBox : 'Scripting Error Detected' It looks like an error occurred that may have been caused by one of your SharpCap python scripts.

The error was : Object reference not set to an instance of an object..

Traceback (most recent call last):
  File "<string>", line 781, in Start
  File "<string>", line 910, in Calculate_PA
  File "<string>", line 1037, in ShowDifference
  File "<string>", line 934, in AlignmentStep
SystemError: Object reference not set to an instance of an object.

cheers,

Robin

[Jean-Francois]

Hello Robin,

Many thanks for looking at my script.

Concerning the error message ...
I have the message "Object reference not set to an instance of an object" too when I close the script window with the "X" too early.
I was first thinking to solve the calculation problem ... I need to improve the function "BeforeClosing()" for a clean stop any movement or other functions.

For the right timing for the Plate Solve. Yes, it happens that with the Sky Simulator the image is not actualised after the end of the movement.
With the Sky Simulator ... you have 2 layer ... the Sky Simulator that generates a new image after detecting that the mount is moved and the camera simulator in SharpCap that load the image and modify it with the gain/exposure settings.
For the real imaging with a camera and the real sky ... it will be a new image every time.

In my script the functions CaptureFrameHandler() and WaitNewImage() are trying to do something after a new image is showed (also "BeforeFrameDisplay"). It exists certainly a better way to do the same thing.

Concerning the sleep() function ...
Yes, I have several time a sleep() function in a while loop, one in the function WaitNewimage().
I tried to use some Thread.xxx function but it was not a success.

Thanks for the "mysleep()" function. But which "sleep()" is to use ? ... a "sleep()" is not known, but a time.sleep().
I changed it to time.sleep() ... but the new function should replace the time.sleep() ... but it use it ??
Or shall I use the thread.sleep(milliseconds) ?

For the Plate Solve result check ... it could be possible to add it, but it means that a mount is connected
I try to write my script for the use without the connection, for example before the mount is powered ... it could be possible to perform the polar alignment manually. I will try during the next weekend (if clear sky) to use my script with a real camera under a real sky ... that will be the first time !

Regards,
Jean-Francois

[admin]

Hi,

time.sleep() or thread.sleep() doesn't really matter in the context of the mysleep function - they both are pretty similar in how they work and the important bit is to sleep for a short period then process windows messages. I think I had a 'from time import sleep', which made a simple 'sleep()' work.

Although sky simulator introduces its own special type of image delay, I suspect in real use you will have to account for things like the first image to arrive after a slew containing trailed stars and similar effects (or the good old favourite for QHY cameras in live mode of the extra buffered frame). Star trailing will likely cause the plate solve to fail as the lines will not be detected as stars if they are long enough.

The BeforeFrameDisplay event is the recommended way to be notified that a new image is being shown (you can also use the FrameCaptured event for notification when a new image arrives from the camera as opposed to when it makes it to the display). Another thing is just to rely on the plate solving to do that for you - it should wait for the next frame to be captured internally and then solve and then return (exception: I think it may use the existing image if there is no connected mount or if the mount has been stationary for longer than the exposure time).

I see you have some handling for SharpCap in still mode in your script - to fully support that you will need to trigger the actual exposures using SharpCap.SelectedCamera.BeginFramingShot()

cheers,

Robin